Document copyright 2012 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.
Hi all —
As I said last month, I've done the R2 class (just two more sessions on the schedule!) enough to have 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. Last month I talked about what might be called "Step Zero," a simple check of your current AD health status before proceeding to R2 or 2008. This month, we'll continue looking into forcing AD replication a bit, do some Sysprep checks and then finally it'll be time to do ADPrep. As I observed before, 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 hope it's a useful read and contains a new idea or two. Before that, however, a word from our sponsor ...
Don't Miss ITEdge Intersection!
Windows Server 2016 is coming, are you ready? Server 2016 and many other important topics are the focus of ITEdge Intersection at the MGM Grand in Las Vegas, Oct 25-29. Your favorite speakers are there, including Scott Guthrie, Brad Anderson, Jeffrey Snover and of course, Mark Minasi. Register today for the conference and a workshop and you can go home with an XBOX One S, Surface 3 table or MS Band 2. Register at www.itedgeintersection.com.
Bring Mark's Windows 10 Support Class and Our PowerShell Classes to Your Site
Mark has delivered his new "Deploying, Managing and Securing "the Last Windows: Working with Windows 10" class to nearly a dozen clients, and the reviews are uniformly great. Designed for the Windows 7 support pro, this course tells you everything you need to know to support, deploy, or manage Windows 10 systems. Fast-paced, lecture-based and entertaining, this course gives you the shortest path to Windows 10 expertise. Learn about Windows 10's completely new licensing approach. See how to enable the new "parallel universe" security tools. Discover the cloud-y new tools in Windows 10 like joining a system not to an Active Directory but instead to a cloud. Find out what you can learn at our course outline at http://www.minasi.com/w10class.htm.
To bring this class to your site, just drop us a line at email@example.com.
And while you're at it, are your folks PowerShell adepts? There really isn't a productivity-enhancer available for Windows support people like PowerShell. Bring Mark's "Learning PowerShell: Hands-On with AD, Networking, and More" class to your site and he'll make your command-line-hating techies into PowerShell fans. Outline at http://www.minasi.com/Posh2day/.
Sysvol SHAKEDOWN: Prepping for your First R2 (or 08) Domain Controller, Step Two
Last issue, we started prepping to install our first 2008 or 2008 R2 domain controller. In that issue, I said that I've found it wise over the years to kick a forest's tires a bit, so to speak, before even thinking about adding a new kind of DC, and that I felt that a good basic test was to force replication of a forest's "configuration naming context," a database containing the structure of the forest's AD (the schema), its DCs and domains by typing something like
repadmin /syncall dc1
Which would get dc1 to try replicating with its partners. What I didn't mention was that if you've got more than one site in your AD then you might want to add "/e," as in
repadmin /syncall dc1 /e
A simple "/syncall," you see, only causes the domain controller that you're running the command on to replicate with its partners in the same site as it, skipping replication with any DCs in a different site. "/e" says, "... and also replicate with your distant replication partners, if any." (Powerful tool, that repadmin, eh? Trust me, if you're doing AD for ages, there will always be new things to learn with repadmin.)
The same would go for a replication not only on the configuration naming context, but also on a given domain, as in
repadmin /syncall dc1 /e dc=bigfirm,dc=com
Which would cause DC1 (a domain controller in a domain named "bigfirm.com") to replicate with all of its partners, both near and far.
Time to Check Sysvol
We're all friends and I hate to bring up a delicate subject, but... have you checked your Sysvol lately? As you probably know, Sysvol is a share you can find on every domain controller, a share that contains files needed by DCs -- the big ones are the file components of group policy objects (GPOs), pieces called "group policy templates" or GPTs, as well as login scripts.
Sysvol is a neat, built-in implementation of DFS (Distributed File Services) that is multi-master, meaning that if you have four DCs named (unimaginatively, but I kind of like simplicity in my names) DC1, DC2, DC3 and DC4, then you can drop a file into any one of those four instances of Sysvol, and eventually DFS will ensure that there's a copy of that file in each of the other three Sysvols. The fact that you can introduce a new file into the family of Sysvols is why it's said to be "multi-master." The alternative would be a system whereby you could only add a new file to all Sysvols from one DC, which isn't the case. (That'd be a "single master" system.) Of course, DCs do that when you make changes to AD accounts -- you can, of course, create a new user account on any DC and it'll soon appear in all DCs.
One sort of annoying difference between AD replication and Sysvol replication is the lack of a repadmin-like tool for Sysvol. That improves a bit in Server 2008, but trust me, there is no reliable way to force Sysvol replication across WAN links in 2000 and 2003, at least prior to 2003 SP2. If you stop and start the File Replication Service on 2000 or 2003 then you'll get immediate local Sysvol replication and sometimes immediate across-the-WAN replication, but there's no promise about the "immediate" part. On 2003 SP3 and later, there's a command that lets you force replication between a source DC (DC3, in this example) and a destination DC (DC2, in this example) that looks like this:
ntfrsutl.exe forcerepl DC2 /r "Domain System Volume (SYSVOL share)" /p DC3
Unlike AD replication, Sysvol replication failures are, um, not entirely unheard-of, and so really, checking Sysvol before moving forward a notch or two in Server versions is an important set of tests. To see that every DC's Sysvol can and does replicate to every other DC, there are a number of tools, but here's the simplest one I know. Ready?
Go to a DC. In its Sysvol, create a file. Just a simple text file will do. Call it dcname.txt, so for example on a domain controller called dc6.bigfirm.com, create a file in its sysvol named dc6.txt. More specifically, log onto the DC and open a command prompt. (Elevated, if you're running Server 2008 or later.) Then type
copy con \\servername\Sysvol\domainname\servername.txt
So, in the case of a domain controller named DC6 in a domain named bigfirm.com, you'd type
copy con \\dc6\sysvol\bigfirm.com
And then just type any text followed by the F6 key (or ctrl-Z, either one works), and you'll see
1 file(s) copied.
(You'd think that with all of the zillions of programmers Microsoft has that they could write some code that says, "if the number of files copied equals 1, then display 'number file copied' and otherwise display 'number files copied.'" Every new version of Windows, I keep hoping, to no avail...)
Now you will have created a small text file whose name reflects the DC that you created it on. Do this for every DC, and wait for a bit. (Or perhaps use the ntfrsutl command.) Then go to each DC and look in its Sysvol... there should be a file for each domain controller. If there isn't, do a bit of analysis. If DC4's dc4.txt shows up nowhere, then DC4 probably has the problem.
Once you've isolated the Sysvol-troubled DC, do what we did before: get rid of it. Run DCPROMO to un-DC it and, if the rest of the network doesn't see that you've un-DCed it, then remove the DC's account from the Domain Controllers OU and remove its metadata, as mentioned in the last article. Then try creating another unique file in each DC's Sysvol, and validate that all's well in your AD. Once you're there, it's time for the next big step.
Before you can install your first 2008 R2 or 2008 DC in your domain, you've got to get both the forest ready and the domain ready. The forest's involvement is the greater of the two, as in every case I can think of we've had to modify the structure of AD, the "schema," and recall that there isn't a different schema for each domain in a forest --nope, there's just one schema for the entire forest, which means that if you work in the us.bigfirm.com domain and there's a sweden.bigfirm.com domain in the same forest, then it's just plain polite to give the Nordics a heads-up before changing the schema. (Unless they've come to expect that you make unannounced changes to the forest but simply accept it, a sort of ... wait for it... "Stockholm syndrome" administration model. Sorry, couldn't resist.)
The wonky part about upgrading a 2003 AD to 2008 or 2008 R2 is that you've got to do the first part, the schema upgrade part, right on the particular DC that's your schema master (unless you've got remote desktop enabled), the one DC in your entire forest where you can change the schema. In case you're not sure which of your DCs is the schema master, run the command "netdom query fsmo" at one of your DCs. (This is another reason to be nice to the Swedish guys... they may have the schema master. The good news is that I've been to Stockholm at many different times of year, and it seems a nice place year-round.)
Once you're at the DC that's the schema master for your forest, log on as an enterprise administrator. Then look in the Sources folder on your Server 2008/2008R2 installation DVD, where you'll find a folder named "ADprep." Open a command line -- elevated if it's 2008 -- and navigate to that folder. Then you'll either type
Server 2008 and R2's install DVDs offer two of them because while Server 2008 shipped both in a 32-bit and 64-bit version, Server 2008 R2 only shipped as 64-bit. Thus, as Server 2008 R2 must be 64-bit, any executables that shipped with it must require a 64-bit processor. That's a problem because if you're moving from, say, a Server 2003 SP2-based set of DCs, then the chances are very good that your DCs (and your schema master in particular) probably run a 32-bit version of Server, which couldn't run a 64-bit version of adprep.exe. That's why you'll find not just adprep.exe in the Sources\Adprep folder on a 64-bit install DVD image but also adprep32.exe, which as I'm sure you've guessed is a version of ADPrep that'll run on a 32-bit processor.
Anyway, once you've run adprep /forestprep or adprep32 /forestprep, your schema master will have a new-and-improved schema that can accommodate R2-based DCs. Recall that it's the only DC that knows that new schema at the moment, and so it's probably a good idea to push those changes out to other DCs in your forest. I like to do that immediately by going to each DC and running repadmin /syncall again, but this time with the "/P" switch (and yes, it must be a capital P), which tells the DC you're running the command on, "don't ask your partners what's new with them... tell them what you know is new." On a DC named DC6, I'd type
repadmin /syncall /e /P dc6
Then I'd go to its replication partners and run that again, although again you've got to replace "dc6" with the name of whatever DC you're sitting at. You can, by the way, see your DC's replication partners by typing
repadmin /showrepl domaincontrollername
Once you've flushed the new schema throughout your forest, you'll need to do one more thing before you can install your first 2008 or 2008 R2 domain controller, an adprep /domainprep. What /domainprep does varies on differing versions of Server, but basically it creates new groups and modifies permissions on various AD-related objects. (When Microsoft first released Windows NT 3.1, they chose to deliberately make it insecure in some ways because those insecurities made NT backwards compatible with Windows for Workgroups and OS/2 LAN Manager. It wasn't the most desirable decision, but it was a good one from a getting-people-to-buy-NT point of view. Over the years, they've been removing those insecurities as it becomes apparent that the market no longer needs them.)
This time, go to the infrastructure FSMO on your domain -- unlike the schema master, there's one for each domain -- and log on. Again, using the files from the sources\adprep folder, run adprep with the "/domainprep" switch from the command line:"
From that point, you're ready to add your first R2 or 2008 DC by running DCPROMO on that 2008 or R2 machine. Next newsletter, I'll talk about some of the other things to consider (and hint, most of them have to do with Sysvol).
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.