February, 2010

Hi Folks. It’s been crazy busy here – sorry for the delay. Hopefully you weren’t sitting around refreshing the page all day.

Not that there’s anything wrong with that.

• RSAT and legacy policies
• Automating GPP creation
• Determining NT 4 to AD domain upgrades

Question

We have a Windows Server 2003 domain and administrators are running Windows 7 with the latest GPMC installed from RSAT. Is it ok for them to be updating policies that affect Windows XP and Windows 2000 machines?

Answer

Yep, it’s ok. We are pretty good about backwards compatibility (take that Apple!). The only exception to this that I am aware of is a specific bug around the – thankfully not used much anymore – legacy policy setting called “Run only allowed Windows Applications.” Read more on this here:

KB976922    The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7
http://support.microsoft.com/default.aspx?scid=kb;EN-US;976922

Question

Is it possible to enter new Group Policy Preferences items using command line? I’m converting hundreds of entries from logon scripts and it would speed things up.

Answer

Yes and no. Starting in Win7/08R2, there is a PowerShell module included to add GPP registry settings:

Set-GPPrefRegistryValue - http://technet.microsoft.com/en-us/library/ee461036.aspx

But if you wanted to modify other elements in the GPP XML files, you will have to roll your own, I’m afraid.

Question

Is there any way to tell if an Active Directory domain was originally in-place upgraded (not migrated) from NT 4.0?

(This question courtesy of one of our MVP friends that will remain nameless unless he wants to be disclosed, and who always finds difficult puzzles for us).

Update: It's Yusuf Dikmenoglu!

Answer

1. The description of the out-of-the-way built-in security group cn=users,cn=builtin,dc=contoso,dc=com will have these differences:

NT 4.0 upgraded: “Ordinary Users”
Not NT 4.0 upgraded: various other completely different wording, depending on OS.

2. The description of the out-of-the-way built-in security group cn=guests,cn=builtin,dc=contoso,dc=com will have these differences:

NT 4.0 upgraded: “Users granted guest access to the computer/domain”
Not NT 4.0 upgraded: various other completely different wording, depending on OS.

3. The description of the out-of-the-way built-in security group cn=administrators,cn=builtin,dc=contoso,dc=com will have these differences:

NT 4.0 upgraded: “Members can fully administer the computer/domain”
Not NT 4.0 upgraded: various other completely different wording, depending on OS.

4. The description of the out-of-the-way built-in security group cn=backup operators,cn=builtin,dc=contoso,dc=com will have these differences:

NT 4.0 upgraded: “Members can bypass file security to back up files”
Not NT 4.0 upgraded: various other completely different wording, depending on OS.

Obviously, my solution is not ironclad. It is reasonable to presuppose that most customers would never change the descriptions on these objects (why bother?); plus, the objects cannot be moved or deleted.

If you find another way that’s more guaranteed, please share it. It’s an interesting exercise.

Update: More good ideas have appeared in the comments!

Until next time.

- Ned “6a” Pyle

Ned here again. Today’s post is quick and dirty… and glossy! One thing users notice immediately about Windows 7 is the default Aero theme. Even if you‘re not a fan of eye candy, your users are – and in the end they run the show in most environments. Especially when their business card says “VP” on it.

Consider the following scenario:

1. Windows XP users have the default display theme of "Windows XP".
2. You use USMT 4.0 to migrate from Windows XP to Windows 7.
3. After migrating to Windows 7 with USMT – using online or offline migrations -- any migrated users that logon have the old and busted "Windows Classic" theme:

… instead of the new hotness:

Why this happens

By default, USMT tries to copy a user’s theme to the target computer. But XP did not have the Aero theme. Worse, XP’s default theme was “Windows XP” which does not exist in Windows 7. The closest possible match is “Windows Classic” so that’s what USMT uses.

Whether or not this default behavior is desirable is open for polite debate in our comments area. :-)

How to get Aero by blocking theme migration

To override the default theme migration, use the following steps:

1. On your reference XP source computer with USMT 4.0 installed, run:

SCANSTATE.EXE /genconfig:config.xml /o

This will create a new customization config.xml file in the scanstate working directory.

2. Open the config.xml in notepad.exe.
3. Locate the following line in the config.xml file (this is wrapped for readability):

<component displayname="Microsoft-Windows-themeui-DL" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui-dl/microsoft-windows-themeui-dl/settings"/>

