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 here. To get it, you will have to log in with a Microsoft account and join the Azure AD Connection program. (This is just the name of the program, you don't actually have to be using Windows Azure Active Directory 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.”

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 Group Policy 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. Group Policy Logging states that the policy is applied as mentioned below:

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:

Now the question is, what this WMI Class “Win32_FolderRedirectionUserConfiguration” 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:

Class

Explanation

Win32_FolderRedirection

The redirection properties of a known folder

Win32_FolderRedirectionHealth

The health of a known folder that is being redirected

Win32_FolderRedirectionHealthConfiguration

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

Win32_FolderRedirectionUserConfiguration

The user's folder redirection configuration settings

Win32_RoamingProfileBackgroundUploadParams

Represents a roaming profile background upload operation

Win32_RoamingProfileMachineConfiguration

The roaming profile configuration for a computer

Win32_RoamingProfileSlowLinkParams

The slow-link parameters for roaming profiles

Win32_RoamingProfileUserConfiguration

Represents a roaming profile user configuration

Win32_RoamingUserHealthConfiguration

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

Win32_UserProfile

Represents a user profile

Win32_UserStateConfigurationControls

Contains properties that control the user state configuration for a computer. The property value settings for this class determine whether Group Policy 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 System Center Configuration Manager and found the setting which might be causing all the pain. The exact configuration is mentioned below:

- 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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UserState\UserStateTechnologies\ConfigurationControls

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

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 System Center Configuration Manager 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 TCP/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.

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

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. Twoof 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 between 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 and 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.