You might think that. At least, you might think that if you'd never needed to muck around with Active Directory and its astonishingly byzantine, godawful Secrets Of The Hidden Masters style of maintenance. If you need to change the configuration of a Unixlike server, you pretty much just have to find a nice, plain, simple human-readable config file and edit it. Unless you've done something odd with it, odds are pretty good that any option you need will already be in the file, even if it's commented out - so it's self-documenting. Just read, make your changes, and restart whatever service you need to play with. Simple.
On the other hand, over on the "easy" side of the road - the Windows server family - check out what you have to do if you want to perform a very simple(!), very common task - add a Windows 2K3 domain controller to a Windows network with a Windows 2000 Server domain controller. Should be a simple upgrade, right? Just start up the appropriate nice, friendly, GUI-driven clicky-clicky and "Next" your way through, right?
Well actually, the very first thing you have to know about adding domain controllers to a Windows network is... a command line tool. There's this tool you run from the command line called DCPROMO, which promotes a server to domain controller status in a domain. Well, okay, that's not so hard right? There's just one command line tool you somehow need to know you have to run. Hey, you learn that once, you remember it for the next time. No biggie! ... Right?
Well actually no, because you're going to have to run another command line tool that isn't mentioned anywhere in any friendly little wizards, called ADPREP. Well, okay. And, uh, you're going to have to run it several times on as many different DC's as you already have, to prep several different roles - you need to do an ADPREP /forestprep, and an ADPREP /domainprep at a bare minimum, and you'll probably have to be damn careful about which machine you run the /forestprep on, since you need to make sure you get that on the "FSMO Role Owner". Um. Okay. Well... still not so bad... Right?
OH BUT WAIT THERE'S MORE. Since you've got an Exchange service running somewhere on the domain, you can't prep the forest yet - when you try, it bombs out with an error.
Adprep was unable to extend the schema.
There is a schema conflict with Exchange 2000. The schema is not upgraded.
The schema conflict must be resolved before running adprep. Resolve the schema conflict, allow the change to replicate between all replication partners, and then run Adprep. For information on resolving the conflict, see Microsoft Knowledge Base article Q325379.
Well, at least it directs you... somewhere... so um, as long as you have live broadband internet access, you can just look up that KB, and it will tell you everything you need to do... Right?
1. Log on to the console of the schema operations master by using an account that is a member of the Schema Admins security group.
2. Click Start, click Run, type notepad.exe in the Open box, and then click OK.
3. Copy the following text including the trailing hyphen after "schemaUpdateNow: 1" to Notepad.
4. Confirm that there is no space at the end of each line. [...]
So, okay. We go to the KB article, we faithfully copy all the text to make ourselves an .ldf script file, we save it, and then we run it with - ANOTHER - Cryptic Monks of Shaolin command line tool you've never heard of... ldifde -i -f inetorgpersonprevent.ldf -v -c DC=x "dc=subdomain,dc=domain,dc=TLD. This is getting to be a lot less friendly than we expected. But we're out of the woods now... Right?
Weeellll... turns out if you hit THAT particular copy of the KB article, you're fucked. Because, well, the tool you're gonna have to run to load that script doesn't know how to handle double-spaced lines. So you're going to get "There is a syntax error in the input file. Failed on token starting with 'C' on line 3. 0 entries modified successfully. An error has occurred in the program." response. And you're going to pull your hair out, and you're going to go back and Google, and you're going to find no useful articles referring to syntax error and failed token because, well, that could be anything. But don't worry, EVENTUALLY you'll find the OTHER copy of the KB article on microsoft.com, and this one will have the .ldf script present for copying WITHOUT the double-spacing, and you'll put THAT in instead, and you'll run the arcane command line tool on it, and everything will be hunky-dory! ... Right?
Actually, once you get the CORRECT script saved to Inetorgpersonprevent.ldf, you're still not out of the woods. NOW when you run the Quivering Palm of Death tool on your CORRECTED .ldf script, you get a DIFFERENT error: "Add error on line 1: Referral. The server side error is A referral was returned from the server. 0 entries modified successfully. An error has occurred in the program." Now, I don't know about you, but the first thing I thought when I saw that was "PC Load Letter? What the fuck does THAT mean?!" This one's a REAL joy to google, by the way, because it turns out about a billion different scripts return similar errors to that, very few of which have fuck-all to do with a domain controller preparation. But eventually, because your google-fu is strong (and has gained two levels and +1 attack per round during this exercise alone) you find the answer: you gotta make sure this machine has the FSMO Master role on the domain. Whatever the hell that is. So, you run yet ANOTHER command line tool - ntdsutil - to check for and/or transfer and/or seize the FSMO Master role (incidentally, if the machine that had that role blew up in a fire or was removed from the domain without first transferring the role, that's Bad Juju... so better hope none of your Windows DCs ever die!). So now you're positive you've got the FSMO Master role on your DC, so now you'll be able to get shit imported! ..Right?
Yeah, you're probably used to disappointment now. But plenty of Googling later (haven't seen a nice friendly clicky little wizard to guide you through anything YET, have you noticed?) you'll find out that, first, what you have to do is ENABLE the update of the schema on the DC that... well... is the only one that can update the schema anyway... by going into the MMC tool, then right-clicking the Active Directory Schema applet (once you've added it) and selecting Operations Master, then checking the box that says to allow updating the schema on this DC. Finally, a GUI! Even if you do have to start the MMC from the command line, most likely! NOW IT WILL BE EASY! ... Right?
Well, actually, NO, because there won't BE an Active Directory Schema snap-in available. You will stare at this, and you will maybe whimper a little. Then you will return to the Internet to find out where the fuck the AD Schema snap-in is, and you will discover that you need to - imagine this - perform ANOTHER arcane kung-fu move on the command line to make this snap-in appear on the list of shit you can add to the management console in order to right-click it and find something else and click a box. (Whew.) So... "regsvr32 schmmgmt.dll". And THEN you can find the Active Directory Schema snap-in. And THEN you can right click it, and select Operations Master, and check the box that says to allow schema updates. And THEN you can run the Quivering Palm of Death on the .ldf script file you created (and replaced with a second copy that actually works) from a page on the internet. And THEN you can run adprep /forestprep and it will actually work.
Thanks for making it easy, Microsoft! God forbid I'd have had to read a self-documenting config file and edit it or something!