UPDATE:  I’ve revised this to cover the “This security ID may not be assigned as the owner of this object” error that is commonly seen when configuring folder redirection.

One challenge you may run into in an SBS 2008 migration is Folder Redirection.  The migration document makes it very clear that if your client PCs have been configured for folder redirection, you must make sure your users log in while both servers are connected to the network.

Sometimes, this may not be possible.  The migration period is for 21 days at most.  SATV, like other businesses, has a number of part-time or contract workers that may have access to our IT, like a webmaster, an accountant or an engineer.  They may come in just once a month, or for just a few weeks around the end of the fiscal year.

Any way it’s expressed, you probably do have users that aren’t logged on during the migration period, and won’t be aware of anything different until you tell them the next time they’re there.

Or they get errors like the one above.

There have been problems with folder redirection in Windows XP SP3, as explained in several threads on the TechNet forums,  "GP error with folder redirections (ids 107, 1504, 1509, 1085)", and "Folder Redirection on Windows XP SP3".

Distilling the advice, there are two things you should check.

1. Check the destination folder, which will be C:\Users\FolderRedirections, on a stock SBS 2008 server.  Check the permissions on the folders for each affected user and make sure the user has Full Control and ownership.
2. If the source server isn’t online anymore, copy the files manually from the old SBS machine, which should be under the share Computer Folders$.  You should have had a backup or have kept the old server around just in case.  Then open Group Policy Manager, select the Small Business Server Folder Redirection policy, make a backup of the GPO and edit it like this:

Uncheck “Move the contents of Documents to the new location”.  Also uncheck “Grant the user exclusive rights to Documents”.  Click OK.

On the machine of the affected user, log on as administrator.  Open a command prompt.  Refresh and force the group policy by typing:

gpupdate /force

Click OK to log off.  Log back on as admin one more time and then log off.

This explanation of XP SP3’s folder redirection comes from the thread on TechNet Forums:

There is a difference in the way Fdeploy.dll works in SP3. I am not too sure if this is a deliberate change to the functionality, however.

If you have a client that is running Windows XP SP3 and their redirect is updated to a new location, you need to ensure that the source is reachable as well as the destination. If the source is not reachable for fdeploy.dll to verify that its moving content, the function will fail and the redirection path will not be updated to the new destination. This differs from SP2 in that if the source isn’t reachable, the process 'moves on' and updates the folder redirect location to the new destination.

If you have replicated the content to the new area using Robocopy or similar utilities and intend to do so as a procedure, I recommend that you update your GPO and uncheck the "Move the contents of My Documents to the new location" option in the GPO (which is enabled by default on a new GPO). Once the GPO change has replicated to all sites, have the client logout and log back in and verify the results.

There is another option cited in the threads, replacing a DLL with one from XP SP2, which I do not recommend;  our machines have had XP SP3 for over a year and I really don’t want to make that kind of change.  System File Protection may not let the DLL be replaced anyway.

If it still doesn’t work, a few other links: 

• Turn on Folder Redirection logging on the client.
• Security Recommendations for Folder Redirection
• Event ID 101 and Event ID 1000 Messages May Be Displaye…

Good luck with your migration!

UPDATE:  Phil has some kind words for me!