March, 2010

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.

Background

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.

Symptoms

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:

“search:query=regedit
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!

Workaround

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:

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

KB

Blogs

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:

• Read-only replicated folders on Windows Server 2008 R2
• Configuring a read-only replicated folder on Windows Server 2008 R2
• The Windows DFSR Help (available in DFSMGMT.MSC)

On with the show.

Architecture

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:

And these configurations are bad:

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
Computer:      2008r2-f-01.contoso.com
Description:
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
Computer:      2008r2-f-01.contoso.com
Description:
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
Computer: WIN7-6946-02.southridgevideo.com
Description:
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.

Troubleshooting

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

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.

• Terminal Services shell desktop policies
• Disabling compromised computers

Question

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?

Answer

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:

http://support.microsoft.com/kb/231287

http://technet.microsoft.com/en-us/library/cc780733(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc782810(WS.10).aspx

Question

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. 

Answer

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?

Statement

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]

Response

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

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.

technet.com/wiki

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

http://blogs.technet.com/keithcombs/archive/2010/02/23/technet-2-0-episode-6-wiki.aspx

Thoughts? Drop us a comment.

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="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
<component context="UserAndSystem" type="Documents">
  <displayName>NedSample</displayName>
  <role role="Data">
    <rules>
      <unconditionalExclude>
        <objectSet>
          <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
        </objectSet>
      </unconditionalExclude>
    </rules>
  </role>
</component>
</migration>

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="http://www.microsoft.com/migration/1.0/migxmlext/test">
  <component type="Documents" context="User">
    <displayName>Block migrating frmcache.dat</displayName>
    <role role="Data">
      <rules>
        <unconditionalExclude>
          <objectSet>
            <pattern type="File"> %CSIDL_LOCAL_APPDATA%\Microsoft\FORMS [frmcache.dat] </pattern>
          </objectSet>
        </unconditionalExclude>
      </rules>
    </role>
  </component>
</migration>

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.

OMGXMLH8U!!!111elevenz

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

KB

Blogs

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] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'
[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] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'
[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] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'
<snip>
[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.

Conclusion

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:

• MDT 2010 lite touch (uses USMT under a GUI)
• MDT 2010 zero touch with System Center Configuration Manager 2007 (ditto)
• Upgrade in place
• 3^rd parties

Until next time.

- Ned “The Riddler” Pyle