How to use a network path for Dropbox’ content folder

Dropbox puts its application data in %APPDATA%\Dropbox. “APPDATA” is an environment variable (the % prefix and suffix tells us APPDATA should be treated as an environment variable and not as a literal string), typically referring to SYSTEMDRIVE:\Users\USER\AppData\Roaming (capitalized words should be replaced, for example SYSTEMDRIVE is typically “C”). This folder contains applications’ roaming application data, which is data that gets a special meaning when used with roaming profiles: their roaming parts are copied from (at logon) and to (at logoff) a profile server, which is a centralized place for storing user profiles. Anyway, the Dropbox folder mentioned is used for storing Dropbox configuration settings.

When you configure your Dropbox account a second Dropbox folder is created, this time meant for Dropbox content related to your Dropbox account. This folder is located by default at %USERPROFILE%\Dropbox. Just like APPDATA, USERPROFILE is an environment variable, typically referring to SYSTEMDRIVE:\Users\USER (capitalized words should be replaced, for example SYSTEMDRIVE is typically “C”). By default this folder belongs to the roaming part of a profile. You can change this folder location through the Dropbox GUI: right-click the Dropbox icon in the notification area, select Preferences and click on the Advanced button. There, in the section “Dropbox location”, you can change the folder where to put the real Dropbox content; not only do you change the folder, possibly previous content is moved (not just copied!) to the new location too. Changing this location can be useful for a number of reasons: perhaps you want to be able to access this folder very quickly through Windows Explorer (for example, by browsing to C:\Dropbox instead of SYSTEMDRIVE:\Users\USER\Dropbox) or perhaps you want to exclude this piece of data from the roaming part of a profile because logon and logoff with roaming profiles is too slow because of the huge size this data has? You may not forget that this content includes the Dropbox cache, which can be many, many gigabytes!

In the case we want to exclude Dropbox content from the roaming part of a user profile we actually have a few different options:
• Make the folder “local”: through group policy we can exclude some folders from the roaming part of a folder. Logon and logoff will become faster and the Dropbox content just stays on the system and isn’t synced with the profile’s central copy at the profile server.
• Move the folder through the Dropbox GUI to a location under a local folder (for example %USERPROFILE%\AppData\Local, which is excluded from the roaming part of a profile by default). This has the same result as the previous option, but is achieved through another way.

Both options lead to new problems:
• What if user profiles are deleted at the system after logoff? In many environments where roaming profiles are used the local copy of the profile is deleted after logoff to save disk space and/or to minimize merging issues when the user logs on again (merging happens between the cached version and the version at the profile server). In such a scenario the Dropbox content is deleted too, which means a lot of content should be downloaded again instead of reused from the Dropbox cache. In some cases this is okay (for example, with very high speed network links that are far from saturated it could be acceptable), in other cases it isn’t…
• Even if the content isn’t deleted, what happens if a user works on different systems (for example a Terminal Server (TS) farm, now called a Remote Desktop Session Host (RDSH) environment)? The cache is saved locally on system 1, so after logon to system 2, the cache isn’t there anymore. With other words, sometimes a central location is necessary for the Dropbox content, even while that content doesn’t belong to the roaming part of a profile.

What I want to make clear is that in some scenarios (and they are more common than you might think) there is a need to keep the Dropbox content, put it somewhere central, but not in the user profile. There are many possible reasons for this: you want to keep Dropbox content of one or more (or even all) users on a NAS, you work in a Terminal Server farm, your local disks haven’t enough free disk space left (one Dropbox cache can take in many, many gigabytes, don’t forget this!),… The answer is simple: change the Dropbox content location to a network path.

Simple? The problem is Dropbox doesn’t want you to change the location to a network folder, like \\SERVER\SHARE or \\DOMAIN\SHARE. If you think you’re smart by mapping a network drive letter to this path and use the drive letter in Dropbox, forget it! Dropbox sees the drive letter is mapped to a network “medium”. Dropbox shows the error “Target folder is on network media” in a message box titled “Error with selected folder” (see picture below).

I’ve searched the Net to find a solution or workaround, but nada! So I had to find out myself, right? Well, what if we fool Dropbox? Here’s the procedure:
1) Choose a still available drive letter you would use to map to a network path. For example, we could refer to \\SERVER\SHARE with the drive letter H. Don’t enforce the mapping yet, just choose the drive letter for now. If the network path is already assigned to a drive letter (for example, H), unmap and choose that drive letter.
2) Assign H to a local formatted partition. You probably have to add a new disk to do this. If you have a virtual machine (VM) you would simply add another hard disk, let Windows rescan the available hard disks, make the disk online, initialize the disk, create a partition and format it. Then you assign H to the drive.
3) Start Dropbox and configure the new location, for example H:\.
4) Dropbox creates the folder “Dropbox” under H:\ and moves already available content to this new location.
5) Shut down Dropbox.
6) Move the Dropbox folder to your network path. Now we have \\SERVER\SHARE\Dropbox and beneath it the Dropbox content.
7) Make the disk offline. H doesn’t exist anymore now.
8) Map H to \\SERVER\SHARE.
9) Start Dropbox. Dropbox won’t check if H is a network drive anymore.
The thing is Dropbox only checks if the location is a network drive at the moment you change the location. Now you can use Dropbox with your network path!

It’s obvious this isn’t a real and supported solution. It’s just a workaround, using a small hole in Dropbox’ defense we exploit. Be aware there could be one or more reasons why Dropbox doesn’t like network paths for its content, although I don’t think the absence of the drive letter is a big issue: if we unmap the drive letter and start Dropbox we just get the following message, so we shouldn’t loose any data.

The bottom line is Dropbox doesn’t seem to like network paths and doesn’t allow them. There is a way to fool Dropbox though, as just explained. Different reasons to do this exist, one of them being a TS/RDSH farm scenario where normally roaming user profiles are used. I must admit the workaround cannot be automated easily: you probably have to execute the procedure for every user… So if you have to do this for hundreds or thousands of users, well, good luck! It’s doable for a few dozens of users, but still… For a few users this workaround is very manageable though. Sorry for those with many Dropbox users, but I guess this workaround is better than nothing, right?

Pedro