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.
Group Policies
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
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.