4. Change the "yes" to "no", so that the line now is:

<component displayname="Microsoft-Windows-themeui-DL" migrate="no" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui-dl/microsoft-windows-themeui-dl/settings"/>

5. Save the config.xml file.
6. Run your usual scanstate and loadstate syntax, making sure to also include your new config file on the scanstate:

/config:config.xml

Disabling this component prevents the following registry keys from migrating (under the covers):

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\LastTheme
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes

And that’s it – now you have Aero.

Until next time.

- Ned “London Dungeon” Pyle

KB

Blogs

Hi folks, Ned here again. Here are this week’s sample of interesting questions sent to AskDS.

• RID pool info
• NT 4.0 and Exchange 5.5
• DFSR staging quota

Question

Is there a way to see information about the available RID pool for a domain?

Answer

Yes, with the attribute: RidAvailablePool

DN path: CN=RID Manager$,CN=System,DC= domain ,DC=com

Global RID space for an entire domain is defined in Ridmgr.h. as a large integer with upper and lower parts. The upper part defines the number of security principals that can be allocated per domain (0x3FFFFFFF or just over 1 billion). The lower part is the number of RIDs that have been allocated in the domain. To view both parts, use the Large Integer Converter command in the Utilities menu in Ldp.exe.

• Sample Value: 4611686014132422708 (Insert in Large Integer Calculator in the Utilities menu of Ldp.exe) 
• Low Part: 2100 (Beginning of next RID pool to be allocated) 
• High Part: 1073741823 (Total number of RIDS that can be created in a domain) 

This is all (buried) in:

305475  Description of RID Attributes in Active Directory
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305475

Update: and see comments - Rick has a slick alternative.

Question

I have an NT 4.0 and Exchange 5.5 environment… <other stuff>

Answer

We’ve got nothing for you, as those operating systems and applications have not been supported for years -the same way if you call Ford and ask about getting warranty work on your '96 Taurus. A handful of Premier contract customers pay a significant premium every year for a “Custom Support Agreement” to maintain support on deceased products. If you’re interested in CSA’s (and if you are running Windows 2000 and getting worried that July 13th is approaching fast), contact your TAM.

Otherwise, whatever you can dig up from our KB or the Internet is your best bet. Your best chance to get an NT 4.0 question answered from us is “I am trying to migrate to a later OS and…”

Question

I am setting up DFSR and I’ve been told the following are best practices:

• Increase the RF staging quota to be at least as large as the 9 largest files on Windows Server 2003 R2 sets.
• Increase the RF staging quota to be at least as large as the 32 largest files on Windows Server 2008 or Windows Server 2008 R2 READ-WRITE sets.
• Increase the RF staging quota to be at least as large as the 16 largest files on Windows Server 2008 R2 READ-ONLY sets.

Is there any easy way to find the N largest files with PowerShell? DIR really blows and the Windows Search GUI is taking forever since I don’t index files.

Answer

Try this on for size (ha!):

Get-ChildItem d:\scratch -recurse | Sort-Object length -descending  | select-object -first 32 | ft directory,name,length -wrap –auto

The highlighted portions are what you need to change. The first one is the path and the second is how many items you want to list as the “biggest”.

Question

I hear that you’re a big Chicago Cubs fan, Ned. Is it true that they have not won the championship in over 100 years?

Answer

I hate you.

Have a great weekend folks,

Ned “the short picture” Pyle

Nearly forgot: depending on who you ask, Active Directory turned 10 years old yesterday. Or nearly 11. Or somewhere in between.

Thanks for the reminder Rick.

OVERLYEXCITEDDORKFISTPUMPPICTUREGO!!!

- Ned "we make weird clipart" Pyle

Ned here again. As odd as it sounds, when you call Microsoft for USMT 4.0 support, you will be sent to the Directory Services team. This is because we support user profiles loading and unloading, as that is a core piece of interactive logons. It’s a tangled web.

Believe it or not, I support more than just DFSR. Really!

DS engineers at Microsoft also have to know about other dependencies USMT can take, such as the Windows Preinstallation Environment (WinPE). You can run USMT 4.0 within a WinPE session so that your scanning process takes place with the source OS completely offline. It’s a pretty slick new feature and we have some straightforward steps in the “Offline Migration with USMT 4.0” guide.

As with any new feature, some common questions start cropping up. Because Windows 7 is being deployed at insanely high rates USMT is becoming a hot topic. Below are some errors people frequently see with USMT running offline migrations in WinPE.

