First published on TechNet on May 27, 2011
Hi folks, Ned 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:
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 – %systemroot%\debug\netsetup.log . 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?
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 services.msc , 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 FSUTIL.EXE to create a hard link:
I can use that other path to open the same data (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):
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: yaaaaaaawwwwnnn ) explanation, check out this article . 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 DirectoryServices namespace:
For example:
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 timedate.cpl , you are updating this registry key:
Windows XP has very different data in that key when compared to Vista and Windows 7:
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 are 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:
We’ve had a number of cases come in this week with the logon failure:
You may also find an application event if you connect remotely to the computer (interactive logon is impossible at this point):
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 Memorial Day really means besides grilling, racing, and a day off.
Ned “I bet SGrinker has the bratwurst hookup” Pyle
Hi folks, Ned 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.
- Cannot join a domain with error "service cannot be started"
- USMT hardlink migrations
- PowerShell LDAP pings
- USMT time zone migration
- Question for our readers
Question
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.
Answer
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 – %systemroot%\debug\netsetup.log . 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?
c:\> err.exe 0x422
ERROR_SERVICE_DISABLED winerror.h
# 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 services.msc , 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.
Question
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?
Answer
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:
c:\hithere\bwaamp.txt
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 FSUTIL.EXE 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 data (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: yaaaaaaawwwwnnn ) explanation, check out this article . Rob and Joseph have never met a File Record Segment Header they didn’t like. I bet they are a real hit at parties…
Question
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! :-)
Answer
One way is going straight to .NET and use the DirectoryServices namespace:
New-Object System.DirectoryServices.DirectoryEntry(LDAP:// yourdc :389/dc= yourdomaindn )
For example:
Yay!
Boo!
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).
Question
Is USMT supposed to migrate the current time zone selection?
Answer
Nope. Whenever you use timedate.cpl , you are updating this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ TimeZoneInformation
Windows XP has very different data in that key when compared to Vista and Windows 7:
|
Windows XP |
|
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] |
|
"ActiveTimeBias"=dword:000000f0 |
|
"Bias"=dword:0000012c |
|
"DaylightBias"=dword:ffffffc4 |
|
"DaylightName"="Eastern Daylight Time" |
|
"DaylightStart"=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00 |
|
"StandardBias"=dword:00000000 |
|
"StandardName"="Eastern Standard Time" |
|
"StandardStart"=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00 |
|
Windows 7 |
|
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] |
|
"ActiveTimeBias"=dword:000000f0 |
|
"Bias"=dword:0000012c |
|
"DaylightBias"=dword:ffffffc4 |
|
"DaylightName"="@tzres.dll,-111" |
|
"DaylightStart"=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00 |
|
"DynamicDaylightTimeDisabled"=dword:00000000 |
|
"StandardBias"=dword:00000000 |
|
"StandardName"="@tzres.dll,-112" |
|
"StandardStart"=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00 |
|
"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 are 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:
- Using SCCM: Use the "Migrate time zone option" in the "Capture Windows Settings" step of the task sequence.
- Using MDT: http://blogs.technet.com/b/deploymentguys/archive/2010/01/11/setting-mdt-time-zone-variables-from-the-source-os-time-zone.aspx
- Using PowerShell: http://blogs.technet.com/b/deploymentguys/archive/2009/06/07/setting-the-time-zone-using-windows-powershell.aspx
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" ?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/currenttimezonesample">
<component type="Application" context="System">
<displayName>Copy the currently selected timezone as long as Vista or later OS</displayName>
<role role="Settings">
<!-- Check as this is only valid for uplevel-level OS >= than Windows Vista –>
<detects>
<detect>
<condition>MigXmlHelper.IsOSLaterThan("NT", "6.0.0.0")</condition>
</detect>
</detects>
<rules>
<include>
<objectSet>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>
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):
ID: 4005
Source: Microsoft-Windows-Winlogon
Version: 6.0
Message: 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 Memorial Day really means besides grilling, racing, and a day off.
Ned “I bet SGrinker has the bratwurst hookup” Pyle
Updated Apr 05, 2019
Version 2.0
NedPyle
Microsoft
Microsoft
