First published on TechNet on May 27, 2011
here again. It’s a long weekend here in the United States, so today I talk to you tell myself about a domain join issue one can only see in Win7/R2 or later, what USMT hard link migrations really do, how to poke LDAP in legacy PowerShell, time zone migration, and an emerging issue for which we need your feedback.
None of our Windows Server 2008 R2 or Windows 7 computers can join the domain – they all show error:
“The following error occurred attempting to join the domain "contoso.com":
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.”
Windows Vista, Widows Server 2008, and older operating systems join without issue in the exact same domain while using the same user credentials.
Not a very actionable error –
which service do you mean, Windows!?
If you look at the System event log there are no errors or mention of broken services. Fortunately, any domain join operations are logged in another spot –
. If you crack open that log and look for references to “service” you find:
05/27/2011 16:00:39:403 Calling NetpQueryService to get Netlogon service state.
05/27/2011 16:00:39:403 NetpJoinDomainLocal: NetpQueryService returned: 0x0.
05/27/2011 16:00:39:434 NetpSetLsaPrimaryDomain: for 'CONTOSO' status: 0x0
05/27/2011 16:00:39:434 NetpJoinDomainLocal: status of setting LSA pri. domain: 0x0
05/27/2011 16:00:39:434 NetpManageLocalGroupsForJoin: Adding groups for new domain, removing groups from old domain, if any.
05/27/2011 16:00:39:434 NetpManageLocalGroups: Populating list of account SIDs.
05/27/2011 16:00:39:465 NetpManageLocalGroupsForJoin: status of modifying groups related to domain 'CONTOSO' to local groups: 0x0
05/27/2011 16:00:39:465 NetpManageLocalGroupsForJoin: INFO: No old domain groups to process.
05/27/2011 16:00:39:465 NetpJoinDomainLocal: Status of managing local groups: 0x0
05/27/2011 16:00:39:637 NetpJoinDomainLocal: status of setting ComputerNamePhysicalDnsDomain to 'contoso.com': 0x0
05/27/2011 16:00:39:637 NetpJoinDomainLocal: Controlling services and setting service start type.
05/27/2011 16:00:39:637 NetpControlServices: start service 'NETLOGON' failed: 0x422
05/27/2011 16:00:39:637 NetpJoinDomainLocal: initiating a rollback due to earlier errors
Aha – the Netlogon service. Without that service running, you cannot join a domain. What’s 0x422?
# The service cannot be started, either because it is
# disabled or because it has no enabled devices associated
# with it.
Nice, that’s our guy. It appears that the service was disabled and the join process is trying to start it. And it almost worked too – if you run
, it will say that Netlogon is set to “Automatic” (and if you look at another machine you have not yet tried to join, it is set to “Disabled” instead of the default “Manual”). The problem here is that the join code is only setting the start state through direct registry edits instead of using Service Control Manager. This is necessary in Win7/R2 because we now always go through the
offline domain join
code (even when online) and for reasons that I can’t explain without showing you our source code, we can’t talk to SCM while we’re in the boot path or we can have hung startups. So the offline code set the start type correctly and the next boot up would have joined successfully – but since the service is still disabled according to SCM, you cannot start it. It’s one of those “it hurts if I do this” type issues.
And why did the older operating systems work? They don’t support offline domain join and are allowed to talk to the Service Control Manager whenever they like. So they tell him to set the Netlogon service start type, then tell him to start the service – and he does.
The lesson here is that a service set to Manual by default should not be set to disabled without a good reason. It’s not like it’s going to accidentally start in either case, nor will anyone without permissions be able to start it. You are just putting a second lock on the bank vault. It’s already safe enough.
USMT is always going on about hard link migrations. I’ve used them and those migrations are fast… but what the heck is it and why do I care?
A hard link is simply a way for NTFS to point to the same file from multiple spots, always on the same volume. It has nothing to do with USMT (who is just a customer). Instead of making many copies of a file, you are making copies of
how you get to the file
. The file itself only exists once. Any changes to the file through one path or another are always reflected on the same physical file on the disk. This means that when USMT is storing a hard link “copy” of a file it is just telling NTFS to make another pointer to the same file data and is not copying anything – which makes it wicked fast.
Let’s say I have a file like so:
If I open it up I see:
Really though, it’s NTFS pointing to some file data with some metadata that tells you the name and path. Now I will use
to create a hard link:
C:\>fsutil.exe hardlink create c:\someotherplace\bwaamp.txt c:\hithere\bwaamp.txt
Hardlink created for c:\someotherplace\bwaamp.txt <<===>> c:\hithere\bwaamp.txt
I can use that other path to open the same
(it helps if you don’t think of these as files):
I can even create a hard link where the file name is not the same (remember – we’re pointing to file data and giving the user some friendly metadata):
C:\>fsutil.exe hardlink create c:\yayntfs\sneaky!.txt c:\hithere\bwaamp.txt
Hardlink created for c:\yayntfs\sneaky!.txt <<===>> c:\hithere\bwaamp.txt
And it still goes to the same spot.
What if I edit this new "”sneaky!.txt” file and then open the original “bwaamp.txt”?
Perhaps a terrible Visio diagram will help:
When you delete one of these representations of the file, you are actually deleting the hard link. When the last one is deleted, you are deleting the actual file data.
It’s magic, smoke and mirrors, hoodoo. If you want a more disk-oriented (aka:
) explanation, check out
. Rob and Joseph have never met a File Record Segment Header they didn’t like. I bet they are a real hit at parties…
How can I use PowerShell to detect if a specific DC is reachable via LDAP? Don’t say AD PowerShell, this environment doesn’t have Windows 7 or 2008 R2 yet! :-)
One way is going straight to .NET and use the
Returning anything but success is a problem you can then evaluate.
As always, I welcome more in the Comments. I suspect people have a variety of techniques (third parties, WMI LDAP provider, and so on).
Is USMT supposed to migrate the current time zone selection?
Nope. Whenever you use
, you are updating this registry key:
Windows XP has very different data in that key when compared to Vista and Windows 7:
"DaylightName"="Eastern Daylight Time"
"StandardName"="Eastern Standard Time"
"TimeZoneKeyName"="Eastern Standard Time"
The developers from the Time team simply didn’t want USMT to assume anything as they knew there were significant version differences; to do so would have taken an expensive USMT plugin DLL for a task that would likely be redundant to most customer imaging techniques. There
manifests (such as "INTERNATIONAL-TIMEZONES-DL.MAN") that migrate any additional custom time zones to the up-level computers, but again, this does not include the currently specified time zone. Not even when migrating from Win7 to Win7.
But that doesn’t mean that you are out of luck. Come on, this is me! :-)
To migrate the current zone setting from XP to any OS you have the following options:
To migrate the current zone setting from Vista to Vista, Vista to 7, or 7 to 7, you have the following options:
Any of the three mentioned above for XP
Use this sample USMT custom XML (making sure that nothing else has changed since this blog post and you reading it). Woo, with fancy OS detection code!
<?xml version="1.0" encoding="utf-8" ?>
<component type="Application" context="System">
<displayName>Copy the currently selected timezone as long as Vista or later OS</displayName>
<!-- Check as this is only valid for uplevel-level OS >= than Windows Vista –>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\* [*]</pattern>
Question for our readers
We’ve had a number of cases come in this week with the logon failure:
Logon Process Initialization Error
Interactive logon process initialization has failed.
Please consult the Event Logs for more details.
You may also find an application event if you connect remotely to the computer (interactive logon is impossible at this point):
The Windows logon process has unexpectedly terminated.
In the cases we’ve seen this week, the problem was seen after restoring a backup when using a specific third party backup product. The backup was restored to either Hyper-V or VMware guests (but this may be coincidental). After the restore large portions of the registry were missing and most of our recovery tools (SFC, Recovery Console, diskpart, etc.) would not function. If you have seen this,
please email us
with the backup product and version you are using. We need to contact this vendor and get this fixed, and your evidence will help. I can’t mention the suspected company name here yet, as if we’re wrong I’d be creating a legal firestorm, but if all the private emails say the same company we’ll have enough justification for them to examine this problem and fix it.
Have a safe weekend, and take a moment to think of what
really means besides grilling, racing, and a day off.
Ned “I bet SGrinker has the bratwurst hookup” Pyle