Blog - Title

Ask the Directory Services Team

  • Locked or not? Demystifying the UI behavior for account lockouts

    Hello Everyone,

    This is Shijo from our team in Bangalore once again.  Today I’d like to briefly discuss account lockouts, and some UI behaviors that can trip admins up when dealing with account lockouts.

    If you’ve ever had to troubleshoot an account lockout issue, you might have noticed that sometimes accounts appear to be locked on some domain controllers, but not on others.  This can be very confusing since you
    typically know that the account has been locked out, but when you inspect individual DCs, they don’t reflect that status.  This inconsistency happens because of some minor differences in the behavior of the UI between Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.

    Windows Server 2003

    In Windows Server 2003 the "Account is locked out" checkbox can be cleared ONLY if the account is locked out on the domain controller you are connected to. This means that if an account has been locked out, but the local DC has not yet replicated that information, you CANNOT unlock the account on the local DC.

    Windows 2003 account properties for an unlocked account.  Note that the checkbox is grayed out.

     

    Windows Server 2008 and Windows Server 2008 R2

    In Windows Server 2008/2008 R2 the "Unlock account" checkbox will always be available (regardless of the status of the account). You can tell whether the local DC knows if the account is locked out by looking at the label on the checkbox as shown in the screenshots below:

    Windows 2008 account properties showing the “Unlock Account” checkbox.  Notice that the checkbox is available regardless of the status of the account on the local DC.

     

    Windows 2008 (and higher) Account Properties dialog box showing locked account on this domain controller

     

    If the label on the checkbox is just "Unlock account" then this means that the domain controller you are connected to recognizes the account as unlocked. This does NOT mean that the account is not locked on other DCs, just that the specific DC we're working with has not replicated a lockout status yet.  However, unlike Windows Server 2003, if the local DC doesn’t realize that the account is locked, you DO have ability to unlock it from this interface by checking the checkbox and applying the change.

    We changed the UI behavior in Windows Server 2008 to help administrators in large environments unlock accounts faster when required, instead of having to wait for replication to occur, then unlock the account, and then wait for replication to occur again.

     

    Windows Server 2012

    We can also unlock the accounts using the Active Directory Administrative Center (available in Windows Server 2008 R2 and later).  In Windows Server 2012, this console is the preferred method of managing accounts in Active Directory. The screen shots are present below about how we can go about doing that.

    You can see from the account screenshot that the account is locked which is denoted by the padlock symbol. To unlock the account you would have to click on the “Unlock account” tab and you would see a
    change in the symbol as can be seen below.

     

    You can also unlock the account using the PowerShell command shown in the screenshot below.

     

    In this example, I have unlocked the user account named test by simply specifying the DN of the account to unlock . You can modify your powershell command to incorporate many more switches, the details of which are present in the
    following article.

    http://technet.microsoft.com/en-us/library/ee617234.aspx

    Hopefully this helps explain why the older operating systems behave slightly differently from the newer ones, and will help you the next time you have to deal with an account that is locked out in your environment! 

     

    If you’re looking for more information on Account Lockouts, check out the following links:

    Troubleshooting Account Lockout

    Account Lockout Policy

    Account Lockout Management Tools

     

    Shijo “UNLOCK IT” Joy

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

    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.

     

    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 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:

    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 = <Applying Folder Redirection policy...>
    -
    -
    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
    User: SYSTEM
    Computer: WIN8TEST.contoso.com
    Description: 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
    __SUPERCLASS :
    __DYNASTY : Win32_UserStateConfigurationControls
    __RELPATH : Win32_UserStateConfigurationControls=@
    __PROPERTY_COUNT : 3
    __DERIVATION : {}
    __SERVER : WIN8TEST
    __NAMESPACE : root\cimv2
    __PATH : \\WIN8TEST\root\cimv2:Win32_UserStateConfigurationControls=@
    FolderRedirection : 1
    OfflineFiles : 1
    RoamingUserProfile : 1
    PSComputerName : WIN8TEST
    ===================================================

    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:

    Under the SCCM Configuration manager,
    - Select Administration
    - Select Client Settings


    clip_image002

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

    clip_image004
    - 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

    clip_image006

    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 : http://technet.microsoft.com/en-us/library/jj591610.aspx
    - Example Scenario for User Data and Profiles Management in Configuration Manager : http://technet.microsoft.com/en-us/library/jj870707.aspx

    RESOLUTION

    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.

     

    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. Two 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 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.

    Post-Graduate AD Studies

    Accelerating Your IT Career

  • Important Announcement: AD FS 2.0 and MS13-066

    Update (8/19/13):

    We have republished MS13-066 with a corrected version of the hotfixes that contributed to this problem.  If you had held off on installing the update, it should be safe to install on all of your ADFS servers now.

     

    The updated security bulletin is here: http://technet.microsoft.com/en-us/security/bulletin/MS13-066

     

    Thanks everyone for your patience with this one.  If anyone is still having trouble after installing the re-released update, please call us and open a support case so that our engineers can get you working again!

    ===============================================================

     

     

    Hi everyone, Adam and JR here with an important announcement.

    We’re tracking an important issue in support where some customers who have installed security update MS13-066 on their AD FS 2.0 servers are experiencing authentication outages.  This is due to a dependency within the security update on certain versions of the AD FS 2.0 binaries.  Customers who are already running ADFS 2.0 RU3 before installing the update should not experience any issues.

    We have temporarily suspended further downloads of this security update until we have resolved this issue for all ADFS 2.0 customers. 

    Our Security and AD FS product team are working together to resolve this with their highest priority.  We’ll have more news for you soon in a follow-up post.  In the meantime, here is what we can tell you right now.

     

    What to Watch For

    If you have installed KB 2843638 or KB 2843639 on your AD FS server, you may notice the following symptoms:

    1. Federated sign-in fails for clients.
    2. Event ID 111 in the AD FS 2.0/Admin event log:

    The Federation Service encountered an error while processing the WS-Trust request. 

    Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue 

    Additional Data 

    Exception details: 

    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load
    type ‘Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.


       at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

       --- End of inner exception stack trace ---

       at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)

       at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

       at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)

       at Microsoft.IdentityModel.Configuration.SecurityTokenServiceConfiguration.CreateSecurityTokenService()

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateSTS()

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateDispatchContext(Message requestMessage, String requestAction, String responseAction, String
    trustNamespace, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext)

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

    System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

       at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

     

    What to do if the problem occurs:

    1. Uninstall the hotfixes from your AD FS servers.
    2. Reboot any system where the hotfixes were
      removed.
    3. Check back here for further updates.

    We’ll update this blog post with more information as it becomes available, including links to any followup posts about this problem.

  • Adding shortcuts on desktop using Group Policy Preferences in Windows 8 and Windows 8.1

    Hi All!

    My name is Saurabh Koshta and I am with the Core Team at Microsoft. Currently I work in the client space so supporting all aspects of Windows 8 and Windows 8.1 is my primary role.

    We very often get calls from customers who are evaluating Windows 8/Windows 8.1 for deployment, but are concerned about some of the changes in the UI that may confuse their users. A typical concern we hear is that users are used to having shortcuts on the desktop for Computer, Documents, and Network. So, I wanted to take a minute to show you how you can easily add those shortcuts (or others) to desktops using Group Policy Preferences.

    I have an OU in my domain called “Domain Computers”, which has Windows 8 machines.

    image

    The next step is to create a policy and link in to the “Domain Computers” OU. In this case it is called “Shortcut”

    image

    Edit the policy and go to the following location:

    Computer Configuration -- > Preferences -- > Windows Settings -- > Shortcuts

    Highlight Shortcuts and on the right pane, right click and select new Shortcut

    image

    In the ‘New Shortcut Properties’, make the following changes so the values look like below:

    1. Action : Update

    2. Target type : Shell Object

    3. Location : All Users Desktop

    4. For Target object, click on the browse option and then chose ‘Computer’

    5. Name : My Computer

    Leave rest of the options as default. Once you have made all the changes, it would look like below:

    image

    Similarly for Network the options are:

    1. Action : Update

    2. Target type : Shell Object

    3. Location : All Users Desktop

    4. For Target object, click on the browse option and then chose ‘Network’

    5. Name : My Network Places

    image

    And for Libraries the options are:

    1. Action : Update

    2. Target type : Shell Object

    3. Location : All Users Desktop

    4. For Target object, click on the browse option and then chose ‘Libraries’

    5. Name : My Documents

    image

    So we have the following three shortcuts

    image

    Restart the client and once logged in with a domain user, the desktop would have the three shortcuts as listed above and it would look something like below:

    image

    The above steps also work with Windows 8.1. Here is how it looks:

    image

    Hope you all find this information useful.

    Thanks,

    Saurabh Koshta

  • Our UK Windows Directory Services Escalation Team is Hiring – Support Escalation Engineers.

    Hi! Its Linda Taylor here again from the Directory Services Escalation team in the UK. In this post, I want to tell you – We are hiring in the UK!!

    Would you like to join the UK Escalation Team and work on the most technically challenging and interesting Active Directory problems? Do you want to be the next “Ned Pyle”?

    Then read more…

    We are an Escalation Team based in Microsoft Campus in Reading (UK). We are part of Microsoft Global Business Support and we work with enterprise customers helping them resolve the most critical Active Directory infrastructure problems as well as enabling our customers to get the best of Microsoft Windows and Identity related technologies. The work we do is no ordinary support – we work with a huge variety of customer environments and there are rarely two problems which are the same. We are the experts in our field and we work closely with the product group to help make Windows and all our other technologies better. 

    You will need strong AD knowledge, great customer services skill, strong troubleshooting skills and great collaboration and team work.

    You can find more of the job details here:

    https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=1&jid=130665&jlang=EN&pp=SS

    Linda.

  • Roaming Profile Compatibility - The Windows 7 to Windows 8 Challenge

    [Editor's note:  Everything Mark mentions for Windows 8 clients here is also true for Windows 8.1 clients.  Windows 8 and Windows 8.1 clients use the same (v3) profile version, so the 8.1 upgrade will not prevent this from happening if you have roaming profiles in your environment.  Something to be aware of if you're planning to migrate users over to the new OS version. -David]

     

    Hi. It’s Mark Renoden, Senior Premier Field Engineer in Sydney, Australia here again. Today I’ll offer a workaround for an issue that’s causing a number of customers around the world a degree of trouble. It turns out to be reasonably easy to fix, perhaps just not so obvious.

    The Problem

    The knowledge base article "Unpredictable behavior if you migrate a roaming user profile from Windows 8 to Windows 7" - http://support.microsoft.com/kb/2748329 states:

    Windows 7 and Windows 8 use similar user profile formats, which do not support interoperability when they roam between computers that are running different versions of Windows. When a user who has a  windows 7 profile signs in to a Windows 8-based computer for the first time, the user profile is updated to the new Windows 8 format. After this occurs, the user profile is no longer compatible with Windows 7-based computers. See the "More information" section for detailed information about how this issue affects roaming and mandatory profiles.

    This sort of problem existed between Windows XP and Windows Vista/7 but was mitigated by Windows Vista/7 using a profile that used a .v2 extension.  The OS would handle storing the separate profiles automatically for you when roaming between those OS versions.  With Windows 7 and Windows 8, both operating systems use roaming profiles with a .v2 extension, even though Windows 8 is actually writing the profile in a newer format.

    Mark’s Workaround

    The solution is to use separate roaming profiles for each operating system by utilizing an environment variable in the profile path.

    Configuration

    File server for profiles:

    1. Create profile share “\\Server\ProfilesShare” with permissions configured so that users have write access
    2. In ProfilesShare, create folders “Win7” and “Win8”


     

    Active Directory:

    1. Create OU for Windows 7 Clients (say “Win7OU”) and create/link a GPO here (say “Win7GPO”)
    2. Create OU for Windows 8 Clients (say “Win8OU”) and create/link a GPO here (say “Win8GPO”)

    Note:As an alternative to separate OUs, a WMI filter may be used to filter according to Operating System:

    Windows 7 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.1%” and ProductType = “1″

    Windows 8 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.2%” and ProductType = “1″

    3. Edit Win7GPO

      1. Expand Computer Configuration -> Preferences -> Windows Settings
      2. Under Environment create an environment variable with
        1. Action: Create
        2. System Variable
        3. Name: OSVer
        4. Value: Win7

    4. Edit Win8GPO

      1. Expand Computer Configuration -> Preferences -> Windows Settings
      2. Under Environment create an environment variable with
        1. Action: Create
        2. System Variable
        3. Name: OSVer
        4. Value: Win8

    5. Set user profile paths to \\Server\ProfilesShare\%OSVer%\%username%\

     

    Clients:

    1. Log on with administrative accounts first to confirm creation of the OSVer environment variable

    2. Log in as users and you’ll observe that different user profiles are created in the appropriate folder in the profiles share depending on client OS

    Conclusion

    I haven't run into any issues in testing but this might be one of those cases where it's important to use "wait for network". My testing suggests that using "create" as the action on the environment variable mitigates any timing issues.  This is because after the environment variable is created for the machine, this variable persists across boots and doesn't depend on GPP re-application.

    You may also wish to consider the use (and testing) of a folder redirection policy to provide users with their data as they cross between Windows 7 and Windows 8 clients. While I have tested this to work with
    “My Documents”, there may be varying degrees of success here depending on how Windows 8’s modern apps fiddle with things.

     - Mark “Square Peg in a Round Hole” Renoden

     

     

  • MD5 Signature Hash Deprecation and Your Infrastructure

    Hi everyone, David here with a quick announcement.

    Yesterday, MSRC announced a timeframe for deprecation of built-in support for certificates that use the MD5 signature hash. You can find more information here:

    http://blogs.technet.com/b/srd/archive/2013/08/13/cryptographic-improvements-in-microsoft-windows.aspx

    Along with this announcement, we've released a framework which allows enterprises to test their environment for certificates that might be blocked as part of the upcoming changes (Microsoft Security Advisory 2862966). This framework also allows future deprecation of other weak cryptographic algorithm to be streamlined and managed via registry updates (pushed via Windows Update).

     

    Some Technical Specifics:

    This change affects certificates that are used for the following:

    • server authentication
    • code signing  
    • time stamping
    • Other certificate usages that used MD5 signature hash algorithm will NOT be blocked.

    For code signing certificates, we will allow signed binaries that were signed before March 2009 to continue to work, even if the signing cert used MD5 signature hash algorithm.

    Note:  Only certificates issued under a root CA in the Microsoft Root Certificate program are affected by this change.  Enterprise issued certificates are not affected (but should still be updated).

     

    What this means for you:

    1) If you're using certificates that have an MD5 signature hash (for example, if you have older web server certificates that used this hashing algorithm), you will need to update those certificates as soon as possible.  The update is planned to release in February 2014; make sure anything you have that is internet facing has been updated by then.

    You can find out what signature hash was used on a certificate by simply pulling up the details of that certificate's public key on any Windows 8 or Windows Server 2012 machine.  Look for the signature hash algorithm that was used. (The certificate in my screenshot uses sha1, but you will see md5 listed on certificates that use it).

    If you are on Server Core or have an older OS, you can see the signature hash algorithm by using certutil -v against the certificate.

    2) Start double-checking your internal applications and certificates to insure that you don't have something older that's using an MD5 hash.  If you find one, update it (or contact the vendor to have it updated).

    3) Deploy KB 2862966 in your test and QA environments and use it to test for weaker hashes (You are using test and QA environments for your major applications, right?).  The update allows you to implement logging to see what would be affected by restricting a hash.  It's designed to allow you to get ahead of the curve and find the potential weak spots in your environment.

    Sometimes security announcements like this can seem a little like overkill, but remember that your certificates are only as strong as the hashing algorithm used to generate the private key.  As computing power increases, older hashing algorithms become easier for attackers to crack, allowing them to more easily fool computers and applications into allowing them access or executing code.  We don't release updates like this lightly, so make sure you take the time to inspect your environments and fix the weak links, before some attacker out there tries to use them against you.

    --David "Security is everyone's business" Beach

  • Managing the Store app pin to the Taskbar added in the Windows 8.1 Update

    Update!

    Warren here with an update on the Store icon issue. Good News! Your feedback has been heard, understood and acted upon. A fix is in the works that will address the scenarios below:

     

    Scenario 1 - You want to block the Store but have enabled the GP to block the Store after applying Windows 8.1 Update.  A fix will be made to the GP, such that it will remove the Store Icon pin if the “disable Store” GP is already set.

     

    Scenario 2 - You want to provide access to the Store but want to remove the Store icon pin from the taskbar. A GP will be provided that can manage the Store icon pin.

     

    Thanks for all of your feedback on this issue!

     

    Warren

    ===========================================================================================================

    Warren here, posting with more news regarding the Windows 8.1 Update. Among the many features added by Windows 8.1 Update is that the Store icon will be pinned to the users taskbar when users first logon after updating their PC with Windows 8.1 Update.

    Some companies will not want the Store icon pinned to the taskbar on company owned devices.  There are currently two Group Policy options to control the Store tile pin - one that you can use before deploying the update that will prevent the Store app from being pinned to the Taskbar, and another that you can use after the update has been deployed and the Store app has been pinned to the Taskbar.

    Option 1:  Turn off the Store application before Installing the Windows 8.1

    Use the Group Policy “Turn off the Store application”

    As mentioned earlier, the Store Icon is pinned to the Taskbar at first logon after Windows 8.1 Update is applied. The Store application will not be pinned to the taskbar if the Group Policy “Turn off the Store application” is applied to computer. This option is not retroactive. The Group Policy must be applied to the workstation before the update is applied. The full path to this Group Policy is:

    Computer Configuration\Administrative Templates\Windows Components\Store\Turn off the Store application

    Or

    User Configuration\Administrative Templates\Windows Components\Store\Turn off the Store application

    You can use either Group Policy. As the name of the policy indicates, this will completely disable the Store. If your desire is to allow access to the Store but do not want the Store tile pinned to the Taskbar see option 2.

    Important note: By default the Group Policy setting “Turn off the Store application” will not show up in GPEDIT.MSC or GPMC.MSC if you run the tools on a Windows Server. You have two options: Install the Remote Server Admin Tools (RSAT) tools on a Windows 8.1 client and edit the group policy from that machine or install the Desktop Experience feature on the server used for editing Group Policy. The preferred method is to install the RSAT tools on a workstation. You can download the RSAT tools for Windows 8.1 here: http://www.microsoft.com/en-us/download/details.aspx?id=39296

    Option 2:  Use Group Policy to remove Pinned applications from the Taskbar after Installing the Update

    Use the Group Policy “Remove pinned programs from the Taskbar”

    This GP is a big hammer in that it will remove all pined tiles from the task bar and users subject to the policy will not be able to pin any applications or tiles to the Taskbar. This accomplishes the goal of not pinning the Store tile to the taskbar and leaves the Store accessible from Start.

    User Configuration\Administrative Templates\Start Menu and Taskbar\Removed pinned programs from the Taskbar”

    Other Options

    The last available option at this time is to have users unpin the Store app on their systems. Programmatically changing the Taskbar pins is not supported nor encouraged by Microsoft. See http://msdn.microsoft.com/en-us/library/dd378460(VS.85).aspx