Gary here, and in this post I am going to talk about USMT and the Links folder not migrating from Vista or Windows 7. This folder is new starting with Vista so it would not be an issue coming from XP to the higher versions of Windows.

In case you are wondering what the Links folder is, it is the Favorite Links or Favorites for Explorer.

   
Windows Vista                                              Windows 7

It also corresponds to the %userprofile%\Links folder with in the user’s profile.

If you are using the migdocs.xml file, it uses the GenerateDocPatterns helper function to go collect most of the user profile folders. It is also worth noting that the miguser.xml file also has the same issue, but use of that file is discouraged regardless. The following table lists the profile folders gathered from each user’s profile directory as documented at “Migration XML Files” site for USMT.

As you see, the list above does not include anything indicating the Link folder would be touched. To gather and restore the LINKS folder you can use the following sample. Please do not modify the migdocs.xml (or miguser.xml) file as you can easily include the additional XML file in the command line. In addition, it would prevent any potential conflicts if newer versions are released and overwrite your hard work.

scanstate.exe c:\store /i:migapp.xml /i:migdocs.xml /i:miglinks.xml
loadstate.exe c:\store /i:migapp.xml /i:migdocs.xml /i:miglinks.xml

<?xml version="1.0" encoding="utf-8" ?>
<!--Sample - migrates user Links (aka quicklaunch) folder from Vista/7 to Vista/7-->
<!--This code is NOT necessary when going from XP to Vista/7 -->
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migratelinks">
<component type="Documents" context="User">
<displayName>Migrate Links Folder</displayName>
<role role="Data">
<rules>
<include>
  <objectSet>
   <pattern type="File">%CSIDL_PROFILE%\Links\* [*]</pattern>
  </objectSet>
</include>
</rules>
</role>
</component>
</migration>

With the use of the above information, you will be able to preserve the user’s Links folder from Vista/7 to Vista/7 migrations.

Happy link migrations!

Gary “look, a USMT post from someone besides Ned is possible” Mudgett

[Editor’s note: this is a reprinted post from the AD Troubleshooting Blog. If you’re not already a subscriber to that blog, you absolutely need to add it to your feed. Ingolfur is a Sr. Support Escalation Engineer in Sweden and a very smart dude - with rather odd hair - who deserves your attention. Make sure you keep this post in your back pocket; if you ever need it, you are going to need it in a hurry  – Ned]

Consider the following disaster recovery scenario:

• The CA has become temporarily unavailable, the current CRL and Delta CRL have expired and revocation checking is failing which is preventing smartcard logons.

• You have the private/public key pair of the CA certificate available and want to quickly get a new valid CRL out for revocation checking to start succeeding again.

For this scenario, as long as the private/public key pairs exist you can manually sign a CRL and publish it to get breathing room while you recover the original CA server installation. Even if it only exists in a PFX file and the original CA server is gone you should still be able to import the PFX file to another server and do the re-signing parts there - the key point is getting an updated valid CRL out that you can publish so that clients and domain controllers can locate CRL's so that CRL-checking will succeed again.

Example: to sign a new CRL that is valid from the current time and 14 days into the future, you can run the following if the private key of the CA that signed the CRL exists locally:

certutil -sign <old expired CRL file.crl> <new valid CRL file.crl> now+14:00 -2.5.29.46

This will produce a new valid CRL file that you can then publish to the CDP locations that are defined on the issued certificates. The -2.5.29.46 option removes any existing Delta CRL from the new CRL so you don't have to worry about having to publish a new Delta CRL if any was present on the old CRL.

How you publish the CRL depends on the CDP, for an HTTP CDP you would most likely need to manually copy the CRL file to the web server. For an LDAP CDP you should be able to use Certutil to publish the CRL.

Example: to publish the CRL to the issuing SubCA object:

certutil -dspublish <new valid CRL file.crl> SubCA

This should publish the updated valid CRL to the issuing CA's object in Active Directory.

Further details:
http://blogs.technet.com/b/instan/archive/2008/12/08/requiring-smart-cards-for-logon-avoiding-the-outage-caused-by-expired-crl-s.aspx

- Ingolfur Arnar Stangeland

Hi folks, Ned here again. I’m trying to get back into the swing of having a mail sack every week but they can be pretty time consuming to write (hey, all this wit comes at a price!) so I am experimenting with making them a little shorter. This week we talk AD PowerShell secrets, USMT and Profile scalability, a little ADUC and DFSR, and some other random awesomeness.

• Get-ADComputer and IP lookups
• USMT profile migration limits
• DSA.MSC and finding computers
• DFSR read-only disconnection
• Other things

Question

Can you explain how the AD PowerShell cmdlet Get-ADComputer gets IP information? (ex: Get-ADComputer -filter * -Properties IPv4Address). Properties are always AD attributes, but I can not find that IPv4Address attribute on any computer object and even after I removed the A records from DNS I still get back the right IP address for each computer.

Answer

That’s an excellent question and you were on the right track. This is what AD PowerShell refers to as an ‘extendedAttribute’ internally, but what a human might call a ‘calculated value’. AD PowerShell special-cases a few useful object properties that don’t exist in AD by using other LDAP attributes that do exist, and then uses that known data to query for the rest. In this case, the dnsHostName attribute is looked up normally, then a DNS request is sent with that entry to get the IP address.

Even if you removed the A record and restarted DNS, you could still be returning the DNS entry from your own cache. Make sure you flush DNS locally where you are running PowerShell or it will continue to “work”.

To demonstrate, here I run this the first time:

Which queries DNS right after the powershell.exe contacts the DC for the other info (all that buried under SSL here, naturally):

