Saturday, May 14, 2011

Desktop.ini woes and Home Drives

Do a search on Desktop.ini on the internet and you should get a bebby of information. You will also read quite a bit on blogs and forums about troubles with the Desktop.ini. One of the main issues is when an admin sets up user's home drive in Active Directory then does a folder redirection for the Documents folder to point to the home drive. The result is that when you look at the root of the Share that holds the home drive, you will see that all, or most, of the folders will have the same name as My Documents. Why? You see a lot of comments about how this is a "bug" with Microsoft Windows; but in reallity is more of a "feature". If you delete the Desktop.ini file from within then do a "refresh", the folder automatically appears as you would expect with the user's user name.

OK, so you can totally skip reading the rest of this post if you want by just remembering not to redirect the My Documents folder to a share as \\server\sharename\username, instead redirect to \\server\sharename\username\Documents

Now as Paul Harvey use to say, here is the rest of the story:

To understand more about the purpose of the Desktop.ini, see the following links:

1. The Desktop.ini file does not work correctly when you create a custom default profile

2. Customizing Folders with Desktop.ini

3. Fix for Special Folders Reverting to Default Folder Icon in Windows Vista

4. Shell folders are displayed with the standard folder icon in Windows Vista

5. Home folders renames to My Documents

6. When you redirect the Documents folder on a Windows Vista-based or Windows 7-based computer to a network share, the folder name unexpectedly changes back to Documents

The setup would be this:

1. On a file server you have set up a folder called users, then shared it as users$. The intent is to have this folder hold all the user's home folders which you have configured in their account settings as: Home Drive is for example U:

2. Then using Group Policy you have deemed that you are going to re-direct the My Documents folder to the user's Home drive.

Where is the problem? The problem lies in that when a user logs in, the My Documents folder points to their Network Share, and therefore a Desktop.ini is created and put in the root of the home drive and then makes the folder appear with the name of "My Documents" instead of for example jsmith (the user's account name). This is what is deemed a problem or bug; but in reallity I believe it to be how it is intended. The Desktop.ini is used as a descriptor of System Folders such as those specal folders: Music, Pictures, Contacts, Searches, etc., so it is working like it is suppose to.

I can easily duplicate the problem as shown here. I have manually redirected the My Documents folder to a folder shared as my home drive on a server. As you can see, my home folder on the server does not show my username as the other users on my server, but instead is hows as My Documents instead of my username. If I were to delete the Desktop.ini file within, then it would revert to display with my username until the next time when I would have the redirectiont take place.

The way to solve the problem is to set up the users home folder and the folder redirection the right way in the first place.

1. On the Domain Controller you would have the account set up the way I already described above. No need to change anything there.

2. But in Group policy you would have folder redirection set up like this:

So what if you are already having the problem and really don't want to change anything, but the whole thing is really annoying? The one work aroud that I have seen work, is that if you are using a Windows 2008 server, you can set up a File Screen. Point the file screen to the Users folder, and set it to "block" the creation of Desktop.ini. Then create a batch file (or do it manually) that deletes any Desktop.ini currently in there. This will solve your problem.

One final note about this whole folder thing-Make sure you have your folder security set up correctly. If you need a refresh, follow this link.


No comments: