An update for ADMT, and a few other things too.

First published on TechNet on Dec 13, 2013

So, we've been quiet for a few months, which is extraordinarily embarrassing after I basically

told everyone

that we were going to not do that. The reality of what we do in support is that sometimes it's “All Hands on Deck”, which is where we've been lately.

At any rate, here's some assorted news, updates, and announcements. Today we're going to talk about ADMT, SHA-1, Folder Redirection, Roaming Profiles, STOP errors, and job opportunites. Yup, all in one big post. It's not quite a mail sack but hopefully you all will find it interesting and or useful – especially the bit at the end. We'll try to get the regular posts moving again asap as we get into 2014.

ADMT OS Emancipation

Update coming to allow you to install on any supported server OS version

News just in: There's an updated version of ADMT on the way that will allow you to install on newer OS versions. Here's what we got from the ADMT product team:

In short, the update will allow ADMT to install on our newer OSs (both the ADMT and PES components). This should help alleviate some of the problems that customers have been reporting with the tool. We know that there are many of you who would like to see improvements or additional features in the tool beyond this, but we made the decision to focus this update on the OS compatibility issues, since that's the thing that is impacting migrations the most right now.  We currently do not have any plans for further updates after this one (beyond bug fixes).

The changes we have made require a fair bit of testing before we can release them – among other things, we have to test full-scale migrations against each combination of OS versions to make sure that nothing unexpected occurs.  Once that testing is complete, we'll publish the new version for public download, probably as an update to the existing 3.2 version.  We don't have an exact date right now, since it's likely to take us a few months to finish our testing, but we're hoping to have it out and available in the first quarter of 2014.

Update:  The new version of the tool is available via the Connect site located


