It should come as no surprise to learn that I set up a lot of Active Directory (AD) environments. I also advise many people about setting up AD environments. I work with large and midsized enterprises, but in truth there are far, far more small AD implementations than large ones. For that reason, I find it troubling that a small AD environment’s domain controllers (DCs) are prone to worrisome and time-consuming—but at the same time innocuous—error messages.
For example, try setting up AD with just one DC. (Yes, I know that a one-DC domain isn’t a great idea, but some people feel that they just plain can’t justify buying a second DC in a small network.) If you then set up the domain’s DNS zone as an AD-integrated zone, every time you boot up the DC, you’ll get scary-looking error messages in the event log about an inability to register or de-register a DNS record dynamically. What’s happening is this: Your DC wants to register a bunch of SRV records in the domain’s DNS zone. However, before it can do that, the DC must log on to the domain. Unfortunately, there’s only one DC in the domain—itself—and inasmuch as its main logon processing code isn’t up yet, the DC can’t get logged on. Which means DNS won’t accept the DC's attempts at registration. Which prevents the DC from putting the SRV records into the domain. Which means the DC can’t find a DC. And so on, and so on. The root problem is that the DC is running a lot of services—and parts of services—that need each other to start up, and because those services take varying amounts of time to start, sometimes one service isn’t yet ready to talk to another service. Microsoft could have fixed this problem with a bit of tweaking, but the company apparently never thoroughly tested a one-DC domain, and so we have the error.
This problem isn’t merely cosmetic. The conscientious new administrator would, and should, take any red “X’s” in the event log quite seriously. I wonder how many millions of hours new AD admins have spent trying to solve this problem. Worse, how many admins are experienced enough to know when AD is merely “crying wolf” but have managers who don’t believe them? Many admins have told me, “I know this can be ignored, but my manager insists on ‘no red’ in the event log.”
And I haven’t chosen an isolated case. In the past few weeks, I’ve seen the nearly ubiquitous Microsoft Distributed Transaction Coordinator (MS DTC) error, in which MS DTC claims that it can’t process a “promotion or demotion event.” The fix is simple: Open the Microsoft Management Console (MMC) Component Services snap-in, navigate to your computer’s Properties page's MS DTC tab in that snap-in, click the Security Configuration screen, click OK, and return to the Properties page. Start and stop the MS DTC service, and the problem goes away.
And then there’s the dire warnings that the system issues to the creator of an AD implementation: He or she must move the infrastructure master role or the domain will fall to pieces. In truth, in a single-domain forest (which, I would bet, is the case for at least 95 percent of domains), the infrastructure master role not only isn’t used, it’s completely unnecessary.
So, here’s my suggestion. In every log except the Security log, there are three kinds of events: information events, which appear blue; warning events, which appear yellow; and error events, which appear red. Why not a class of almost errors, items that aren’t attractive but aren’t a great injury, either? They’re more like a bruise. I think purple would be a great color for that.
In the end, I understand that although the vast majority of AD setups are no larger than one domain and typically contain no more than two DCs, that majority doesn’t constitute much in the way of profit for Microsoft. But it would be a great help to many.