Error: “The subsystem needed to support the image type is not present”

This error is caused by running a 32-bit version of USMT within a 64-bit WinPE image. There are two rather obvious solutions to this:

1. Use an x86 version of WinPE when running an x86 version of USMT.

2. Use an x64 version of WinPE when running an X64 version of USMT.

It’s fine to use x64 WinPE and USMT to run a scanstate on an x86 offline OS. Always remember to specify the environment variable for the offline OS architecture being scanned. This variable is:

MIG_OFFLINE_PLATFORM_ARCH=<32 or 64>

For example, if the offline OS being scanned was 32-bit Windows XP, you would specify the following in the WinPE command prompt that is about to run scanstate:

SET MIG_OFFLINE_PLATFORM_ARCH=32

Return Code 29: “A minimum of 250 MB of free space is required for temporary files”

You see this error even if you have forty bajillion GB free. When you examine your scanstate log you will see something to the order of:

2009-12-01 15:04:25, Info  [0x000000] USMT Started at 2009/12/01:15:04:25.187
2009-12-01 15:04:25, Info  [0x000000] Command line: scanstate z:\store /offline:c:\usmt\offline.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:5 /encrypt /key:****
2009-12-01 15:04:25, Status  [0x000000] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'
2009-12-01 15:04:25, Status  [0x000000] Activity: 'MIGACTIVITY_AUTO_GENERATE_OFFLINE_VERSION'
Info  [0x000000] Drive X:\ has 30 MB free; a minimum of 250 MB is required[gle=0x000000cb]
Info  [0x000000] Failed.[gle=0x000000cb]
Info  [0x000000]   A minimum of 250 MB of free space is required for temporary files[gle=0x000000cb]
Info  [0x000000] USMT Completed at 2009/12/01:15:04:26.078[gle=0x000000cb]
Info  [0x000000] Entering MigShutdown method
Info  [0x000000] Leaving MigShutdown method

This error will appear even if you are running scanstate.exe on the source computer’s local hard drive. The problem is that you’re missing a required environment variable that must be set in the WinPE CMD prompt in order to execute an offline migration. Use the following environment variable:

USMT_WORKING_DIR=<some non-WinPE path>

For example, to specify the physical computer's C:\temp path to act as the temporary storage space, run:

SET USMT_WORKING_DIR=C:\temp

Naturally, you would also see this error if not using an Offline migration and the source computer hard drive really was out of disk space, or was exceeding disk quotas.

Return Code 36: “Use /offline to run gather on this platform”

This error is especially weird because the /offline switch is only available within scanstate.exe, not loadstate.exe. If you try to follow the error’s suggestion to use /offline in the loadstate, you get a new error:

An error occurred processing the command line.
loadstate ##ERROR## --> /offline
Undefined or incomplete command line option 

The real problem is you’re running loadstate within the WinPE session, which is not possible. Loadstate must always be run within a running target OS, never in WinPE.

Scanstate /UI /UE rules with user names are ignored

Consider the following command being run in an offline migration:

Scanstate.exe c:\store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:contoso\nedpyle /ue:*\* /i:migApp.xml /i:MigDocs.xml /v:5

You would expect that /ui:contoso\nedpyle and /ue:*\* would cause the Contoso domain user NedPyle to migrate, and all other user profiles to not migrate. When run, no user profiles are migrated at all. The same exact migration run on the same computer in an online migration works perfectly and only NedPyle is migrated.

This behavior is both expected and unavoidable. The WinPE computer has no knowledge of the domain and no way to perform SID translation. Specifying /ui:domain\username or /ui:*\username is therefore an invalid command. If only the scanstate tool would tell you this!

To work around the limitation, you must use a SID in your /ui or /ue arguments. All profiles are defined in the registry as SIDs, and without the need to translate a user name USMT will work fine. So this would give the desired result:

1. The SID of my contoso\nedpyle user is S-1-5-21-1405795100-2172710363-725018148-1112.

2. My command-line to include this user but exclude all other users in an offline migration would be:

Scanstate.exe :\store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:S-1-5-21-1405795100-2172710363-725018148-1112 /ue:*\* /i:migApp.xml /i:MigDocs.xml /v:5

To figure out SIDs I recommend the old reliable psgetsid.exe tool.

Wrap up

Want to know what all these cryptic error codes mean? Make sure you book mark the USMT 4.0 return codes matrix.

