Blog - Title

February, 2010

  • USMT, OST, and PST

    Ned here again. Do you remember time before email in the office? It’s been a while now. Email isn’t an option these days any more than a phone. And since Exchange has reached around 65% market share, odds are decent that you’re using some version of Outlook. If you’re planning on migrating to Windows 7 with USMT 4.0, you likely have two questions:

    1. How can I get Outlook OST’s to migrate?
    2. How can I get Outlook PST’s to migrate?

    Updated April 16, 2012 to be more complete 

    OST migration

    I am just going to rip the bandage off here, so grit your teeth: you cannot migrate Outlook OST files with USMT. USMT makes no special allowances for OST files because the Outlook team does not support those files moving between computers; they were never designed for portability and Outlook’s developers don’t want anyone copying them around. The only supported way to get an OST file is for Outlook to create it.

    If you create a custom Include XML file that copies over OST files then Outlook may state the OST is invalid or that it cannot be opened. Please don’t call us asking for workarounds: this is expected behavior and there is absolutely nothing that the USMT or Outlook support teams can do. The OST may appear to work also; you got lucky for now, but there may be buried badness in that file that rises up someday like a mail-enabled Dracula – no one knows.

    And it's not just me saying this: http://technet.microsoft.com/en-us/library/cc179110.aspx#BKMK_MigrationConsiderations

    PST migration

    By default, USMT 4.0 migrates PST files that are linked to a user’s Outlook profile. This is done through internal USMT functions named SetPstPathInMapiStruct and UpdateMvBinaryMapiStruct which is called from within migapp.xml.

    What this means is that PST files which are simply stored on the drive but not actually connected to Outlook might not migrate when using /i:migapp.xml and /i:migdocs.xml.  For example, if a user has a PST file store in their c:\users\someuser\appdata\local\microsoft\outlook folder: USMT doesn't just copy that folder's contents willy-nilly; after all, those are mostly local per-computer settings and data, and just blasting them onto another computer could cause problems.

    It’s very possible a user is keeping those around for archive purposes, though. Migdocs.xml will gather customer folder contents from the roots of drives with little though to their contents, but you may need some XML to target PSTs appropriately and surgically. Consider this scenario, where the archive.pst and nov2009on.pst are not attached to Outlook, and are just loose files on the computer:

    image

    If you just wanted the c:\pst copy, you get it for free as long as you use migdocs.xml. In order to migrate  all of those PST files though, you’ll need to use a custom XML override. Here is a sample that will gather all PST files from all fixed drives, regardless of their location:

    <?xml version="1.0" encoding="utf-8" ?>
    <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/pst">
      <component type="Documents" context="UserAndSystem">
        <displayName>All PST migrated from all fixed drives, regardless of location</displayName>
        <role role="Data">
          <rules>
            <include>
              <objectSet>
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>
              </objectSet>
            </include>
          </rules>
        </role>
      </component>
    </migration>

    Paste that into Notepad and save as PST.XML into your USMT folder. When you add that to your scanstate and loadstate command-lines with /i:pst.xml then all fixed drive PST files will be migrated. You could also paste it into Visual Studio 2008 Express, nudge nudge.

    Here's another sample XML, which has the added bonus of not accidentally copying PST files that a user connected to Outlook through a UNC path (which is unsupported except for one small scenario, by the way - http://support.microsoft.com/kb/297019):

    <?xml version="1.0" encoding="utf-8" ?>
    <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/pst">
      <!-- This component migrates .PSTs except for ones on the network-->
      <component type="Documents" context="UserAndSystem">
        <displayName>All PST files migrated from all fixed, no PST’s migrated from network, regardless of context or outlook registry catalog settings</displayName>
        <role role="Data">
          <rules>
            <unconditionalExclude>
              <objectSet>
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Remote")</script>
              </objectSet>
            </unconditionalExclude>
            <unconditionalExclude>
              <objectSet>
                <pattern type="File">\\* [*.pst]</pattern>
              </objectSet>
            </unconditionalExclude>
            <include>
              <objectSet>
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.pst]", "Fixed")</script>
              </objectSet>
            </include>
          </rules>
        </role>
      </component>
    </migration>

    Side note: the migXmlHelper.GenerateDrivePatterns option allows me to avoid hard coding paths, drive letters, or non-fixed storage. It’s something you should get comfortable with as it’s extremely useful in environments with non-standard images and users roaming freely with USB thumb drives. Since you’re going to Windows 7, don’t forget about “BitLocker to go” for those scenarios!

    Another side note: Make sure you are using latest USMT 4.0 so that you capture Outlook 2010 settings correctly! http://support.microsoft.com/kb/2023591

     

    Until next time.

    - Ned “ends in t” Pyle

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

    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:

    image

    … instead of the new hotness:

    image

    image

    image

    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.

    image

    Until next time.

    - Ned “London Dungeon” Pyle

  • Inventorying Computers with AD PowerShell

    Hi, Ned here again. Have you ever had to figure out what operating systems are running in your domain environment so that you can plan for upgrades, service pack updates, or support lifecycle transitions? Did you know that you don’t have to connect to any of the computers to find out? It’s easier than you might think, and all possible once you start using AD PowerShell in Windows Server 2008 R2 or Windows 7 with RSAT.

    Get-ADComputer

    The cmdlet of choice for inventorying computers through AD is Get-ADComputer. This command automatically searches for computer objects throughout a domain, returning all sorts of info.

    As I have written about previously my first step is to fire up PowerShell and import the ActiveDirectory module:

    image

    Then if I want to see all the details about using this cmdlet, I run:

    Get-Help Get-ADComputer -Full

    Getting OS information

    Basics

    Now I want to pull some data from my domain. I start by running the following:

    Important note: in all my samples below, the lines are wrapped for readability.

    Another important note (thanks dloder): I am going for simplicity and introduction here, so the -Filter and -Property switches are not designed for perfect efficiency. As you get comfortable with AD PowerShell, I highly recommend that you start tuning for less data to be returned - the "filter left, format right" model described here by Don Jones.

    Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto

    image

    This command is filtering all computers for all their properties. It then feeds the data (using that pipe symbol) into a formatted table. The only attributes that the table contains are the computer name, operating system description, service pack, and OS version. It also automatically sizes and wraps the data. When run, I see:

    image

    It looks like I have some work to do here – one Windows Server 2003 computer needs Service Pack 2 installed ASAP. And I still have a Windows 2000 server that is going to move quickly and replace that server.

    Server Filtering

    Now I start breaking down the results with filters. I run:

    Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

    I have changed my filter to find all the computers that are running “Windows Server something”, using the –like filter. And I stopped displaying the OS version data because it was not providing me anything unique (yet!).

    image

    Cool, now only servers are listed! But wait… where’d my Windows 2000 server go? Ahhhh… sneaky. We didn’t start calling OS’s “Windows Server” until 2003. Before that it was “Windows 2000 Server”. I need to massage my filter a bit:

    Get-ADComputer -Filter {OperatingSystem -Like "Windows *Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

    See the difference? I just added an extra asterisk to surround “Server”.

    image

    As you can see, my environment has a variety of Windows server versions running. I’m interested in the ones that are running Windows Server 2008 or Windows Server 2008 R2. And once I have that, I might just want to see the R2 servers – I have an upcoming DFSR clustering project that requires some R2 computers. I run these two sets of commands:

    Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*2008*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

    Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*r2*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

    image

    image

    Starting to make sense? Repetition is key; hopefully you are following along with your own servers.

    Workstation Filtering

    Okeydokey, I think I’ve got all I need to know about servers – now what about all those workstations? I will simply switch from -Like to -Notlike with my previous server query:

    Get-ADComputer -Filter {OperatingSystem -NotLike "*server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto

    And blammo:

    image

    Family filtering

    By now these filters should be making more sense and PowerShell is looking less scary. Let’s say I want to filter by the “family” of operating system. This can be useful when trying to identify computers that started having a special capability in one OS release and all subsequent releases, and where I don’t care about it being server or workstation. An example of that would be BitLocker – it only works on Windows Vista, Windows Server 2008, and later. I run:

    Get-ADComputer -Filter {OperatingSystemVersion -ge "6"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto

    See the change? I am now filtering on operating system version, to be equal to or greater than 6. This means that any computers that have a kernel version of 6 (Vista and 2008) or higher will be returned:

    image

    If I just wanted my Windows Server 2008 R2 and Windows 7 family of computers, I can change my filter slightly:

    Get-ADComputer -Filter {OperatingSystemVersion -ge "6.1"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto

    image

    Getting it all into a file

    So what we’ve done ‘til now was just use PowerShell to send goo out to the screen and stare. In all but the smallest domains, though, this will soon get unreadable. I need a way to send all this out to a text file for easier sorting, filtering, and analysis.

    This is where Export-CSV comes in. With the chaining of an additional pipeline I can find all the computers, select the attributes I find valuable for them, then send them into a comma-separated text file that is even able to read the weirdo UTF-8 trademark characters that lawyers sometimes make us put in AD.

    Hey, what do you call a million lawyers at the bottom of the ocean? A good start! Why don’t sharks eat lawyers? Professional courtesy! What do have when a lawyer is buried up to his neck in sand? Not enough sand! Haw haw… anyway:

    Get-ADComputer -Filter * -Property * | Select-Object Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | Export-CSV AllWindows.csv -NoTypeInformation -Encoding UTF8

    image

    Then I just crack open the AllWindows.CSV file in Excel and:

    image

    What about the whole forest?

    You may be tempted to take some of the commands above and tack on the necessary arguments to search the entire forest. This means adding:

    -searchbase “” –server <domain FQDN>:3268

    That way you wouldn’t have to connect to a DC in every domain for the info – instead you’d just ask a single GC. Unfortunately, this won’t work; none of the operating system attributes are replicated by global catalog servers. Oh well, that’s not PowerShell’s fault. All the data must be pulled from domains individually, but that can be automated – I leave that to you as a learning exercise.

    Conclusion

    The point I made above about support lifecycle is no joke: 2010 is a very important year for a lot of Windows products’ support:

    Hopefully these simple PowerShell commands make hunting down computers a bit easier for you.

    Until next time.

    - Ned “bird dog” Pyle

  • Friday Mail Sack – First Attempt Edition

    Hi all, Ned here again. Today I will share some recent questions we’ve gotten offline that never ended up as full blown blog posts. Naturally any names have been changed to protect the innocent and things are often paraphrased. This post starts a new series that will appear every Friday, barring some kind of disaster such as me being out sick, me taking the day off, or me just not feeling like it (so nyyyaaahhh).

    Onward.

    Question:

    Is there any risk running Windows disk defrag on a DC? I need to defrag my drives and I’m worried about NTDS.DIT corruption.

    Answer:

    Nothing to worry about. In fact, starting in Windows Server 2008 and continuing in R2, you have been running a disk defrag every Wednesday at 1 AM whether you knew it or not. This is default behavior, even on domain controllers.

    image

    Note that the task is designed to run in idle state though, so if things stay really busy on a DC all night long, the automatic defrag may be preempted. The Task Scheduler Help has more info on what “Idle” means.

    Question:

    When I search AD for old computer accounts by using the whenChanged attribute that computers seem to be constantly “new”. How can I find old unused computer accounts using PowerShell?

    Answer:

    The attribute you want to use in this scenario is lastLogonTimeStamp; Warren wrote up a pretty comprehensive treatise in this older post. You can search for these inactive accounts using things like AD PowerShell’s cmdlet search-adaccount. For example, this would find all computers in the domain that have not logged into AD in a year:

    Search-ADaccount -AccountInactive -Timespan 365 -ComputersOnly

    Avoid looking at stale passwords, as password changes can be disabled. And before acting upon inactive accounts, make triple sure it’s really inactive. Cluster virtual computer objects don’t necessarily “logon” but if you arbitrarily get rid of them there will be heck to pay. Automating the removal is generally a bad idea.

    Question:

    I am trying to use the Delegate Control wizard within DSA.MSC. When I use a custom task delegation for User Objects I can’t specify certain attributes like Office, E-Mail, City, State, or Country. How can I get these?

    Answer:

    Choose the inetOrgPerson object class instead of User – this will get you the granularity you need with the delegation wizard. Chalk this up to vagaries of snap-in, schema, class, and inheritance.

    image  image

    Question:

    Application X doesn’t seem to work correctly with Read-Only Domain Controllers, and I am not finding anything online that says it is compatible. What should I do?

    Answer:

    Find out who created that application and talk to their support staff. If it’s a Microsoft application or Windows component, open a support case and ask to speak that particular specialty. If not MS, call that vendor. If internal to your company, find that developer! There’s no way for the AD developers test everything against RODC’s – not even within the MS-developed gamut of applications, which is huge. They have to rely on application developers to add it to their test harnesses. If the conversation with the vendor starts with “What’s an RODC?”, they probably don’t test it. :)

    No matter who you talk to, once it’s established that an RODC is or isn’t supported, make them document it publically; even if it’s just a blog post, you are helping out your fellow IT humans.

    Question:

    Hey, I think I found an error in KB article Y. Can you fix it?

    Answer:

    You betcha. Just tell us exactly what you think is wrong, making sure to give us repro steps. If we confirm it as factual error  the KB should be corrected within a few weeks. If it comes down to semantics or a difference of opinion…well, as my wife says “we’ll just have to agree to disagree” (i.e. Ned is wrong, Lisa is right, and there’s nothing Ned can do about it).

    Question:

    I need some deeper support than this blog is set up for and time is not an issue, but I am a bit strapped for cash. Is there anywhere reputable I can go?

    Answer:

    Our community forums are an excellent place to ask deeper specific questions. These are moderated by MS support engineers and MVP’s. Many questions can be answered quickly and reliably by trustworthy folks.

    If time and live support is critical though, open a support case. Time is money.

    I reckon that’s enough for today. Have a nice weekend folks.

    - Ned ‘going postal’ Pyle

  • Friday Mail Sack – Very Late Edition

    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.

    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

  • USMT Custom XML the Free and Easy Way

    Ned here again. XML is used to configure all aspects of USMT 4.0 migration and is especially important when customizing. Unfortunately most IT staffers are not familiar with XML – why should they be? It’s barely used within Windows and is mainly an applications-specific file store. Maybe you noticed that group policy ADMX files are XML – did you care, since you were using the GP editor to make changes?

    Unfortunately, there’s no USMT XML editor. What’s more, XML follows programming conventions– tags must be closed; nesting must be complete; rules are case-sensitive. And any mistake in the XML will cause the migration to fail or skip crucial steps.

    XML, like any programming file format, has rules. This means that there are tools that can examine that file and see if the rules are being broken – programmers are not super human. One such tool is Visual Studio 2008 Express. It has an excellent suite of XML authoring and validation options – and it’s free :).

    Let’s come up with a scenario that requires custom XML, create our file, and then validate it.

    The Scenario

    End users love wallpaper. I mean they love it, in a manner usually reserved for grandkids, puppies, and their first car. So when you find that USMT doesn’t migrate wallpaper from XP to Windows 7, you know they won’t be pleased.

    After some Internet exploration, you find all the wallpaper settings from XP and the default wallpaper locations are made up of a few registry settings and folders. You have examined our various references, including:

    Now you want to bang out a custom XML file. Most folks are not familiar with VS2008 so I’ll go through this step-by step.

    Authoring

    1. Download and install Visual Studio 2008 Express Edition (.Net), then start it up.

    image

    2. Choose File, New Project, and select “Empty Project”. Call it USMT.

    image

    3. In your new project, select Add then New Item.

    image

    Select XML file and give it a name like “wallpaper.xml”, then add it.

    image

    Click File menu, then Save All. Save your project and files somewhere.

    4. Paste in the following sample that migrates wallpaper and background settings. It’s wrapped for readability:

    <migration urlid="http://www.microsoft.com/migration/externalUserDocs">

      <!-- This component migrates wallpaper settings -->
      <component type="System" context="User">
        <displayName>Wallpapers</displayName>
        <role role="Settings">
          <rules>
            <include>
              <objectSet>
                <pattern type="Registry">HKCU\Control Panel\Desktop [Pattern]</pattern>
                <pattern type="Registry">HKCU\Control Panel\Desktop [PatternUpgrade]</pattern>
                <pattern type="Registry">HKCU\Control Panel\Desktop [TileWallpaper]</pattern>
                <pattern type="Registry">HKCU\Control Panel\Desktop [WallPaper]</pattern>
                <pattern type="Registry">HKCU\Control Panel\Desktop [WallpaperStyle]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes [SetupVersion]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [BackupWallpaper]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [TileWallpaper]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [Wallpaper]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [WallpaperFileTime]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [WallpaperLocalFileTime]</pattern>
                <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [WallpaperStyle]</pattern>
                <content filter="MigXmlHelper.ExtractSingleFile(NULL, NULL)">
                  <objectSet>
                    <pattern type="Registry">HKCU\Control Panel\Desktop [WallPaper]</pattern>
                    <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [BackupWallpaper]</pattern>
                    <pattern type="Registry">HKCU\Software\Microsoft\Internet Explorer\Desktop\General [Wallpaper]</pattern>
                  </objectSet>
                </content>
              </objectSet>
            </include>
          </rules>
        </role>
      </component>

      <!-- This component migrates wallpaper files -->
      <component type="Documents" context="System">
        <displayName>Move JPG and BMP</displayName>
        <role role="Data">
          <rules>
            <include>
              <objectSet>
                <pattern type="File"> %windir% [*.bmp]</pattern>
                <pattern type="File"> %windir%\web\wallpaper [*.jpg]</pattern>
                <pattern type="File"> %windir%\web\wallpaper [*.bmp]</pattern>
              </objectSet>
            </include>
          </rules>
        </role>
      </component>
    </migration>

    It will now look much better, which is one important advantage of using VS 2008 to work with USMT XML: many mistakes can be avoided just by the visual cues of colored letters and proper formatting.

    image

    5. Click the XML menu and choose Schemas… (note that if you don’t select an XML document tab, the menu won’t appear).

    image

    Add in the MIGXML.XSD from your USMT folder. This file defines the schema of USMT XML and will allow Visual Studio to point out further errors.

    image

    6. Open the View menu and select Error List:

    image

    Now you will see all syntax errors in your XML file in real time, both with an underline squiggle, a la MS Word, as well as in the error window below. The sample I gave to paste in is (of course!) perfection, so you have no errors yet.

    Validation

    Let’s create some intentional mistakes to show how Visual Studio can help:

    • Change <component type="System" context="User"> to <component type="System" context="user"> . Note how the lower-case “user” is now underlined and the error list shows “The ‘context’ attribute is invalid.” XML tags are case-sensitive and a lower case user no longer matches the schema defined name of “User”, so an error is raised. Change it back.
    • Change <component type="System" context="User"> to <component type="System" context="SystemAndUser"> . Since the real value must be “UserAndSystem”, the context attribute is invalid. Change it back.
    • Change any <include> tag to <include . The next line will show an underline and “Expecting ‘>’” will appear with a line number. Change it back.
    • Delete any </include> tag. Now you will see an error “Tag was not closed” and “Expecting end tag </include>”. Change it back.

    See how much easier this is than using Notepad? :) The right tool for the job makes all the difference and didn’t cost you a dime. Take a few more of the examples included in Exclude Files and Settings and Include Files and Settings, paste them into some new XML files in your project, and start tinkering. Repetition breeds familiarity. Everything above also works with Visual Studio 2008 Professional of course.

    Save your Wallpaper.XML to the USMT folder and fire up scanstate in a test environment with /i:wallpaper.xml . Your users can now have their old wallpapers migrated free of charge. I’m sure they will thank you. Riiiiiiight.

    Update October 29 2010: If using Visual Studio Express 2010, make sure you click "Tools --> Settings --> Expert Settings" in order to see the XML menu and other feateures described above. We buried a lot in this version...

    Until next time.

    Ned “bliss.bmp” Pyle

  • Friday Mail Sack – Big Picture Edition

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

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

    image

    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

  • USMT and OfflineWinOld: Taking XP to Windows 7 in a Hurry

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

    image

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

    image

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

    image

    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…

    image

    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.

    image

    Open a CMD prompt as an Administrator.

    image

    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:

    image

    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.

    image

    image

    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.

    image

    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

     

    image

    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