From Mark Minasi’s website:
For an “R2,” Server 2008 R2 delivered a fairly impressive list of new goodies for Active Directory (AD) techies. One of the most important of those goodies was Active Directory’s new support of PowerShell scripting, in combination with 73 new AD-related PowerShell cmdlets and their GUI cousin, a brand-new administrative tool for AD called the Active Directory Administrative Center (ADAC). Why is ADAC a “cousin” of PowerShell? Simple: PowerShell 2.0, which Microsoft embedded in Windows Server 2008 R2, offers the new ability to create GUI-based PowerShell tools… and ADAC is one of the first of those. Sure, ADAC looks like a it’s just a better-arranged version of the ten-year-old Active Directory Users and Computers (ADUC) MMC snap-in, but on the inside, the two are as different as night and day.
Now, I haven’t had time to put an R2 domain controller (DC) on my internal production network yet, but I really like some of the new PowerShell cmdlets and really like the ADAC GUI tool, so I was pleasantly surprised to learn that you can fairly simply bring R2’s PowerShell cmdlets and ADAC to any Active Directory running pre-R2 domain controllers. In fact, you can even retrofit Powershell and ADAC support on domain controllers as far back Windows Server 2003.
The key lies in the fact that under the hood, Microsoft built PowerShell clients to talk to the Active Directory with a completely new network protocol. Instead of having ADAC and PowerShell make AD requests to DCs via LDAP, ADSI or some sort of RPC, Microsoft built a brand-new web service for Active Directory. Thus, every time an administrator sits down and issues some command to AD via R2’s PowerShell tools or ADAC, then under the hood that PowerShell cmdlet or ADAC actually transmits the admin’s request as a pile of XML data packaged in one or more SOAP (Simple Object Access Protocol) packets, and then transferred via HTTP/HTTPS to the web service program running on every 2008 R2-based Active Directory DC.
Now, I hear a few heads getting ready to explode out there: “whaaaat???? Our DCs are web servers? Nooooooooo….” Relax; R2’s DCs are not web servers, they just run a web service. Those are two very different things, I promise. Heck, they don’t even use ports 80 and 443; instead, they use TCP port 9389, which is easy to remember if you’re leery about the whole web service thing, know a microscopic amount of German and recall the port number normally used by LDAP in Active Directory: “nein, 389!” Really, you do not have to run IIS on your DC to make this work.
Anyway, Microsoft decided to take their R2 AD web service and back-port it to Server 2003, Server 2003 R2, and Server 2008 DCs and, once you’ve done that, you’ll be ADAC-ing to your non-R2 DCs. There are, of course, a few details, mainly that you’ve got to download and install a bunch of stuff to make it all work, but it’s worth it in the end.
First, you’ll need a Windows 7 desktop or a Windows Server 2008 R2 member server. You need one of them because the only way that I know of to get PowerShell 2.0, the AD PowerShell Module, and ADAC is either to be running a 2008 R2 system, or to download the “Remote Server Administrations Tools for Windows 7” (RSAT) from Microsoft’s Download Center and you can unfortunately only install RSAT on a Windows 7 system. In other words, sorry… you’ll have to do the AD administration from a Win 7 system rather than a Vista or XP box.
Second, the client Windows 7 system (or 2008 R2 member server) should be a member of the domain that you aim to do your PowerShelling on. (You could probably make it work otherwise, but it’d be a pain.)
Third, you need a DC that can support the AD web service. That would be a DC built upon Server 2003 with SP2 or Server 2008.
Fourth, your DC needs .NET 3.5 SP1. Search www.microsoft.com/downloads for “Microsoft .NET Framework 3.5 Service Pack 1 ” and take the download with that exact name, as it’s not only an SP1 that you’d add to .NET 3.5 but instead it is .NET 3.5 with its SP1 already installed.
Fifth, your DC probably needs a hotfix or two. Apparently there’s something about the way that Windows 7 talks to Server 2003 and 2008-based DCs that confuses them, and these hotfixes address that.
- Server 2003 SP2 systems need the hotfix in KB 969429. You can’t just download it, you’ve got to “request” it. (It happens immediately and automatically, you needn’t talk to anyone for it, but it takes a minute or two waiting for your “request” to be granted. Perhaps it’s a hotfix with mildly narcotic side-effects and thus is unlawful in some localities?)
- Server 2008 SP1 and 2003 SP2 systems both also need the hotfix in KB 967574. 2008 SP2 systems do not need this hotfix. The page explaining this hotfix seems to indicate that 2003 systems do not need this hotfix, and that KB 969429 and 967574 are either/or hotfixes, but I tested this on a 2003 R2 DC and it seemed to need both hotfixes before I could proceed.
Sixth, you’re ready to install the AD web service on those prepared DCs. Search for the “AD management gateway service” at Microsoft’s Download Center, and note that there are four possible choices of files to download depending on whether you’re installing it to 2003 x86, 2003 x64, 2008 x86 or 2008 x64. It’s packaged as an MSU (Microsoft update), so it’s a simple install.
Now log onto that Win 7 system with RSAT, fire up ADAC and you’re ready to go. Happy PowerShelling!
Aditional info: http://technet.microsoft.com/en-gb/magazine/ee914610.aspx