Then I run the identical command again – note that there is no DNS request or response this time as I’m using cached info.

It still tells me the IP address. Now I delete the A record and restart the DNS service, then flush the DNS cache locally where I am running PowerShell, and run the same PowerShell command:

Voila! I have broken it. :)

Question

Is there is a limit on the number of profiles that USMT 4.0 can migrate? 3.01 used to have problems with many (20+) profiles, regardless of their size.

Answer

Updated with new facts and fun, Sept 1, 2011

Yes and no. There is no limit real limit, but depending on the quantity of profiles and their contents, combined with system resources on the destination computer, you can run into issues. If possible you should use hardlink migration, as that as fast as H… well, it’s really fast.

To demonstrate (and to show erstwhile USMT admins a quick and dirty way to create some stress test profiles):

1. I create 100 test users:

2. I log them all on and create/load their profiles, using PSEXEC.EXE:

3. Copy a few different files into each profile. I suggest using a tool that creates random files with random contents. In my case I added a half dozen 10MB files to each profile’s My Documents folder. You can’t use the same files in each profile, as USMT is smart enough to reuse them and you will not get the real user experience.

4. I run the harshest, slowest possible migration I can, where USMT writes to a compressed store on a remote file share, with AES_256 encryption, from an x86 Windows 7 computer with only 768MB of RAM, while cranking all logging to the max:

This (amazingly, if you ever used USMT 3.01) takes only 15 minutes and completes without errors. Loadstate memory and CPU isn’t very stressful (in one test, I did this with an XP computer that had only 256MB of RAM, using 3DES encryption).

5. I restore them all to another another computer – here’s the key: you need plenty of RAM on your destination Windows 7 computer. If you have 100 profiles that all have different contents, our experience shows that 4GB of RAM is required. Otherwise you can run out the OS resources and receive error “Close programs to prevent information loss. Your computer is low on memory. Save your files and close your programs: USMT: Loadstate”. More on this later.

This takes about 30 minutes and there are no issues as long as you have the RAM.

6. I bask in the turbulence of my magnificence.

If you do run into memory issues (so far we’ve only seen it with one customer since USMT 4.0 released more than two years ago), you have a few options:

a. Validate your scanstate/loadstate rules – despite what you may think, you might be gathering all profiles and not just fresh ones. Review: http://blogs.technet.com/b/askds/archive/2011/05/05/usmt-and-u-migrating-only-fresh-domain-profiles.aspx. Hopefully that cuts you down to way fewer than 100 per machine. Read that post carefully, there are some serious gotchas: such as once you run scanstate once on a computer, all profiles are made fresh afterwards for any subsequent scanstate runs. The odds that all 100+ profiles are actually active is pretty unlikely.

b. Get rid of old XP profiles with DELPROF before using USMT at all. This is safer than UEL, as like I mentioned, once you run scanstate that’s it – it has to work perfectly on the first try, as all profiles are now “fresh”. (On Vista+ you instead use http://support.microsoft.com/kb/940017, as I’m sure you remember)

c. Get more RAM.

Question

Is it possible in DSA.MSC to have the Find: Users, Contacts, and Groups default to finding computers or include computers with the user, contacts, and groups? Is there a better way to search for computers?

Answer

The Find tool does not provide for user customization – even starting it over without closing DSA.MSC loses your last setting. ADUC is a cruddy old tool, DSAC.EXE is the (much more flexible) replacement and it will do what you want for remembering settings.

There are a few zillion other ways to find computers also. Not knowing what you are trying to do, I can’t recommend one over the other; but there’s DSQUERY.EXE, CSVDE.EXE, many excellent and free 3^rd parties, etc.

Question

If I delete or disable the outbound connection from a writable DFSR replicated folder, I get warning that the “topology is not fully connected”. Which is good.

But if that outbound connection is for a read-only replica, no errors. Is this right?

Answer

It’s an oversight on our part. While technically nothing bad will happen in this case (as read-only servers - of course - do not replicate outbound), you should get this message in all cases (There are also 6020 and 6022 DFSR warning events you can use to track this condition). A read-only can be converted to a read-write, and you will definitely want an outbound connection for that.

We’re looking into this; in the meantime, just don’t do it anywhere. :)

Other Things

• Cubs-Red Sox this weekend. This is their first meeting since 1918, and there is a lot of interesting history between the teams. The least we can do is help the Sox to a three game winning streak… >_<

Just to make myself feel better: “Little roller up along first. Behind the bag! It gets through Buckner!”

• If you have parents, siblings, children away at college, nephews, cousins, grandparents, or friends, we have the newest weapon in the war on:

1. Malware
2. Your time monopolized as free tech support

Yes, it’s the all new, all web Microsoft Safety Scanner. It even has a gigantic button, so you know it’s gotta be good. Make those noobs mash it and tell you if there are any problems while you go make a sandwich.

• Finally: thank goodness my wife hasn’t caught this craze yet. She has never met a shoe she didn’t buy.

Have a nice weekend folks.

Ned “86 years between championships? That’s nothing… try 103, you big babies!” Pyle

Hi folks, Ned here again with a quick public service announcement:

Are you running Windows Vista Service Pack 1? SP1 support ends on July 12, 2011 - that's barely two months from now. Once that happens, computers running Vista SP1 do not get further security updates, MS Support will insist on SP2 installation before further troubleshooting, and you are generally in a world of hurt. Service Pack 2 has been out for two years; it's time to make it happen, IT pros.

• Download Vista SP2 (x86 version)
• Download Vista SP2 (x64 version)

Obviously, an even better option is installing Service Pack 7.

Chop chop!

- Ned 'I still run NT 4.0 SP3 just to be a jerk" Pyle