Hopefully the info above saves you a headache someday in your quest to deploy Windows 7, the greatest OS we have ever made. :-)

- Ned “two trick pony” Pyle

Ned here again. To paraphrase Mark Twain, reports of XP’s life have been greatly exaggerated. Mainstream support ended in April 2009 and Service Pack 2 support ends on July 13, 2010. With the release - and crazy popularity – of Windows 7, companies are exploring various options to move on from XP.

But there’s a catch: XP cannot be in-place upgraded to Windows 7. And even if you could upgrade it, most IT admins are wary of in-place upgrades, even if only by reputation. So what do you do? You use USMT 4.0’s new offline migration feature /OfflineWinOld.

The high level process

1. Examine your current XP image(s) and inventory what applications are installed.

2. Make a decision on how you plan to deploy:

a. Use a Windows 7 DVD and install applications by hand (less than 100 computers – keep reading this post)

b. Create a new Windows 7 image that contains all your applications and is sysprepped (more than 100 computers – go read all about large deployments and maybe forget about this post).

c. MDT 2010 or SCCM 2007 (go read Mike and Dan’s blog and definitely forget about this post!)

3. Install WAIK somewhere and drop the USMT directory onto a network share or thumb drive.

4. Install Windows 7 on an XP computer using a “Custom (Advanced)” installation and not formatting the hard drive. Add the applications and join the computer back to the domain.

5. Run USMT scanstate with an offlinewinold hardlink migration.

6. Run USMT loadstate against that hard link store.

7. Repeat steps 4 to 6 until done.

8. Give self a raise - just like Congress.

The step-by-step process

Critical note: Everything I describe below is happening in your test environment first. Really.

Another critical note: There are certain OS customizations that may have made that cannot be migrated offline due to product limitations. Make sure that nothing on this list really bothers you before proceeding:

• DCOM settings
• Internet Options
• Regional Language settings
• Media Player settings
• Offline Files settings
• RAS settings
• Display settings
• Speech recognition settings
• Handwriting recognition settings
• Phone and modem settings
• Media Center settings
• Windows Search settings
• Mapped network printers <-- probably the one you think is important, but isn’t necessarily

In addition, offline migrations can’t handle situations where someone has moved the Program Files or Documents and Settings folders to a different drive than the Windows folder. For businesses, many of these settings are unimportant (Media Center!) or are controlled through Group Policy anyways (Offline Files) so most customers don’t get in a twist over them. But if any of these are a show stopper for you, go with a normal online migration. It will be slower but ultimately more capable.

Good to go? On with the show.

1. Begin by inventorying your XP computers. You need to know what applications are installed on them so that they can be reinstalled. Check with your hardware vendors to make sure your computers don’t have any known issues with running Windows 7, or if they have updated firmware if they do. By now any credible vendor can at least tell you if an application is supported or not – even if the answer is “no”. If the vendor doesn’t know, it’s probably time to start looking at competitors – and I bet if you mention that, the vendor will suddenly know in a hurry! :-)

   For more Windows 7 application compatibility info, go to our portal here.

2. Decide how to migrate and create your image. In this case, you decided to install Windows 7 by hand, add the applications (or create a simple Win7 image with the applications included), then use USMT to offline migrate.

3. Download the Windows Automated Installation Kit and burn the ISO to a DVD. Install on an administrator computer running Win 2003 SP2, Win Vista, Win 2008, Win 7, or Win 2008 R2 somewhere in the environment. You cannot install it on XP.Inside the (default) location for WAIK you will find the USMT data:

   %programfiles%\Windows AIK\Tools\Usmt\x86

   %programfiles%\Windows AIK\Tools\Usmt\amd64

Copy those folders to a network share, to a USB thumb drive, etc. You will be using those files a lot for the next few days. If you only have plans to use x86 and not deploy 64-bit Windows 7 then don’t bother with the amd64 folder.

4. Note the name of your XP computer, and then install Windows 7 over the top of your existing Windows XP installation. In the example below you have booted from the DVD. Click “Install Now”.

You are prompted to choose “Upgrade” or “Custom (Advanced)”. If you choose upgrade, you get smacked down, so make sure you choose custom:

Windows servicing then notes that you already have Windows (XP) installed.

Here’s the critically important part: do NOT delete or format the disk. This sounds obvious, but I’ve already had several people format drives and then ask why USMT didn’t migrate any data. Guess what sort of backups they had taken…

