Hello all, Eric here again. Today, I wanted to expand a bit on a relatively recent posting that AskDS posted – http://tinyurl.com/askds-post.
I’m sure the escalation engineers have seen that issue a number of times, one of which was with a customer of mine when that customer hit the CritSit button. Obligingly, I escalated after I spent an hour or so stumped as to what happened since I was told that no changes were made. They chose to escalate with good reason though, as their environment was only a few months old and the whole enterprise was Windows Server 2008; that and the Regional Locale preference (which is a bug), was set at the domain level, so the impact was huge.
As far as expanding upon the article, I just wanted to cover a couple of additional points by talking about the issue in a bit more detail and discussing service dependencies. As far as the bug goes, in short, when the Regional Locale preference is applied, it pushes a decimal data value to the locale registry value, when it should be a hexadecimal data value, so in their case their machines had:
HKEY_USERS.DefaultControl PanelInternational Locale (REG_SZ) set to 0001033
while it should have been set to:
HKEY_USERS.DefaultControl PanelInternational Locale (REG_SZ) set to 0000409
As Scott mentions, the work around is to just change the value to the correct one.
The bug impacts/impacted all 2008 servers, but the impact is the greatest on Domain Controllers because DNS generally lives there, and if the DNS service can’t start, clients can’t locate services, which triggers a domino effect of problems, and then everyone is having a bad day.
Note: This happened to me in August of ‘09 and at that time Windows Server 2008 R2 was still in beta, but in testing in my lab environment on Windows Server 2008 R2, I was not able to repro the issue. It was fixed there before the hotfix for 2008 was available. Unfortunately, the RTM wasn’t available for them to deploy or they likely would have the next day.
Also mentioned in the article is that the DNS Server service and Task Scheduler service were also not started. That’s because in Windows Server 2008 they depend on the Windows Event Log service, so if it’s not started neither are they. In Windows Server 2008 R2, ADWS is also added to that list of services that depend on the Windows Event Log service. You won’t find this service dependency listed on the Dependencies tab of the DNS Server, ADWS, or Task Scheduler service properties. That’s the kicker, it’s a hidden dependency.
What actually prompted me to write this blog entry was another case where the bug impacted me. I was testing a 2008 server deployment scenario in my lab and after the automated deployment of the server was added to the domain, I went to go check the event log for something, but couldn’t. The service wasn’t started. Until then, the domain and all of the servers in it were all 2008 R2 (which isn’t impacted), and this was the first time that I’d installed 2008 in the domain to test. I’d forgotten to remove the preference. 😉 Scenarios like that happen quite frequently actually because I never return the lab back to the state that it should be in. It’s kind of good in a way though – it keeps me on my toes.