Hello folks, Ned here again. It’s been a while since I’ve blogged, mainly due to me being a huge dirtbag. Today I discuss USMT, certificates, service packs, DFSR, and other random goo.
Before I get rolling though:
Don’t forget to give to the US Marine Corps Toys for Tots campaign. They distribute new toys to needy children and have been doing it since 1947. Unlike many charitable organizations, the gifts you give to them go right to kids. No monetary donations go to salaries or manpower costs either, so if you give cash you know it’s going to the right place and not to pad some “executive’s” pocket. They usually need more toys for ages 1-3 and 10-14.
You can find a list of toy drop off points here or you can donate cash that they will use to buy toys on your behalf here. Spending ten bucks on a toy at Target will really turn a kid’s Christmas around.
- USMT certificate migration behavior
- Limiting file sizes to replicate in DFSR
- USMT manifest descriptions
- Adding a computer to a specific OU during domain join
- DFSR minimum file permissions
- Other random thoughts
Does USMT 4.0 migrate all certificates or just EFS certificates? What about computer certificates? What about from XP? The TechNet docs are kinda vague.
- Does USMT 4.0 migrate all user certificates or just the EFS certificate?
USMT 4.0 migrates all user certificates regardless of type. This capability is implemented in the included manifests “capi2_certs-dl.man” and “capi2_certs-repl.man” plus in the “crypto_keys-dl.man”. For example:
These user certs are 100% functional and work fine.
- Does USMT 4.0 migrate computer certificates?
Yes and no:
- Yes, the certificates are partially migrated over.
- No, the certificates are not functional.
While the manifests do copy the registry data for computer certificates, the private keys are not copied – this renders those certs useless. Additionally, computer certificates are often based on matching the computer’s name – that subject and SAN will not change so the certificates would not chain even if the private key existed. This was not intentional, it’s a bug that was overlooked for a few years as no customers reported it.
Practically speaking, USMT does not migrate computer certificates. New certs must be issued to the new computers, hopefully using autoenrollment.
Note: the certificates snap-in will claim that the computer certs have a private key, but it is wrong. If you use the command:
CERTUTIL.EXE -VERIFYSTORE MY
… you will see that those certs return error “cannot find the certificate and private key for decryption”.
- Does USMT 4.0 migrate certificates from XP (as USMT 3.01 did not)?
Yes, via manifests “capi2_certs-dl.man” and “crypto_keys-dl.man”. There is no need to export certificates or manually decrypt files when running scanstate on Windows XP, unlike with USMT 3.01.
Can DFSR limit the size of file that is replicated by DFSR? For instance, to ignore any files larger than 100MB.
If the names of the large files are in a predictable format then a filter could be used – i.e. as long as all 100MB files are called “BIG*.*” or “*.BIG” or the like. You can wildcard any form of the name in DFSR file filters. But you cannot filter based arbitrarily on size.
Is there a master list of all the specific individual settings that USMT 4.0 migrates by using the CONFIG.XML file?
Many things can be reverse engineered from examining the included manifests and matching them up with the entries in CONFIG.XML. For example, let’s say I generated a config.xml with /genconfig and I am interested in what “Microsoft-Windows-feclient-DL” is doing.
I would locate that manifest within USMT:
C:\Program Files\Windows AIK\Tools\USMT\amd64\DlManifests
C:\Program Files\Windows AIK\Tools\USMT\amd64\ReplacementManifests
I can use FIND.EXE to do this:
<snipped out a long list>
Aha! It’s implemented in “feclient-dl.man”. Which does all of this:
<pattern type=“Registry“>HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\* [*]</pattern>
<pattern type=“Registry“>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\* [*]</pattern>
Looks this copies over your customized EFS settings. Nifty. I better not turn that one off, I reckon.
And yes, having all these described is on my to-do list. But since there are 350 manifests and various other plug-ins, it will be awhile. In the meantime you will be forced to earn that big salary of yours. 🙂
Is there any way to join a computer to a domain , where the computer account gets created in a specific OU using PowerShell or other command?
Yes, when you join a computer to a domain there are a few options to specify account location:
- Use NETDOM.EXE JOIN /OU This tool is included with Win2008/2008 R2/Win7 RSAT/Vista RSAT/Win2003 Support Tools/XP Support tools.
- Use PowerShell cmdlet “Add-Computer -Domain -OUPath”. This is included with PowerShell 2.0, the version included with Win7/2008R2 and available as a download for other OSs.
- Use DJOIN.EXE PROVISION /MACHINEOU. This tool is included with Win7/2008 R2 and can be used for offline domain joins.
- Pre-create computer accounts wherever you want – when the same named computer is joined to the domain it will use that computer object (as long as the user doing it has permissions).
When is Windows 7 and Windows Server 2008 R2 SP1 coming out?
Please stop asking! I really don’t know!!! I am not keeping it a secret!!!! Arrrgghhh!!!!!!111one.
The only public info I have is first half of 2011. And no, I do not know if there is going to be a Win2008 or Vista SP3 either. And if you ask about Win8 I will just laugh.
I have removed SYSTEM permissions to files being replicated by DFSR, but they are still replicating fine. How can this be?
DFSR does not use permissions to copy files in and out of staging or to replicate, it uses internal backup and restore privileges. That’s because DFSR is using the BackupRead() and BackupWrite() functionality to guarantee it can access those replicated files without issues. The buried treasure is here. And I do mean buried; that’s the only public reference to this anywhere.
You can remove all permissions altogether and not have SYSTEM listed as the file owner and it will continue to work. There’s no way to remove those privileges from SYSTEM via security policy, so you can’t break it either. Even this will replicate fine:
This does not mean that you can delete SYSTEM’s default FULL CONTROL permissions in the DfsrPrivate folder or DFSR database folders though. Doing so will explode DFSR completely and it will stop replicating.
I love when people wonder about stuff working too well. 🙂
So long Ron Santo.
Best email thread seen this week:
Randy (to everyone in North Carolina): “Did anyone take my headset?”
Sean: “I was wondering why Chris was wearing headphones over his headphones today. He said he was trying to get surround sound to work.”
Chris: “Maybe you should include Texas. They might help.”
Make sure you have any Amazon Kindles you are buying sent to your office and not your house. Otherwise your wife will see a box sitting on the porch that is shaped like a Kindle, comes from Amazon, has the Kindle logo on it, and pretty much just says “ATTENTION, THIS BOX CONTAINS A KINDLE, SORRY I RUINED CHRISTMAS.” Gah.
One of our long time readers and all around good guy Mark Morowczynski got a job at Microsoft a few weeks back. They must not be working too hard in PFE since he’s already had time to set up a new blog. Wish him well. It’s always interesting to read new employee blogs, you get to see the evolution of someone coming into the fold and learning a ton of new stuff, then sharing it out. I like biographies.
Next week I will be getting frickin’ laser beams shot into my eyes to correct my inferior genetics. When combined with our holiday short staff it may be a while before folks reply to your comments and emails. Take a break, whydoncha? Your family and friends probably miss you.
Until next time.
– Ned “MS Office’s included clipart is the greatest thing in the history of the planet Earth” Pyle