I’ve recently had a number of queries about why everyone’s home folders have been renamed to Documents in the network share they reside in.
This obviously makes finding a particular users home folder difficult, especially in schools where administrators and teachers regularly look in the home folders.
This is a feature of Windows Vista, Windows 7 & Server 2008. A desktop.ini file is created when the user first accesses their home folder to give it a friendly display name of Documents and a custom icon. This is to make it look pretty and stand out when viewed under your profile in Windows Explorer.
However, the side effect is as above. Whenever anyone else views the folder, and this will normally be in the context of the network location it is stored, their Explorer will also read the desktop.ini file to get display information and give the impression that there are multiple folders called Documents.
As it’s only the display name which is changed you can still navigate into the folder by typing in the name in the address bar, which will auto-complete properly, but it’s not ideal.
The desktop.ini file is a hidden system file so you won’t see it unless you have your setting set up to view system files so unless you know what’s happening it can seem very mysterious.
Microsoft have a knowledge base article about this at http://support.microsoft.com/kb/947222.
In it, it suggests 3 options for stopping this behaviour.
1. Put the home folder in a wrapper folder which is called the user’s username, but point the Active Directory attribute to the folder within it.
2. Give the user exclusive rights to the folder.
3. Deny read permission to the desktop.ini file in the home folder to other users. Then they won’t be able to read the display information and the name won’t change.
In a school environment, where there are legitimate reasons for other users to go into the students’ home folders option, 2 isn’t an option. Both 1 & 3 work nicely, but 3 seems cleaner to me as it doesn’t require any extra folders creating just to get round a display issue.
I’ve knocked up a quick PowerShell script to automate setting the permissions on the desktop.ini files. Note the groupName below should be changed to the name of an Active Directory group you want to be able to view the real folder names. Be careful that this group doesn’t include any back up process opoerators or backups could fail.
$folders = Get-ChildItem | where-object {$_.psiscontainer};
foreach ($folder in $folders)
{
$ErrorActionPreference = "SilentlyContinue"
$desktopIni = Get-ChildItem $folder -Filter desktop.ini -Force
if ($desktopIni -ne $null)
{
$Acl = (Get-Item $desktopIni.FullName -Force).GetAccessControl("Access")
$Ar = New-Object system.security.accesscontrol.filesystemaccessrule `
("groupName","Read","Deny")
$Acl.SetAccessRule($Ar)
Set-Acl $desktopIni.FullName $Acl
}
}
All you need to do is save this script as a .ps1 file in the directory containing your home folders. If they are split for example along intake years, you’ll need to do this in each containing folder. So in the example above, you would save in \\fileserver\Intake2008. Then change groupName to the name of an Active Directory group containing the users you want to see the real names. Open up PowerShell and navigate to the directory containing the script file and then run it.
If you haven’t run PowerShell scripts before you’ll need to set the execution policy to allow it, I normally use RemoteSigned. Run
help set-executionpolicy
and
help about_execution_policies
in your PowerShell prompt for more information.
Update 05 April 2011
Removed the use of Get-Acl as Set-Acl then tries to set the owner. Talked about back up operators. Thanks to Jay Hutter for both of those.
Update 16 September 2011
Added $ErrorActionPreference = “SilentlyContinue” at the start. Otherwise an error is thrown when re-running as you don’t have access to the desktop.ini files you modified last time.
