Document copyright 2012 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.
Hi all —
As I've done the R2 class (and if you've been thinking of attending, there are only three more sessions -- Philly in three weeks, Phoenix in late June and the Washington, DC area in September) , I've gotten a fair amount of questions about what folks have to do to get ready to start adding Windows Server 2008R2 (or, for that matter, Windows Server 2008) DCs to their domains. I feel dumb for not having covered it before, mostly because I'm an OS geek and so I get my domains on the latest version of Server when it appears, but of course in the real world most IT folks have, well, a few other priorities. Anyway, getting a forest ready for R2 is actually pretty easy and I'm sure that many of you are already pretty far down "the R2 road," but for those who've only recently gotten the go-ahead from On High to start adding 2008 or 2008R2 DCs to their forests, I've put together a few articles, the first of which is here. I hope it's a useful read and contains a new idea or two but first, a word from our sponsor ...
Prepping for your First R2 (or 08) Domain Controller, Step One
Windows Server 2003's a pretty good product... so good, in fact, that an awful lot of folks haven't yet moved their Active Directories from 2003 to 2008 or 2008 R2. At least, that's what I hear from a lot of people who ask me, "what's' involved in adding my first 2008/2008 R2 DC?" Fortunately, it's fairly simple to move to 08/8R2, but there are a few wrinkles, so here's the first in a short series of newsletters on what to watch for when moving up to 08 or 08R2. As I see it, there are four issues:
Ready to start moving from 2003? Let's take up the first hurdle...
Step Zero: Not Every Forest Can Upgrade
Minor item, but I should mention in passing that you can't add a 2008 or R2 DC to a forest that is in 2000 Mixed Mode, or 2003 Interim Mode. If you're not sure what functional level your forest is currently at, open up Active Directory Domains and Trusts, right-click on the icon labeled "Active Directory Domains and Trusts" and then click on "Raise forest functional level." In the resulting dialog box, you'll see your current forest functional level, like this:
In that case, you see that I'm working from a forest in 2008 R2 forest functional level. If you do have a forest in 2000 Mixed or 2003 Interim level, then you must have had NT 4 domain controllers in your network at some point... but if you do, it may be time to consider bidding them a fond farewell. Once they're gone, you can go to 2000 Native Mode or 2003 Forest Functional Level, and then you'll be ready to start thinking about incorporating 2008 or R2 DCs.
Step One: Check the Pipes with Repadmin
(Note: this first step will be obvious so some readers -- I'm going to talk about doing some AD replication tests -- so if that sounds like a diagnostic that you know well and do every day, then feel free to skip this. Otherwise, welcome, I hope this is useful!)
In general, adding your first 08/08r2 DC is pretty risk free, unless there's an existing problem in your AD, in which case trying to add your first 08/08R2 DC is the moral equivalent of making an asthma sufferer run a marathon during pollen season. It's not terribly unusual for me to run into the odd AD that's been running for seven years that seems okay... but isn't. Maybe one of the DCs has somehow dropped off the radar from the point of view of the other DCs, but that DC doesn't know that it's out of touch -- and maybe even thinks that they've all gone away, and has decided to go all Al Haig on the domain. Maybe Sysvol stopped replicating on a DC because on 2003, Sysvol shuts itself off if it sees less than a gigabyte free on its volume, without leaving any events behind, without telling you that it shut itself off, and, well, without telling you anything. (And there are a number of equally dumb reasons why Sysvol gets unhappy, which is a major reason why you want to at least get to 2008 domain functional level, because at that point you can kiss the old Sysvol transport system (FRS) goodbye and move up to DFS-R... but that's a story we'll cover later.) Or, heaven forbid, your schema FSMO's offline and no one's noticed because, well, you really don't change your schema all that often... but you're going to have to change the schema before you can add your first 08/08R2 DC.
Basically what I'm saying is that if you think of your DCs as toilets and your AD replication pathways as pipes (which is, I know, not something you normally hear, but trust me, it'll work), then before we start trying to put in a few of those fancy toilets with the seat warmer and the cleansing spray (those are the AD features in this metaphor), let's just flush all the toilets and make sure that the pipes don't leak before we put any strain on the system. If anything's wrong with AD, let's find that out and get it fixed now, before we start changing things. And where, then, is the flush handle? It comes with the finest AD replication tool in the land, "repadmin."
In case you're not currently using repadmin, it first arrived as a Resource Kit tool back in Server 2000 and 2003, and "went legit" in 2008, where it's built into the OS. It is a command-line tool, so try it out on a repadmin-equipped system by opening up a command prompt and typing
repadmin /syncall dcname
Where dcname is the host name of the DC you're sitting at, so for example if I'm sitting at a machine named DC64.bigfirm.com, I'd type
repadmin /syncall dc64
Yes, it's goofy to have to type the name of the system you're sitting at, but they wrote repadmin back in the days when no one had firewalls on their servers, and so the idea was that you could sit at one system and issue "replicate now!" commands to any number of DCs. Several versions of repadmin ago, you could just use a period to mean "this server I'm sitting at," as in
repadmin /syncall .
but that stopped working in 2008, if memory serves. Anyway, let's dissect what this does. "/syncall" says, "contact all of your replication partners and ask them to tell you about anything that's changed since the last time you asked them." Now, given that systems created with 2003 SP1 or later check in with their partners every 15 seconds and earlier systems check in every five minutes, it's likely that your DC won't learn anything new from its partners, but that doesn't matter; instead, what matters is just one thing: seeing The command completed successfully. Trust me, sweeter words an admin cannot read. Again, we don't really care what got delivered -- we care that the pipes are clear, and that validates it.
But what did we replicate? Interestingly enough, we essentially replicated the schema, and, again, given that we don't change the schema much, we had no real reason to replicate much. More accurately, we replicated the "configuration naming context," a combination of the schema and a sort of "executive summary" of the forest -- none of which, like the schema, changes all that often, as it's basically a list of the domains, FSMOs, and domain controllers in the forest.
Next, go do that on every DC in the forest. We're about to change the schema, and the schema is a forest attribute, not a domain attribute, so we want to be 100 percent sure that every DC in the forest is ready, willing and able to accept schema changes.
Dealing With Troubled DCs
Did your DCs pass? If so, excellent... we've got another tests to try, and I'll cover it in a minute. But what if repadmin failed on a DC or two? In that case, take a minute and identify the bad DC. If you have three DCs named DC1, DC2 and DC3 and DC3 is malfunctioning, then all three of your repadmin commands will show at least one failure -- but a closer look will show that when you run it on DC1, then the replication to DC2 works but the replication to DC3 fails, repadmin on DC2 works with DC1 but fails with DC3, and all replications from DC3 fail... which pretty much pulls the chain on DC3.
Once you know that DC3 is troubled, you've got a couple of options. First, you can spend some time (or perhaps a lot of time) trying to figure out what's wrong with it. If you do that, and if you succeed, then terrific, my hat's off to you, but let me let you in on a little AD old-timer secret: it's usually not worth spending a lot of time on one troubled DC. Believe or not, one of the best AD repair and diagnostic tools is DCPROMO. If I've got a troubled DC, I like to run DCPROMO to "un-DC" it, and then run DCPROMO again to try to re-promote it. Sometimes that solves the whole problem, and we can just go on working. Other times, though, DCPROMO fails, and when it does, it leaves some very useful logs in \windows\logs that can help smoke out the problem.
Either way, my advice is the same: don't start moving to 08 or 08R2 until your DCs are all working well. So if you've got a DC that simply can't replicate, get it off your AD. As it can't really replicate, the safest way to remove it is a three-step process:
In either case, we're doing that same thing: ripping a DC out of AD by its roots. Once that's gone, run your repadmin tests again and all should be well. Eventually you should try running DCPROMO on the troubled systems to make them DCs again, but before we do that, let's get that first 2008/2008R2 DC in the forest. Before we do that, however, let's do one more test.
Replicate the Domain Naming Context
So far, we've used repadmin to check the way all of the DCs in our forest replicate the "configuration naming context." I suggested that you do that first because the configuration naming context (let's abbreviate that to "configuration NC") contains the schema and, again, we're going to update the schema. The phrase "naming context," by the way, essentially means "database," and as I've already said, the configuration NC is a relatively small bit of overview data on the forest. Every domain in the forest also has an NC of its own, so if your forest had, say, five domains in it, then you'd have six NCs in your forest -- one for each domain, and the one configuration NC for the whole forest. (DNS can also have something like an NC, but we needn't worry about it here.)
Before moving in the new DC, then, we'll want to know not only that the configuration NC replicates without trouble but also that the NC for the domain where we're going to add our first 2008 or R2 DC also replicates. Now, in 99.9% of the cases where I've done this, I've not encountered a problem, inasmuch as long as the configuration NC replicates okay then the domain NC replicates okay as well, but it doesn't hurt to try. To force replication on a DC's naming context, the repadmin command looks like
repadmin /syncall dcname LDAP-name-of-domain
As you may know, many AD tools don't want you to express the name of your domain as something like "UK.bigfirm.com" but instead "dc=UK,dc=bigfirm,dc=com," the "LDAP-ese" way of expressing it. In that case, supposing that you were running repadmin on a DC called Surry.uk.bigfirm.com, you'd type
repadmin /syncall surry dc=uk,dc=bigfirm,dc=com
Again, do that for all of the DCs in that domain, and remove any troublemakers. Once you've gotten all that done, you'll be ready for the next step, ADPREP... and I'll cover that in the next newsletter.
To Subscribe, Read Old Newsletters, Send Me a Comment or Change Your Email Address
To subscribe: (which just means I'll send you about a tweet-sized message in plain text via email including a link to my latest newsletter), please visit http://www.minasi.com/nwsreg.htm.
To change e-mail or other info, link to http://www.minasi.com/edit-newsletter-record.htm.
To read old newsletters: visit http://www.minasi.com/nwstoc.htm and, if you like 'em, please consider subscribing.
To send me a comment: please visit http://www.minasi.com/gethelp.
All contents copyright 2012 Mark Minasi. I encourage you to quote this material, SO LONG as you include this entire document; thanks! See you next month.