.  To get it, you will have to log in with a Microsoft account and join the Connection program.  (This is just the name of the program, you don't actually have to be using Windows Azure or anything like that).

Out with the old (and the insecure)

We've announced the deprecation of SHA-1 algorithms

This one comes to us from former AskDS writer Mike Stephens. Mike changed roles last summer, and most of what he works on these days we can't talk about – but some things we can:

Some of you may remember

this security advisory

where we announced the deprecation of RC4-based cryptographic algorithms. Some of you may also remember

this blog post

from a few months ago where we talked about the upcoming deprecation of MD5-based algorithms.

Deprecation is a fancy word for “we don't support it anymore moving forward, so you should look at turning it off.”

If you're sensing a trend here, you're not wrong.

We just announced yesterday that we are planning the deprecation of SHA-1 algorithms.

This means that moving forward, the minimum security you want on anything cryptographic is SHA-2 with a 2048-bit key. Those of you running certificate authorities should start planning on transitioning to stronger keys as soon as you can. Those you who have server or web applications in your environment (pretty much everyone) should start reviewing your applications to find any applications that are using weak certificates. Update them if you can, contact the application vendor if you can't.

Just like the previous updates, we're not going to issue a hotfix that turns off SHA-1 on all your servers and workstations. We know that there are lots of older applications out there that might need to be updated before your environments are ready for this kind of change so you are in control. What we will do is give you a KB article that tells you how to turn SHA-1 off when you're ready. That, and we'll turn it off by default in the next version of the OS.

That being said, two notes of caution. First, make sure you really, really check before disabling support for older cryptography algorithms in your environments. We've had a few cases where admins didn't check the certificates their applications were using, and caused an outage with one or more of their applications when they turned off RC4. The point here is to test and verify application dependencies and compatibility before you make a widespread change. Second, have a plan to roll back the change if something you didn't expect breaks. Finally, don't wait to start transitioning your environment to stronger [using] crypto graphic algorithms. The longer your environment is using less secure cryptography, the more vulnerable you are to attacks. You can get ahead of the curve by updating your application requirements now to higher standards, and starting the work to transition your existing apps over to new certificates.

One way, or the other…

Folder Redirection doesn't apply to Windows 8 and Windows 8.1 clients when you also configure it in System Center

This one comes to us from one of our tech leads, Kapil Chopra. Among many other duties, part of Kapil's role is to watch for trends in the support cases that come into our frontline engineers, so that we can prioritize fixes that are affecting lots of customers.

I had a chance to work on multiple cases where in folder redirection doesn't gets applied on Windows 8 and Windows 8.1. So I thought of posting the details to make sure that everyone is aware of the fact and should be able to resolve the issue.

In all the cases that I addressed, we see the below mentioned symptoms on the client


1. In the RSOP, under the properties of User Configuration, we see that the Folder Redirection settings got applied successfully.

2. Under the RSOP, when we browse to the User Configuration > Policies > Windows Settings, we don't see Folder Redirection folder.

3. Under the GPRESULT /v output we see that the folder redirection setting is showing up as N/A.

4. There is no failures reported under the Application / System logs.

5. Logging states that the policy is applied as mentioned below:

GPSVC(32c.b6c) 12:55:50:136 ProcessGPOs(User): Processing extension Folder Redirection

GPSVC(32c.b6c) 12:55:50:136 ReadStatus: Read Extension's Previous status successfully.

GPSVC(32c.b6c) 12:55:50:136 CompareGPOLists: The lists are the same.

GPSVC(32c.b6c) 12:55:50:136 CompareGPOLists: The lists are the same.

GPSVC(32c.b6c) 12:55:50:136 GPLockPolicySection: Sid = S-1-5-21-2130729834-1480738125-1508530778-62684, dwTimeout = 30000, dwFlags = 0x0

GPSVC(32c.b6c) 12:55:50:136 ProcessGPOList: Entering for extension Folder Redirection

GPSVC(32c.b6c) 12:55:50:136 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy…

GPSVC(32c.b6c) 12:55:50:136 ProcessGPOList: No changes. CSE will not be passed in the IwbemServices intf ptr

GPSVC(32c.43c) 12:55:50:136 Message Status =

GPSVC(32c.b6c) 12:55:50:152 ProcessGPOList: Extension Folder Redirection returned 0x0.

6. Under the folder redirection tracing, it isn't getting past fdeploy.dll into the shell components and is not even attempting to read the fdeploy.ini files.

From the above symptoms, it is pretty evident that there is something that is stopping the Folder Redirection engine from proceeding further. So we went ahead looked into the Folder Redirection operational logs under “Event viewer > Application and Services Logs > Microsoft > Windows > Folder Redirection > Operational Logs”.

Under the Operational logs we found an interesting event which might be causing the problem:

Log Name: Microsoft-Windows-Folder Redirection/Operational

Source: Microsoft-Windows-Folder Redirection

Date: 11/4/2013 11:54:58 AM

Event ID: 1012

Task Category: None

Level: Information




Folder Redirection configuration is being controlled by WMI configuration class Win32_FolderRedirectionUserConfiguration.

In order to confirm if it's only the Folder Redirection or other components as well getting controlled by WMI, we ran the powershell command “gwmi Win32_UserStateConfigurationControls” and found that all components i.e. Folder Redirection / Offline Files / Roaming User Profiles were controlled by WMI.


__GENUS : 2

__CLASS : Win32_UserStateConfigurationControls


__DYNASTY : Win32_UserStateConfigurationControls

__RELPATH : Win32_UserStateConfigurationControls=@




__NAMESPACE : rootcimv2

__PATH : WIN8TESTrootcimv2:Win32_UserStateConfigurationControls=@

FolderRedirection : 1

OfflineFiles : 1

RoamingUserProfile : 1

PSComputerName : WIN8TEST


Now the question is, what this WMI Class “


” has to do with Folder redirection?

In order to answer that, everyone should be aware of the fact that with Windows 8 we have introduced new WMI classes to manage and query Folder Redirection and Remote User Profiles configuration using WMI controls. These WMI classes are mentioned below:




The redirection properties of a known folder


The health of a known folder that is being redirected


The health configuration properties for a known folder that is being redirected


The user's folder redirection configuration settings


Represents a roaming profile background upload operation


The roaming profile configuration for a computer


The slow-link parameters for roaming profiles


Represents a roaming profile user configuration


Represents health configuration properties for all roaming user profiles on a computer


Represents a user profile


Contains properties that control the user state configuration for a computer. The property value settings for this class determine whether or WMI should be the configuration mechanism for user state components.

So, the big question is – who is giving the control on FR/CSC/RUP to WMI?

In all the cases that we have dealt with, we found that the machines were deployed and managed using SCCM. So there might be something in the SCCM configuration which is changing the default behavior and passing on the control to WMI. We looked into the and found the setting which might be causing all the pain. The exact configuration is mentioned below:

Under the SCCM Configuration manager,

– Select Administration

– Select Client Settings


– Pull up PROPERTIES of Default Client Settings configuration and click on Compliance Settings


Enable User Data and Profiles

mentioned above is the setting which drives the control of Folder Redirection and Remote User Profiles.

The above configuration by Default is set to NO. Once enabled (set to YES), it passes the control of Folder Redirection, Offline Files, and Remote User Profiles to WMI and stores this configuration under the registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUserStateUserStateTechnologiesConfigurationControls


This is evident from the fact that FolderRedirection, OfflineFiles, and RoamingUserProfiles registry entry mentioned in the above snippet is set to 1.

More details about Managing UserState via System Center Configuration is documented under the

articles mentioned below:

– How to Create User Data and Profiles Configuration Items in Configuration Manager :

– Example Scenario for User Data and Profiles Management in Configuration Manager :


To resolve the issue we need to change the value of “Enable User Data and Profiles” to NO under the Compliance settings in SCCM Configuration.

Another important fact that I need to point out is, changing the value of above registry entries to “0” will resolve the issue for a while on a client but the registry entries will automatically be flipped to 1 once the SCCM configuration client piece gets executed on the Win8 or Win8.1 machines. By default, this configuration runs every hour to pull changes from the server. So you have to make the change in System Center if you want it to stick.

Most customers don't realize what they are doing when they set this value to YES, so they will want to make sure it is set to NO in their environments. If a customer does want to use it, then they will need to make sure they are managing Folder Redirection through WMI and not through Group Policy or they will run into the problems mentioned above.

Getting Rid of Pesky STOP Errors

Hotfix released to correct a crash in /IP.

Here is a fix

you will want to test and then deploy to your servers as soon as you can. For the past few months we have been tracking a large number of cases where servers would crash (blue screen) with a STOP 0xD1 error. We've been tracking this issue for a long time, but we were never able to figure out what exactly caused it because it only happened under specific circumstances on multiprocessor computers It took us so long to figure this out. Those conditions used to be pretty rare but as multiprocessor computers are now the norm, problem frequency has increased.  We now have a

hotfix for Windows Server 2008 R2

available just in time for the holidays.

2012 and 2012 R2 versions of the same hotfix are being tested and will be released in January 2014 if the testing pans out.

Making the kids play nice together

Roaming profiles now coexist properly for Windows 7, Windows 8 and Windows 8.1 computers.

Some of you may recall

a blog post

from one of our friends in PFE about problems roaming user profiles between computers running Windows 7 and Windows 8. In the original blog, we presented a workaround that, while it helped, was not really a fix for the issue.

Well, now we have a fix for the issue.


of them

, rather. I'll explain.

To set expectations: Windows 8 uses a new profile format (just like Windows 7 had a new format when compared to XP). Windows 8.1 uses a third (or fourth) new profile format. So, if you want to move data


computers running Windows 7, Windows 8, and Windows 8.1, you will need to use Folder Redirection…. OR you can consider using the cool new feature called Work Folders, which we'll be adding support for Windows 7 in the coming months. But if you don't do one of these things, then the two profiles are separate – no data gets shared between the two OS versions.

KB 2887239


KB 2890783

allow roaming profiles to “roam” properly even if you're in a mixed OS environment. That means users will be able to log in seamlessly to different devices without having to follow the workaround mentioned in Mark's blog post.

Last, but definitely not least:  We're hiring.

I mentioned at the start of this that the last few months for us in DS (and really in all of support) have been “All Hands on Deck”. And while things slow down a little over the holidays, we have more work to do than we have hands and minds to do it right now.

So we're hiring. If you're the sort of person who enjoys fixing hard problems, who likes getting into the guts of how software works, and who's not afraid to constantly be asked to learn something new, you really should check out our

careers page

. There are positions available in Charlotte, NC, in Las Colinas, TX, and in Fargo, ND. And this isn't just for DS – it's for all of our Windows support teams (and others). If you're interested, look for Support Engineer positions and send in your resume.

What we do is possibly the most technically demanding and challenging infrastructure job there is. Every day we work on problems that impact hundreds or thousands of users out there in the world, and some with more impact with that. It's not an *easy* job. But it is a very fulfilling one.

If you're interested in applying, check out these two blog posts we put up a while back, and we'll look forward to talking to you.

Post-Graduate AD Studies

Accelerating Your IT Career


This article was originally published by Microsoft's Directory Services Team. You can find the original article here.