Microsoft’s newest server operating system, code-named Longhorn Server and officially named Windows Server 2008, offers several advantages over the Microsoft Windows Server 2003 operating system. Microsoft Windows Server 2008 includes a 64-bit architecture; a pared-down installation option called Server Core; and Active Directory, Group Policy, and Terminal Services improvements.
Sometime early next year, Microsoft will release Windows NT Server 6.0, once known as "Longhorn Server" and now as Windows Server 2008. Will you love it? Well, that depends: Are you looking for a revolution, or just a bit of evolution?
When it comes to Windows 2008, think more Darwin and Wallace, not Marx and Lenin. As with its two predecessors, Windows Server 2003 and Windows Server 2003 R2, Windows 2008 offers some nifty new tools and innovations, as well as fixes for some old irritations. However, Windows 2008 doesn't have the kind of paradigm-busters that we saw in Windows 2000 Server—which means that the new OS will be relatively easy to incorporate into an existing Windows server environment. Unfortunately, Windows 2008 lacks solutions for some of its earlier sibling's most significant annoyances (as did Windows 2003 and Windows 2003 R2). Although Windows 2008 offers many new technologies, I only have space to cover a few of its features.
Whether you love it or hate it, Vista—Microsoft's newest desktop OS—is the most secure version of Windows yet. Windows 2008 builds on Vista's code base, so it inherits Vista's security. In addition, Windows 2008 benefits from Vista's improved functionality.
64-Bit Is It!
Perhaps the most comprehensive change in Windows 2008 is an architectural one: 64 bits. The default processor architecture is now considered to be 64 bits; 32 bits is pure legacy. According to Microsoft, Windows 2008 is the last server OS that the company will offer for 32-bit processors.
Good or bad, you might ask? Wonderful, I'd say! Yes, 64-bit code is somewhat larger than the corresponding 32-bit code, but the AMD64/EM64T chip architecture makes for easier low-level coding for programs—which means that developers are more likely to produce solid code. And even better, 64-bit architecture frees us from the 4GB address space and lets Windows grow to 16TB. Because loading what is essentially the desktop version of Windows 2008—"64-bit Vista Ultimate"—on a desktop generates a Windows Task Manager report that Windows is using 1.08GB before you even start running applications, busting out of the 4GB limit seems like a very good idea. And since Exchange Server 2007 already requires 64 bits, perhaps Windows 2008's 64bit–centricity isn't such a shock.
By far, the feature with the single biggest "wow" factor in Windows 2008 has to be Server Core. Working with various versions of UNIX and Linux over the years has made me wish for a Windows version that's only loosely connected to its GUI. On a UNIX/Linux server, you can fire up the GUI just long enough to run a graphical administration tool, configure the server, then turn off the GUI. This approach gives you a server that uses less RAM, needs less CPU power, and is more secure (simply because less software equals fewer places for exploitable bugs).
With Windows 2008, I got my wish, to a certain extent. The Windows 2008 beta gives you the option of installing either the full-blown version, or installing Server Core. When I installed Server Core, the installation was lightning quick. I installed Server Core as a virtual machine (VM) on a system that was already fairly busy, and I was stunned that the entire installation took only 11 minutes, start to finish, and used just 200MB of RAM.
In addition, Server Core runs on some downright skinny hardware. Although I don't suggest that you run a production Server Core system on a 256MB system, it is possible. Considering that Vista won't even install on a system with less than 512MB of RAM and won't run worth a darn on a system with less than 1.5GB, I find it eye-opening for Server Core to show just how much we willingly give away in computing power in order to have a GUI.
But once you see the Server Core desktop, you might beg to trade that computing power to get your GUI back—Server Core's desktop is nothing more than a command prompt window. Server Core lacks about 80 percent of the Windows GUI and completely lacks .NET. Server Core also can't use Windows PowerShell, although it can use some PowerShell commandlets.
Before you quit reading right here, using Server Core isn't as bad as it sounds. You can use several methods to administer a Server Core system. For example, you can hunker down and use the command prompt. Over the years, Microsoft has added more and more command-line administrative power to Windows. Server Core offers several new Call Level Interface (CLI) tools, making CLI-based administration more reasonable.
And GUI addicts, fear not—you can still click to your heart's content. Just fire up a Microsoft Management Console (MMC) remote-management snap-in on a full-blown Windows 2008 system to remotely control your Server Core system.
Server Core can't do everything that full-blown Windows 2008 can; for example, it can't host an Exchange server or a SQL Server machine. It can, however, be a DHCP, WINS, DNS, or Microsoft IIS server (although without ASP.NET support); a domain controller (DC); and a file and print server.
Why use Server Core? Two reasons. First, as I've said, Server Core runs on much lighter hardware than the full-blown version of Windows 2008 does. Thus, Server Core might make more sense as a VM in production than the complete version makes. Or, Server Core might fit on an inexpensive bit of computer hardware, making a server in a branch office more feasible than a server requiring more silicon and iron might be. Second, a smaller software base offers fewer places for bugs to crop up that would allow malicious users to attack and exploit a Server Core system—which Microsoft claims will prevent Server Core systems from needing patching as often as full-blown systems. All other things being equal, less software means better security (which, I think, is why Microsoft didn't include .NET in Server Core). And although some of you will disagree with me, I think Microsoft should keep .NET off Server Core. The .NET platform is a hefty bit of software with its own security subsystem—adding it to a "minimalist" version of Windows 2008 that's designed for sturdiness would defeat the purpose of Server Core. The big question is: Will Server Core sell? And the answer depends on just one thing: price. Microsoft says that when you buy a copy of Windows Server 2008 Standard Edition, Enterprise Edition, or Datacenter Edition, you'll have the option of installing either the complete or Server Core version of the software. If so, Server Core is doomed. Why would someone pay thousands of dollars for a server OS, then install its reduced-function version? My prediction is that Server Core will die on the vine—which would be a shame. Microsoft should think seriously about making Server core the Windows 2008 "low-price alternative."
Active Directory Changes
The first change that Windows 2008 brings to Active Directory (AD) is a new name, Active Directory Domain Services. ADDS alters Windows-based domains in several ways: read-only DCs (RODCs), fine-grained password policies, and AD snapshots.
Before I discuss what's new in Windows 2008 AD, let me point out what's not new: improvements to forest restructuring tools. Windows 2008 still offers no easy way to merge forests, pluck a domain from a forest and make it a new forest, merge two domains, or perform any of the other tasks that mergers, acquisitions, and reorganizations require.
Read-only DCs. Windows 2008 has a new sort of DC called a read-only domain controller (RODC), which might be the OS's second-biggest change after Server Core. Recall that prior to Win2K, domains had just one server with a read/write copy of the domain accounts—the server called the primary domain controller (PDC). All the other DCs had just read-only copies of the domain accounts; they were called backup domain controllers (BDCs). In Win2K, all DCs became equal, with every DC being a read/write DC.
Microsoft finally decided that neither of these approaches is optimal. Therefore, in Windows 2008 you can select the mix of read/write DCs and RODCs you want. Read/ write DCs are useful because they can accept updates to domain accounts, whereas RODCs can't. So, you can't use an RODC to create a new user account or change a password.
Why use an RODC? First, RODCs generate less replication traffic. Second, RODCs have a feature that Windows NT 4.0 BDCs lack: fine-grained control of exactly how much domain data you share with a given RODC. For example, you could put an RODC into a small branch office with eight employees and tell the RODC only the passwords of those eight people. If the RODC were then stolen and its AD copy hacked, the only passwords at risk would be the ones on those eight accounts, rather than the passwords of every account in the domain. Or, you could be even more cautious and not tell the RODC any of the passwords, making the DC a nearly useless target.
A branch office RODC without any passwords would still be useful because although it couldn't provide initial logon services for a user, it could handle subsequent logons. A user's first-thing-in-the-morning workstation logon would require a WAN link, but the local RODC could handle any further logons (e.g., a Sysvol connection to read group policies, a logon to a local print server, a connection to the Exchange server). And if a branch office DC were stolen, Windows 2008's AD lets you run a wizard to change the stolen passwords or make the user accounts inactive. This wizard also makes removing a dead DC from AD far simpler than using the Ntdsutil tool.
Fine-grained password policies. The only reason for having more than one domain in an AD forest that still makes technological sense is if you want some of your users to have to change their passwords every X days and other users to have to change their passwords every Y days. Ever since Win2K, all members of an AD domain have been subject to the same password policies.
Windows 2008's AD changes this rule. You can now tell AD to show different password policies (i.e., Password Settings Objects—PSOs) to different groups or individuals. Creating PSOs is a bit arcane—the most user-friendly tool for doing so is adsiedit.msc. However, the under-the-hood features are quite well thought out. For example, have you ever created a new Group Policy Object (GPO) that failed to take effect because it was blocked by a permission or overridden by another policy? The obvious solution is to use a tool that computes Resultant Set of Policy (RSoP), which is the ultimate analysis of which policy triumphs over others. Windows 2008 has a simple built-in RSoP tool that runs automatically every time you create a PSO.
AD snapshots. Wouldn't it be neat to look at an AD snapshot as if it were a live, working, running AD? Windows 2008 lets you do so—sort of. An AD snapshot is an image taken from a working copy of AD on a DC, like a backup. But an AD snapshot is more than a just a backup; you can use the tool dsamain.exe to mount an AD snapshot and get a seemingly functional but nonactive AD installation. Then, you can use an LDAP editor to examine the backed-up AD's objects, object attributes, and so on.
A benefit of AD snapshots is that you can compare two different DCs' ADs, or you can compare the state of a DC's AD over time to see what changed in the DC's copy of AD. AD snapshots also let you easily browse your AD backups. The alternative method for examining an AD backup is to set up a DC that's disconnected from the enterprise network, then restore the backup—which is fairly time consuming.
The one fly in the AD snapshots ointment is a lack of LDAP viewers. You can't fire up the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to examine a snapshot; instead, you're stuck with adsiedit.msc or ldp.exe. Perhaps a future version of Windows Server will offer a tool that simplifies the process of exploring AD naming contexts. For example, a tool for sifting through a Global Catalog (GC) would certainly make Exchange troubleshooting a lot easier.
Although Windows 2008 brings a lot of Group Policy improvements, we've already seen most of them in Vista, which makes sense because the workhorse of group policies isn't the DC that holds the GPOs—instead, it's the Group Policy client software that runs on the desktop and server systems. Still, Microsoft saved a few Group Policy goodies for Vista's big brother, Windows 2008.
First, and long overdue, Group Policy Management Console (GPMC) gets a Find command. Although GPOs can contain any or all of more than 2,400 settings, no command currently exists for easily finding the setting you want. For example, you can't ask the Group Policy Object Editor to show you all the settings that refer to WPA.
Second, Windows 2008's GPMC will let you add comments to GPOs. As someone who's been running production ADs for more than seven years, I admit that sometimes I can't remember what I was thinking when I assembled a particular GPO. Just being able to add an explanatory paragraph to a GPO will be a welcome addition.
Finally, Windows 2008's GPMC introduces the notion of "starter GPOs." Although Group Policy can accomplish many tasks, performing some of them can seem a bit cryptic. For example, Windows systems have always had a quirky security weakness called an "anonymous logon" or "null session." This weakness lets people on your intranet access information about your computer without logging on. To reduce these anonymous users' power in Windows, you need to activate several Group Policy settings. And as anyone who's ever pored over the many Windows "hardening guides" can attest, figuring out those settings and how to enable them can take a lot of time. Windows 2008 offers some help in the form of a starter GPO document that anyone can create to collect the settings in one place, then distribute them to users. Microsoft promises a few built-in settings, including a desktop hardening starter GPO, but I'm sure that users will create some great ones as well.
Terminal Services just continues to get better in Windows 2008. For example, you just have to love the Terminal Services Gateway (TSG). This new service lets users connect to a terminal server/remote desktop behind a firewall by first logging on to the TSG, then choosing the terminal server/remote desktop inside the firewall that they want to access. The beauty is that a TSG user doesn't need to connect to a draggy VPN in order to log on to the desired system. But TSGs are still secure because they employ a new sort of RDP over Secure Sockets Layer (SSL). The result is speed and security. And from what I hear, you don't need Windows 2008 (or even Vista) to use RDP over SSL; apparently the new RDP client for Windows XP that Microsoft released earlier this year extends RDP over SSL capabilities to XP and Windows 2003.
In addition, Terminal Services takes a leaf right out of Citrix's playbook, using "Remote Programs" (which resemble Citrix's "Seamless Windows" feature). With Remote Programs, you can use Terminal Services to deploy an application to a Windows desktop. In such a deployment, a user would see a new icon on the desktop and could click the icon to use the associated application, without the local hard disk having to store any of the application's code. The application would actually be nothing more than a Terminal Services window, but with a normal Windows frame.
Give It a Whirl!
Microsoft's upcoming Windows Server offering has many interesting new features. If you have access to the Windows 2008 beta, I strongly recommend that you fire it up and start playing. The last I heard, Windows 2008's release to manufacturing (RTM) date is early November, with general availability in February 2008. The more you can learn ahead of time, the better off you'll be.