Tag Archives: Server 2008 r2

Strange “Recent Places” issue in windows 7 / Server 2008 R2.

Just a quick post about a funny little issue I saw recently.

First to give some background on this wonderful little folder. The recent places folder you see in the windows explorer Favorites menu is a collaboration of all the folders you have saved to recently. Windows compiles this folder view by first looking at your “Recent Files” in %userprofile%AppDataRoamingMicrosoftWindowsRecent and then filtering the results by directory. Leaving you with a view of all the folders you have worked in recently.

In my case, when using mandatory profiles in Server 2008 R2 and Windows 7, the Recent Places Folder in windows Explorer is spelled incorrectly. Instead of being “Recent Places”, it’s listed as “RecentPlaces” without the space.

When this issue occurs, the folder will correctly list the folders you have recently worked in, but the name will be incorrect for the duration of your session.

This will occur if active setup has not run on your profile, or as part of your profile creation. It seems despite following the Microsoft guide to the letter, active setup still needs to run on a Mandatory profile each time a user logs in…

The individual component of active setup responsible for many things including this profile adjustment is {89820200-ECBD-11cf-8B85-00AA005B4340} found in these registry locations:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftActive SetupInstalled Components
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftActive SetupInstalled Components

This active setup component run’s the following command:

C:WindowsSystem32regsvr32.exe /s /n /i:U shell32.dll

To fix the issue, reinstate the active setup keys you wrongfully deleted (bad admin) or run the above command.

Once you’ve done this the folder will be displayed correctly.

For a great explanation of Active setup, check out Helge’s write up over here.

If you still hate active setup (like I do) the above command can be run on  as part of a login script or better yet as part of a RES Workspace Manager “Execute Command” without the annoying active setup pause. This will then fix this issue each login before the user see’s it.

This command is actually really useful to be aware of and I’ll blog about this a little later in the week about some other applications of this seemingly routine command.

Controlling the creation of Libraries in Windows 7 / Server 2008 R2.

Following on from my previous post about libraries, I have found you can actually control library creation, but there is a two fairly large caveats I’ll cover later in this post.

To Block Library creation, you can create a user group policy blocking the known folder ID. You may argue a login script can simply delete the unwanted libraries, and you would be right, but a shell context menu exists to restore these libraries on user request. The method below ensure’s they are never created.

For every default windows directory, these directories have known folder names and GUID’s. A great reference site for these GUIDS can be found here:


In our case, we’re interested in the following five Known Folders:

FOLDERID_DocumentsLibrary   GUID{7B0DB17D-9CD2-4A93-9733-46CC89022E7C}
FOLDERID_MusicLibrary             GUID{2112AB0A-C86A-4FFE-A368-0DE96E47012E}
FOLDERID_PicturesLibrary         GUID{A990AE9F-A03B-4E80-94BC-9912D7504104}
FOLDERID_VideosLibrary            GUID{491E922F-5643-4AF4-A7EB-4E7A138D8174}

and the little known:

FOLDERID_RecordedTVLibrary  GUID{1A6FDBA2-F42D-4358-A798-B74D745926C5}

Once we know which folders we wish to block, open group policy and navigate to the following policy:

User Configuration > Policies > Administrative Templates > Windows Components > Windows Explorer.

In this section, you will find a Disable Known Folders Setting.

Enable the policy and click show, here you can configure the libraries you wish to block:

(below I’m blocking the creation of Video’s and Music.)

Configuring the value above will leave you with libraries as so:


It’s a once off thing… Blocking the creation of a library will only take effect on the first login, aka the profile creation. There is no microsoft solution available to control these libraries after the fact. You could make do with login scripts, but its messy.

It’s not the size, its the contents that matter… You cannot control the cotents of libraries, i.e. you cannot block the link to the shared folders libraries. This is really silly, as you would assume that were you to block the known folder PublicDocuments aka {ED4824AF-DCE4-45A8-81E2-FC7965083634}. This would stop it being created in the profile on first load, you’d be very wrong, blocking this known folder causes the library to not be created. Not sure who thought that was a good idea, but I digress.

So that’s it in a nutshell, for more information on locking down the server 2008 r2 profile check in later or follow me on twitter @andyjmorgan.

Libraries in Server 2008 R2 mandatory profiles.

Love them or hate them, the new library system Microsoft has included in Windows Vista and later operating systems are here to stay. But when you start provisioning mandatory profiles in server 2008, you quickly begin to see issues with these static file mappings.

Bear in mind with libraries, there are no group policys  to control what is populated in a library. You can control which libraries are created, but you cannot by default control what goes into them.

Shared local folders in the enterprise:

The first issue to be found with libraries are their default locations, for each respective library it contains the users personal folder and a shared folder accessible by all on the local machine.

This shared folder may serve a good purpose in the home, with multiple family members sharing a pc and wanting to share music and pictures, but in the enterprise shared folders on a shared system require maintenance. Worse yet, if you are sharing hosted desktops with other departments / customers this is where data may fall into the wrong hands.

Static mappings from the mandatory profile:

After the initial login, if the user browses directly to the contents of the library contents without first opening the parent library, they will often receive the following error:

The user we see above, manny, was the name of my mandatory profile creating account. If you browse to the parent before entering your documents folder, windows is clever enough to rectify the issue without giving an error.

But alas, despite following the best practices available on-line we’ve some how ended up with a static mapping, how annoying.

To get to the crux of the issue, we need to know more about these libraries.

So what is a library? 

A library, is a collection of indexed* directories, allowing you to view the contents of multiple folders in a single view. They have more cool features, but lets leave it as that for the moment.

* libraries will allow un-indexed directories to be mapped if part of a group policy, but it will complain about the source not being indexed.

A library is a text document, stored in %appdata%Microsoftwindowslibraries. These files have the file extension of .library-ms. The contents of the file can be opened with a text editor as its XML based.

When i opened my mandatory profile’s documents.ms-library file, below you can see the contents:

As you can see above, the library contains the user’s sid and the following default locations are listed under the <URL> tag. To compare a known folder’s GUID to a  folder, check the following site provided by Microsoft for reference. In the case of the documents Library here are the locations that are in there by default:

{FDD39AD0-238F-46AF-ADB4-6C85480369C7} = Documents

{ED4824AF-DCE4-45A8-81E2-FC7965083634} = PublicDocuments

Note the Serialized string also, this seems to be a static mapping to the folder in question.

So how do we fix this?

Well, that’s a two part answer. If you decide you are happy that the public documents folder will be displayed to all users in their documents library, simply delete the libraries from the mandatory profile, this will cause the libraries to be recreated each time they login, resolving the static mapping error above.

If you want to remove the public folders, you first need to modify the library file in question in the mandatory profile and remove the public documents. To remove the public folder, simply remove the <searchconnectordescription> value containing the public folder in question. In the case of the documents library above you would remove the following:

This will get rid of the public folder in the library, to remove the static mapping, remove the usersid section, along with the serialized section. The finished result is below for reference:

Saving the above file in your mandatory profile will correctly provision the documents folder without a shared folder or incorrect mapping. This practice can also be applied to the remaining libraries.