Now, the setup runs and because it is not an upgrade it installs fast. My Windows 7 installations in a hyper-v guest usually take less than 20 minutes.

Log on and install any applications you need – at least the ones that were installed on XP for business use. Join the computer to the domain using the same name the XP computer used. This will keep the domain SID, group memberships, etc. that had belonged to this computer when it was XP.

At this point we have a nice pristine computer that has its old name, is joined to the domain, and has its old applications installed. We’re ready to migrate.

5. Start Windows Explorer and have a look around the drive. There is now a Windows.old folder. Expand that folder and you’ll find inside that all the user profile data exists – this includes files in My Documents, data on the Desktop, the user’s registry settings etc. The Windows.old folder also contains the system’s registry and file structure, under Windows and Program Files. Other folders that were not in the users’ profiles, Windows, and Program Files directories will still be on the drive in their original location. Everything has been preserved.

Open a CMD prompt as an Administrator.

Navigate to wherever you decided to store the USMT files. In the examples below they were copied from a network location to a local folder c:\usmt on the computer being migrated.

Run your scanstate operation. This will examine and gather up all the data that was preserved in the Windows.old folder. This scanstate should include the following commands at a minimum:

<store path>
/offlinewinold:<path to your old XP Windows folder>
/i:migapp.xml
/i:migdocs.xml
/hardlink
/nocompress

For example:

The store path will be used to store migration information about settings and what are called “hard links”. These are pointers to files that allow USMT to migrate those files without having to copy the files into the store or duplicate files that are identical. It saves a huge amount of time and space during the migration.

Note: If you have users that are specifically added to local groups on the XP source computer you will need to use a custom /config:config.xml file to specify that users should be added into specific groups. Usually this is for users that are members of the Administrators group in XP – something which you should not continue to do!

Here is a sample config.xml that makes all migrated users members of the Administrators group. Which again, you shouldn’t do! I cannot emphasize that enough, but I get asked about it frequently. Just remember that if you make your users administrators all the other security best practices in the world will not save them. This goes for every operating system ever made.

<Configuration>
<ProfileControl>
    <localGroups>
      <mappings>
         <changeGroup from="*" to="Administrators" appliesTo="MigratedUsers">
            <include>
               <pattern>*</pattern>
            </include>
         </changeGroup>
      </mappings>
    </localGroups>
</ProfileControl>
</Configuration>

Genconfig has other good reasons to be run, make sure you look into it.

The scanstate runs, examining all the profiles and the computer configuration. All the data and settings are gathered up into migration units that are saved or hard-linked in the store.

Note: If you are interested in seeing what I mean about hard links, look at this sample output using FSUTIL.EXE. Here I dump out the hard link info from a file that actually exists in the backed up Windows.old folder. The hard link allows it to simultaneously “exist” in both spots at the same time.

Note: If you run the hard link scanstate successfully, you can get an error if you try to run it again:

   scanstate.exe c:\store /o /hardlink /offlinewinold:c:\windows.old\windows /nocompress

   Failed to delete 'c:\store\usmt'. Windows error 18.

   Failed.
     An error occurred processing the command line.
     Invalid store path; check the store parameter and/or file system permissions

   Scanstate returned code: 27

This is expected. Use the usmtutils.exe tool included with USMT to delete the hard link store, then you can run the scan again. This in no way affects the real data living in windows.old; it’s just deleting the hard links.

6. Now you run the loadstate operation against the same store you just created – there’s no need to reboot or so anything fancy. The loadstate should include the following commands at a minimum:

<store path>
/i:migapp.xml
/i:migdocs.xml
/hardlink
/nocompress

All the files, settings, profiles, application configurations, etc. are restored to their original spots on the hard drive. If any of the migrated users logon now they will find their files and settings haven’t changed – for the most part; it is a new operating system after all.

7. Repeat for all the other computers in your test environment. Then evaluate the results, have some users try things out, and consider going for it in production, repeating steps 4-6.

8. Chuckle at all the people that complained about the lack of an XP upgrade, secure in the knowledge that you now have a much more stable system with all the data and settings your users care about.

And yes, we do have this all publically documented in TechNet. But it’s buried pretty well in the appendix of this article and doesn’t have my pretty pictures. :-)

Until next time.

- Ned “no longer a DFSR SME” Pyle

KB

No new Directory Services-related KB articles this week.

Blogs