If you use XenApp or even just Remote Desktop Session Host you probably use roaming profiles and also Group Policy to redirect various folders out of the folder and onto fixed network locations. I’m currently designing/implementing a new Server 2008 R2 and XenApp 6 system that will primarily be providing full desktops, though this would be just as much a problem if you only published individual applications.
Tried to redirect the Downloads folder? Then tried to get IE to download something to it? Failed miserably?
Redirecting the folder is easy, you can even do it yourself through the Windows GUI. Find the actual Downloads folder (not the shortcut to it in the Explorer Favorites bar). It defaults to the root of the user profile, so probably C:\Users\<your username>. Right-click the Downloads folder (it’ll have a blue “down” arrow on it), choose Properties, go to the Location tab, Click Move… and pick where you want it to go.
Now, you might be lucky and this might work, or it might look like it’s worked… Either way it’ll redirect and if you click the Explorer favorite link to Downloads you’ll be taken to the new location. You’ll probably be able to write files/folders to it. But now try and test it for what it was put there for – downloads from Internet Explorer. Find a link to a file or something you might want to download, right-click and choose Save Target As… pick the Downloads folder from the Save As dialogue’s Favorites, click the Save button. This is where you find out if it’s your lucky day or not. If the files saves first time you’re ok. If the Save As dialogue flicks away then opens again a split second later – oh dear – not your day is it?
Now, I should point out that as I’m putting in a new system I’m using the latest version of IE, currently version 9, with all the latest updates as of time of writing (at the end of the automated server build process I run a loop of “WUInstall, reboot” repeatedly until WUInstall returns a code 2 – no more updates found to install). So this may be a problem with IE9. Windows itself will let you write to the folder quite happily.
So, how do you fix this annoyance? Give the users Full Control on the share permissions. Doesn’t matter if they still only have Modify on the NTFS permissions. Wierd huh? Took a lot of testing to whittle it down to this, but there you go.