Blog - Title

March, 2010

  • USMT and /SF

    Hi all, Ned here again. I’ve seen an emerging issue with USMT that I need to address while our TechNet documentation is updated. If you are using USMT 4.0 for migrations from XP, this is required reading to avoid some very gnarly problems when using the /SF switch in loadstate. Onward.


    When reading our TechNet USMT documentation, you may find occasional examples that have the loadstate.exe using a switch called /SF. If you look at the USMT command-line documentation though, there is no mention of this switch at all. And in the great majority of our examples, the switch is never used. Running loadstate.exe /? shows:

    /sf Restores shell folder redirection

    What the what?

    Shell folder redirection is an option within Windows Explorer to change the default locations of the built-in shell folders, such as My Documents. It’s typically configured through Folder Redirection group policy. In the grand scheme of hundreds of millions of business computers though, it’s strictly in the minority and rarely used compared to the defaults – especially in an unmanaged fashion; it’s not easy for the typical end user to find.

    The USMT /SF option was designed to migrate the shell folder settings. Unfortunately, when loadstate runs it incorrectly updates the global registry path:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

    This happens with both online and offline migrations.


    If you use the /SF switch to migrate from an XP computer to Windows 7 or Vista, you see the following issues:

    • Attempting to open the Administrative Tools folder returns error:

    "Location is not available
    C:\Users\Public\Start Menu\Programs\Administrative Tools refers to a location that is unavailable. If could be on a hard drive on this computer, or on a network. Check to make sure the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location."


    • The “search programs and files” box does not allow you search for any files. For example, when typing in “regedit” it returns error:

    Windows cannot find ‘search:query=regedit’. Make sure you typed the name correctly, and then try again.”


    • The “All Programs” menu only shows "Internet Explorer", "Accessories", "Maintenance", and "Startup".


    There may be more, these are just the ones that I have been able to find or reproduce from customer feedback. Use that Comments section!


    There are a few ways to resolve these issues:

    1. If you are not using redirected folders in Windows XP source computers, stop using the /SF switch on loadstate.

    2. If you want to use /SF or are unsure if redirected shell folders are being configured on clients, you can add the following sample batch file to your steps. After running loadstate.exe, you would then run these in a CMD batch file:

    REM This sample script is provided "AS IS" with no warranties, and confers no rights.
    REM For more information please visit
    REM to find terms of use.
    REM Copyright 2010 Microsoft Corporation

    REM Simple batch script to fix up user shell folder registry values

    REM The empty SET commands are necessary to prevent the environment variables from being expanded by CMD and REG
    REM Note also that the variables are being escaped with double % marks - this is necessary when run in a CMD file

    REM This script code should be added to the end of the loadstate batch file being run during offline migration

    SET ProgramData=

    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Desktop" /d "%%PUBLIC%%\Desktop" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Documents" /d "%%PUBLIC%%\Documents" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "CommonPictures" /d "%%PUBLIC%%\Pictures" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "CommonMusic" /d "%%PUBLIC%%\Music" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "CommonVideo" /d "%%PUBLIC%%\Videos" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "{3D644C9B-1FB8-4f30-9B45-F670235F79C0}" /d "%%PUBLIC%%\Downloads" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Start Menu" /d "%%ProgramData%%\Microsoft\Windows\Start Menu" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Programs" /d "%%ProgramData%%\Microsoft\Windows\Start Menu\Programs" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Startup" /d "%%ProgramData%%\Microsoft\Windows\Start Menu\Programs\Startup" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common AppData" /d "%%ProgramData%%" /f
    reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /t REG_EXPAND_SZ /v "Common Templates" /d "%%ProgramData%%\Microsoft\Windows\Templates" /f

    I’ve attached this as a TXT file as well, since the formatting here is not pretty.

    And that’s that. Please don’t ask about a bug fix or ETA on TechNet being updated, I’ve got nothing for you yet. This article is designed to get you out of the woods.

    - Ned “documenting the undocumentable” Pyle

  • New Directory Services KB Articles/Blogs 2/28-3/6



    A Windows Server 2008 domain controller cannot allocate new ports when Server for NIS is running


    The "Remote Desktop Services" service cannot protect a console session from being disconnected in Windows Server 2008 R2


    Error message when you try to start the Server service in Windows Server 2008 R2: "The network path was not found"


    Certificate store types are truncated when you create a new connection security rule in some non-English versions of Windows 7


    A computer cannot identify the network when the computer is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2, and is a member of a child domain


    Deleting saved credentials in the Remote Desktop Connection client on a computer that is running Windows 7 deletes all saved credentials for the destination computer


    Friday Mail Sack - Something Something Edition

    USMT 4.0 and Custom Exclusion Troubleshooting

    USMT 4.0: Cryptic Messages with Easy Fixes

    Automatically Deleting Expired Objects in FIM 2010

    Windows Licensing in a Unix, Linux, Apple Mac, Java and Web World

    Group Policy Setting of the week 16 – Background upload of a roaming user profile’s registry file while user is logged on

    What are Group Policy Preferences

    Handy WireShark Filter for looking at Kerberos ticket requests/responses

    Internet Explorer 8 Still the Best at Staying Safe While Browsing the Web

    Business users to get Office 2010 on May 12

    Welcome to the new Windows Phone Developer Blog

    Standalone versus domain-based namespaces in Windows DFS

    Microsoft to discontinue its mid-market server line

    Two-Minute Drill: Disabled performance counters and Exctrlst.exe

    Active Directory Schema Requirements for Personal Virtual Desktops

    New Networking-related KB articles for the week of February 21 – February 27

    Hotfix: The "Desktop Wallpaper" Group Policy setting is not applied in Windows 7 or in Windows Server 2008 R2

    PowerShell in the Enterprise

    How to use Group Policy to configure home page settings – Part 2

    How to use Group Policy to turn off the Backup Notification in the Windows 7 Actions Center

    Pushing the Limits of Windows: USER and GDI Objects – Part 1

    Active Directory Web Services brings new power to R2

    Manage Your Organization's Identity with Microsoft Forefront Identity Manager 2010

    Windows 7: More than 90 Million Copies Sold!

    How to use Group Policy to restore missing second printer in Windows 7

    How to use Group Policy to disable the EU Browser Choice

    Windows Server 2008 R2 Learning Guide

    ADAM or ADLDS now available for Windows 7

    How to download and install the Group Policy Management Console (GPMC)

    Group Policy Setting of the week 16 – Prevent Roaming Profile changes from propagating to the server

  • Read-Only Replication in R2

    Ned here again. I’ve been involved with DFSR since its late beta days in 2005. Through good luck and a previous interest in FRS, I decided to take on DFSR as a focus area; when the support cases started rolling in I dealt with most of the issues. My expertise in DFSR is pretty much happenstance. :-)

    Since that first week, I have had hundreds of customers ask me about configuring DFSR “one-way” replication. I’ve also had many customers try to invent their own read-only configurations for DFSR, with results ranging from pretty decent – using share permissions - to “OMG cleanse it with fire!!!” topology hacking.

    Thankfully, Windows Server 2008 R2 takes care of this now in a more sophisticated way. I am going to discuss the architecture of read-only replication in Win 2008 R2, cover some best practices, and describe a few troubleshooting techniques. If you are looking for introductory information about why you would use read-only DFSR or how to configure it step by step, I highly recommend the DFSR development teams blog posts and help file:

    On with the show.


    Read-only (RO) replication refers to the concept of “one-way” replication, where a downstream RO replicated folder is incapable of sending files outbound. It also prevents the creation, modification, or deletion of files in the RO content set locally. RO replicated folders sets can exist on a server that also contains other Read-Write (RW) replicated folders - the boundary of RW or RO is the replicated folder itself on a given server. This new system is ideal for static data that end users are never supposed to modify, such as application installation points, corporate procedural files, centralized backup locations etc.

    RO replication relies on the new mini filter file system driver DFSRRO.SYS. This IO-blocking driver is at an altitude below most common filters, meaning that other drivers will have to abide by DFSRRO’s decisions – including anti-virus software. DFSRRO.SYS is implemented at the “FSFilter Content Screener” level:


    Because the filter driver blocks write IOs, any applications or even many kernel-mode drivers that attempt to save data in the RO folder will receive "Access is denied" (0x5 ERROR_ACCESS_DENIED). This also means that if an application opens files with a WRITE disposition unnecessarily - even if the application only intends to read data – DFSR will return access denied. You can read more about CreateFile dispositions here and file system drivers here.

    A Replication Group containing an RO replicated folder must still contain both inbound and outbound connections. Since a replication group could potentially maintain a mix of RO/RW, and because an RO can change to an RW dynamically, both connections must exist at all times. RO replicated folders can only directly replicate from RW replicated folders. An RO replicated folder cannot source from another RO replicated folder. Also, an RW cannot transitively replicate through an RO.

    So these configurations are good:

    image                     image                 image

    And these configurations are bad:


    image                                 image

    Note: my arrows indicate direction of replication, not a single DFSR connection object! Don’t make me come over there.

    An RW replicated folder can be converted to an RO replicated folder (and back) “on the fly”. Converting will cause a non-authoritative sync to occur on the replicated folder for the server being altered. This is done to ensure that the contents are up to date with the partner before data can flow inbound/outbound. This gives you DFSR event log messages 4620 or 4622:

    Log Name:      DFS Replication
    Source:        DFSR
    Date:          2/22/2010 4:27:29 PM
    Event ID:      4620
    Task Category: None
    Level:         Information
    Keywords:      Classic
    User:          N/A
    The DFS Replication service has detected that ken, which used to be a read-write replicated folder has now been configured to be a read-only replicated folder. The DFS Replication service will not allow any changes to be made to the contents of this replicated folder. Any updates occurring on other read-write replicated folders will be replicated in and applied to the contents of this read-only replicated folder.
    Additional Information:
    Replicated Folder Name: ken
    Replicated Folder Root: c:\ken
    Replicated Folder ID: 171E6A7E-6182-496D-8277-1797FF18C05C
    Replication Group Name: clu2
    Replication Group ID: 8A645529-FE74-4430-9ECD-D1BDC0BA800A
    Member ID: 0EAD46B4-A442-48EA-97F6-109714968E40


    Log Name:      DFS Replication
    Source:        DFSR
    Date:          2/22/2010 4:31:31 PM
    Event ID:      4622
    Task Category: None
    Level:         Information
    Keywords:      Classic
    User:          N/A
    The DFS Replication service has detected that ken, which used to be a read-only replicated folder has now been configured to be a read-write replicated folder. The DFS Replication service will now allow any changes to be made to the contents of this replicated folder. Any updates occurring on this read-write replicated folder will be replicated out and applied to the contents of other replicated folders on other members.
    Additional Information:
    Replicated Folder Name: ken
    Replicated Folder Root: c:\ken
    Replicated Folder ID: 171E6A7E-6182-496D-8277-1797FF18C05C
    Replication Group Name: clu2
    Replication Group ID: 8A645529-FE74-4430-9ECD-D1BDC0BA800A
    Member ID: 0EAD46B4-A442-48EA-97F6-109714968E40

    These events would be followed by 4102 and 4104. There is also a new event that will write when someone tries to restore over a read-only RF:

    Log Name: DFS Replication
    Source: DFSR
    Date: 11/21/2008 11:29:14 PM
    Event ID: 1112
    Task Category: None
    Level: Error
    Keywords: Classic
    User: N/A
    The DFS Replication service failed a restore request. This could happen if an
    attempt was made to restore the contents of a read-only replicated folder
    authoritatively. Read-only replicated folders should only be restored
    non-authoritatively. Authoritative restores should be performed only on read-write
    replicated folders.

    Additional Information:
    Replicated Folder Name: foo
    Replicated Folder ID: 02436A8B-D620-4D83-980A-657E2603FBA0

    Finally, there are also new debug entries for RO, under the module ID’s BFLT, FREP, RFLT ad well as updated in VLMG and CCTX. If that makes no sense, review this insomnia cure.

    Best Practices and Answers to Common Questions

    Note: some of these will be repeats from this and other blog posts. I do that because no matter how many times I talk about certain best practices, people continue to ignore me. :-)

    1. Before deploying read-only folders you must test! Your antivirus software, your backup software, and especially your line of business applications that open files from the replicated folder may all react badly to RO. There are no known MS applications that have any problems.

    2. Converting a replicated folder from RW to RO (or the reverse) will cause a non-authoritative sync to occur on the replicated folder. Plan accordingly.

    3. DFSR read-only is not a panacea! If users can access files on the read-write folders, RO will not prevent anything. If you are trying to stop administrators from changing data, get better administrators.

    4. Tell your users! Unless you want to have lots of help desk tickets about “I get access denied errors”, make sure your users understand that you are marking previously writable data as read-only. Not that they will read the email where you told them this, but at least you tried.

    5. You cannot authoritatively restore data to an RO folder. Duh. Getting backups from there is fine and highly recommended.

    6. Don’t bother trying to circumvent RO. Even when running as SYSTEM, you will not be able to write files into an RO-protected folder. If you don’t want RO protection, don’t run RO. Make your changes on RW folders.

    7. RO can replicate inbound from Windows Server 2003 R2 and Windows 2008. You will need to have extended the AD schema to at least Windows Server 2008 though.

    8. An RO replicated folder can have more than one RW partner replicating inbound, as long as those RW servers have more than just the transitive RO connection.


    There aren’t many new steps to troubleshooting read-only replication compared to classic read-write – make sure you have two connections between every server, in both directions, just like RW. Make sure you have the latest hotfixes. Review everything I described above about topology – most issues in RO have been admin-generated so far. :-)

    The one thing you can add to your test environment troubleshooting is FLTMC.EXE. This tool allows you to dynamically load and unload the DFSRRO.SYS filter driver for testing purposes, using the LOAD and UNLOAD commands. This way if you are testing an application that mysteriously fails when talking to a read-only folder, you have a way to temporarily allow writing to the folder and confirm the application is trying to write data without the need to completely remove RO. There is a lazy sync worker thread that removes changes and replicates down changes from the RW server after the driver is reloaded, so that the file system does not get irrevocably out of sync. Remember to load the driver back up when done testing!

    Wrap Up

    It’s one more good reason to ditch FRS and deploy DFSR.

    And a funny story about that previous interest in FRS I mentioned: most people in MS support really dislike FRS for all of its inadequacies, but I owe it a debt of gratitude. When I was in my hiring interview years ago, one of the questions I got asked was “Can you describe in as much detail as possible how FRS processes files?” The panel thought that was a real stumper. So I drew this on the whiteboard from memory and explained it:


    And I got the job. So thanks FRS, I owe you this gig.

    Until next time.

    Ned “r” Pyle

  • Friday Mail Sack - Something Something Edition

    Hi folks, Ned here again. Despite worries in our Comments sections, the Friday Mail Sack is GO. This week we cover some GP, some computer maintenance, and some really nice fans.


    I am deploying Terminal Servers [Don’t you mean Remote Desktop Services – MS Sales Borg] and I’d like to remove all the shell icons from the users’ desktop. You know, stuff like “My Documents”.

    I’d also like a background wallpaper that is automatically set when users are logged into Terminal Server only, but that won’t affect them when they are just using their desktop computers. Can you hook me up?


    You bet.

    To block all desktop icons in all versions of Windows, you can use the “Hide and disable all items on the desktop” group policy. This is stored in User configuration\<policies>\administrative templates\desktop.


    You can also turn off specific shell icons on an individual basis via this set of policies, using things like “Remove Computer icon on the desktop”. And that desktop wallpaper setting is in here, under the second Desktop node.

    Windows 7 and Windows Server 2008 R2 also introduce a new and highly customizable policy of “Disable Known Folders”, which is under User configuration\<policies>\administrative templates\windows components\windows explorer. This new policy lets you specify any kind of known shell folder you like, by name or GUID. Fancy schmancy!

    Finally, if you want all this to apply to users only when they are logged into Terminal Servers [Don’t make me assimilate you! – MS Sales Borg] but not their desktops, you need to deploy Loopback Policy Processing. Good reading on this here:


    We are trying to remove inactive computers from Active Directory. We have discovered through testing that disabled computer accounts still allow access to domain resources when a user logs in with cached credentials.

    How can I be sure a user who logs on to a computer that has been disabled cannot access the domain using cached credentials?  I do need to allow cached credentials for our mobile users and I need to allow logging on with cached credentials in the case of a WAN outage for our desktops. 


    How are the computers truly inactive if users are still logging on to them while accessing the corporate network? :-)

    If you set the client computer account to disabled and then restart the client computer, it never lets anyone logon with cached domain credentials again.

    XP example:


    Without a restart the computer would continue to allow interactive domain logon for up to 10 hours, since it has a cached Kerberos ticket. The user will have his own Kerberos tickets as soon as he tries to access remote resources too.

    I have a couple solutions here, and they also cover where you no longer trust a computer and just want it gone:

    • You could audit for Logon/Logoff events. In Win2003 these would be event 540 on the DC, and would include the computer name and IP address. If you had just zapped a bunch of clients for being inactive, you could monitor this log on DC’s for any computers you know are now disabled then use the IP info to locate the computers physically and confiscate them. In Win2008 that would be event 4624.
    • If the computer is still online and you know its local administrator password, you could disable the computer account in AD and force that to replicate. Then you could send the remote shutdown.exe command to boot the client – once it comes back up it’s not going anywhere, nor are any domain users.
    • You could use IPSEC. When you had computers that you wanted to ban from the network, you would simply revoke their computer certificate centrally and deny them any connectivity. It would be a good idea to lower the delta CRL publishing interval to 1 hour if this was being used as a “lockout” methodology, so that DC’s would know sooner that the computer was untrusted.
    • The whole NAP… thingy. I don’t know much about that, but it’s there for these sorts of network trust scenarios.

    I bet I got at least one more good method in the comments section. Will it be yours?


    Hey, thanks for writing article <foo>. It:

    A. Gave me good info.
    B. Saved me time.
    C. Fixed my problem.
    D. Saved me from a résumé generating event.

    [Obviously, I am paraphrasing pretty hard – Ned]


    Thanks for all the nice emails from folks that have taken time out of their insanely hectic IT days to give us an attaboy. We really appreciate them.

    Plus it gives management here proof that we’re worth funding – they get to update customer satisfaction spreadsheets and whatever else managers are doing in those little offices besides playing Farm Town.


    As a side note, that comment I pointed to in the introduction has some info uncovered by our pal cortez, plus further clarification from me and the AD development team about using domain controllers with virtualization. I recommend you give it a read. Unless you like late nights.

    Until next time.

    - Ned “Hey, a post not about USMT or DFSR. Weird.” Pyle

  • TechNet Wiki – Contribute Boldly!

    Earlier this week the TechNet Wiki Beta site went live. Now instead of just providing additions to articles like you could with Community Content on MSDN and TechNet, you can create new content and edit anything to your heart’s content. Some of us think this could be rather a big deal.

    Certain types of technical content may never do well on a wiki, because they need to be read-only as they are the company’s official guidance. If you are trying to use Microsoft’s best practices, for example, you may not be inclined to get that from a wiki.

    But there is also content that could do well being vetted, edited, and augmented by the community. Some content stands on its own merit. You read it, you understand it, it makes sense, and it works. You don’t need to take anyone’s word for it because you can easily and safely try it out for yourself.

    So sign up and give it a go. The more the merrier.

    Keith Combs gives a good overview with his blog post here -

    Thoughts? Drop us a comment.

  • USMT 4.0 and Custom Exclusion Troubleshooting

    Ned here again. Because Windows XP cannot be in-place upgraded to Windows 7 and because XP has ruled supreme for longer than most IT staffers’ careers, everyone who managed to avoid USMT are now coming out of the woodwork. Perhaps the most asked question is “I am trying to block X from being migrated to the new computer but it always comes over anyway: what step am I missing?

    USMT 4.0 is incredibly flexible and powerful, to the point where its complexity can make tasks tricky. Exclusions are a case in point, and today I’ll go through the three common mistakes that prevent exclusions from working.

    Consider the case of the frmcache that wouldn’t die. The frmcache.dat file is the part of Microsoft Outlook that stores forms and apparently is rather fragile. One of our customers found that a third party application had modified the frmcache and the cache no longer worked when opened by a later version of Outlook. Since the customer was migrating to new computers running Outlook 2007, they just wanted to block the frmcache.dat from migrating and let Outlook create a fresh one automagically. They created a custom XML file with an exclude rule.

    Except that it didn’t work; the file kept migrating. They suspected – correctly – that USMT was still migrating the file because their custom rule was wrong. After a brief dig, they found it being migrated by the migapp.xml. For good reason they didn’t want to modify that included XML file directly. Why wasn’t the custom XML file working and how could you run into the same exact issue?

    Common cause 1: Your XML uses exclude and not unconditionalExclude

    The rules around USMT conflict and precedence handling are complex and often subtle – read more here if you want a cure for insomnia. Generally speaking, though, if you have some reason to specifically exclude a file or a registry setting there is no circumstance where you ever want it to get included. This means you should use <unconditionalExclude> in your custom XML. This special rule ignores any precedence or inclusion conflicts.

    Here is a sample rule that will absolutely not, no matter what, allow any MP3 files to be migrated to a new destination computer.

    <?xml version="1.0" encoding="utf-8" ?>
    <migration urlid="">
    <component context="UserAndSystem" type="Documents">
      <role role="Data">
              <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>

    Obviously, you need to be very careful about unconditional excludes – setting it for .DOC* files will not endear you to users. Exclusions should strive have as specific a path as possible, unless you know without a doubt that a file has no business being migrated. MP3’s are a good example of those to most businesses, if only for liability reasons!

    Common cause 2: You have set unconditionalExclude in the wrong context

    Within unconditionalExclude there is still a delineation of context for User, System and UserAndSystem. The context tag tells USMT when to care about a section of XML – if gathering a user’s profile it will use the rules for User and UserAndSystem. If gathering the system (aka computer’s) profile, it will use rules for System and UserAndSystem.

    Here is a sample custom rule XML file that will prevent a specific file pattern (frmcache.dat) from being migrated from any user's local appdata profile (%CSIDL_LOCAL_APPDATA%) where the file exists in a specific path (\Microsoft\FORMS).

    <?xml version="1.0" encoding="UTF-8"?>
    <migration urlid="">
      <component type="Documents" context="User">
        <displayName>Block migrating frmcache.dat</displayName>
        <role role="Data">
                <pattern type="File"> %CSIDL_LOCAL_APPDATA%\Microsoft\FORMS [frmcache.dat] </pattern>


    Common cause 3: You have not correctly provided the case for unconditionalExclude

    Finally – and most insidiously - USMT XML tag handling is case-sensitive. This is not just for includes and excludes, so just get in the habit. If you set "unconditionalexclude" it will not work and neither will "Unconditionalexclude" or "UnconditionalExclude". But if you set "unconditionalExclude" your rule will process.


    If you want to avoid these sorts of typo problems in the future, take a look at this previous blog post.

    Until next time.

    - Ned “tweener” Pyle

  • New Directory Services KB Articles/Blogs 2/21-2/27



    Application Compatibility Update for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2: February 2010


    Error message when you try to change a password on a computer that is running Windows 7 or Windows Server 2008 R2: "The specified account does not exist"


    The domain controller runs slower or stops responding when the garbage collection process runs


    You cannot enter an agreement number of a volume license that contains more than seven digits in Remote Desktop Licensing Manager or in TS Licensing Manager


    The DFS Replication service stops responding on a Windows Server 2008-based downstream server that is configured to replicate data from many upstream servers


    A Windows Server 2008 R2-based Remote Desktop server denies some connection requests randomly under heavy logon or logoff conditions


    Error code when the kpasswd protocol fails after you perform an authoritative restore: "KDC_ERROR_S_PRINCIPAL_UNKNOWN"


    FIX: Communication over an IPsec connection is broken unexpectedly when a client reconnects to the IPsec server within four minutes after the client restarts


    Microsoft Advisory Services Engagement Scenario – Windows 2000 End of Support Networking/DHCP


    Microsoft Advisory Services Engagement Scenario – Windows 2000 End of Support Domain Controller Migration


    Microsoft Advisory Services Engagement Scenario – Windows 2008 R2 Cluster Installation with Hyper-V


    Microsoft Advisory Services Engagement Scenario – Windows 2008 R2 Cluster Installation


    SSL connections that are successful on earlier versions of Windows can fail in Windows 7


    The customized folder names might not be copied when you enable the Folder Redirection feature in Windows Vista SP1, Windows Vista SP2, and in Windows 7


    Get Shiny with USMT: Turning the Aero Theme on During XP to Windows 7 Migration

    Friday Mail Sack – Very Late Edition

    Powershell script to help check WMI setting has been configured

    Find out when your Password Expires

    Load Balancing Domain Controllers

    NIST “Guidelines for the Secure Deployment of IPv6” Special Publication is available for public comment

    Creating a Firewall Rule to Allow ICMPv4 Echo Requests

    Planning for disaster recovery with Microsoft Hyper-V

    Integrated Authentication with Firefox and Exchange 2010

    How does a RODC know what writable DC to replicate from?

    Windows Server 2008 Failover Clusters: Networking (Part 3)

    New Networking-related KB articles for the week of February 14 – February 20

    Identity and Access Management Solution

    How to use Group Policy to configure home page settings – Part 1

    End of Support for Windows 2000, Windows XP SP2 and Windows Vista RTM

    Mi-Greatness: Full release version of Windows Server Migration Tools update lets you migrate Hyper-V and RRAS

    Powershell 2.0 Script to Backup GPOs

    Troubleshooting Group Policy

    Microsoft DirectAccess Connectivity Assistant - Now Available!

    Hyper-V Technical Information and Resources

    Looking for Reviewers for PowerShell Cookbook v2

    Measuring Response Times

    TechNet 2.0 – Episode 6 – Wiki

    Announcing Managed Desktop Optimization Pack 2010

    FAQ: Windows Server 2008 R2

  • USMT 4.0: Cryptic Messages with Easy Fixes

    Ned here again. As you begin the process of moving off your older operating systems to Windows 7 you may end up using USMT 4.0. With its powerful capabilities and intended audience of IT professionals, the tool can be unforgiving and often gives inscrutable messages. Today I’ll cover a few of the most common but unclear errors people see when they first run the tool.

    Return code 27: Invalid store path

    You ran a scanstate and now you’re trying to restore the data to a new target computer. You run:

    Loadstate.exe c:\store\usmt /auto

    And…you get a store error. Examining the loadstate log shows:

    [0x000000] USMT Started at 2010/01/31:15:53:58.796
    [0x000000] Command line: loadstate c:\store\usmt /auto
    [0x000000] Failed.[gle=0x00000002]
    [0x000000]   An error occurred processing the command line.
      Invalid store path; check the store parameter and/or file system permissions[gle=0x00000002]
    [0x000000] USMT Completed at 2010/01/31:15:53:58.812[gle=0x00000002]
    [0x000000] Entering MigShutdown method
    [0x000000] Leaving MigShutdown method

    But you look and that path definitely exists with a valid store MIG file inside it.

    This is an easy mistake to make; when you specify a store path during scanstate, USMT automatically makes a sub-folder called “USMT” that contains your data. Admins often assume they need to specify the full path - you don’t. Just provide a path to the same folder level that was used in the scanstate. So in the above case:

    Loadstate.exe c:\store /auto

    Return code 28: Unable to find a script file specified by /i

    You are running a scan or load with a perfectly valid command-line, but every time you start it:


    You get error 28. You examine the directory where scanstate.exe is located and the XML files are definitely there. You examine the scanstate.log and see:

    [0x000000] USMT Started at 2010/01/31:15:59:28.118
    [0x000000] Command line: c:\temp\usmt\scanstate.exe c:\store /v:5 /i:migdocs.xml /i:migapp.xml /o
    [0x000000] Script file is not present: 'C:\users\std\migdocs.xml'[gle=0x00000002]
    [0x000000] Failed.[gle=0x00000002]
    [0x000000]   An error occurred processing the command line.
      Unable to find a script file specified by /i[gle=0x00000002]
    [0x000000] USMT Completed at 2010/01/31:15:59:28.149[gle=0x00000002]
    [0x000000] Entering MigShutdown method
    [0x000000] Leaving MigShutdown method

    This error is returned because both scanstate.exe and loadstate.exe assume that the working folder is the current directory -- where the command is execute -- and not the directory wherein the executable is located. Since the XML files do not exist in my profile -- the current directory -- the command fails. To fix the issue, first switch to the directory containing your USMT files using the CD command, or specify full paths to the XML files with each /i.

    Return code 26: Software malfunction or Unknown exception

    Hooboy, that is a really helpful error. You examine the scanstate log and see:

    [0x000000] USMT Started at 2010/01/31:16:11:54.383
    [0x000000] Command line: scanstate c:\store /o /i:miguser.xml /i:migapp.xml /v:5
    [0x000000] Entering MigStartupOnline method
    [0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
    [0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
    [0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
    [0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
    [0x080405] EnablePrivilege: AdjustTokenPrivileges failed (Error:0x514)
    [0x0803ac] Initializing online WinNT platform (Read/Write)
    [0x080000] Platform is not using admin privileges

    Aha! As you hopefully know from your reading, USMT requires you to be an Administrator to run the scanstate with full functionality or to run loadstate at all. The problem here is that while you are logged on with an account that is a member of the Administrators group, User Account Control is turned on and this CMD prompt is not elevated. That means that your user account shows up as an Administrator but can’t do anything. If you were to lookup that 0x514 error you’d see it means “Not all privileges or groups referenced are assigned to the caller”. Indeed, they are not.

    Elevate your CMD prompt, use an account that bypasses UAC, or turn off UAC – the issue will go away.

    User running the scanstate is the only profile ever migrated

    Why. Do. You. Ignore. My. Command. Line?!? ARRRRGGGHHHH!!!

    This one is just unfair. As I mentioned above, you must be an administrator to run loadstate – it gives you a very specific error otherwise:


    But if you run scanstate as a user that is not a member of the Administrators group, you get no errors. Goo gets gathered up; everything seems fine.


    Except that nothing you put on the command-line for /ui is considered at all, and if you were to closely examine the store data, you’d find tons of operating system settings missing. I have two different accounts on this computer that contain “ned” in some way, that examination should have gotten them both.

    Yes, this is by design -- more information is tucked away here. There is almost no good reason to run any USMT command as a standard user; just get into the habit of using an (elevated) administrator.


    Migrating your computers to Windows 7 can be a very interesting exercise. Hopefully this blog post makes things a bit easier.

    Oh - and why did I only say “may end up using USMT 4.0” at the start of this post? Because you have other options:

    Until next time.

    - Ned “The Riddler” Pyle