 TechNet Magazine May 2008

TechNet Magazine May 2008

Windows Administration: Active Directory Backup and Restore in Windows Server 2008

Windows Server 2008 and the new Windows Server Backup utility bring many changes and welcome enhancements to backing up. Here is an in-depth guide to backing up and restoring Active Directory in the new server OS.

Gil Kirkpatrick Windows Administration: Designing OU Structures that Work

Too many administrators underestimate the importance of having a well-designed Organizational Unit structure. Find out why having a sound OU strategy is important and determine the best OU structure for your organization.

Ken St. Cyr Windows Administration: Extending the Active Directory Schema

Many applications that rely on Active Directory define their own changes to the schema. But it's important that these changes don't impact other applications. Get an overview of extending the Active Directory through the classSchema and attributeSchema objects.

Vikas Malhotra System Center: Introducing System Center Mobile Device Manager

The new System Center Mobile Device Manager provides a complete set of tools for managing Windows Mobile devices through an MMC snap-in or via Windows PowerShell. Find out how this vital tool will allow you to manage mobile devices, increase security, and deliver mobile VPN capabilities.

Matt Fontaine System Center: What's New in System Center Essentials SP1

Service Pack 1 introduces significant enhancements for System Center Essentials 2007. Explore some of the key changes that will improve the user experience and streamline administration.

Pete Zerger From the Editor: A Warm Welcome to "Inside SharePoint"

Joshua Hoffman Sustainable Computing: Putting IT on a Diet

As the environment becomes a topic of increasing attention, many IT departments are looking for ways to reduce their energy consumption. In the first installment of our new online Sustainable Computing column, Dave Ohara discusses ways you can start to cut down on the amount of energy your organization consumes.

Dave Ohara Sustainable Computing: Imagine Cup 2008: Competing for Change

For the 2008 Imagine Cup, students have been challenged to use technology to enable a sustainable environment. Finalists in the U.S. competition recently presented their solutions in Los Angeles, and MSDN Magazine was there to see the innovative ideas participants have come up with.

Mitch Irsfeld Sustainable Computing: Sleep or Hibernate?

Leaving your computer on when it's not in use is a waste of energy. Features like Sleep and Hibernate make it easy to power down your system when you're not using it, and these features are more reliable now than in previous versions of Windows. Here's a look at the differences between these features and some best practices for configuring them.

Mark Aggar, Megan Morrone, and Michael Walsh Sustainable Computing: Conserving Energy with Group Policy

Enforcing a power management strategy on the systems throughout your entire organization can add up to substantial savings. And Windows Vista includes 35 power management settings that you can configure and enforce with Group Policy. Here is some guidance for configuring some of the more common settings.

Mark Aggar, Pat Stemen, and Michael Walsh Letters: Readers Speak Out

Toolbox: New Products for IT Pros

Greg Steen Exchange Queue & A: Exchange 2007 SP1 Deployment

In this installment, we provide answers to your questions about Exchange Server 2007 SP1.

Nino Bilic Utility Spotlight: SharePoint Capacity Planning

Explore the SharePoint Capacity Planning Tool and see how you can design a topology for deploying SharePoint and then revise that topology after running load and usage simulations.

Peter Skjøtt Larsen and Satish Mathew Inside Sharepoint: Building Your SharePoint Infrastructure

SharePoint is powerful, but its complexity can make deployment quite challenging. Our new SharePoint column can help. In this first installment, we give an overview of the SharePoint architecture and show you how to set up a basic SharePoint infrastructure with WSS 3.0.

Pav Cherny Windows PowerShell: Automating Directory Management

Version 1 of Windows PowerShell offers less than impressive Active Directory management capabilities. Find out how you can use add-ins to get more powerful ways to work with Active Directory objects from within Windows PowerShell.

Don Jones Hey, Scripting Guy!: Raising Eyebrows on Regular Expressions

The scripting guys visit the Louvre, take up art criticism, and show you how to use regular expressions in a script to do a search and replace.

The Microsoft Scripting Guys Security Watch: Principles of Quantum Security

Find out how the Heisenberg Uncertainty Principle and other elements of quantum physics can shed light on evolving security strategies. (Note: No cats were harmed in the writing of this article.)

Jesper M. Johansson The Desktop Files: Leaving the Administrator Behind

Why is everyone running as Administrator? Wes Miller looks at the risks of running as Administrator and explores the benefits of transitioning your users (including yourself) to running as Users.

Wes Miller Field Notes: Multiple Mice, One PC

What do you do when students outnumber the computers available in a classroom setting? Microsoft Research India has developed a solution, termed MultiPoint, that allows multiple mice to be used simultaneously on one computer.

Kentaro Toyama Windows Confidential: 16-Bit Icons Are So Passé

Raymond Chen looks at why Windows Vista doesn't support 16-bit icons, and wonders whether anybody has even noticed.

Raymond Chen


 Windows Administration: Active Directory Backup and Restore in Windows Server 2008
Windows Administration Gil Kirkpatrick

Active Directory Backup and Restore in Windows Server 2008
At a Glance:
  • NTBACKUP vs. Windows Server Backup
  • Backup tools and options
  • Recovery tools and options
  • Keys to a sound Active Directory backup strategy

You all know that Active Directory Domain Services (ADDS) is a mission-critical component in your Windows infrastructure. If Active Directory goes down, your network is essentially useless. Consequently, your backup and recovery plans for Active
Directory are fundamental to security, business continuity, and regulatory compliance.
Windows Server® 2008 brings many new features to Active Directory®, two of which have a significant impact on your backup and recovery plans: the new Windows Server Backup utility and the ability to take and work with Volume Shadow Copy Service snapshots of Active Directory. In this article I will describe the changes these enhancements bring to the table and how you can take advantage of these changes to streamline your Active Directory backup activities.

NTBACKUP vs. Windows Server Backup
Group Policy Settings
Windows Server Backup provides several Group Policy settings that give you some limited control over how backups work on your servers. With these backup policies, you can mitigate some of the risks associated with people performing unauthorized backups to obtain access to unauthorized data. The options include:
Allow Only System Backup If this is set, Windows Server Backup can only back up critical system volumes. It cannot perform volume backups. Disallow Locally Attached Storage as Backup Target When enabled, this setting does not allow backups to locally attached drives. You can only back up to a network share.
Disallow Network as Backup Target This setting does not allow backing up to any network share.
Disallow Optical Media as Backup Target When this is set, Windows Server Backup cannot back up to any optical device, such as a recordable DVD drive.
Disallow Run-Once Backups This setting does not allow Windows Server Backup to run unscheduled, ad hoc backups. Only backups that are scheduled through the Windows Server Backup MMC snap-in are allowed to run.

The NTBACKUP you've known and loved since Windows NT® 3.5 is gone. Replacing it is Windows Server Backup. And this new tool is not just a gussied-up NTBACKUP; it's a whole new backup technology that will force you to rethink the way you back up your systems.
Although Windows® Server Backup is the only in-the-box backup solution for Windows Server 2008, it is not a feature-for-feature replacement for NTBACKUP. The biggest difference is that Windows Server Backup is a disk-to-disk backup solution; it doesn't support backing up to tape. You can create backup images on direct-attached disk volumes, on network shares, and even on external USB hard drives and multi-volume recordable DVDs. But you cannot back up to tape. Just to be clear, you can still hang a tape drive on a Windows Server 2008 server and copy the Windows Server Backup-generated backup images to the tape drive—but you'll have to use someone else's software to do so.
Whereas NTBACKUP is a file-based backup and restore tool, Windows Server Backup is volume- and block-based. Windows Server Backup deals with its backup source as a set of volumes, with each volume as a collection of disk blocks. This is considerably more efficient than backing up files through the file system. Dealing with backups on a block basis also allows Windows Server Backup to make use of Volume Shadow Copy Service snapshots to perform block-level incremental backups, as well as to create snapshots on the target volume to simplify the use of (and reduce the space used by) multiple backups.
Even if you are doing full backups, Windows Server Backup provides some great space efficiencies on the target disks. For instance, you might perform multiple full backups of the same volume. Since Windows Server Backup uses Volume Shadow Copy Service snapshots on the target disks where it stores the backup images, the snapshots will only store the blocks that have changed. This substantially reduces the space used by multiple full backups. This eliminates the need to perform multiple restore operations to recover an incremental backup. Even though the snapshot only stores the deltas for each backup, Volume Shadow Copy Service makes each backup appear complete.
Be aware, though, that you only get the benefits of Volume Shadow Copy Service snapshots on the target if you back up to a local hard disk—Windows Server Backup can't perform Volume Shadow Copy Service operations on backups stored on DVD or network shares.
As an added bonus, Windows Server Backup stores its backup images in Microsoft® Virtual Hard Disk (VHD) format. You can actually take a backup image and mount it as a volume in a virtual machine running under Microsoft Virtual Server 2005. You can simply mount the VHDs in a virtual machine and browse for a particular file rather than having to perform test restores of tapes to see which one has the file is on it. (A note of caution: you can't take a backup image and boot a virtual machine from it. Since the backed-up hardware configuration doesn't correspond to the virtual machine's configuration, you can't use Windows Server Backup as a physical-to-virtual migration tool.)
There is a downside to Windows Server Backup's volume- and block-orientation. Since this new tool looks at the backup source as a set of volumes and blocks, it doesn't allow you to back up only selected files. You have to back up the entire volume. And even more problematic, by default you cannot store a backup image on one of the volumes being backed up (there are some ways to configure around this; see support.microsoft.com/kb/944530). This has profound implications for system state backup, as I will discuss later in this article.

Installing Windows Server Backup
Windows Server Backup is a "feature" in Windows Server 2008 and is not installed by default. Before you can perform a backup with Windows Server Backup, you have to install the feature, using either Server Manager, or the SERVERMANAGERCMD command-line utility:
C:\> servermanagercmd -install Backup-Features
Windows Server Backup is composed of two sub-features, Windows Server Backup and Command-line Tools. Note that Command-line Tools refers to a set of Windows PowerShellTM cmdlets—not the WBADMIN .EXE command-line tool. Thus, if you choose to install both sub-features, you must install the Windows PowerShell feature.
After installing Windows Server Backup, you can find the Microsoft Management Console (MMC) snap-in under the Storage node in Server Manager and on the Administrative Tools menu. If you are installing Windows Server Backup on a Windows Server 2008 Server Core installation, use the OCSETUP command (it's important to note that the OCSETUP command is case-sensitive):
C:\> ocsetup WindowsServerBackup
A complete description of the installation process is available at go.microsoft.com/fwlink/?LinkId=113146.
Note that Windows Server Backup can't restore images created with NTBACKUP. For this unlikely scenario, Microsoft has made available a downloadable version of NTBACKUP for Windows Server 2008 (see go.microsoft.com/fwlink/?LinkId=113147).

The Windows Server Backup Components
The way in which the Windows Server Backup application is architected represents a significant change. This new backup solution consists of four components:
  • MMC user interface (WBADMIN.MCS)
  • Command-line interface
(WBADMIN.EXE)
  • Backup service (WBENGINE.EXE)
  • Set of Windows PowerShell cmdlets
Splitting the application into a client and a service has several advantages, the most important being increased reliability. Whether you start a backup from either the MMC client or the command-line interface, the WBENGINE service is doing the heavy lifting. The client programs just report the status of the backup. Thus, terminating the client will not result in a half-baked backup. The client will stop and the service will continue to completion. Of course, if you really want to stop the backup, you can, but you must do so explicitly.
The other advantage of this split architecture is that you can use the client to manage backups on remote machines. This is particularly nice when you have to back up Windows Server 2008 Core machines.
Windows Server Backup supports bare-metal restores using the Windows Recovery Environment, or WinRE, which comes on the Windows Server 2008 installation media. WinRE simplifies the process of recovering a server from scratch. I will discuss performing a bare-metal restore later in this article. It's worth mentioning that Windows Server Backup supports several Group Policy settings for managing backups—these are outlined in the "Group Policy Settings" sidebar.

Volume Shadow Copy Service
Windows Server Backup uses Volume Shadow Copy Service in three different ways. When you start a full backup on Windows Server 2008, the first thing that the application does is make a shadow copy of all of the source volumes. Doing this provides a consistent view of the file system for the backup software to work with. (This is similar to what NTBACKUP did.) Windows Server Backup then copies blocks from the source volume—block by block—to the backup target, building a VHD image for each backed-up volume in the process.
Unless you specify otherwise, Windows Server Backup also creates a snapshot of the source volume so that Volume Shadow Copy Service will keep track of all changed blocks on the volume. This enables Windows Server Backup to create block-level incremental backups that only require reading the changed blocks of the source volume. Rather than reading and writing an entire file because one bit was changed in the file, Windows Server Backup can read and write only the block that has changed.
This makes for very efficient incremental backups, but at the expense of extra disk I/O for write operations on the source volume. If you are backing up a particularly busy or performance-critical volume, you should disable the Volume Shadow Copy Service snapshot on the source volume by selecting the Configure Performance Settings link and then disabling incremental backups on that volume (as shown in Figure 1).
Figure 1 Disable incremental backups on busy volumes
Figure 1 Disable incremental backups on busy volumes
When the backup is complete, Windows Server Backup takes a snapshot of the target volume (assuming you are backing up to a locally attached hard disk). During the next backup, the target VHD files are overwritten. But since Volume Shadow Copy Service is maintaining shadow copies of the target volume, there are, in effect, multiple versions of each VHD file corresponding to each of the full backups. You essentially get multiple full backups for the cost of one full backup and the changed blocks.

Backing Up to Network Shares
Backing up to a network share is just as easy as backing up to a local volume. The significant difference is that it can't create a Volume Shadow Copy Service snapshot of the remote volume. Therefore, each full backup will overwrite the previous, leaving you with just the latest full backup image of each server on a network share. Due to this limitation, you can't use the Windows Server Backup scheduler to schedule backups to a network share. You can, however, use the Windows Task Scheduler to run the WBADMIN command-line program to perform full backups to a network share. If you elect to schedule full backups to a network share this way, change the target folder for each backup to avoid overwriting previous backups.

Backing Up to Recordable DVDs
Windows Server Backup also supports backing up to optical media, such as writable DVDs. And you can create backup sets that span multiple volumes, as well. Windows Server Backup always compresses backups to DVDs, which means that you can only perform full system or full volume restores from DVD. Windows Server Backup doesn't support system state or file level backups and restores when using DVDs. And you can't schedule backups to DVD.

System State Backups and Restores
System state backups, which include only select files and some application databases (rather than entire volumes) is handy and often essential. But early builds of Windows Server 2008 didn't support system state backups and restores. Instead, the backup tool just backed up critical system volumes (meaning any volumes necessary for recovering and rebooting the OS and key applications). These critical system volumes were the volume-oriented equivalent of a system state backup.
Acknowledging feedback from customers, Microsoft added system state backup and restore capabilities to Windows Server Backup. The application creates multiple VHD files, one for each volume that hosts the system state data, but it only copies the necessary files and databases to the VHDs. Another issue is that when you perform a system state backup, Windows Server Backup does not create a snapshot of the target volume as it does in the normal backup process. Instead, each system state backup generates an entirely new set of VHD files, which means you don't get the space efficiencies you find with the snapshot-based volume backups.
You can only perform a system state backup using the WBADMIN.EXE command-line program—the MMC snap-in doesn't provide this option. To perform a system state backup, you use this command:
C:\> wbadmin start systemstatebackup
–backuptarget:e:
WBADMIN will then back up the critical system files and application databases to the target volume, in a folder reserved for system state backups. The system state backup on a 32-bit Windows Server 2008 domain controller (DC) with a default directory information tree (DIT) runs a little more than 6GB—this is more than 5GB larger than on Windows Server 2003 due in part to the fact that Windows Server Backup is capturing core OS files that NTBACKUP didn't.
The time required to back up the system state is also greater, as you would expect. These initial numbers, of course, are based on a pre-release version of the OS. You'll certainly need to test this in your own environment, but it's likely that you'll need to plan for larger system state backups (and longer backup times) when you move your domain controllers to Windows Server 2008.

Backing Up a Server with the MMC
When you run the Windows Server Backup MMC (see Figure 2), you have the option of either setting up a backup schedule or immediately running an ad hoc backup. In this case, I select Backup once to perform an immediate backup.
Figure 2 Windows Server Backup MMC
Figure 2 Windows Server Backup MMC
As you can see in Figure 3, I can choose whether to back up all the volumes on the server or back up just the specific volumes that I choose. If I select Full server, Windows Server Backup will back up all mounted volumes, but I won't have the option of backing up to a mounted hard drive—instead, I will have to back up to a recordable DVD or to a network share.
Figure 3 Using the backup configuration dialog to specify all or select volumes
Figure 3 Using the backup configuration dialog to specify all or select volumes
In this example, I want to back up to a local hard drive, so I select the Custom option. A dialog then lets me select the volumes to back up (see Figure 4). By default, Windows Server Backup checks the Enable system recovery box, which causes Windows Server Backup to select the boot volume, the OS volume, and any other volumes with critical system files and application databases. On a DC, this includes the volumes hosting SYSVOL, the Active Directory DIT, and Active Directory logs. This is the equivalent of a system state backup but it backs up all the critical volumes, not just the critical files on those volumes. In fact, I even have the ability to perform a system state recovery from a system recovery backup set.
Figure 4 Selecting specific volumes to back up
Figure 4 Selecting specific volumes to back up
After I select the destination type (local drive or network share) and specify the destination, Windows Server Backup prompts me to select either a "VSS copy" backup or a "VSS full" backup. The terminology is a little confusing, as both options will back up the selected volumes in their entirety. The difference lies in the way Windows Server Backup handles the source files after they've been backed up. If you select the copy option, Windows Server Backup will leave the backed up files alone. If you choose the full option, Windows Server Backup will then reset the archive.

Backing Up a Server from the Command Line
If you want to script the backup process, or if you are backing up a server on a Server Core installation, you can use the WBADMIN.EXE command-line program. WBADMIN provides a complete set of options that perform essentially the same functions as the MMC snap-in, including managing backup schedules.
Suppose I want to start the WBENGINE service, which will in turn perform the backup process. All I do is enter this command:
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
Or to back up all critical system volumes, I can enter this command:
C:\> wbadmin start backup -allcritical
–backuptarget:e:
After starting the backup, WBADMIN continues to run and show the progress of the backup. If I terminate WBADMIN, the backup will continue in the background. I can then reconnect WBADMIN to a running backup using this command:
C:\> wbadmin get status
And if I want to terminate a running backup, I just enter this:
C:\> wbadmin stop job

Scheduling Backups with the MMC
The backup scheduler that is integrated with the Windows Server Backup is really designed to do one thing: simplify scheduling of daily full-system backups to a local disk volume. You can use the built-in scheduler to automatically rotate backups among multiple target volumes. If you have easily removable hard drives (or you are using USB-attached hard drives), you can use this feature to set up a rotation scheme where you remove the backup disk and store it off-site and return the oldest backup disk to the server for the next scheduled backup.
The Windows Server Backup scheduler only lets you schedule backups that always occur daily. There is no way to schedule backups for, say, Mondays, Wednesdays, and Fridays. So if you don't want to run your scheduled backups daily, you'll have to work directly with the Windows Task Scheduler.
When you set up a scheduled backup to a local disk, Windows Server Backup takes responsibility of the disk, formatting it, setting up a specific folder structure, and making the target disk invisible to Windows Explorer. The target disk must be a basic volume—Windows Server Backup cannot backup to disks configured as dynamic volumes.
Scheduling backups through the MMC snap-in is very easy. In this example, I first select the Backup Schedule link, specify the type of backup and the volumes to back up, and then Windows Server Backup shows the "Specify backup time" dialog (see Figure 5).
Figure 5 Specifying when daily backups should occur
Figure 5 Specifying when daily backups should occur
After selecting the times at which I want the backup to occur, I can select the volume (or volumes) to which I want to back up. In this case, I select the backup volume E:, as shown in Figure 6. Windows Server Backup tries to select an appropriate target volume for you, but if it happens that the disk you want to back up to doesn't appear, you can use the Show All Available Disks button to view all attached disk devices. After going through a couple of "confirm" dialogs, Windows Server Backup formats the target volume(s) and schedules the backup task using the Windows Task Scheduler.
Figure 6 Specifying the destination disk for a scheduled backup
Figure 6 Specifying the destination disk for a scheduled backup
Each time a scheduled backup is completed, Windows Server Backup takes a snapshot of the target volume. And every seven days, it creates a new base image. Activity is logged in the Microsoft/Backup/Operational log. You can check there to see if your backups completed successfully; you can also associate a task, such as sending an e-mail message, with the success and failure events so you will always know the status of your scheduled backups.

Scheduling Backups from the Command Line
If you are scheduling backups on a Server Core installation or you just want to script the process, you can manage the backup schedule using the WBADMIN command-line. To add a scheduled backup, you use the WBADMIN ENABLE BACKUP command, specifying the target, source, and scheduled time, like so:
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
This command would back up the C: and D: drives to the E: drive three times a day, at 6:00 A.M., 12:00 P.M., and 6:00 P.M. (note that all times are specified using a 24-hour clock). To back up all critical system volumes (from which you can perform a bare metal restore or a system state restore), replace the –include switch with –allcritical.
You can also use WBADMIN to disable all scheduled backups, like this:
C:\> wbadmin disable backup
This command will delete all the scheduled backup jobs created by the Windows Server Backup scheduler and release all the backup target volumes for normal use. Note that you can always use the WBADMIN MMC snap-in to remotely manage the backup and restore activities of Server Core servers.

Bare-Metal Recovery of a Domain Controller
One of the most exciting improvements for backup and recovery is how the WinRE has been incorporated into the installation process. When you boot Windows Server 2008 from the installation media, you can choose the Repair your computer option, as shown in Figure 7. I point this out because it is easy to miss if you're not looking for it.
Figure 7 The Repair your computer option is available on the installation screen
Figure 7 The Repair your computer option is available on the installation screen
After I select the repair option on the installation screen, Windows lets me select a recovery option, as shown in Figure 8. In this case, I select Windows Complete PC Restore, which invokes the Windows Recovery Environment.
Figure 8 Specifying system recovery options
Figure 8 Specifying system recovery options
After you select the operating system you want to repair (there is typically only one choice), WinRE allows you to select the backup from which you want to restore. By default, WinRE selects the most recent complete system backup, but you can specify other backups stored on local disks or search the network for backups that are stored on file shares on other servers.
In my example, I select the most recent complete system backup. The next dialog (shown in Figure 9) lets me format and repartition all the disks before they are restored. This is an appropriate option if the problem you are recovering from was caused by some sort of disk failure or if you've replaced one or more disk drives in the server.
Figure 9 You can easily format and repartition disks before they're restored
Figure 9 You can easily format and repartition disks before they're restored
After a couple of confirming dialogs, WinRE starts the restore process and the server reboots. This is a pretty painless way to perform a bare-metal recovery on a server.

System State Recovery of a Domain Controller
If you need to recover from some sort of Active Directory-related problem—such as recovering a deleted OU from backup—you should restore the Active Directory Domain Services (ADDS) database to an earlier state, rather than restore the entire system. Even though you can stop ADDS like a service in Windows Server 2008, you still need to boot the server into Directory Services Restore Mode (DSRM) to perform a system state restore on a domain controller.
Changing the boot options to make Windows Server 2008 boot into DSRM is not quite as easy as it used to be. The entire Windows boot environment has been re-engineered to support the new Extensible Firmware Interface (EFI) and the old school boot.ini file no longer exists. Instead, Windows Server 2008 uses Boot Configuration Data (BCD) to control the boot process.
The simplest way to manage the BCD is to use the BCDEDIT command line program. A discussion covering all the BCDEDIT commands and options would require its own article, so I'll just show you some useful examples here.
To reboot a Windows Server 2008 DC into DSRM, use the following command:
C:\> bcdedit /set safeboot dsrepair
This will set the safeboot option for the default boot loader entry. In a fresh Windows Server 2008 installation, there is only one boot loader entry, WINLOAD.EXE. To remove the safeboot option and reboot in normal mode, use this command:
C:\> bcdedit /deletevalue safeboot
To make things a little easier for yourself, you can configure two bootloader entries on your DCs—one for a normal boot and one for a DSRM boot. This way, you can change the boot options using the Startup and Recovery settings dialog available under System Settings. To add a new bootloader entry, use this command:
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
This action will create a new bootloader entry by copying the default bootloader entry. BCDEDIT will display something like this:
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
The GUID identifies the new entry. Then use this command to set the safeboot option for the new bootloader entry in the BCD:
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
You can now switch from normal boot mode to DSRM boot mode using the Startup and Recovery settings (see Figure 10).
Figure 10 Disable incremental backups on busy volumes
Figure 10 Disable incremental backups on busy volumes
Before you use WBADMIN to start a system state restore, you must identify the backup from which you want to restore. WBADMIN can perform a system state restore from either a full system backup, a backup that contains just the critical system volumes, or a system state backup. In any of these cases, you have to specify the version of the backup you want to use. The easiest way to identify the backup versions that are available is to use the following WBADMIN command:
C:\> wbadmin get versions
WBADMIN will then display the backup versions in a form similar to the info shown in Figure 11. Note that each backup has a backup time, backup target, a version identifier (which, by the way, is the time and date the backup was started in Universal Mean Time), and a list of the types of recovery operations the backup can support.
Figure 11 Identify backups available for recovery (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
In this case, I select the most recent backup and start the system state restore with this WBADMIN command:
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
This will perform a non-authoritative restore. If you want to perform an authoritative restore of the SYSVOL, you can just mark the restored SYSVOL replica as being authoritative by adding the authsysvol option to the WBADMIN command. For more information on this process, see go.microsoft.com/fwlink/?LinkId=113152.

Taking Active Directory Snapshots
One of the most exciting changes in terms of backup for Active Directory has nothing at all to do with Windows Server Backup. In Windows Server 2008, you can take advantage of the fact that Active Directory can provide Volume Shadow Copy Service snapshots. These snapshots are very lightweight, point-in-time backups of the running Active Directory service. And even better, they take only a few seconds of your time to create! You can then mount these snapshots and access them using normal LDAP-based utilities, such as the LDP tool.
You take snapshots of ADDS or Active Directory Lightweight Directory Services (ADLDS) using the NTDSUTIL command, as shown here:
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
This sequence of NTDSUTIL commands creates a Volume Shadow Copy Service snapshot of the volumes that contain the Active Directory DIT, logs, and SYSVOL. Even though Active Directory is still being updated, Volume Shadow Copy Service uses a copy-on-write strategy to make sure that the snapshots you've taken are properly maintained. Note that the snapshots are not a complete copy of the DIT. They are really just a collection of disk blocks in the DIT that have been modified since the snapshot was taken. By combining these blocks with the current copy of the DIT, VSS can present the Active Directory DIT just as it appeared at the time of the snapshot. Figure 12 shows how to delete old or unneeded snapshots.
Figure 12 Delete unneeded snapshots (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

Mounting Active Directory Snapshots
In order to use one of these snapshots, you must first instruct Volume Shadow Copy Service to make the snapshot available to the file system. You do this using the ntdsutil command to list the available snapshots and then mount the snapshot you are interested in (see Figure 13).
Figure 13 Using ntdsutil to mount a snapshot (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
The "list all" command lists all the available Active Directory snapshots that are currently being maintained by Volume Shadow Copy Service. The "mount 1" command mounts the selected snapshots of the Active Directory DIT and log volumes and makes them available in the file system. They are located at C:\$SNAP_200712032318_VOLUMEC$\ and C:\$SNAP_200712032318_VOLUMED$\.
If you look in these folders, you'll see the entire contents of those volumes as they were when the snapshot was taken. Note, however, that the mounted snapshots are read-only—meaning you can't modify any of the files in the mounted snapshot.

Recovering Data from Active Directory Snapshots
The task of mounting the snapshots of the volumes that contain Active Directory seems a bit like magic. How can you get to the Active Directory data contained in those snapshots? The secret is the DSAMAIN command. This is the executable that runs ADLDS. It is essentially a standalone LDAP server that shares almost all of its code with ADDS. You can use DSAMAIN to make the mounted snapshots look like a read-only LDAP server containing the Active Directory data as it was at the time the snapshot was taken.
Consider this command:
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
This mounts the ntds.dit file located in the c:\$snap_200712032318_volumed$\ntds\dit folder and makes it available to LDAP operations on TCP port 10000 (or whatever open port you specify). DSAMAIN will open the LDAPS port (the port used for LDAP over Secure Sockets Layer) on the port you specified plus one (in this case, 10001), the GC port (the port used for global catalog connections) on the port you specified plus two (10002), and the GCS (Global Catalog over Secure Sockets Layer) port on the port you specified plus three (10003).
You can use any LDAP program (such as LDP) to access the mounted DIT on the specified port. But in Windows Server 2008, Active Directory Users and Computers (ADUC), Sites and Services, and Domains and Trusts, as well as ADSIEDIT, have all been modified to allow you to connect them to a DIT mounted using DSAMAIN. If you right-click on the top-level node in the navigation pane of any ADUC and select Change Domain Controller, you will see the dialog box shown in Figure 14. If you simply type the name or IP address of the server hosting the mounted snapshot, along with the port (in my example, localhost:10000), ADUC will connect to the mounted snapshot, allowing you to browse the contents of the directory as it existed at the time of the snapshot. Pretty amazing, isn't it?
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Being able to access directory data in this way makes many kinds of data recovery tasks much easier than they used to be. For instance, to recover a deleted object from a backup formerly required that you perform a non-authoritative restore of the backup on an existing DC and then perform an authoritative restore of the deleted object. And if the backup you restored didn't have the correct data, you had to start all over again with a different backup. Now, using tombstone reanimation and snapshots, you can quickly find and recover deleted data, and you don't even have to take the domain controller offline to do it.
There are some limitations, however. For instance, each active snapshot increases the disk I/O associated with write operations to the directory, so you probably shouldn't have more than one or two snapshots active at any point in time on a production DC. Also, the longer you keep snapshots active, the larger the Volume Shadow Copy Service delta store becomes—this can also affect performance. And, of course, simply recovering a deleted object is only the first part of the recovery problem. You will probably have to recover the object's linked attributes, such as group memberships, as well. But even in this case, the snapshot can help you identify all the groups the deleted object was a member of.

A Sound Backup and Recovery Strategy for Active Directory
Windows Server 2008 brings an entirely new backup and recovery system to the table. Some of the changes may at first cause weeping and gnashing of teeth. But once IT organizations have accepted these changes and incorporated the new backup technology into their day-to-day operations, they will wind up with a more effective backup and recovery implementation.
Even with all of the changes in the way you back up servers in Windows Server 2008, the basic strategy for backing up and recovering Active Directory doesn't really change that much. So when planning your strategy, be sure to keep these best practices in mind:
  • Schedule periodic full system backups so you can recover a DC after a hardware failure. How frequently you schedule full backups of a DC depends on how frequently your data is updated, your tolerance for downtime and/or data loss, and the effort that may be required to rebuild the DC from scratch.
  • Schedule frequent system state backups to back up changes in Active Directory. How frequently you perform system state backups depends on your tolerance for lost Active Directory data. But you should do this at least once a day. If you have the hardware, keep at least one or two system state backups on a local disk and copy older system state versions to a DVD or to a network share.
  • Be sure to do system state backups on at least two DCs in each domain. This will provide some insurance in case one of the backups is bad or unavailable.
Be sure to back up DCs with application partition replicas if you have defined them. And consider creating a Windows Recovery Environment partition on your DCs so you can boot quickly into WinRE in case a critical system drive fails. 

Gil Kirkpatrick is the CTO at NetPro and has been developing software for Active Directory since 1996. Along with Guido Grillenmeier from HP, he delivers the popular Active Directory Disaster Recovery workshops. Gil is also the founder of the Directory Experts Conference (see www.dec2008.com).
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Windows Administration: Designing OU Structures that Work
Windows Administration Ken St. Cyr

Designing OU Structures that Work
At a Glance:
  • Key principles of good OU design
  • Common OU design models
  • Document your OU design

Don't underestimate the importance—and complexity—of designing a good Organizational Unit (OU) structure. I've found that IT departments often go in either direction—they
put too much emphasis on the OU structure or they don't put enough thought into it. Either way, this can lead to problems with your Active Directory® model.
Overemphasizing the OU structure takes focus away from other areas of Active Directory design, such as planning the site topology or thinking about domain controller sizing. On the other hand, when OU planning is put on the back burner, Group Policy and delegation suffer.
One of the excuses I've heard on occasion is that the OU structure is flexible and can be changed at a later date if it doesn't fit. It's true that the OU structure is flexible; however, administrators often discover that changing the OU structure down the road is harder than they had originally anticipated. Sure, new OUs can be added, but the old ones are not easy to clean up.
A poorly planned OU structure tends to take on a life of its own. If a new object is created in the directory and the administrator doesn't know where in the OU structure to place the object, he will either create a new OU or put the object somewhere that it doesn't belong. There are dangers to both of these scenarios. Creating a new OU is easy to do, but hard to track over the long run. Rampant OU creation contributes to a chaotic OU structure, and it's easy to let things creep into the directory undocumented. On the other hand, if you add an object to an existing OU in which it doesn't really belong, the new object might receive policies that it shouldn't get or permissions to the object might be delegated to unintended users.
When designing OU structures, you should keep a basic equation in mind: simplicity + adaptability = sustainability. If your design is too simple, it may not be adaptable and therefore will have to be changed too often. If your design is too adaptable, then everything will be compartmentalized, and that brings about too much complexity.
There are three key principles regarding Group Policy, delegation, and object administration that can help guide your design decision. These principles can be summed up with three questions you should ask yourself that will help to ensure the OU structure you are creating will stand the tests of time and organizational change:
  1. Does this OU need to be created so a unique Group Policy Object (GPO) can be applied to it?
  2. Does a particular group of administrators need to have permissions to the objects in this OU?
  3. Will this new OU make it easier to administer the objects within it?
If the answer to any of these questions is "yes," then you should probably create the OU. If the answer to all three questions is "no," then you should rethink the layout and determine whether a different design might create a better fit. But before I dive into this any deeper and show you how to apply these principles, I should first explain why these principles are important.

Principle 1: Group Policy
The first principle of OU design is to take into account the Group Policy Objects that will be applied to an OU. A GPO allows you to configure settings for users and computers in an enforceable manner. You can define multiple GPOs in Active Directory and apply them to the entire domain, various OUs, or even the sites in the domain. GPOs are split into two categories—one for users and one for computers.
Both computer policies and user policies can be defined in the same GPO. The User Configuration section of the GPO mostly defines the experience the user will have when logged in. These types of settings also exist in the Computer Configuration section, but this section also contains more settings related to the security of the computer, such as who can log on to the computer locally or how data is encrypted.
Here are some fundamentals to keep in mind when defining OUs to support GPOs. First off, just because user and computer policies can both be defined in the same GPO, that doesn't mean it's a good idea to put user and computer objects in the same OU. Combining them in the same GPO makes GPO application harder to troubleshoot. This becomes very evident when you have a loopback policy enabled.
Secondly, many people forget that you can apply GPOs at the site level and therefore design their OU structures to model their site structure for the purposes of GPO application. This is a common model of OU design, known as the Geographic Model. I'll talk more about this model in a bit. I would be remiss not to acknowledge that the Geographic Model has its place in OU design, but as you'll see later, I don't believe that GPO application should be the primary reason for implementing this model.
Also, when you think about your OU structure in terms of GPOs, the goal should be to eliminate complexity. Make sure that the OU adds to the flow of GPO inheritance. If your OU contains servers that require the same policy as other servers, consider putting these computer objects under a broader Servers OU and creating multiple OUs for different server types below the Servers OU (see Figure 1). This can simplify policy application, as each computer object in the lower OUs will get the policy from the Servers OU as well as any other policies that are specific to that specific type of server.
Figure 1 Creating multiple OUs for different server types
Figure 1 Creating multiple OUs for different server types
Another fundamental is to ensure that you don't unnecessarily create or link multiple GPOs. With a GPO, you can create one policy and apply it to multiple OUs. This is sometimes helpful, but it can also be harmful. If you have to change a GPO setting and you have an overly complex system of linked GPOs, you could accidently apply a change to the wrong objects. The more links you create, the more difficult it is to grasp the scope of a policy. Likewise, you should avoid creating additional policies with the same settings as other policies. If you find that you often do this, consider modifying your OU structure to apply a new GPO inheritance model.
And finally, you should almost always create a new OU for user objects and computer objects. By default, user and computer objects are placed in containers, which don't allow you to link GPOs directly to them. GPOs can be applied to the Users and Computers containers from the domain, but unless you block inheritance elsewhere, those policies will be applied to every user and computer in the domain. In Windows Server® 2003, you can use the rediruser.exe and redircomp.exe tools to change the default location for user objects and computer objects to the OU that you created for them.

Principle 2: Delegation
It is important that you create the OU structure in a manner that is consistent with how permissions are delegated in the domain. Keep in mind that when permissions are delegated in Active Directory, the permission changes are made only to the object. So if you were to give a user Full Control for a particular computer object, that person would be able to modify the attributes of the object, but they would not have Administrator privileges on the computer itself.
Here are some recommended practices regarding delegation for when you design an OU structure:
Design with Permission Inheritance in Mind For instance, say you want your Tier 1 administrators to be able to change the password for most accounts. There is a special group of users for which the administrators should not have the ability to reset passwords, but the admins do need to be able to change the display names on those accounts.
You really have two options here. First, you could create two separate parallel OUs and separate the special users from the regular users. This, however, means that if you want to change the delegation options for all users then you have to change these permissions in two separate places. This also contradicts the practice of not unnecessarily multiple linking policy (see Figure 2).
Figure 2 Maintaining two separate parallel OUs
Figure 2 Maintaining two separate parallel OUs
The other option is to create a nested OU and place an explicit deny permission on the OU that has special users in it. Any delegation expert will tell you that an explicit deny is not preferable—but in this case, you need to select the lesser of the two evils (see Figure 3). You can either duplicate and maintain the settings on two separate OUs or you can place an explicit deny on one of the OUs. The explicit deny is actually the better long-term decision.
Figure 3 Using an explicit deny permission
Figure 3 Using an explicit deny permission
Beware of AdminSDHolder This example works well unless the special users all belong to one of the Admin groups (Domain Admins, Schema Admins, Enterprise Admins, or Administrators) since permissions for accounts in these groups are handled differently. The idea is that you don't want to accidently give someone permissions to an admin account.
If you create a separate OU for administrators, you'll find that the permissions that you delegate to them keep disappearing. This is due to AdminSDHolder, which is a special container that applies its Access Control List to every administrator account on a specified interval. As a result, any delegation changes you make to an admin account will be reversed if the changes aren't also made to the AdminSDHolder container. So you shouldn't separate administrator accounts from other accounts for the purpose of delegation. It is preferable, though, to separate out the administrator accounts for the purpose of Group Policy—this is especially true in Windows Server 2008, where you can have multiple password policies.

Principle 3: Object Administration
The OU should facilitate administration of the objects. Grouping objects into the same OU can often make it easier to perform bulk changes. The Active Directory Users and Computers snap-in lets you edit certain attributes on a selection of multiple objects. So if you regularly have to change an attribute on a group of objects, it is easier to do if they are all in the same OU.
This is also particularly useful if you are making updates with a script. Scripting languages make it very easy to enumerate all of the objects in an OU and deal with them one by one. The other option is to search for and modify each object individually. Simply placing the objects in the same OU for administration can sometimes save you hours of unnecessary work each week.
Another way to help with the administration of objects is to separate the objects into different OUs based on their type. Creating a separate OU for printer objects or published shares ensures that these objects won't need to be weeded out when you perform administration on other objects in the OU. This practice also aligns with the practice of not grouping user and computer accounts together in the same OU.

Choosing a Model
Now that I've covered the principles of OU design, I can take a closer look at some common design models. Note that there are many more models than the ones I have space to cover here. And you aren't limited to working within the constraints of a single model. You can pick pieces from each and build your own hybrid model that addresses your particular needs.
Just about any model can be successful on a small scale, but when your enterprise grows, your ability to keep a handle on the environment shrinks. So make sure that you first thoroughly test your model in an adequate lab environment. And remember that while OU structures can be changed easily at first, they are harder to change the longer they are in place.

The Shallow Model
The Shallow Model gets its name from the fact that it is kept mostly flat. In this model, a few high-level OUs contain the majority of the objects (see Figure 4). This model is mostly exercised in smaller businesses where there is a small IT shop, there aren't a lot of different divisions, or people tend to play multiple roles. I typically recommend not going any deeper than 10 sub-OUs, though Microsoft suggests a 15 sub-OU limit before performance penalties are realized.
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
If your Human Resources person is also your payroll person, then it doesn't make sense to create two separate OUs for Human Resources and Payroll. In the Shallow Model, all the user objects can be grouped into one big Accounts OU or they can be kept in the default Users container. At the very least, your user objects should be separated from your computer objects.
For this model, I also recommend that you go a step further and separate your workstations from servers. Then you can at least apply different Group Policies without having to define a GPO that uses a Windows® Management Instrumentation (WMI) Query to filter out workstations or servers.
One advantage of keeping your OU structure wide, rather than deep, is that Active Directory searches will execute faster. I typically recommend not going any deeper than 10 sub-OUs. Your control over objects isn't very fine-grained in this model, but if you're managing objects in a small business, you won't need that fine-grained control. Thus, this model would be difficult to use successfully in a large enterprise, but it works very well in smaller organizations.

The Geographic Model
In the Geographic Model, you create separate OUs for different geographic regions. This model is best suited for organizations that have decentralized IT departments but don't want to incur the costs associated with operating multiple domains (see Figure 5).
Figure 5 The Geographic Model separates OUs by geographical region
Figure 5 The Geographic Model separates OUs by geographical region
Let's say you have offices in Atlanta, Baltimore, and Seattle. If each site manages its own users and computers, then this might be a good fit in terms of delegation. But what happens if a Seattle user flies out to Baltimore for training and then locks out his account. The IT folks in Baltimore may not be able to help this user if they have not been delegated permissions to this user's account. If it's 8 A.M. in Baltimore, it's 5 A.M. in Seattle, which means the user may have to wait hours before he can reach someone in the Seattle office for help.
Some global companies use a "follow the sun" model, where help desk calls are routed to a site located in a time zone where it's currently standard business hours. This means the company doesn't have to operate a 24-hour help desk at each site but can still provide late-night employees with help, such as unlocking their accounts, when necessary.
If this is your model, creating separate OUs based on geographical location probably isn't the best choice for your operational needs. You would have to delegate separate permissions to each regional help desk for every OU of users. However, if your sites do have their own IT departments, then the Geographic Model might, in fact, be a good model for your organization.
The Geographic Model is also difficult to pull off in a single domain due to the nature of how a domain operates. A domain tends to have a different security model from other domains. This is more evident when you look at an enterprise-wide application, such as Microsoft® Exchange.
The Exchange Server in Atlanta may have different message policies defined, but all of the Exchange Servers in the enterprise probably have the same GPOs applied. If this is the case, then putting the Exchange Servers in separate OUs based on region would cause you to unnecessarily link the same GPO to multiple OUs. In terms of delegation, you have to ask if the Exchange administrators really need unique permissions to the computer objects for the Exchange Servers. In most cases, computer objects that are split into geographic OUs are done so for Group Policy purposes, not delegation purposes.

The Type-Based Model
The Type-Based Model classifies objects by their purpose (see Figure 6). When you created your last user object, was it for a regular user account, an administrative account, or a service account? In a Type-Based Model, each of these objects is treated differently.
Figure 6 The Type-Based Model groups objects according to their functions
Figure 6 The Type-Based Model groups objects according to their functions
In most cases, you should distinguish among different classifications of user objects for policies. Your policies will most likely differ based on user account type. For example, allowing people to log on to a computer with a service account is generally a bad business practice. Service account passwords are usually shared among many people, so if someone logs on with a service account, their identity remains anonymous. If something were to happen, you would have trouble tracking down the user who was logged in when the event occurred. In this example, you'd need to set a policy on service accounts that prevents interactive logon. This fits well in the hierarchical model shown in Figure 3.
You could use GPO inheritance to your advantage here. For instance, you could have an All Users policy that refers to policies in place for all user objects. In addition, you could have a separate and distinct policy for service accounts, which builds on the All Users policy. This approach ensures your service accounts have the same base set of policies as every other account as well as the specific logon restrictions.
This approach also works well for delegation, where you are using permission inheritance instead of GPO inheritance. Suppose you want your Tier 2 administrators to have the ability to reset passwords for all accounts except for the Tier 3 administrator accounts. With a flat OU structure, you would have to delegate permissions to each OU that holds user accounts. However, in a Type-Based Model with a hierarchical structure, you can give the Tier 2 group "reset password" permissions on the Accounts OU, and then at the Tier 3 OU, you could simply uninherit the permissions or even set an explicit deny for Tier 2 to reset passwords.
This also works well for computer objects. Servers and workstations can be separated allowing different policies to be applied to them. Servers can then be further sub-divided into functions (see Figure 1). In this design, you can set a high-level policy on the Servers OU that affects all servers and still set individual policies on each lower-level OU.
For example, let's say you have a Microsoft Operations Manager (MOM) service account. With this tiered model, you can create a MOM GPO and apply it to the MOM Servers OU. And then inside that GPO, you can give the MOM service account rights to logon as a service. This would only apply to the MOM servers in that OU. The MOM servers will still get the Servers GPO from the higher-level Servers OU, but they will also get the specialized MOM GPO, which is linked at the MOM OU.

Document the Design
It can be very rewarding to design an OU structure that will stand up to the many changes an Active Directory environment encounters. But you need some way to track the dynamic characteristics of OUs. If you don't have this, you could quickly lose a handle on your environment. When things do need to change and an OU needs to be added or deleted, there must be clear guidance on what to do to ensure that your model continues to follow your design model, adhering to the three guiding principles. That's why you must have a well-documented design.
Microsoft provides documentation guides in the Windows Server resource kit. These guides are good if your structure is a solid framework that you don't expect to change much. But most organizations have a very dynamic structure that changes frequently. So here are some important tips to ensure that your OU structure is well-documented and able to support a dynamic environment.
Make Sure All the Info Is Relevant I'm a strong believer in documentation that has purpose. Too many operational documents have so much extraneous information that it's hard to find the stuff that matters. Don't get caught up in the process of documenting just for the sake of documenting. Do you really need to include the number of objects in each OU or each Access Control Entry (ACE) on the Access Control List for the OU? For OU documentation, the following information will usually be sufficient:
  • OU Name
  • Short description
  • Who created it—or who to contact for more information or changes
  • When it was created
Don't Make Updates Difficult If you have to tediously update some complex Microsoft Word document, you're more likely to put off entering updates. It's OK if you hold off on inputting small changes when you know you will soon have a bigger bulk of updates to input all at once. Unfortunately, people often forget these little changes or simply keep putting them off and then the job never gets done. Therefore, updating the document must be very easy so as not to discourage you. In most cases, a simple Microsoft Excel® spreadsheet with a few columns will work fine.
Make Comments on the Object Itself OU objects have a description attribute where you can enter comments. Rather than writing the comments in the design document, consider putting them in the description attribute so others can tell right away what the OU is for. If you need to include more details, then put a brief description in the description attribute and include more details in the OU document.
Automate the Documentation A script can be written to dump the contents of the OU structure out to a text file, an Excel spreadsheet, or even an HTML file. This script could be run on a scheduled task every night. This can be very useful if you incorporate comments in the description field of the OU. Then it's just a matter of dumping out the description attribute to the file and you automatically have a fully documented OU structure that is always current. If you create a new file every time the script runs, as opposed to overwriting the existing document, you can keep a historical record of how the OU structure has changed over time.
Unfortunately, most administrators don't realize the importance of good OU structure documentation until they really need it. And by then, at 3 A.M., it's nearly impossible to figure out what other OUs were accidently deleted without performing a restore.
Don't wait until this happens to you. I highly recommend that you become proactive in this area and immediately start an OU document and designate one person to be responsible for updating it. And if you follow the rule of making the documentation easy to update, this will be a very small task to keep rolling. 

Ken St. Cyr is a consultant for Microsoft with 10 years of IT industry experience. He has designed and implemented directory solutions based on Active Directory since its inception.


 Windows Administration: Extending the Active Directory Schema
Windows Administration Vikas Malhotra

Extending the Active Directory Schema
At a Glance:
  • Understanding the default Active Directory schema
  • Adding classSchema or attributeSchema objects
  • Getting and using object identifiers
  • Extending your schema using .ldif files
Download the code for this article: Schema2008_05.exe (151KB)

Since the introduction of Active Directory with the release of Windows 2000, Microsoft has provided customers with the base schema definition for implementing Active Directory.
The presence of Active Directory® also marked a shift in the way many applications were written and implemented on Windows®. Before then, applications such as Microsoft® Exchange 5.5 were built to contain their own directory structure. As Active Directory became available, many applications (both from Microsoft and other companies) started to take advantage of the underlying structure it provided, instead of building their own schema from the ground up.
These applications began with the basic architecture provided by Active Directory, then extended it as needed. Microsoft Exchange 2000, for example, utilized Active Directory for messaging implementations, thereby defining the future of the Microsoft messaging architecture.
Today, many applications written to work in an Active Directory environment rely on its underlying schema in order to function, and many also define their own changes to the schema as needed. This, of course, requires a schema capable of extension, as I'll discuss in this article. Moreover, since so many applications are dependent on the base definitions in Active Directory, the continued stability of the core schema is critical. Since many applications need to work alongside one another in the same Active Directory, changes made for any one application must not impact the others.

What Is a Schema?
To many, the Active Directory schema is a black box, and the idea of modifying the schema on one's own can be intimidating. Of course, extending your Active Directory schema is not something you'll need to do every day, but certain applications or business needs may require doing so. Thus it is very important to understand what a schema is and what it contains, since Active Directory is a vital asset in many organizations, and having it malfunction due to an incorrect update can have a very significant impact.
As a strategy, there are many organizations that consider using Active Directory Lightweight Directory Service (ADLDS) in Windows Server® 2008 (or Active Directory Application Mode, ADAM, in Windows Server 2003) as an alternative for testing or for directly implementing the customized schema definitions instead of extending the Active Directory schema.
A schema is the underlying structure that provides the format for a directory service. The Active Directory schema defines the object classes and attributes that are used in Active Directory Domain Services (ADDS). The core schema provides definitions for many well-known classes (such as user, computer, and organizationalUnit) and attributes (such as telephoneNumber and objectSID). The objects present in the core schema definition are known as Category 1 objects, and objects that are added are called Category 2 objects.
An Active Directory schema can be found in the container defined at the path cn=Schema, cn=Configuration,dc=X, where X is the namespace of the Active Directory forest. Note that an Active Directory forest contains just a single schema; making changes to the schema definition in a forest affects all the domains in that forest. Figure 1 shows the number of classes and attributes that are added in the Active Directory schema in different versions of Windows Server.
Figure 1 Number of classes and attributes (Close Figure 1)

Version | Number of Attributes Added | Number of Classes Added | Schema Extension Files
Windows Server 2003 | 208 | 49 | Sch14.ldf to sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | Sch32.ldf to sch44.ldf
The schema update for different versions of Windows Server is done using a utility named Adprep. With the updates for Windows Server 2003 R2, the schema version gets updated to 31, and it changes to 44 with Windows Server 2008.
This can be verified by checking the value of the objectVersion attribute of cn=Schema,cn=Configuration,dc=X in your Active Directory using a tool such as ADSIEdit. Note that some applications such as Exchange Server, System Management Server (SMS), or others that are dependent on Active Directory may modify the schema according to the application needs.

Bricks and Mortar
Active Directory consists of two types of objects: classSchema (class for short) and attributeSchema (attribute for short). Extending the Active Directory schema is typically considered when an organization wants to store data in certain attributes that are not available in the existing schema. You create an attribute in an Active Directory schema by first specifying an attributeSchema object in the schema container and then defining the necessary properties for the new object.
You'll find a list of properties for attributeSchema objects along with information about them at go.microsoft.com/fwlink/?LinkId=110445. As you can see, there are many properties that can be defined for attributeSchema objects; a number of these properties are required.
Apart from the regular attributes, there are also special attributes called Linked attributes within a schema that are implemented in pairs by providing a forward link and a backward link. As an example, consider group membership in Active Directory. The member attribute of any group (for example, a group named ContosoEmployees with a member named John Doe) is the forward link, and the corresponding memberOf attribute of the member object is the back link (so that, for example, when the memberOf attribute of John Doe is queried, the distinguished name, or DN, of ContosoEmployees group is calculated).
The forward link behaves much like any other attribute. The values can be single-valued or multivalued (as with the member attribute, which can contain multiple objects as members of a group) and are stored together with the parent object in the directory.
Back links, on the other hand, are maintained by the system to ensure referential integrity. When you query for the value of a back link attribute, the results will be calculated from all the matching forward link values. Back links are always multivalued.
Each object class in ADDS is defined by a classSchema object in the schema container. You'll find a list of the attributes critical to the successful definition of the classSchema object at go.microsoft.com/fwlink/?LinkId=110445.
There are three types of classes that can be specified: Structural, Abstract, and Auxiliary. These are defined by the value of objectClassCategory attribute. (A fourth category, known as 88, includes classes defined before X.500 1993 standards. This type of class is specified by a value of 0 in the objectClassCategory attribute. This type of class should not be defined any longer.)

Getting and Using Identifiers
The identities of each classSchema and attributeSchema object in the directory are defined using a mandatory object identifier (OID), which is defined against governsID for classSchema objects and attributeID for attributeSchema objects. These are unique numeric values supplied by certain issuing authorities to identify the objects. The numbering is governed by definition of the LDAP protocol (RFC 2251). Some of the OIDs in the Active Directory schema are issued by the International Organization for Standardization (ISO) and some are issued by Microsoft. An OID must be unique for an object within the directory.
The OID is a string of numbers, for instance 1.2.840.113556.1.y.z, as described in Figure 2. Thus an OID for a user classSchema object, for example, is 1.2.840.113556.1.5.9.
Figure 2 Identifier for the user object (Close Figure 2)

Value | Meaning | Description
1 | ISO | Identifies the root authority.
2 | ANSI | Group designation assigned by ISO.
840 | USA | Country/region code assigned by the organization.
113556 | Microsoft | Organization designation assigned by the country/region.
1 | Active Directory | Assigned by organization (by Microsoft, in this case).
Y | Object Type | Number defining the different object type (category) such as classSchema or attributeSchema. For example, 5 defines object class.
Z | Object | Number identifying a particular object within the category. For example, the user class has the number 9 assigned to it.
When an organization intends to extend the schema, it ensures that the OID is unique by obtaining its own OID root number, which is then branched off to provide unique IDs to the new object classes and attributes that the organization creates. The OID root may be obtained directly from an ISO National Registration Authority (NRA), which in the United States is the American National Standards Institute (ANSI).
You can get the procedure and fee schedule for obtaining a root OID at ansi.org. For other regions, contact the corresponding ISO member organization; ISO offers a list at iso.org/iso/about/iso_members.htm.
Organizations used to be able to obtain an OID from Microsoft by sending e-mail to schemreg@microsoft.com. However, that now results in an automated reply prompting the requester to download and run the VBScript from go.microsoft.com/fwlink/?LinkId=110453.
For the OIDs that are issued by Microsoft, the number is assigned under the Microsoft OID number space: 1.2.840.113556.1.8000.x, where x is a unique number assigned to the organization. The organization may further divide these OIDs to specify the objects. Thus an organization might use 1.2.840.113556.1.8000.x.1.y for new classSchema objects and 1.2.840.113556.1.8000.x.2.z for attributeSchema objects (where x represents the organization's unique number, and y and z, respectively, are the numbers assigned for specific classSchema and attributeSchema objects). It is also recommended that an organization-specific prefix be used in the names of these objects to distinguish them.

Defining Linked Attributes
It is important that the attributeSyntax value of a forward link be 2.5.5.1, 2.5.5.7, or 2.5.5.14. These values correspond to syntaxes that contain a distinguished name, such as the Object (DS-DN) syntax.
The attributeSyntax value of a back link must be 2.5.5.1, which is the Object (DS-DN) syntax. By convention, back link attributes are added to the mayContain value of the top abstract class. This enables the back link attribute to be read from objects of any class because back link attributes are not actually stored with the object; instead they are calculated based on the forward link values.
Windows Server 2003 introduced a feature organizations could use to link two objects in a schema: auto-generation of linkIDs. With this feature, the system automatically generates a linkID for a new linked attribute when the attribute's linkID attribute is set to 1.2.840.113556.1.2.50. A corresponding back link is created by setting the linkID to the attributeId or ldapDisplayName of the forward link. The schema cache must be reloaded after creating the forward link and before creating the back link. Otherwise, the forward link's attributeId or ldapDisplayName will not be found when the back link is created. The schema cache is reloaded on demand, a few minutes after a schema change is made or when the domain controller is rebooted.
If your Active Directory is at Windows 2000 level, you will need to request linkIDs from Microsoft by sending e-mail to schemreg@microsoft.com. Within the automated response, you'll see this line: "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments." For this, provide the following information in the e-mail: company name, contact name, e-mail address, phone number, prefix registered (if applicable), OID registered (if applicable).

Ready to Extend the Schema
Let's say you've decided to extend your Active Directory schema. This analysis may have involved discounting the use of an alternate directory implemented using ADLDS (or ADAM in Windows Server 2003) after making sure it would not meet the requirements. As a next step, you have identified the new attributeSchema objects you want to add to the schema and, in doing so, you have defined all the required values (such as cn, ldapDisplayName, and so forth) that specify these new objects. In defining the attribute values for the object, you have also obtained the OID from Microsoft or from another source. You have essentially documented the above as business requirements and technical specifications. Moreover, you have also implemented a lab environment that mimics your Active Directory and is ready for testing.
Many organizations actually set up committees to approve or deny such changes and to set the process for implementing them. The need for such checks and balances is crucial since Active Directory is used as an authoritative information source in many organizations, and the importance of keeping it up and running after changes are made cannot be stressed enough.
Once the organization decides to move ahead, you must define test and implementation plans for this project. You may extend the schema by either adding the new objects using the Active Directory schema snap-in within the Microsoft Management Console (MMC) or by using programmatic or semi-programmatic methods to extend the schema (such as using LDIFDE to import .ldif format files; CSVDE to import .csv format files; or with Active Directory Service Interfaces, ADSI, scripting).
Whichever method you use, this function must be performed on a server that is either connected to or holds the Flexible Single Master Operations (FSMO) role of Schema Master in the Active Directory forest. Also, the account you use for the schema update needs sufficient admin privileges in order to perform the update, so make it a member of the Schema Administrators group. Finally, you must enable schema updates for the forest (this is disabled by default).
Unless the change is very simple, it should be made in an automated fashion in order to foster standardization between the test and production implementation phases and to reduce the sorts of errors likely to result by performing the steps manually. Let's suppose you decide to implement your change using LDIFDE. To apply updates when extending the schema, you would add the new attributes and classes, add the new attributes to classes, and then trigger a cache reload. Let's walk through a couple of scenarios.

Adding Attributes
Suppose, for the sake of argument, an organization named Contoso wants to add an attribute into its Active Directory that identifies the shoe size of each employee. The Active Directory forest has two domains: contoso.com and employees.contoso.com. The requirement is that all the objects created using the user class definition should also contain this new attribute.
It's important for you to keep in mind that the schema change will affect both domains since they are in the same forest. Let's assume you have received the OID of 1.2.840.113556.8000.9999 from Microsoft and that you have further subdivided it into 1.2.840.113556.8000.9999.1 for classSchema and 1.2.840.113556.8000.9999.2 for attributeSchema objects for Contoso. Now you are going to define all the attribute values for this new object, as shown in Figure 3.
Figure 3 Defining the contosoEmpShoe attribute (Close Figure 3)

Attribute | Value | Notes
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | Specifies a Unicode string.
oMSyntax | 64 | Indicates a Unicode string.
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | As defined by the organization.
isSingleValued | TRUE | Only one shoe size value can be stored.
searchFlags | 1 | Your analysis shows that you want to index this attribute. Note: you will perform the stress test analysis in the lab environment.
isMemberOfPartialAttributeSet | TRUE | You want this attribute to be available in the Global Catalog.
Further, while the contosoEmpShoe attribute needs to be available for all objects created as user class objects, it is not recommended that you modify the default definition of the user class. Instead, you should define an auxiliary class named contosoUser that has the value of mayContain specified as contosoEmpShoe, as shown in Figure 4. Then you add the attributes defined for the contosoUser auxiliary class to the user class.
Figure 4 Defining contosoUser class (Close Figure 4)

Attribute | Value
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1 (as defined by the organization)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, container
objectClassCategory | 3 (defines an auxiliary class)
Now that you have performed the analysis and defined the values, it is time to create the .ldif file, which will look like the code in Figure 5. You can copy the contents of Figure 5 into Notepad and save the file as contosoUser.ldif (or you can also find a copy in the code download on technetmagazine.com).
Figure 5 .ldif file for extending your schema (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
After generating the .ldif file, you'll want to test the implementation thoroughly in a lab environment, verify the end-to-end replication of your domain and forest, and enable the updating of the schema in the forest. At this point, you should login with an account that has Schema Admin privileges. You may want to disable outbound replication on the schema master (where the change will be performed) and then run the following command to import the .ldif file:
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
Once the change takes place, enable outbound replication on the schema master and verify that the replication has happened for all domain controllers.
Take a deep breath—you're finished! You defined a new attribute in the schema that will be associated with the objects created using the user class (that is, user accounts).
To verify the change, open Active Directory Users and Computers, connect to the employees.contoso.com domain, browse to the Users organizational unit (OU), and create a new user account named ContosoTestUser. Now open the adsiedit.msc console and connect to domain partition dc=employees,dc=contoso,dc=com, expand the Users OU, right-click on the ContosoTestUser, and open the Properties page. Browse to find the contosoEmpShoe attribute. You may edit this attribute to enter a value. You can also use the Ldp.exe utility to verify and modify the attributes.
Now let's look at an example that defines and links two attributes, and let us imagine a scenario where Contoso puts high importance on employee shoe sizes and wants the annual performance of the people who take shoe sizes in the company to be tracked somehow. While this may sound funny, let's further suppose Contoso wants to keep track of not only who was responsible for measuring employee shoe sizes but also whose shoe sizes they measured and how many—all by querying one attribute. (You may think this data is more appropriately stored in database tables, but the idea here is simply to explain the workings of forward and backward links.)
Of course, you would first go through the same kind of analysis I noted in the earlier example. Here, however, let's move forward to generate the .ldif files linkids1.ldif and linkids2.ldif, as shown in Figure 6. Then run this command to import the .ldif files:
Figure 6 Forward and backward link .ldif files (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
Now when a user object is created, it will also have ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe as its attributes. While creating the user object for, say, John, the ContosoShoeSizeTaker attribute is filled with the DN of the person who took the shoe size, the person named Frank. Now when you go into Frank's user object's properties and query the ContosoShoeSizesTakenByMe attribute, the result will contain John's DN and any others that Frank may have taken. To complete our scenario, the management may reward Frank based on how many DNs exist in his user account's ContosoShoeSizesTakenByMe attribute.

System Checks and Balances
A critical update like schema modification cannot be performed without checks against architectural requirements. These consistency checks and safety checks are used by Active Directory to verify that the changes do not cause any inconsistencies or other problems whenever an addition or modification is made to the Active Directory schema.
First, the value of governsID for each class must be unique within the schema. When defining a schemaClass object, all the attributes that are defined in the systemMayContain, mayContain, systemMustContain, and mustContain lists must already exist. At the same time, all classes that are defined in the subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors, and possSuperiors lists must already exist, too.
Further, the objectClassCategory of all classes in the systemAuxiliaryClass and auxiliaryClass lists must be either 88 class or Auxiliary class. Similarly, the objectClassCategory of all classes in the systemPossSuperiors and possSuperiors lists must be specified as either 88 class or Structural class.
While defining various classes, Abstract classes can inherit only from other Abstract classes, Auxiliary classes cannot inherit from Structural classes, and Structural classes cannot inherit from Auxiliary classes. Also, the attribute specified in the rDNAttID attribute must have Unicode-string as its syntax and be single-valued.
These are some of the rules that relate to classSchema objects. What about those for attributeSchema objects? As with the governsID value for classes, the value of attributeID must be unique. Also, the value of mAPIID, if any, must be unique. Further, if rangeLower and rangeUpper are present, rangeLower must be smaller than rangeUpper. The values of attributeSyntax and oMSyntax must match. If the attribute is object-syntaxed (oMSyntax =127), it must have the correct oMObjectClass. The linkID, if any, must be unique. In addition, a back link must have a corresponding forward link.

What if You Goof?
Once the schema has been extended with the new objects (classes and attributes), they cannot be deleted. However, a class or attribute can be deactivated by setting the attribute isDefunct to TRUE on the schema object. You cannot deactivate schema objects that are part of the default schema that ships with Active Directory (Category 1 objects). You can only deactivate objects that have been added to the default schema; that is, only Category 2 objects can be disabled and only when Active Directory has verified that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors list of any existing non-defunct class.
With any attempt to make an attribute defunct, Active Directory checks that the attribute is not used in the mustContain or mayContain of any existing non-defunct class. The disabled objects can be resurrected by setting the attribute isDefunct to FALSE. If your Active Directory is at the Windows Server 2003 level, you can reuse the ldapDisplayName, schemaIdGuid, OID, and mapiID values of the disabled object.

Conclusion
Adding or modifying class or attribute definitions in the schema involves adding or modifying the corresponding classSchema object or attributeSchema object. This process is similar to adding or modifying any object in Active Directory, except that additional checks are performed to ensure that changes do not cause inconsistencies or problems in the schema in the future.
While modifying the Active Directory schema is straightforward, it's important to understand the formation of schema and how it functions to implement these changes. Any change to production Active Directory schema requires a lot of planning and must be done carefully. It's critical that you define the business requirements and technical specifications for new objects and perform a great deal of lab testing. Since changes can have profound effects, it is recommended that you only extend the Active Directory schema when it is absolutely necessary.

Vikas Malhotra is with Microsoft Consulting Services in New York. During his 12 years in the business, he has worked with many IT organizations in large and mid-range companies on their infrastructure architecture needs such as directory, messaging, security, and data networking. He holds a Bachelor of Engineering in Electronics and Telecommunications and a Master of Science in Telecom (Tech) Management. Contact him at vikasmal@microsoft.com.


 System Center: Introducing System Center Mobile Device Manager
System Center Matt Fontaine

Introducing System Center Mobile Device Manager
At a Glance:
  • A typical Mobile Device Manager system
  • Extending Active Directory to Windows Mobile
  • Enrolling, provisioning, and inventorying Windows Mobile devices

The launch of Microsoft System Center Mobile Device Manager 2008 is an exciting development for IT pros managing Windows Mobile devices on corporate networks. By providing device management, security management, and Mobile Virtual Private Network (VPN)
capabilities in a single product, this new offering can help lower administrative burdens and foster enhanced return on investment (ROI) for mobile device fleets.
Mobile Device Manager enables IT pros to use the existing Active Directory® and Group Policy infrastructure to enforce device settings. Over-the-air (OTA) device-management capabilities let IT pros deliver updates and applications to devices easily, while OTA self-provisioning makes deployment easier and more scalable. Mobile VPN gives end users access to data and applications behind the firewall while providing an always-on connection for administrators to control deployed devices. With all these capabilities in one extensible, customizable, and scalable product, Mobile Device Manager is a vital tool for today's IT pros.

The Need for Management
The mobile workforce is expected to continue its rapid growth in years to come. Mobile devices have historically been more difficult to manage than other network equipment due to the very fact of their mobility. They connect to the network in a variety of ways, and some devices are not as secure as others—they may exist outside the firewall, they use different operating systems from client devices, and they are small and easy to misplace or lose.
The expanded functionality of today's mobile devices provides enticing benefits to both enterprises and end users, but it also makes supporting those devices more complex. This may expose corporate data and networks to additional security risks, especially when devices are used to access sensitive line-of-business (LOB) applications and customer data. Such devices can create security emergencies if lost, stolen, or used improperly.
As the functionality gap between mobile devices and traditional network clients closes, there is a growing need to manage mobile devices just as if they were laptop or desktop computers. That is the idea behind Mobile Device Manager. As the Windows Mobile® platform continues to grow in popularity among business users, Mobile Device Manager will become a crucial aspect of Windows®-based IT management systems.
Mobile Device Manager is designed to provide end-to-end management and control of Windows Mobile Devices as easily as if those devices were networked PCs or laptops. It has three key functions:
Device Management Centralized functionality for provisioning, monitoring, and managing Windows Mobile devices, scalable to tens of thousands of users per server.
Security Management Better mechanisms for protecting sensitive data and keeping track of devices.
Mobile VPN Better access to behind-the-firewall data and applications with always-on functionality.
Mobile Device Manager is aligned with the overall System Center philosophy of equipping IT pros with tools to manage corporate assets as first-class citizens—on a par with desktop and laptop machines. It also provides a user interface that will be familiar to those who already use other System Center products.
This also means that Mobile Device Manager works well by design with an existing Windows-based infrastructure. To cite a few examples, it uses Active Directory and Group Policy; it works with existing Microsoft analysis and reporting tools (such as SQL Server®); and it is extensible using Microsoft® Management Console snap-ins and Windows PowerShellTM cmdlets.

The Mobile Device Manager System
Mobile Device Manager is highly scalable and can support tens of thousands of devices on a single instance, as well as multiple configuration options. Generally speaking, there are four main system components to the server side of Mobile Device Manager: a gateway server, a device management server, an enrollment server, and SQL Server databases (see Figure 1).
Figure 1 Typical Mobile Device Manager system
Figure 1 Typical Mobile Device Manager system
The gateway server is usually installed in the perimeter network. It acts as the terminal for a device's network connection, authenticates incoming device connections, provides stable IP addresses for devices, and performs other functions related to device or network connectivity.
The device management server is the hub of device administration and management, including Group Policy implementation, OTA software distribution, and device wipes. It works with existing domain controllers. Device management servers act as surrogate network clients for Windows Mobile devices, enabling those devices to communicate with other systems.
The enrollment server creates Active Directory Domain Service objects that represent mobile devices in the domain controller, enabling those devices to be managed like other domain members. This server also handles certificate requests and retrieval for mobile devices. It uses Active Directory as the basis for authenticating devices before accepting or issuing enrollment certificates. The SQL Server databases provide a repository for all the information related to device configuration, tasks, status settings, and so on.
Once the infrastructure is up and running, Mobile Device Manager has three types of interactions with mobile devices: device enrollment; the establishment of Mobile VPN connections; and device management. Device enrollment is the process by which a device joins the Active Directory domain. Mobile Device Manager uses a "shared secret"—an expirable one-time password—to enable devices to be enrolled over non-secure connections. Once enrolled, a device can make a Mobile VPN connection to the gateway server through which network traffic from the device is routed. Using the Mobile VPN connection, the administrator or the system can perform device management, pushing software and settings to the device.

Extending Active Directory to Windows Mobile
Hybrid or ad hoc IT security approaches can be riskier than a fully integrated approach to security. Mobile Device Manager is designed to help reduce such risks by providing a way to manage mobile devices such as Windows PCs using the existing Active Directory Domain Services infrastructure. The result is streamlined identity and access management, more consistent policy targeting, and one-stop security configuration.
Just as with PCs or servers, Group Policy Objects related to Windows Mobile devices can be assigned to Organizational Units (OUs), security groups, and Windows Management Instrumentation (WMI) filters. Administrators can also prevent specific devices from getting Group Policy settings.
There are more than 130 settings and policies for Windows Mobile devices, enabling fine-grained control over a variety of functions. Here's just a sample:
  • Password settings include password requirement; type and minimum length; password expiration; and local device wipe after a specified number of failed tries (including user notification of the number of tries remaining).
  • Platform lockdown settings enable administrators to selectively enable or disable device functionality including camera, wireless LAN, infrared, Bluetooth, and removable storage. Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Short Message Service (SMS), and Multimedia Messaging Service (MMS) messaging can all be turned off, and Windows Update for Windows Mobile can be disabled.
  • Mobile Device Manager provides granular application control. It can prevent devices from running unsigned applications or applications with non-approved signatures, or allow specific unsigned applications at the administrator's discretion.
  • To help protect data, the administrator can enforce encryption of files created on removable storage cards (with the encryption key tied to the device). Device encryption is also available for protection of sensitive data on the device. Besides the files that are protected by default, the administrator can specify additional files to be encrypted.
  • Mobile VPN settings determine what control users have over their devices' VPN connections and can also be used to set data encryption levels.
  • ActiveSync® settings set message format, e-mail age filters, size limits, synchronization settings, and more.
  • S/MIME settings can require message signing, message encryption, or the use of specific algorithms.
These settings, and others, support a wide range of scenarios. They let IT pros decide which kinds of applications can run on which devices. Hardware features can be enabled or disabled OTA—for example, cameras can be disabled to help prevent the accidental or intentional compromise of sensitive information. Data encryption can be enforced on devices, removable storage cards, or both to reduce the likelihood that lost or stolen devices or cards will deliver proprietary data into the hands of unauthorized individuals.
Other security management tools are also part of Mobile Device Manager. With thousands of apps available for Windows Mobile devices, there is a clear need for administrators to have control over those that can or cannot be installed. Mobile Device Manager lets you create and enforce application Allow and Block Lists for just that purpose. It also provides powerful remote wipe capabilities. Because of the always-on VPN connection to devices, devices can be wiped immediately without waiting for them to connect to the network and synchronize. When a device is wiped remotely, it is removed from the domain controller and its certificate is revoked. If a device is later recovered, it can be set to rejoin the domain after re-enrolling with a new one-time password.

Keeping Mobile Devices in Check
Mobile Device Manager is designed to make managing Windows Mobile devices on the network as easy as possible by providing complete device management functionality in a single solution, including OTA provisioning; OTA software and update distribution; and comprehensive and centralized inventory management.
OTA self-enrollment is a feature likely to win the hearts of busy IT pros and end users. A user enters an e-mail address on a Windows Mobile 6.1 device, which attempts to locate the Mobile Device Management Server based on the given e-mail address. If the server is not found, the user is prompted to enter the address of the Management Server manually. Once the server is found and it is determined that the user may enroll, the user is asked to enter a one-time passcode that is pregenerated by the administrator.
The e-mail address and the passcode are used to authenticate the user and to enroll his device in the Management Server. When this is done, administrator-defined settings and policies are pushed down to the device. The self-enrollment approach is designed to increase the scalability of Windows Mobile device deployments and to reduce the time and money necessary to get those devices up and running.
Mobile Device Manager's OTA software distribution capabilities are based on Windows Software Update Services (WSUS) 3.0, the software update toolkit already used by many IT pros around the world. As shown in Figure 2, WSUS 3.0 delivers the targeting and application-packaging functionality necessary for complex IT needs. Software can be delivered automatically to appropriate devices based on rules and policies set by the administrator. As with server and client updates, mobile device updates and patches can be automated using WSUS 3.0. Just as crucially, automatic updates can be turned off for deployment planning and testing.
Figure 2 Software distribution wizard
Figure 2 Software distribution wizard
One of the biggest challenges of managing mobile equipment deployed at scale is simply keeping track of everything. Mobile Device Manager centralizes inventory information and provides flexible, customizable reports based on SQL Server 2005—again, utilizing software that many users will already have on board and be familiar with. Administrators can collect more than a hundred items of inventory information, including (but not limited to) operating system and version, device model, installed applications, and security policies. The inventory is extensible, allowing the administrator to add items and registry settings.
For even more flexibility, you can control the Mobile Device Manager using Microsoft Management Console snap-ins if you favor a graphical user interface (see Figure 3) or with the Windows PowerShell console if you prefer a command line. Either way, the system is extensible and customizable—essential for enterprise users who want the software to fit their organization.
Figure 3 Mobile Device Manager Console
Figure 3 Mobile Device Manager Console

Mobile VPN
Information workers have been e-mailing and messaging one another on mobile devices for years. Today, one of the most useful developments in mobile device technology is the ability to access business data and apps that reside behind the firewall. With increased access, new security risks arise, so the added functionality must be carefully managed to prevent vulnerabilities. Mobile Device Manager provides cutting-edge Mobile VPN capabilities, enabling users to access intranet data ranging from Microsoft DynamicsTM Customer Relationship Management (CRM) to SAP to Siebel. The model is built to match existing remote-access strategies for desktop and laptop PCs (see Figure 4).
Figure 4 Mobile VPN settings
Figure 4 Mobile VPN settings
The Mobile VPN connects the device to the gateway server using a double-envelope security feature, wherein data is transmitted in SSL-encrypted form through an IPsec-encrypted tunnel. Once the device is authenticated, the user has access to resources as specified by the resource-specific policy in combination with the user's credentials.
The Mobile VPN technology used by Mobile Device Manager enables an always-on connection to be established, which not only gives users improved access but helps ensure that IT pros can keep devices updated with current policies and settings—and wipe a device immediately if it is lost or stolen. Even if a session is interrupted, fast reconnect helps ensure that the device session continues without the need for re-authentication. Mobile Device Manager allows for a smooth transition between Wi-Fi and cellular networks while maintaining connectivity.
The security technology used in Mobile Device Manager Mobile VPN is based on industry standards, including Open Mobile Alliance for Device Management (OMA DM), Internet Key Exchange (IKE) version 2, and OMA Software Component Management Object (SCOMO). This helps make the system more extensible and customizable for specific situations faced by IT pros working in complex environments.

A Complete Solution
Mobile Device Manager delivers a complete set of tools for managing Windows Mobile devices, accessible through a single interface. It utilizes Active Directory and Group Policy to provide security tools that help protect data, devices, and the network. Device management is made easier by OTA enrollment, provisioning, and updating, as well as by powerful inventory tools. Mobile VPN is designed to deliver the functionality that enterprises and users want without compromising security.
All this is integral to the idea of making the jobs of IT pros easier by allowing mobile devices to be managed on the network as first-class citizens. Mobile Device Manager gives IT pros the power to deliver quality end user experiences, reduce administrative overhead, and provide better ROI for management—and that's a combination worth calling home about.
Thanks to Brian Hoskins, Derek Snyder, Prithvi Raj, Lax Madapaty, and Katharine Holdsworth for their contributions to this article.

Matt Fontaine is a freelance technology writer and consultant working with BuzzBee Company. He attends to a wide array of industries including high-performance computing, enterprise software, actuary, commercial real estate, engineering, construction, and consumer packaged goods. Matt is a proud alumnus of The Evergreen State College.


 System Center: What's New in System Center Essentials SP1
System Center Pete Zerger

What's New in System Center Essentials SP1
At a Glance:
  • Easier installation with integrated installer package
  • Enhanced overrides for fine-tuning management packs
  • Support for workgroups
  • New health state recalculation task

With the release of System Center Essentials 2007 last July, Microsoft made good on its commitment to midsize businesses, bridging the gap between expensive, complex enterprise tools and shareware
solutions to deliver a unified management solution for IT operations. Essentials 2007 is specifically designed to meet the challenges faced by the midsize business, where IT pros often perform a broad range of tasks.
Essentials is easy to install and configure, enabling IT pros to proactively monitor and manage clients and servers, as well as track hardware and software assets. It is designed to simplify traditionally complex tasks, like application and IT service monitoring, client and server software deployment, and troubleshooting desktop issues.
Since the initial release, Microsoft has been collecting feedback from customers in the field who are already using Essentials to manage their IT infrastructure, and this information has been incorporated into the first service pack for the product. More than simply delivering bug fixes, SP1 introduces significant enhancements that make the product more flexible in meeting customer needs in a variety of deployment scenarios. Moreover, performance improvements considerably enhance the user experience and streamline administration.
In this article, I'll review the key advancements delivered in Essentials 2007 SP1. I'll also look at how they can make managing your environment even easier.

Easier Installation
The SP1 integrated installer package rolls up all Essentials hotfixes to date, making installation an easy task that requires just a few clicks. Essentials can now also be configured to use a remote 64-bit SQL Server® 2005 instance, while the Essentials Server resides on a 32-bit Windows Server® 2003 instance. This grants administrators greater flexibility in utilizing the existing server infrastructure in their environment in a distributed Essentials deployment topology. Moreover, Windows Server 2008 will be a supported platform for the Essentials 2007 SP1 Server, console, and agent. Full support for Windows Server 2008 is expected sometime shortly after the new OS is released to manufacturing.

Better Console Performance
If you've used the RTM release of Essentials 2007, you'll appreciate the dramatically more responsive Essentials Console interface in SP1. Performance has been improved in Alert, Event, Performance, State and Task Status Views. For example, in all Alert views, changes in data fetching (retrieval) results in alert data selection that is as much as three times faster. Actions and reports are now fetched in the background, which further improves UI performance. Likewise, context-based Tasks and Reports (displayed in the Actions pane in the right-hand side of the Operations Console) are loaded in the background, allowing the Views to respond more quickly to your selections.
Alert knowledge that is displayed in the Alert Details pane can now be shown or hidden according to the user's preference simply by clicking the Show Knowledge or Hide Knowledge links (see Figure 1). This preference is then remembered when viewing future alerts. Administrators can now also perform copy-and-paste of Alert details with the standard keyboard shortcuts (such as Ctrl+C and Ctrl+V).
Figure 1 Alert Details pane with Show/Hide Knowledge links
Figure 1 Alert Details pane with Show/Hide Knowledge links

Override Enhancements
Overrides are used to tune your management packs, disabling rules and monitors where they are not needed, as well as for tweaking various threshold values. There are several significant improvements related to overrides that not only make tuning rules and monitors to your environment easier, but that also provide greater visibility into the overrides already present in your Essentials environment. The result is a reduced need to create custom rules and less time spent trying to identify the overrides present in your environment.
For example, after you have created an override for any management pack object, you can now look at the summary of overrides for the object type in the Overrides Summary box. Essentials 2007 SP1 ensures that the description of the override target is complete. If you create an override for Logical Disk Free Space for the C:\ drive of Server1, for example, the summary will display 'server1/c:'. An example may clarify the importance of this change.
Notice in Figure 2 that in this Overrides Summary for the Windows Server 2003 Logical Disk Free Space in the Essentials 2007 RTM release, it is impossible to tell which computer is hosting the C:\ drive instance targeted by the override. In the same Overrides Summary in Essentials SP1, you can see that the Name column now displays not only the target drive instance, but also the computer hosting that drive (see Figure 3).
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Alert severity can have a substantial impact on the volume of alert traffic being collected by administrators. Until now, if an Essentials Rule in a sealed management pack was configured to generate a critical alert that was not critical on some servers, administrators could not do anything to adjust this setting, as alert severity and priority were not exposed in rule overrides. The only workaround was a labor-intensive exercise of creating overrides to disable the rule for some machines, followed by recreating the rule(s) in an unsealed management pack where alert parameters could be manipulated—clearly not an ideal situation from an administration perspective.
This problem is handled neatly in SP1, with both alert severity and priority exposed as override parameters in all sealed management pack rules, as shown in Figure 4. Administrators can thus quickly and easily lower or raise the severity and priority of the alerts generated by rules in Essentials 2007 by creating overrides.
Figure 4 Alert severity and priority rule overrides
Figure 4 Alert severity and priority rule overrides
You may also have noticed the Enforced checkbox in Figure 4, which is not present in the console interface in the Essentials RTM release. In cases where multiple overrides are enabled for an object, the override with the Enforced flag selected will be given higher priority. This can come in handy when the same override is set for two groups of objects and some objects have membership in both groups. By setting the Enforced option on the override you want to take precedence, you can be certain exactly which override setting is applied.
To make the creation of new management packs easier, Essentials 2007 SP1 introduces the ability to copy views from any existing management pack to an unsealed management pack. The copy operation is supported for all types of views (such as Event, Alert, Performance, Dashboard, and Diagram) and can be done in the Monitoring space. For example, if you have created a management pack for Active Directory® overrides and want to use one of the Active Directory management pack views in the Active Directory overrides management pack, you would simply select the desired view, and then copy and paste it into the desired custom management pack folder in the Navigation pane in the Monitoring space.

New Override Reporting
Also worth mentioning is the new Overrides Report in the Microsoft® Generic Reporting Library, located in the Reporting pane of the Essentials Console. This report provides a way to describe overrides from the perspective of the management pack in which they are stored or according to the management pack to which they are applied (see Figure 5). Users are able to set report parameters to exclude sealed MP overrides from the report. This is an important filtering option because sealed management packs from Microsoft and others contain many overrides you will not care about when reporting on changes made in your own environment.
Figure 5 Overrides Report parameters
Figure 5 Overrides Report parameters
If you follow the Microsoft best practice of creating a separate custom management pack for each sealed management pack (one for the Active Directory MP, one for the Exchange MP, and so forth), you will have the ability to more effectively narrow the scope of the report to view the overrides that apply to a specific management pack.
Once you have selected the appropriate unsealed management packs, you can run the report, which displays output as pictured in Figure 6. Note that the report clearly displays the rule or monitor to which the override applies (the Affected element column), as well as the Installed and Deleted date and time associated with the monitor. This illustrates the fact that the Overrides Report serves as not only a list of active overrides, but also as a report of override configuration change history.
Figure 6 Overrides Report detail
Figure 6 Overrides Report detail
Finally, at the bottom of the detail view for each affected Rule or Monitor, you will find a hyperlink labeled Rule configuration view. This link launches a separate Rule view or Monitor view with scope of the view already targeted at the affected object type. For example, if you click the Rule configuration view link for the override pictured in Figure 6, which is an override on a rule targeting the Active Directory Domain Controller Server 2003 Computer role, note that the resulting Rule view will only display rules that target that object type.

Support for Workgroup Computers
One of the significant points of customer feedback related to the need to manage servers and workstations in workgroup configurations. Many environments have at least one server sitting in a perimeter network or branch office not joined to the domain. Because Essentials requires mutual authentication between the Essentials Server and agent-managed computers, workgroup machines residing outside the trust boundary of the Essentials server also fall outside the scope of Essentials agent deployment. In many environments, this means potentially leaving key components of the infrastructure unmonitored and outside the Essentials patch management process. How can we securely manage these machines?
SP1 introduces certificate-based authentication for scenarios where Active Directory and Kerberos authentication is not available. This requires both the Essentials Server and the agent-managed computer have a X.509 digital certificate installed. The digital certificate can be issued from either a Windows® Standalone or Enterprise root Certificate Authority. If you do not currently have a Windows Certificate Authority in your environment, you can install this feature through Add/Remove Programs on a domain controller or member server in your environment, including the Essentials Server. For more information on Certificate Services and Public Key Infrastructure (PKI) in Windows Server 2003, see microsoft.com/windowsserver2003/technologies/pki.
To configure certificate-based authentication in Essentials, you first request and issue a certificate to both the Essentials Server and the computer targeted for management. The request can be entered via a Web site on the server acting as the Certificate Authority.
After the certificate is issued and installed, it must be "registered" for use with Essentials by using the MOMCertImport command-line utility. To complete the certificate configuration, you simply export the certificate to a file (in .pfx format) and run MOMCertImport on the local computer with the following syntax:
MOMCertUtil.exe <cert path \ name>
Once all of these steps have been executed on the Essentials Server and the computer targeted for management, these systems can mutually authenticate and then securely exchange data over an encrypted channel. To complete the agent deployment process, just perform a manual installation of the Essentials agent on the target computer.

Network and Device Monitoring
Essentials 2007 delivers network device monitoring functionality capable of discovering common attributes of many SNMP-enabled network devices. While SNMP version 2c (SNMPv2c) is the most widespread today, all network devices are not created equal. With that in mind, SP1 delivers support for SNMP version 1 (SNMPv1) to accommodate monitoring of a variety of older network devices, such as some UPSs, routers, and print servers that are not SNMPv2c-capable. As Figure 7 shows, administrators can tell Essentials which SNMP version to use through an additional dropdown field in the Computer and Device Management Wizard.
Figure 7 Enhanced interface for network device discovery
Figure 7 Enhanced interface for network device discovery

Enhanced Update Management
Significant improvements in update management are also delivered in SP1. Windows Server Update Services (WSUS) 3.0 auto-approval rules allow you to specify different products and update classifications, such as automatic approval for definition updates for Microsoft Word.
Support for multiple auto-approval rules has also been added to Essentials, bringing its functionality on par with that of the WSUS 3.0 platform (see Figure 8). This empowers administrators to create auto-approvals for multiple categories of updates, including Windows Vista® critical updates and service packs for the 2007 Office system. Auto-Approval rules will then be applied to all updates that are currently on the WSUS server. As a result, by clicking the Run Rule(s) Now task in the Auto-Approvals dialog, administrators can apply changes immediately to existing updates that are present in the Essentials Console.
Figure 8 Auto-Approvals in Update Management
Figure 8 Auto-Approvals in Update Management
With the added support for agent deployment to computers in workgroup configurations, administrators will be able to control update management for their entire environment from the Essentials Console.

Calculating Object Health State
In the past, when viewing the state of monitors in the Health Explorer, administrators had to wait for the periodic refresh of monitor state to determine if Recoveries or other corrective actions were successful. New in the SP1 version of the Health Explorer is the Recalculate Health task, which performs on-demand recalculation of monitor health (see Figure 9). This can substantially expedite the troubleshooting process by eliminating minutes of wait time between corrective actions while waiting to see if the monitor state returns to healthy.
Figure 9 Recalculate Health Task in Health Explorer
Figure 9 Recalculate Health Task in Health Explorer
Similarly, the Reset Health task (present since RTM) has also undergone some important improvements to ensure that every monitor will actually respond to a request to reset its health state to healthy (green). This is even true of reset requests executed against the Essentials Server itself, which did not always respond to reset requests in the RTM release.

Scripted Diagnostics
Diagnostics are a special type of inline task new in Essentials 2007, allowing automatic or on-demand execution of data collection tasks when an alert is raised. An automatic diagnostic is one that is configured to be executed whenever a monitor goes into an error state. The results of the diagnostic appear in the Details pane of the State Change Events tab of the Health Explorer. An on-demand diagnostic appears as a hyperlink in the same area and can be executed simply by clicking on the link. Results are displayed in a pop-up window on the local machine.
As Figure 10 shows, SP1 extends the functionality of diagnostics by allowing scripts to be used in diagnostic tasks (as opposed to command-line responses only in RTM). This provides the framework for executing more elaborate and varied automated data collection responses when error conditions are encountered. Note that both VBScript and JScript® are supported for use in these diagnostic tasks.
Figure 10 Alert Details pane with Show/Hide Knowledge links
Figure 10 Alert Details pane with Show/Hide Knowledge links

Export to Visio
Another new feature in SP1 is support for exporting diagrams to Microsoft Visio® 2007 format, with a button exposed on the toolbar when the user selects a diagram view. This provides a very convenient documentation feature, as the Active Directory and Exchange Server 2003 management packs provide detailed topology diagrams right out of the box, saving administrators valuable time writing documentation. Furthermore, diagram layout preferences can be saved. These preferences will be remembered by the Essentials Console the next time the diagram view is selected.

Better Backup and Recovery Guidance
Immediately following installation of Essentials 2007 SP1, the installation wizard now automatically prompts the user to back up the Essentials Management Server encryption keys (see Figure 11). This key pair is used by the Essentials Server in the secure storage of Run As Credentials in the Operations database. These keys are also required in the event that Essentials Server must be restored from backup. Without this key pair, Essentials would need to be reinstalled and configured from scratch.
Figure 11 Essentials encryption key backup
Figure 11 Essentials encryption key backup

Improved Management Pack Quality
In addition to the many improvements in SP1 for Essentials, the Essentials product team is making great strides in improving the quality of the management packs for the Essentials platform through more varied and rigorous testing procedures, as well as through greater interaction with the various product teams and application subject-matter experts. The results will be reflected in the release of more management packs that take advantage of the new features in the Microsoft monitoring platform, including self-tuning thresholds, service-oriented monitoring using distributed application models, as well as the powerful reporting engine.
Microsoft will begin releasing more native management packs leveraging the new features in Essentials beginning in 2008. Management packs for Essentials 2007 can be downloaded from the System Center Management Pack Catalog at go.microsoft.com/fwlink/?LinkId=112399.

Give It a Try
SP1 delivers performance enhancements making System Center Essentials 2007 a wise investment for managing the IT infrastructure of your mid-size business. If you already have Essentials 2007 in your environment, download a copy of SP1 and experience the feature and performance improvements for yourself. If you have not yet deployed Essentials 2007 and want to try Essentials 2007 with SP1, you can download the SP1-integrated installer package. Both packages, as well as additional product information, can be found at the Essentials 2007 homepage at microsoft.com/systemcenter/essentials. 

Pete Zerger is a consulting partner with AKOS Technology Services and has nine years of experience in the IT industry. He focuses on design and deployment of enterprise operations management, directory services, and messaging solutions. Pete holds an MCSE for Messaging, an MCTS for SQL Server 2005, and he is a Microsoft MVP for Microsoft Operations Manager. He is founder of systemcenterforum.org, a popular community site covering Essentials 2007 and the System Center Suite.


 From the Editor: A Warm Welcome to &quot;Inside SharePoint&quot;
From the Editor
A Warm Welcome to "Inside SharePoint"

As you may recall from last month's Editor's Note, after wishing a fond farewell to The Cable Guy, I mentioned that this issue of TechNet Magazine would feature the debut of a new column. Please give a warm welcome to "Inside SharePoint," a monthly column covering everything an IT pro needs to know about architecting, deploying, securing, maintaining, and supporting a SharePoint infrastructure. As promised, Pav Cherny gets us started back at the beginning with an overview of the key elements of a flexible SharePoint infrastructure. We'll continue next month with coverage of SharePoint site administration. And our offer remains open: if you have specific SharePoint topics you'd like to see covered, drop us a line at tnmag@microsoft.com.
Also in this month's issue, Gil Kirkpatrick returns with an in-depth and comprehensive overview of the Active Directory backup and restore process in Windows Server 2008. In many (if not most) Windows-oriented networks, Active Directory is the authoritative source for identity and access information (which, I think we can all agree, is pretty important stuff). It's also a key infrastructure element of any deployment of Exchange, SharePoint, Configuration Manager ... the list goes on. Yet, when I attended one of Gil's sessions at the Directory Experts Conference in Chicago last month, and he asked how many people in the room had a comprehensive disaster recovery plan for Active Directory, you could count the number of hands raised, well, on one hand. Suffice it to say that everyone should read Gil's article.
On the incredibly remote chance that Active Directory is not your forte, not to worry—there's plenty more here for you. Matt Fontaine introduces us to System Center Mobile Device Manager (a must-have new technology if you're managing Windows Mobile devices in your organization), Pete Zerger walks us through what's new in System Center Essentials SP1, and Jesper Johansson applies the Heisenberg Uncertainty Principle to IT security. The Scripting Guys are with us, as always, Exchange Queue & A returns, and much more.
Finally, we're working on a project for the spiffy new TechNet Magazine Web site (still found at technetmagazine.com). Some of our favorite authors are developing how-to screencasts—videos that will accompany our articles online to walk you through the content step-by-step. We'd love to hear what topics and technologies you'd most like to see covered with these screencasts. Once again, e-mail us at tnmag@microsoft.com. Thanks! —Joshua Hoffman


 Sustainable Computing: Putting IT on a Diet
Sustainable Computing
Putting IT on a Diet
Dave Ohara

As the environment and energy consumption become topics of increasing attention, IT has been called out by many as a large energy consumer. And rightfully so. There are many problems throughout the IT environment—over provisioning, underutilized equipment, poor user practices and policies, inefficient hardware, and lack of hardware retirement policies, to name just a few.
Yet there are countless strategies for making IT more environmentally sensitive. This creates an excellent opportunity for you, as an IT professional, to drive change. Every organization needs a solid sustainable computing strategy and this, in turn, requires IT professionals with knowledge who are ready to lead and evangelize changes throughout the organization.
The topic is vast and constantly changing. And your strategy is something you should be thinking about every day. So we are kicking off this new online column to explore the issues, solutions, and strategies that make up environmental and sustainable computing. In fact, there's so much to discuss, we'll be publishing, for the time being, new columns every two weeks.

The Energy Diet
Data centers used 61 billion kWh of electricity in 2006. That represents 1.5 percent of all U.S. electricity consumption that year. More alarmingly, it is double the amount consumed by data centers just a few years earlier, in 2000. (See the March 2008 Fact Sheet on National Data Center Energy Efficiency Information Program available at energystar.gov/ia/partners/prod_development/downloads/NDCFactSheet.pdf for more information.)
If current trend continue, energy consumed by data centers can be expected to grow by 12 percent per year. And the problem reaches beyond the data center. Desktops, laptops, and mobile devices are all large energy consumers, but their exact numbers are hard to grasp as devices are scattered around offices.
With Web services becoming increasingly common and the proliferation of mobile devices growing at exponential rates, companies, organizations, and governments around the globe are looking at how we can reduce consumption and put IT on an energy diet, such as expanding initiatives like the Energy Star program from desktops to severs as well.
Government agencies, for example, are looking into how to regulate energy use. As one of the largest energy consumers, IT is the least regulated. So don't be surprised when the government implements future requirements for sustainability and efficiency reporting.

Accumulating Waste
Many environments are reducing total energy use in the larger picture by shifting from intensive solutions to IT-based solutions. For example, while the move from a paper billing system to an electronic billing system may increase energy consumption in the data center, it reduces the overall environmental impact of paper bills. One study, published by Javelin Strategy, projects that people could save 17 million trees and prevent 4 billion tons of greenhouse gasses each year by simply eliminating paper checks and bills (please see javelinstrategy.com/2007/07/24/2007_obbp_release/).
Energy waste accumulates in the IT world as systems are overprovisioned for worse case scenarios, projects are abandoned yet unnecessary servers are left running, users leave desktops on when they aren't being used; the list goes on.
Consider Moore's Law, which says that devices double in transistor count every 18 to 24 months. As a result, performance increases. Along with that performance comes an increase in power consumption. Power density in IT equipment is going up, creating more power and cooling issues. Imagine trying to manage your weight and health, but finding that fat is getting denser while taking up less space and needing more energy to burn. Your clothes still fit, but you weigh more than ever, it costs more to eat, and you feel less healthy.
In the data center, space (in other words, room to accommodate all of the equipment) is not the problem. Power and cooling capabilities are the scarce resources. And with scarcity comes an increase in energy costs.
What about renewable energy? Unfortunately, at this stage, renewable energy is subsidized and its true costs are more expensive than carbon-emitting fuels. But carbon emissions taxes will increase the cost of carbon-based energy. And the cost of coal, natural gas, and oil are all increasing. So get ready for a bigger electricity bill.
You have a choice—you can keep your head down, focus on your metrics, and ignore energy use. This may sound a bit selfish, but it is a common approach. The point of the green movement is to get people to take their heads out of the sand, look around, and see the impact of their actions. Going on an energy diet is smart, both for the environment and for your company's bottom line.

How Much Energy Can You Save?
When you want to lose a little bit of weight, you have built-in feedback mechanisms: how your clothes fit, how you look in the mirror, and so on. So how do you know when your hardware is not energy efficient? Circuit breakers might trip. Devices might overheat. Power bills may skyrocket. There are horror stories of people who have deployed blade systems that push the limits of the cooling system, new SAN systems that overload electrical circuits. Contact your data center and facilities staff—these are the folks who can tell you when and how often they run into these issues.
Keep in mind that remedying these problems takes power and cooling capital expenditures. These expenses are typically rolled into the total overhead and not billed to the specific department that caused the problem.

There's No Magic Energy-Saving Pill
When people talk about energy efficiency in IT, virtualization is almost always the top pick of technologies to deploy. Far too many people, however, fail to think through the long term impact. After reducing energy consumption and lowering the costs of deploying servers, virtualization will often lead to an increased rate of server deployments. This, in turn, leads to rolling out more virtualization software, more management software, and eventually more hardware.
Don't despair—virtualization is definitely part of the solution. It's an important tool for you to use in your strategy, but you can't leave virtualization to itself and expect it to make all the difference. Instead, your energy diet will require moderation.
A diet requires a shift in your mindset and making certain lifestyle changes. For your energy diet, you'll need to make changes throughout the entire IT lifecycle to account for energy use and factor in energy as a part of the total cost of ownership (TCO). Jump right in, pick an area, and measure its power consumption. To do this, add some energy monitoring equipment to your performance and test labs. (After all, you wouldn't go on a diet without using a scale to weigh yourself.)

What's in a Number?
Before you buy energy efficient technology (such as a new server), first test it in your own environment under your own load. With the current focus on environmentally friendly products, many companies are now labeling their products as green and even providing some general numbers regarding energy savings.
Beware; these numbers are usually based on what can be achieved under the best conditions to show maximum results. This serious problem is often referred to as "greenwashing." The numbers over-promise and the solutions under-deliver. Unfortunately, there is currently no equivalent to an EPA miles-per-gallon test to uniformly test equipment. Some test are in process, though. One place to look for up to date information is the Energy Star Web site for data center efficiency (energystar.gov/index.cfm?c=prod_development.server_efficiency).

Steps to Get Started
Becoming energy aware, putting a strategy together, and implementing changes will all take time. But there are key steps you can take to get started and help you form a good foundation for your efforts.
  1. Start a group that includes people who are interested in environmental sustainability in IT. Volunteers are everywhere. You can try to get executive support, but don't be discouraged if they do not see this as a priority.
  2. Make friends with your facilities staff and find out more about your building power and cooling systems. Be sure to find out what power and cooling issues exist in your IT environment.
  3. Create a spreadsheet of actual energy consumption of IT equipment. The ratings on the devices usually provide maximum power numbers for the power supplies. Your actual usage may be as low as 50 percent of that number.
  4. Inventory all of your IT equipment and calculate your total power consumption.
  5. Get your power bill and calculate the costs for power and the percentage of your power bill used by your IT equipment.
  6. Set up meters to monitor IT energy consumption.
  7. Identify opportunities to save. This can be through more efficient equipment, eliminating over provisioning, making better use of deployed equipment (server consolidation), upgrading power and cooling systems, and turning off equipment when it's not needed. There are many solutions, which we will explore over the months to come.
  8. Set goals to hit. Success is measured in small gains, and tracking the small steps will add up. A good strategy balances reducing energy consumption and using energy more effectively.
  9. Get the cooling bill for your facilities and find out how efficient the cooling system is in removing heat. For every watt generated in the office or data center, how many watts are needed to remove the heat? Many facilities require 1 watt of cooling to remove 1 watt of heat. Holistically, there is a measurement for the data center called power usage effectives (PUE). For more on this, see "The Green Grid Data Center Power Efficiency Metrics: PUE AND DCiE" paper (thegreengrid.org/gg_content/TGG_Data_Center_Power_Efficiency_Metrics_PUE_and_DCiE.pdf).
  10. 10. If you can, do an entire system design of your IT infrastructure. This is discussed in the "Best Practices for Energy Efficiency in Microsoft® Data Center Operations" paper (download.microsoft.com/download/a/7/b/a7b72ab1-ca17-4589-923a-83b0ff57be6d/Energy-Efficiency-Best-Practices-in-Microsoft-Data-Center-Operations-CeBIT.doc).

Moving Forward
A move toward sustainable computing and more energy efficient IT environments is a complex but worthwhile project. There are numerous factors and just as many solutions. As the landscape changes, the solution may seem like a moving target. Finding what is right for your organization will take time, resources, support, and a deep understanding of the issues at hand.
Just remember that your environmental and sustainability efforts are something you need to pursue on a daily basis. We hope TechNet Magazine can help you along the way.

Dave Ohara has 26 years of experience in technology. He is now working with multiple companies implementing green initiatives.


 Sustainable Computing: Sleep or Hibernate?
Sustainable Computing
Sleep or Hibernate?
Mark Aggar and Megan Morrone and Michael Walsh

Part of living a more sustainable life means taking actions, such as recycling, using reusable bags at the grocery store, and turning off the lights when you leave a room. Just as leaving the lights on in an empty room is a waste of energy, leaving your computer on when it's not in use also wastes energy.
Windows Vista® offers a variety of features that can help conserve power when you're not using your computer. Many of these settings are turned on by default. And while each of these features generally offers just a small step toward improved energy efficiency, together they add up to big returns—both for your checking account and for the environment.
Some people hesitate to use the advanced power consumption features in Windows Vista because they don't want to wait for the computer to shut down and start up each time they step away for a few minutes. This was a legitimate concern in the past with systems taking a long time to start back up. But Windows Vista addresses this issue, offering better reliability and more control over the power-saving functionality. In particular, sleep, hibernate, and hybrid sleep let you use different power-saving states for different purposes.

Time to Sleep
Sleep, which is the default power-saving state in Windows Vista, is a low-power state that preserves whatever you were doing in memory. A small amount of power is used to maintain that memory (typically less than 1 watt on a modern laptop).
It causes your computer to go to sleep automatically if you haven't used the system for a set amount of time. Of course, if you know you are stepping away from your computer, you can also choose to put it to sleep manually.
On most computers that are running Windows Vista, you can put the system to sleep simply by pressing the power button (on a laptop, you can also close the lid). This is the default setting on most computers. However, if you want to customize your experience, you can do this by using the Power Options applet in the Control Panel.
To wake most computers from sleep, you can just press the power button again, or open the lid if the system is a laptop. Your computer will resume full power almost immediately. Computers certified for Windows Vista should take around two seconds to resume from sleep. (Resuming from hibernate takes longer.)
Note that when your system is in sleep mode, it can still wake up at specified times to download and install updates and perform other routine maintenance tasks. After these tasks have finished, the computer will go back to sleep automatically.

When to Hibernate
Like sleep, hibernate is a power-saving state. In Windows Vista, sleep saves your settings in memory and draws a small amount of power to maintain that memory. Hibernate, on the other hand, writes your settings and the content of memory to the hard disk and then completely powers down the system.
On a laptop, this means that the computer is not using any power (unless the laptop is charging, of course). On a desktop that remains plugged in, power usage can vary. In fact, hibernate may not use significantly less power than sleep.
To put your computer into hibernate mode, click the Start button, and then the small arrow next to the Lock button, and then click Hibernate. You can wake up most computers from hibernation by pressing the power button (or lifting the lid if you're using a laptop). But since not all computers are the same, you might have to press other keys on the keyboard or click the mouse.
Waking from a state of hibernation takes longer than waking from sleep. This is because your computer needs to load your data and applications from the hard drive back into memory. Hibernate is particularly useful on a laptop when you know you won't be using the computer for an extended period of time and you won't have an opportunity to charge the battery.

Hybrid Sleep (Desktop Computers Only)
Hybrid sleep is a power-saving feature designed primarily for desktop computers. Because laptops have batteries, there is limited risk that power will be completely lost unexpectedly. If a laptop is in a sleep state and the battery starts to run low, the system will wake up and immediately go into hibernate, which requires no power to preserve memory. But a desktop computer does not typically have a battery backup, so if the computer loses power while in sleep, all the contents stored in memory will be lost (including any unsaved work).
Hybrid sleep addresses this issue by combining the fast resume capabilities of sleep with the reliability of hibernate: specifically, it saves the contents of memory to hard disk. This means that you can quickly resume from sleep in most cases, but if a power failure occurs, Windows Vista can restore your work and settings from the hard disk.
On desktops, hybrid sleep is usually turned on by default. When this is enabled, clicking Sleep will put the computer into hybrid sleep. (When hybrid sleep is turned off, or if your computer doesn't support hybrid sleep, clicking Sleep puts the computer into the standard sleep mode.) To wake up most computers from hybrid sleep, simply press the power button and the computer will resume exactly as you left it.

Should You Use a Screen Saver?
Screen savers were originally developed to save older monitors from damage by preventing the burn-in of pixels into the screen. Today, screen savers are mainly used to personalize computers or to protect them with passwords required after a certain amount of idle time.
Screen savers do not conserve energy. In fact, many of today's sophisticated screen savers use more energy than your computer would use under light conditions. Even when a display goes blank, many screen savers continue to run and consume energy. And some screen savers actually prevent your PC from going to sleep.
To increase the energy efficiency of your computer and make less of an impact on the environment, you should use display blanking instead of a screen saver. If you want the security of requiring a password to access the computer after the display has blanked, configure your PC to use the blank screen saver and check the box to display the logon screen on resume. The blank screen saver doesn't consume any more energy than an idle computer, and it allows your PC to go to sleep when the sleep idle timeout is reached.
Note that you might want to set the screen saver timeout to be slightly longer than display blanking timeout. This lets you avoid having to type your password each time your display blanks while you are sitting at the computer. Only after the screen saver itself starts up will you need to type your password to get back to your session.
If your computer is unused for a longer time (and there are no background tasks keeping it awake), then Windows Vista will automatically put your computer into sleep. By default, this timeout is set to 60 minutes and requires a password to be entered after your computer wakes from sleep.

Becoming More Energy Efficient
Whether you want to save money or reduce your environmental impact, Windows Vista can help you reduce the amount of energy your computer consumes. When you're not using your system, press the power button to put it to sleep or close the lid on your laptop. Try to avoid using elaborate screen savers that generally burn energy.
We should also point out that Windows Vista Media Center has also been enhanced to be more energy efficient. A Media Center PC can be configured to go to sleep when not in use and can be easily woken by using the remote control. It will also wake automatically to record scheduled programs and go back to sleep when it is finished recording. A Media Center PC can even be configured to wake up when you turn on your Media Center Extender.
Media Center power configuration, however, is a topic unto itself. So watch for a future installment of the Sustainable Computing column dedicated to Windows Vista Media Center power settings.

Mark Aggar is an Environmental Technologist at Microsoft.
Megan Morrone is a Freelance Writer from Resources Online.
Michael Walsh is the Senior Environmental Product Manager at Microsoft.


 Sustainable Computing: Conserving Energy with Group Policy
Sustainable Computing
Conserving Energy with Group Policy
Mark Aggar and Pat Stemen and Michael Walsh

Power management on a single computer can save energy and money. When you enforce your power management strategy on systems throughout your entire organization, obviously the savings can be far more substantial.
Windows Vista® is configured by default to use its energy efficiency features. But it also gives IT professionals numerous options for tailoring power management settings to optimize energy efficiency throughout their companies. In fact, Windows Vista ships with more than 35 power management settings that you can use to create the power management strategy that best suits your organization's needs. And you can quickly put your strategy into practice with minimal effort using Group Policy. Here is guidance for some of the more common settings you can enforce with Group Policy. For a quick overview of all 35 settings that are available, see the sidebar "35 Settings for Managing Power."

Using Group Policy to Enforce Power Settings
As you know, administrators can enforce specific settings using Group Policy in Windows Vista. This, of course, can be used to set power-related features, such as display and system sleep settings.
The advantage of using Group Policy to configure power settings is that Windows Vista will use the values specified by Group Policy, preventing end users from changing the settings. If the user attempts to make a change, the Windows Vista Power Options Control Panel informs him that the selected power policies may not be changed because they are enforced by the administrator.
While Windows Vista does let the user switch between power plans (such as battery saver and balanced), the administrator can use Group Policy to enforce specific settings within those power plans. Even if the user changes power plans, the Group Policy power setting is enforced.
To enforce a power setting using Group Policy, use the Group Policy Management Console to edit a new or existing Group Policy Object (GPO). The power management policies are located in Power Management, under Computer Configuration | Administrative Templates | System | Power Management. Note that there are no power management policies under User Configuration in Windows Vista.
Each power setting lets you specify separate values for when the computer is plugged-in (AC) or running on battery power (DC).

Sleep Idle Timeout
Additional Resources
For more information on Windows Vista power policy and power policy configuration, check out the following papers:
  • Power Policy Configuration and Deployment in Windows Vista
  • Optimizing Windows Vista Platforms for Energy Efficiency
  • Windows Vista Energy Conservation

The sleep idle timeout automatically places a system into a low-power sleep state after a set period of user and system inactivity. Sleep idle timeout is enabled by default in all power plans except the High Performance power plan. However, the timeout value varies by power plan personality in the default Windows Vista power plans.
The sleep state saves all of the user's open programs and documents and allows the user to quickly resume working with the system. The power consumption of sleep on current laptops is less than 1 watt, which is comparable to the power consumption of the hibernate and shut down states on a desktop PC.
The sleep idle timeout policy is located in Sleep Settings under Power Management. To set the sleep idle timeout setting for AC power, choose Properties for the Specify the System Sleep Timeout (Plugged In) policy. Windows Vista displays the dialog box shown in Figure 1. Click Enabled and enter the value in the System Sleep Timeout (seconds) box. Note that the sleep idle timeout value is represented in seconds with a minimum of zero, which indicates never idle to sleep. In this example, the timeout value set is 1,200 seconds (or 20 minutes). Now just click OK to save the policy setting value.
Figure 1 Specify the System Sleep Timeout (Plugged In) properties
Figure 1 Specify the System Sleep Timeout (Plugged In) properties

Display Idle Timeout
The display idle timeout automatically powers off display devices that are attached to a system after a set period of user inactivity. In the default Windows Vista power plans, this timeout varies according to the power plan.
The display idle timeout can have a substantial impact on the power consumption of the display device. Energy savings that result from enforcing a display idle timeout vary by usage patterns and the specific display device, but can be significant—especially on systems equipped with CRT monitors.
The display idle timeout policy is located in Video and Display Settings under Power Management. There are separate policy objects for both AC (utility) and DC (battery) power. To set the display idle timeout power setting for AC power, choose Properties for the Turn Off the Display (Plugged In) policy. Windows Vista then displays the dialog box shown in Figure 2. Click Enabled and enter a timeout value in the Turn Off the Display (seconds) box. Again, the display idle timeout value is represented in seconds with a minimum of zero indicating to never turn off the display. Now click OK and the policy setting value is saved.
Figure 2 Turn Off the Display (Plugged In) properties
Figure 2 Turn Off the Display (Plugged In) properties

Confirming a Display Idle Timeout Is Enforced by Group Policy
To confirm that the display idle timeout power setting has been enforced on a system by using Group Policy, you can view the setting in the Power Options Control Panel, as shown in Figure 3. The figure shows Power Options with a display idle timeout of five minutes enforced with Group Policy. The message in the yellow banner indicates that some power settings are enforced by the system administrator. Note also that the Turn Off the Display selector used to change the display idle timeout setting is disabled.
Figure 3 Power options showing a display idle timeout enforced with Group Policy
Figure 3 Power options showing a display idle timeout enforced with Group Policy

Configuring the Screen Saver Policy
Finally, the screen saver can be configured with Group Policy using the policies available under User Configuration | Administrative Templates | Control Panel | Display. To maximize energy efficiency (as well as security), you should configure the screen saver to use the blank screen saver and require a password on resume. For user convenience, consider setting the screen saver to come on shortly after the display is blanked. This gives the user an opportunity to bring back the desktop without entering a password if they are sitting at their PC when the screen goes blank. Figure 4 lists the relevant screensaver policy settings.
Figure 4 Screen saver policy settings (Close Figure 4)

Policy | Description | Recommended Value
Screen Saver | Enables the screen saver. | Enabled
Screen Saver Executable Name | Configures which screen saver to use. | Scrnsave.scr (for the blank screen saver)
Screen Saver Timeout | Indicates the number of seconds of user inactivity before enabling the screen saver. | A value slightly longer than the display idle timeout setting
Password Protect the Screen saver | Specifies whether a password needs to be entered after the screen saver comes on. | Enabled

35 Settings for Managing Power
Group Policy offers 35 settings that you can use to optimize the power settings used throughout your organization. Some of these settings are only appropriate in very special circumstances and should only be used with a thorough understanding of how they function. (Disabling suspend states, for example, is only needed in hardcore BitLocker Drive Encryption deployments.) Here's an overview of the 35 settings to get you started.

Group Policy Setting | Description | Notes
Critical Battery Notification Action | Specifies the action that Windows takes when battery capacity reaches the critical battery notification level. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Low Battery Notification Action | Specifies the action that Windows takes when battery capacity reaches the low battery notification level. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Critical Battery Notification Level | Specifies the percentage of battery capacity remaining that triggers the critical battery notification action. | To set the action that is triggered, see the Critical Battery Notification Action policy setting. If you disable this policy setting or do not configure it, users can see and change this setting.
Low Battery Notification Level | Specifies the percentage of battery capacity remaining that triggers the low battery notification action. | To set the action that is triggered, see the Low Battery Notification Action policy setting. If you disable this policy setting or do not configure it, users can see and change this setting.
Turn Off Low Battery User Notification | Disables a user notification when the battery capacity remaining equals the low battery notification level. | If you enable this policy, Windows will not show a notification when the battery capacity remaining equals the low battery notification level. The notification will only be shown if the Low Battery Notification Action policy setting is configured to No Action. If you do not configure this policy setting, users can see and change this setting.
Select the Power Button Action (Plugged In) | Specifies the action that Windows takes when a user presses the power button. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Sleep Button Action (Plugged In) | Specifies the action that Windows takes when a user presses the Sleep button. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Lid Switch Action (Plugged In) | Specifies the action that Windows takes when a user closes the lid on a laptop. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Start Menu Power Button Action (Plugged In) | Specifies the action that Windows takes when a user presses the user interface Sleep button. | Possible actions include Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Power Button Action (on Battery) | Specifies the action that Windows takes when a user presses the power button. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Sleep Button Action (on Battery) | Specifies the action that Windows takes when a user presses the Sleep button. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Lid Switch Action (on Battery) | Specifies the action that Windows takes when the user closes the lid on a laptop. | Possible actions include Take no action, Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Select the Start Menu Power Button Action (on Battery) | Specifies the action that Windows takes when a user presses the user interface Sleep button. | Possible actions include Sleep, Hibernate, and Shut Down. If you disable this policy setting or do not configure it, users can see and change this setting.
Turn Off the Hard Disk (Plugged In) | Specifies the period of inactivity before Windows turns off the hard disk. | The value indicating how much idle time should elapse before Windows turns off the hard disk is specified in seconds. If you disable this policy or do not configure it, users can see and change this setting.
Turn Off the Hard Disk (on Battery) | Specifies the period of inactivity before Windows turns off the hard disk. If you enable this policy, you must provide a value, in seconds, indicating how much idle time should elapse before Windows turns off the hard disk. If you disable this policy or do not configure it, users can see and change this setting. | The value indicating how much idle time should elapse before Windows turns off the hard disk is specified in seconds. If you disable this policy or do not configure it, users can see and change this setting.
Specify a Custom Active Power Plan | Specifies an active power plan when you enter a power plan's GUID. | You can retrieve the custom power plan GUID by using powercfg, the power configuration command -line tool. To specify a plan for the list of default Windows power plans, use the Active Power Plan policy setting. If you disable this policy or do not configure it, users can see and change this setting.
Select an Active Power Plan | Specifies the active power plan from a list of default Windows power plans. | To specify a custom power plan, use the Custom Active Power Plan setting. To enable this setting, select Enabled and choose a power plan from the Active Power Plan list. If you disable this policy or do not configure it, users can see and change this setting.
Prompt for Password on Resume from Hibernate / Suspend | Allows you to configure systems to always lock when resuming from a hibernate or suspend. | If you disable or do not configure this setting, users can decide if their computer is automatically locked or not after performing a resume operation.
Turn on Applications to Prevent Sleep Transitions (Plugged In) | When enabled, this setting allows applications and services to prevent the system from sleeping. | If you disable this policy setting or do not configure it, users can see and change this setting.
Specify the System Hibernate Timeout (Plugged In) | Specifies the period of inactivity before Windows transitions the system to hibernate. | If you disable this policy setting or do not configure it, users can see and change this setting.
Require a Password When a Computer Wakes (Plugged In) | Specifies whether the user is prompted for a password when the system resumes from a sleep state. | If you enable this policy, or if it is not configured, the user is prompted for a password when the system resumes. If you disable this policy, the user is not prompted for a password when the system resumes.
Specify the System Sleep Timeout (Plugged In) | Specifies the period of inactivity before Windows transitions the system to a sleep state. | If you disable this policy setting or do not configure it, users can see and change this setting.
Turn Off Hybrid Sleep (Plugged In) | This setting disables hybrid sleep and the system will not generate a hiberfile when transitioning to sleep. | If you do not configure this policy setting, users can see and change this setting.
Turn on Applications to Prevent Sleep Transitions (on Battery) | Allows applications and services to prevent the system from sleeping. | If you disable this policy setting or do not configure it, users can see and change this setting.
Specify the System Hibernate Timeout (on Battery) | Specifies the period of inactivity before Windows transitions the system to hibernate. | If you disable this policy setting or do not configure it, users can see and change this setting.
Require a Password When a Computer Wakes (on Battery) | Specifies whether the user is prompted for a password when the system resumes from a sleeping state. | If you enable this policy, or if it is not configured, the user is prompted for a password when the system resumes. If you disable this policy, the user is not prompted for a password when the system resumes.
Specify the System Sleep Timeout (on Battery) | Specifies the period of inactivity before Windows transitions the system to sleep. | If you disable this policy setting or do not configure it, users can see and change this setting.
Turn Off Hybrid Sleep (on Battery) | This setting disables hybrid sleep and the system will not generate a hiberfile when transitioning to sleep. | If you do not configure this policy setting, users can see and change this setting.
Turn Off Adaptive Display Timeout (Plugged In) | This manages how Windows controls the setting that specifies how long a computer must be inactive before Windows turns off the computer's display. | When this policy is enabled, Windows automatically adjusts the setting based on what users do with their keyboard or mouse to keep the display on. When this policy is disabled, Windows uses the same setting regardless of keyboard and mouse behavior. If you don't configure this setting, users can see and change this setting.
Turn Off Adaptive Display Timeout (on Battery) | Specifies how Windows controls the setting that specifies how long a computer must be inactive before Windows turns off the computer's display. | When this policy is enabled, Windows automatically adjusts the setting based on what users do with their keyboard or mouse to keep the display on. When this policy is disabled, Windows uses the same setting regardless of keyboard and mouse behavior. If you don't configure this setting, users can see and change this setting.
Turn Off the Display (Plugged In) | Specifies the period of inactivity before Windows turns off the display. | If you disable this policy or do not configure it, users can see and change this setting.
Turn Off the Display (on Battery) | Specifies the period of inactivity before Windows turns off the display. | If you disable this policy or do not configure it, users can see and change this setting.
Allow Standby States (S1-S3) When Sleeping (Plugged In) | Specifies whether Windows is allowed to use standby states when the computer goes into a sleeping state. | If this policy is disabled, the only sleep state a computer may enter is Hibernate.
Allow Standby States (S1-S3) When Sleeping (on Battery) | Specifies whether or not Windows is allowed to use standby states when the computer goes into a sleeping state. | If this policy is disabled, the only sleep state a computer may enter is hibernate.
Do Not Turn Off System Power after a Windows System Shutdown Has Occurred | Specifies whether power is automatically turned off when Windows shut down completes. If you enable this setting, the computer system will be safely shut down, and remain in a powered state, ready for power to be safely removed. | This setting is only applicable when Windows shut down is initiated by software programs invoking the Windows programming interfaces ExitWindowsEx() or InitiateSystemShutdown(). This setting does not affect behavior when Windows is shut down manually by the user. If you disable or do not configure this setting, the computer system will safely shut down to a fully powered-off state

Mark Aggar is an Environmental Technologist at Microsoft.
Pat Stemen is a Senior Program Manager at Microsoft.
Michael Walsh is the Senior Environmental Product Manager at Microsoft.


 Letters: Readers Speak Out
Letters
Readers Speak Out

Windows Clusters
How is Windows® Compute Cluster Server different from a conventional Windows cluster?
—from blogs.technet.com/tnmag

That's a very common question! I do get many questions about availability clustering (failover clustering) when I talk about Windows Compute Cluster Server (CCS). Compute clusters are different from "availability clusters," which provide failover of services among systems.
Compute clusters use a job queue or scheduler to assign tasks to different systems in the cluster. The scheduler (running on the head node of the cluster) receives job scheduling requests and then assigns the work to the other compute nodes in the cluster. Simply put, CCS lets you divide up work among computers, while availability clustering strives to provide uninterrupted service.
—John Kelbley, Senior Technical Product Manager

Robocopy GUI
Thank you for the column on the Robocopy GUI (November 2006, technetmagazine.com/issues/2006/11/UtilitySpotlight). It makes Robocopy easy to use, and the tabs groupings have made it easier for me to comprehend the many command-line options.
—Biff M.

Thanks very much for your feedback! It's great to hear that you're finding this tool useful. As always, if there are any other tools you'd like to see covered in TechNet Magazine, please just let us know! Drop us a line at tntools@microsoft.com.

Device Drivers
How does one list all of the specific files associated with particular device drivers?
—T.P.

If you're trying to determine the list of all of the various files that support a specific driver installation, unfortunately there is no perfect solution. Your best bet is to look at the INF file included with the driver in question—in particular at the section usually marked *.copyfiles, as it relates to the Plug-n-Play ID (PnPID) for that driver. That section will list the files copied during the driver's installation.
This is made more difficult, however, with some drivers that call "CoInstallers" as a part of the driver—one of those may in turn actually extract or install other files. But parsing the CopyFiles section will get you the majority of the files the majority of the time—you just have to look carefully and understand what the INF is saying.
—Wes Miller, Columnist, The Desktop Files

Windows Authentication
I've been trying to find articles or whitepapers that offer information about Windows Authentication. Specifically, I would like to learn more about wireless using Internet Authentication Service (IAS) in a Windows 2000 Active Directory® Domain. Can you direct me to articles that have this information?
—Brett M.

The best source of content that you can find on this subject is probably the IAS TechCenter on TechNet, which you can find at technet.microsoft.com/network/bb643123. It includes links to a number of articles and whitepapers on authentication with IAS.
Another appropriate online forum in which to pose these questions would be the Windows 2000 Server Security Newsgroup at microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security.

An Appreciative Reader
I have read your interesting article "A Guide to Basic Computer Forensics" in the December 2007 issue (which can be found at technetmagazine.com/issues/2007/12/Forensics). First, I want to congratulate you for publishing such important information. Next, I want to congratulate coauthor Tom Cloward, Program Manager at Microsoft, for using his excellent experience in the security field. I also want to congratulate coauthor Frank Simorjay, Technical Program Manager and security subject matter expert at Microsoft. You are employed in the security field and have agreed to share your vast knowledge on the subject to resolve problems caused by Internet security attacks. It is very commendable. Many thanks.
—Mr. S.

Thanks for your note, Mr. S. We agree that this is a very important subject, and we hope you'll be happy to know that we have more coverage of this topic already planned in the upcoming issues of TechNet Magazine. Thanks again!


 Toolbox: New Products for IT Pros
Toolbox
New Products for IT Pros
Greg Steen

Analyze Disk Space
FolderSizes
foldersizes.com
How do you know what is taking up all the space on your client's machine? You may have a disk space monitor in place to let you know when the machine is nearing capacity, but determining how to clean up the disk to regain a healthy ratio of free space can sometimes be an arduous task. One utility that can help you identify what is taking up space is FolderSizes from Key Metric Software.
When you launch this application for the first time, it gives you a quick walkthrough of the application's UI to help you get going (though the application is very straightforward). To analyze a drive or folder, you simply double-click it in the hierarchical Folder Browser panel. Once FolderSizes has scanned the target, the program provides a graph of disk usage and a folder view that shows you how much space the contents of each parent folder takes up. And with just one click, you can change the visualization of your folders between a pie chart and a bar chart to get a handle on where the space is being used. Personally, I find the bar chart more useful when dealing with numerous sibling directories.
Double-clicking on a bar, pie slice, or folder drills down into the sub-folder. This navigation makes it quick and easy to zoom in on potential problem points, such as a "hidden" directory of mp3s your user named Sales Presentations. Or, if you have a user who is a document hound and just likes to keep anything and everything on his machine, you can sort by last modified date to see which files haven't been accessed in a very long time. This makes for a good argument to the user that the files can probably be archived to a CD or deleted forever without causing problems.
Another cool feature is how FolderSizes lets you customize the number of levels you want presented in the chart. For example, you could view a chart of every folder on the drive, sorted from largest to smallest all at once, letting you isolate problem spots. Once you do find a trouble spot, you can right-click to access the "command prompt from here" and "explore this folder" actions. This lets you run any other utilities or checks you may need.
FolderSizes also includes a built-in Report Generator that gives you yet another set of views of your target file system's contents. You can, for example, find the largest files of a specific type or the oldest files on the system; you can find temporary or duplicate files; you can locate all read-only files; and you can determine all files that have a specific owner on your file server. The list goes on. And once you have generated your report, you can filter the view, print it, or even export it to XML, HTML, or CSV.
In addition to all this, FolderSizes also offers a great way to streamline your backups, ensuring you only grab the files you really need to archive. You could also use the command-line interface of the application to script and automate checks of your client or server systems. So if you are looking for a quick way to isolate what is hogging the disk space on your servers or client machines, consider giving FolderSizes a shot.
Price: Starts at $50 (single user license).
FolderSizes offers chart visualization of system folders
FolderSizes offers chart visualization of system folders

Manage User Accounts
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
The bigger your organization, the easier it is to lose track of inactive user accounts. And in terms of security, it is always a good idea to have a process in place to make sure you can easily track down those inactive user accounts and disable or remove them, eliminating a potential security hole. Inactive Users Tracker, a freeware utility from NetWrix Corporation, provides a simple way to do that.
The tool periodically scans your Active Directory® domains for inactive users and e-mails the list of inactive accounts to the administrative e-mail address of your choice. You can specify which domain you would like to manage as well as which account has permission to scan Active Directory for inactive accounts. In addition, you can set the number of days that an account must be inactive for it to be "labeled" as inactive and included in the e-mail notification. And, of course, you can schedule when the process will kick off.
Other than that, you simply configure your SMTP server to relay the notification e-mail to the administrative address and specify whether or not you want the utility to filter the inactive user accounts using a name filter—for example, you might have all your consultant accounts start with "c_".
There is also a commercial version available (price quotes are tailored to the customer purchasing the product). This version lets you customize the e-mail messages sent to your users, supports automatically disabling inactive user accounts, and includes technical support.
Price: Free
Inactive Users Tracker notifies you about inactive users
Inactive Users Tracker notifies you about inactive users

Enhance E-Mail Communications
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
On one hand, with today's ever-increasingly litigious and regulated world, it is very important that your organization protect its e-mail communications. At the same time, consistent communication and brand recognition help your organization build a better relationship between itself and those with which it communicates. Exclaimer Mail Utilities 2007, which is designed to work with Exchange Server 2007 deployments, can help you on both fronts.
The application has three base features, which help to unify and protect your organization's e-mail commutations: disclaimers, branding, and signing. In addition, you have the ability to add modules that can help fight spam and viruses.
In terms of disclaimers, Exclaimer Mail Utilities helps you reduce your exposure to litigation and increase your compliance with regulations, such as Health Insurance Portability and Accountability Act (HIPAA) and Circular 230, by adding a customized message (that appears either after or before the e-mail text) to every message that leaves your organization. As for branding, you can easily add an image and brand tag to every message you send to ensure that communications with your client base have a consistent feel. And for signatures, you can ensure that an automatic signature is applied to every message, whether it is sent from a smart device, Microsoft® Outlook® Web Access, or a standard Outlook client. The signature is dynamically generated from data that you probably already store in your Active Directory tree. And you can configure the tool to customize those signatures based on a number of factors, including whether the e-mail is sent to an internal or external person, who the sender is, who the recipient is, and what the subject of the message contains.
Pricing for Exclaimer Mail Utilities 2007 is user-based and starts at $245 for 25 users with discounts as you go up in count. In addition, the anti-spam module, the antivirus module, and technical support also increase the base cost. Support is mandatory for the first year and starts at $55 for 25 users. For performance reasons, you need a computer running 64-bit Windows Server® 2003 or Windows Server 2008 to run Mail Utilities. If this sounds good, but you are still running Exchange Server 2003, there is another version available.
Price: Starts at $245 for 25 users.

Book Review
How to Cheat at Securing SQL Server 2005
syngress.com
As IT professionals, we all know that security should be a top concern for our infrastructure implementations. Just consider how interconnected environments are today and how much sensitive information is retained on your systems. This is especially true for your SQL Server® instances, as they tend to be centralized sources of sensitive information. In addition, the regulations now in place to protect people's privacy, such as Sarbanes-Oxley and HIPAA, can cause you significant legal and financial headaches if something were to happen and this data were to be compromised.
When securing your SQL Server 2005 instances, you might want to take a look at How to Cheat at Securing SQL Server 2005. The title is somewhat misleading—the book doesn't provide "cheats" but instead offers a step-by-step reference to locking down your SQL Server 2005 deployments. The strategy follows the basic principle of "least access," where you only allow what you need to serve the business needs and then turn off the rest.
After the introduction, the book starts out by exploring how to reduce the surface area of your SQL Server 2005 instance using the Surface Area Configuration Tool. You get useful information, such as the default services with their default startup (manual, automatic, or disabled) options when you install SQL Server 2005. In the next chapter, you learn about SQL Server roles and how they can greatly simplify administration tasks. For example, the book shows you how to tie a role to a Windows® group. That way, if you add a new user to the group, he is automatically granted access to the resources available to that role.
The chapter on authentication and granular access discusses Windows and SQL Server logins and the benefits and drawbacks of each. It also explores the Microsoft best practices regarding authentication. The book then flows into authorization, covering the options available to you for fine-tuning what your users will be able to do on the instance (or, in database-speak, your principles' permissions for securables). You learn about things like the dedicated administrator connection (DAC), which provides a local, administrator-only connection that lets you get onto an instance when a query or process eats up all the resources, making the server unresponsive. This is a handy feature that was lacking before SQL Server 2005.
In SQL Server 2005, schemas and users are separated into distinct entities. There is a chapter on defining, updating, and deleting schemas via T-SQL and the SQL Server Management Studio. In this section, you will also find some good tips, such as learning not to use the sp_adduser stored procedure to create new users in SQL Server 2005 unless you want to create a new schema. Instead, use the CREATE USER T-SQL statement to create the user and nothing else.
Passwords are, of course, another important part of securing your setup, and the next chapter discusses password policies at length to help you obtain a uniform level of security across accounts. The author explores different scenarios of implementation to guide you in choosing the best policy and policy type for your environment. Then you move on into Data Definition Language (DDL) triggers and how they can help protect against unintended structural changes and provide audit trails for changes to server logins.
In the next chapter, you discover the many ways SQL Server 2005 can encrypt your data and schemas to protect sensitive information. Finally, the book gives an overview of SQL Reporting Services, SQL Analysis Services, and SQL Server Integration Services (SSIS), including security-related best practices guidelines. The two appendices are also very useful, providing insight into how to secure and implement group policy and Active Directory as it relates to SQL Server 2005.
I found two particularly useful constructs used throughout the book. First, each chapter features a "Solutions Fast Track" section, which gives you a bullet-point rundown of features, facts, and best practices for the elements covered in the chapter. The second is a "Frequently Asked Questions" section, which provides quick answers to questions about administering your SQL Server 2005 instance. If you are looking for a quick way to get up to speed on SQL Server 2005 administration from a security perspective, you might want to consider adding How to Cheat at Securing SQL Server 2005 to your reference shelf.
Price: $19.98 for e-book, $49.95 for paper book

Powerful Screen Capturing
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
Screen captures offer a great way to document step-by-step user instructions, illustrate error messages that occur in applications, or put together a quick feature presentation. Of course, Windows has its own built-in screen capture functionality (PrtScr for a full screen capture, Alt-PrtScr for just the active window). However, the capabilities built into the OS are limited. If you want more granular control over what gets captured and when it gets captured, or if you want to capture a screen from movie playback, you'll need to check out one of the many third-party screen capture utilities available to help you do so. One such tool is ScreenHunter Pro from Wisdom Software. This inexpensive utility has a number of useful features that let you tailor your screen captures to meet your specific needs better.
The UI is straightforward. You simply pick where your screen capture should come from and then direct it to where the capture should go using the aptly named From and To tabs. In terms of what you can capture, the application lets you grab an adjustable or fixed rectangular area, a specific object or window, the active window, a specific portion of the active window, the whole screen, a DirectX® or screensaver source, movie playback, or a more complex shape (a freehand, elliptical, or polygon area that you define). You can also capture multiple window objects or message boxes at the same time (which is great for snagging only the active application along with its dialog or other windows interfaces). You can then dump the screen capture to the clipboard, a specified viewer or editor, a printer, or a file. You can even choose to have it sent to an e-mail address.
Captured images can be saved as BMP, PNG, JPEG, or TIFF files of various image qualities. In addition, you can have the application auto-scale your capture to a specific size, add a border, or add a watermark on the capture, reducing the amount of "post-production" work you need to do to the image. You can even set the application to automatically capture the screen at a specified interval, in effect recording activities on the machine.
Another nice feature is how ScreenHunter Pro supports auto-scroll functionality, allowing you to capture, for example, a long Web page with a viewable region that extends beyond the viewable area on your screen. Like many IT pros, I have multiple monitors, and therefore I like the multiple-monitor capture support, which allows you to grab all the information on your screens with one capture.
This utility even includes a built-in image editor, letting you tailor your images within the same application context. If you don't need some of the more advanced functionality—such as automatic e-mailing, scheduled capture, watermarks, and multi-monitor captures—you might be interested in the slightly cheaper ScreenHunter Plus version. A stripped-down version is also available for free.
Price: $29.95 for ScreenHunter Pro
ScreenHunter Pro lets you specify when and what you capture
ScreenHunter Pro lets you specify when and what you capture

Greg Steen


 Exchange Queue &amp; A: Exchange 2007 SP1 Deployment
Exchange Queue & A
Exchange 2007 SP1 Deployment
Nino Bilic

Q I am wondering whether or not Exchange Server 2007 SP1 is available only in the 64-bit version? If it turns out that it is also available in a 32-bit version, is that version supported for a production environment?
A In this regard, there isn't any difference between the original (RTM) and SP1 versions of Exchange 2007. SP1 is available in both 32- and 64-bit flavors. However, it is important to keep in mind that, just as with the RTM version, only 64-bit is supported for installed server roles in a production environment. You can use the 32-bit SP1 version in order to run various /prepare setup switches and to manage your 64-bit servers, though, just as you could with RTM.

Q Do I need to complete the full installation of the Exchange 2007 RTM version first and then apply SP1 to get the SP1 server?
A This is a characteristic of Exchange 2007 SP1 that is quite different compared with service packs for previous versions of Exchange. When you get the SP1 bits, you are essentially getting the RTM bits with SP1 slipstreamed into them as well, and this means that you do not have to use the RTM DVD for new installs of Exchange 2007 SP1.
So, in order to install new Exchange 2007 SP1 servers, all you need are the SP1 bits. Even if you are joining the first Exchange 2007 into the Exchange Server 2003 organization, for example, you will still be able to get started with SP1 right away.
Q I have a server running Exchange 2007 RTM on Windows Server® 2003, and I am installing Exchange 2007 SP1 on the machine now. Because Microsoft says that Exchange 2007 SP1 is supported on Windows Server 2008, I plan to do an in-place upgrade to Windows Server 2008 later. What do you think of this plan?
A Unfortunately, this is a bad idea. In-place upgrading the server from Windows Server 2003 to Windows Server 2008 with Exchange 2007 RTM or SP1 installed is not supported. There are multiple technical reasons for this, and you should understand that your Exchange installation will break if such an in-place upgrade is performed.
For more information, read "Mission Impossible: In-Place Upgrading Microsoft® Exchange Server 2007 from Windows Server 2003 to Windows Server 2008" at msexchangeteam.com/archive/2007/10/04/447188.aspx.

Q I have never entered the product IDs for a few of my lab servers. Because of this, when I launch the Exchange Management Console, I get a pop-up warning that says I have "0 days" left. Will I be able to upgrade to Exchange 2007 SP1 without entering product keys for those servers?
A Yes. Exchange 2007 SP1 setup (see screenshot) cannot check the length of the trial period for an already installed server. There is no upgrade block in place for this scenario.

Q I have already installed Exchange 2007 SP1 on my Mailbox server. Now I would like to add the Client Access server role to this server. Do I need to use my Exchange 2007 RTM or the new Exchange 2007 SP1 bits?
A You need to use your Exchange 2007 SP1 bits to install additional server roles after Exchange 2007 SP1 was already applied. As noted earlier, Exchange 2007 SP1 is a complete product that contains all of the files required to run Exchange 2007, and you will not need your Exchange 2007 RTM bits once SP1 is successfully installed.
Of course, if you have multiple server roles on the server that you are upgrading to Exchange 2007 SP1, the application of SP1 will automatically upgrade all of the roles installed. You cannot apply SP1 to only some of the roles on the same physical server.

Q My Exchange organization has multiple Exchange 2007 servers, and server roles are distributed among several of them. Which server roles should I upgrade first?
A Before doing anything, you should download and read the Exchange 2007 SP1 release notes (go.microsoft.com/fwlink/?LinkId=112364), as they contain important information about the application of SP1 to an existing installation.
To respond directly to your query, though, what follows is an excerpt from SP1 release notes that addresses this very question:

"We recommend that you upgrade your servers that are running the Mailbox server role after you upgrade your servers that are running the Client Access, Unified Messaging, Hub Transport, or Edge Transport server roles. If you upgrade your servers in this order, you may avoid potential service interruptions. (Upgrading roles in that order will assure that the servers that "front" the functionality for mailboxes are able to communicate with the mailbox server without interruptions, rather than running into problems when trying to communicate with a more-featured back-end server.) We also recommend that you upgrade your Client Access servers that reside in Internet-facing sites before you upgrade your Client Access servers that reside in sites that are not accessible from the Internet.
If you are running the Edge Transport server role in your Exchange organization and have created an Edge Subscription, all transport servers that participate in the EdgeSync process must be running the same version of Exchange 2007. You must upgrade all the subscribed Edge Transport servers and all the Hub Transport servers in the Active Directory® site to which the Edge Transport servers are subscribed; and you must do so within 15 days of the first upgrade to Exchange 2007 SP1 of any transport server that participates in the Edge Subscription process."

Q I have ForefrontTM Security for Exchange Server installed on my Exchange 2007 RTM server. Do I have to do something special before upgrading to Exchange 2007 SP1?
A The RTM version of Forefront Security for Exchange Server is incompatible with Exchange 2007 SP1. You need to either remove Forefront Security for Exchange Server or upgrade it to a later version before you can upgrade. The SP1 release notes can provide you with more detail.
And, by the way, Exchange 2007 SP1 setup has a new prerequisite check that will warn you of this in case you are in this situation and you attempt the upgrade.

Q I have Exchange 2007 RTM with the post-RTM Rollup Update (RU) installed. Do I have to remove the RU before I apply Exchange 2007 SP1?
A You do not have to go ahead and manually remove any rollup updates before installing Exchange 2007 SP1. Exchange 2007 SP1 setup will take care of getting rid of any updates that might have to be removed before SP1 is applied to the machine. 

Nino Bilic is a Supportability Program Manager for Exchange Server. He is getting insanely rich by exploring the galaxy and whooping bad guys in Mass Effect.


 Utility Spotlight: SharePoint Capacity Planning
Utility Spotlight
SharePoint Capacity Planning
Peter Skjøtt Larsen and Satish Mathew

Planning a large installation of Microsoft® Windows® SharePoint® Services (WSS) and Microsoft Office SharePoint Server (MOSS) can be a complex undertaking. Many factors go into determining the most cost-effective topology, hardware, and bandwidth requirements. And there are a multitude of configuration options to consider, depending on how the system will be used. Often, administrators and planners have little more than rules of thumb to help with sizing a system.
Happily, Microsoft has released the second generation of the Microsoft System Center Capacity Planner (SCCP) 2007, a general-purpose tool that combines a model of various apps with a simulator that can estimate how they behave in a particular deployment. This release introduces the new SharePoint Capacity Planning Tool, which adds two more models for WSS 3.0 and MOSS 2007 to this engine.
The SharePoint Capacity Planning Tool and the SCCP 2007 are freely available from the Microsoft Download Center at microsoft.com/systemcenter/sccp/default.mspx.
The SharePoint Capacity Planning Tool collects your organization's requirements by compiling your answers to questions about expected usage and operating conditions. To generate a preliminary design, a wizard prompts you for relevant information about your structure and your projected SharePoint needs, including number and type of users (authenticated versus anonymous), network parameters, hardware configuration, usage patterns (such as publishing or collaboration), storage requirements, and indexing and query requirements.
Results of a simulation in the SharePoint Capacity Planning Tool
Results of a simulation in the SharePoint Capacity Planning Tool
The tool then generates a recommended baseline topology using names particular to your own setup. You run load and usage simulations against the suggested topology to see how the proposed installation would operate under various conditions.
The initial topology can be modified with a model editor, and you can then run what-if scenarios to simulate the impact of usage growth, enterprise branch office expansion, additional hardware, and increased bandwidth. As the screenshot shows, the simulation generates estimated server loads and user experience reports that let you start optimizing the configuration based on parameters such as cost, performance, and available hardware. You can export a detailed or summary report to an Excel® spreadsheet and the topology diagram to a Visio® file.
The SharePoint Capacity Planning Tool eases the burden of greenfield deployment by letting you test a variety of circumstances to arrive at a reasonable starting configuration. Because you can also model an existing topology and run through various what-if scenarios, the tool is useful for exploring potential changes to existing deployments as well.

Peter Skjøtt Larsen is a Senior Product Manager on the Microsoft Solution Accelerator's team. He has been with Microsoft for four years, working with UNIX Migration and Communications and Collaboration.
Satish Mathew is a Program Manager on the Microsoft Solution Accelerator's team. He has been with Microsoft for almost five years, working first with the Windows PowerShell team before transitioning to his current team.


 Inside Sharepoint: Building Your SharePoint Infrastructure
Inside Sharepoint
Building Your SharePoint Infrastructure
Pav Cherny
Download the code for this article: SharePoint2008_05.exe (412KB)

Just as e-mail messaging transformed business communication, Web-based collaboration is changing how people work together and share information. As a good example, take a look at what SharePoint technology offers. With Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server
(MOSS) 2007, you can create team sites, portals, Web content management solutions, document libraries, and search centers, not to mention the 2007 Microsoft® Office system integration, XML-based forms, workflows, mobility support, and so on.
It's not always simple to get started with SharePoint®, however. The terminology can be confusing. The system architecture can be complex, and SharePoint requires you to deal with multiple components, including IIS, the Microsoft .NET Framework, SQL Server®, and possibly other technologies, such as Business Intelligence, InfoPath® Forms Services, Rights Management Services (RMS), Exchange Server, and ForefrontTM Security.
You can quickly lose your way with integrations and customizations given the many approaches you can take to create SharePoint solutions, whether through the built-in user interface or programmatically. Moreover, when a SharePoint application does not work, troubleshooting can be complicated. Oftentimes, you must have the mindset of an application developer to understand the components involved and how they interact. With all these challenges, where do you begin in order to build a robust, scalable, and manageable SharePoint infrastructure?
In this column, I'll show you how to get started first by building a foundation with a high-level architecture discussion and then by diving into the deployment of WSS, including very basic branding customizations. Using the Self-Service Site Management feature of WSS 3.0, you will see how to delegate permissions for creating and managing SharePoint sites to individual users while maintaining centralized administrative control over the SharePoint infrastructure.
By looking first at the SharePoint architecture, it becomes easier to understand the deployment and configuration steps necessary to implement a flexible and scalable infrastructure. So let's take a glance at the dependencies and then go straight into the deployment of WSS 3.0. For detailed deployment instructions, see the companion material for reference. You can find this material at the downloads section of the TechNet Magazine Web site at technetmagazine.com.

SharePoint Architecture
With SharePoint, it is helpful to think about the technology from a system architect's point of view. You don't have to know all the nitty-gritty details, but if you are familiar with the overall dependencies that arise from the SharePoint architecture, you can arrive at solutions faster because you can anticipate what you need to configure and why.
SharePoint is a technology for provisioning Web applications and sites. It is an IIS-based Web site solution, integrating with IIS through ASP.NET and relying on a SQL Server database back end for storing configuration data and content. In short, SharePoint combines three different architectures at its core (IIS, .NET, and SQL Server), as illustrated in Figure 1.
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Don't let the diagram intimidate you. The architecture might look overwhelming at first, considering the sheer number of components. But all of these components fit into a logical framework that, when examined systematically, gives insight into the component dependencies.
As depicted, SharePoint relies on IIS and ASP.NET to handle HTTP requests and responses. Standard IIS components, such as the HTTP kernel-mode driver (http.sys) and the Worker Process (w3wp.exe), perform the initial queuing and routing of requests until they arrive at the ASP.NET ISAPI filter (aspnet_isapi.dll). When you install the .NET Framework, the setup routine registers aspnet_isapi.dll in the IIS Metabase (C:\Windows\System32\Inetsrv\metabase.xml), as follows:
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
Once IIS loads the ASP.NET ISAPI filter, all incoming requests for a Web site can be passed to ASP.NET, which is important because SharePoint must eventually receive these requests through ASP.NET. To accomplish this, SharePoint extends the configuration of the selected Web site by adding a wildcard application map that routes all incoming requests, regardless of the file name extension, to the ASP.NET ISAPI filter.
You can see this in IIS Manager after you install WSS 3.0 using the Basic installation option. The WSS setup routine deactivates the existing default IIS Web site on the server and creates a new default Web site on port 80 that has the ASP.NET wildcard application map defined, as shown in Figure 2.
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Figure 2 Wildcard application map for ASP.NET ISAPI filter
For ASP.NET to pass requests in turn to SharePoint, SharePoint must also extend the HTTP Request Pipeline through a custom HttpApplication object, which is implemented by means of a class called SPHttpApplication in the Microsoft.SharePoint assembly. SharePoint defines this custom application object in the ASP.NET application file (global.asax), which you can find in the file system in the root folder of SharePoint-extended Web sites. The following code lists the content of such a global.asax file:
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET dynamically parses and compiles this file to instantiate the SharePoint application object.
For each received request, ASP.NET triggers a series of events that the Web application can process, such as BeginRequest, AuthenticateRequest, ProcessRequest, and EndRequest. The details of event handling are beyond the scope of deploying and managing SharePoint, yet it is important to know that, in addition to SPHttpApplication specified in global.asax, SharePoint implements custom HTTP handlers and modules defined in the web.config file for the site. For example, SharePoint uses an HTTP module based on the SPRequestModule class, registered as the first HTTP module prior to standard ASP.NET modules. SPRequestModule initializes the SharePoint runtime environment, such as by registering an SPVirtualPathProvider component with ASP.NET. SPRequestModule is for internal SharePoint use, but SharePoint solution developers can modify the web.config file to register additional components, such as custom HTTP handlers and modules. Through both custom and standard HTTP modules, SharePoint takes advantage of ASP.NET while maintaining tight control over all requests to SharePoint applications.
Note that when you create a Web application using the SharePoint 3.0 Central Administration site, WSS adds the ASP.NET wildcard application map to the selected IIS Web site and creates the global.asax and web.config files in the Web site's root folder. Each Web application uses its own set of top-level global.asax and web.config files.
To process requests and return meaningful information to browsers, WSS 3.0 and MOSS 2007 rely on the standard ASP.NET page parser, which compiles the requested ASP.NET pages or processes them in no compilation mode. But the ASP.NET pages that SharePoint passes to the ASP.NET parser are not necessarily located where they appear to exist. For example, you will not be able to find a default.aspx file in the root folder of a SharePoint-extended Web site, such as the SharePoint 3.0 Central Administration site, yet you are opening default.aspx when displaying the home page of that Web site. It is the SPVirtualPathProvider component that virtualizes the environment by loading the page content from the local file system or a SQL Server content database and passing it as a virtual file to the ASP.NET page parser. For the Central Administration site, SharePoint loads the default.aspx file from the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin folder.
The home page, as well as most other SharePoint site pages, is linked to an ASP.NET Master Page (default.master) that implements a common layout for menus and navigation controls. Default.master resides in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global folder and includes named placeholders for further content pages that can also reside on the local file system or in a SQL Server content database. The key point is that when you open a SharePoint site in a Web browser, you are actually viewing information from a collection of content pages that are not necessarily located on the local Web server and that are arranged according to a layout defined in a Master Page.
The general rule is that unmodified pages (or uncustomized pages in SharePoint terminology) exist as page templates on the local file system of every SharePoint server, and customized pages are written to the content database so that all SharePoint servers in a Web farm have access to the same set of pages (see Figure 3). It is assumed that uncustomized pages are identical across all servers and sites in the Web farm. However, if you customize a content page or a Master Page in a SharePoint site, perhaps by using Office SharePoint Designer 2007, SharePoint automatically stores the customized page in the content database.
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
In addition to customized pages and other Web site content, SharePoint also stores configuration data in a SQL Server database. SharePoint keeps the configuration data separate from the content because the configuration data is global in nature while the content is specific to each individual Web application and site collection. Accordingly, a Web farm can only have a single configuration database but it can have multiple content databases.
All WSS servers in the Web farm use the same configuration database to share metadata, configuration settings, and information about every single IIS Web site that has been SharePoint- extended in the Web farm. Individual Web applications, on the other hand, can be associated with one or more content databases (though each content database can only be associated with one Web application).
The relationship between IIS Web sites, Web applications, site collections, sites, and content databases can be confusing. In SharePoint terminology, the term Web application refers to a SharePoint-extended IIS Web site. A Web application can include multiple site collections, and each site collection again can include a top-level site and sub-level sites that share the same configuration settings.
Among other things, creating multiple site collections enables you to delegate site collection administration to different users and groups. A single site collection cannot span multiple content databases, but a Web application can use multiple content databases for multiple site collections to increase scalability and mitigate the performance impact of a large site that generates a significant amount of database activity on other SharePoint sites. However, it is not a good idea to place every SharePoint site in its own site collection because this form of deployment limits cross-site functionality.
WSS 3.0 does not support content searches across multiple site collections. Such searches require MOSS 2007 or Microsoft Search Server 2008. For example, you can create a Web application and top-level site for http://contoso, and a site collection administrator can then create sub-level sites using the SharePoint user interface, such as http://contoso/info and http://contoso/events. All these sites exist in the same content database because they belong to the same site collection.
As a farm administrator, you can also use a managed path, such as /sites, and then define additional site collections, such as http://contoso/sites/IT and http://contoso/sites/HR, in SharePoint 3.0 Central Administration. These three site collections (http://contoso, http://contoso/sites/IT, and http://contoso/sites/HR) can have different site collection administrators, configuration settings, and content databases, but they are still all accessed through the same IIS Web site (http://contoso) and use the same application pool identity of the Web application.
Of course, there are many more details, but this relationship among IIS, ASP.NET, and SQL Server is especially important to understand to get comfortable with SharePoint. If you are interested in reading more about the SharePoint architecture, I recommend Ted Pattison's MSDN® Magazine article "Discover Significant Developer Improvements in SharePoint Services," available at msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

SharePoint Infrastructure Elements
Now let's translate our brief architecture discussion into a flexible SharePoint infrastructure. As you certainly have noticed, we need Windows Server®, IIS, .NET Framework 3.0 (both for ASP.NET and the Windows® Workflow Foundation), WSS 3.0 or MOSS 2007, and SQL Server. Although you can look forward to IIS 7.0 on Windows Server 2008, we'll use IIS 6.0 on Windows Server 2003 for our purposes because at the time of this writing, it is the most commonly deployed version. We will stay with WSS 3.0 because we require no MOSS 2007-specific features for an initial SharePoint pilot.
For a minimalist approach, you can install WSS 3.0 with all required components on a single computer (as outlined in the WSS 3.0 on a single computer.pdf, available in the companion material for this column), which is good enough for a lab server or a small workgroup environment. However, if you intend to focus on flexibility in your SharePoint infrastructure, you should not start with a standalone deployment in your production environment. For the sake of availability as well as future scalability, it is better to start with a multitier infrastructure and add more servers as needed.
Figure 4 shows the SharePoint infrastructure I recommend if you are looking for a straightforward and flexible system configuration. It includes a Web farm of two SharePoint servers and a separate computer running SQL Server. This configuration eliminates database processing overhead on the Web servers, increases availability, scalability, and facilitates system maintenance. Note that you do need Active Directory® because this is a software requirement of WSS 3.0 in a Web farm deployment. For step-by-step deployment instructions, see the Basic SharePoint Infrastructure.pdf file in the companion material.
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
The domain account that you use to deploy SharePoint in this arrangement requires the permissions of a local administrator on the Web servers. It is also necessary to add this account to the SQL Server roles dbcreator and securityadmin as well as to the database role db_owner for the master database in SQL Server 2005, as shown in the Basic SharePoint Infrastructure.pdf. You can then use the SharePoint Products and Technologies Configuration Wizard during the WSS 3.0 installation to create the necessary configuration database for the Web server farm and a content database for the SharePoint 3.0 Central Administration site. Otherwise, a SQL Server administrator must provision these databases for you and add the WSS system accounts to the db_owner role.
It is important to keep in mind that the user account you use to install SharePoint is not the account SharePoint uses to access the configuration database or the content database for the Central Administration site. Instead, SharePoint uses the system account configured as the identity of the application pool for the SharePoint 3.0 Central Administration site.
The SharePoint Products and Technologies Configuration Wizard will prompt you for the account information. It is a good idea to use a dedicated domain user account for this, such as CONTOSO\WssConfigAdmin. My general practice has been to use individual, dedicated user accounts for any additional Web applications that I create later. Using a separate application pool for each Web application helps to ensure process isolation, and using a different user account for each application pool helps to maintain security isolation. It should be noted though that this is just one approach, and the manageability and potential performance impact that may have should be evaluated against your own environment and business requirements.
Another important system account that a domain administrator should create for you is the search service account. You can use the Central Administration account, but for added security it is better to use a dedicated search account, such as CONTOSO\WssSearch, that has no administrative permissions and cannot modify any content. Write permission to content databases is not necessary because the Search service only crawls content for indexing purposes and maintains the search data in a separate database.
When you create a Web application in a server farm, you can associate that content database with a search server, which implicitly adds the corresponding search service account to the Web application's Full Read policy. Search servers are SharePoint servers running the Windows SharePoint Services Search service. If you followed the step-by-step instructions in the Basic SharePoint Infrastructure.pdf file, you have configured both Web servers as search servers so that you can distribute the load of crawling and indexing multiple content databases. However, it is also possible to configure a dedicated search server in a Web farm, excluded from network load balancing and client connections so that client connections are not affected by crawling activities.

Self-Service Site Management
With a basic SharePoint infrastructure in place, we can delegate the administration of site collections and sites to individual departments and users without decentralizing administrative control over Active Directory, the Web server farm, or the SQL Server databases. As a farm administrator, you collaborate with Active Directory and SQL Server administrators to provision application pool accounts and content databases for your Web applications. Within these Web applications, you then create site collections and designate site collection administrators with the right to create sub-level sites. In this way, site collection administrators within individual departments can manage their SharePoint resources with minimal involvement of the IT department, as illustrated in Figure 5.
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
It is also possible to give users the ability to create site collections under managed paths (such as the /sites path or other managed paths with wildcard inclusions that you create in SharePoint 3.0 Central Administration). If you enable the Self-Service Site Management feature within a Web application, users can create their own site collections and manage site groups and permissions within the SharePoint user interface. Unlike sub-level sites, site collections do not inherit permissions from a parent site.
Self-Service Site Management is not appropriate for every SharePoint environment and is disabled by default. If you enable it, you might end up with a large number of infrequently used site collections in your content databases. However, this feature demonstrates very vividly the flexibility of SharePoint administration, and I recommend you check it out in your pilot deployment. (Additionally, there are options within SharePoint to notify users and/or administrators about inactive sites so they can be removed if necessary.) You must enable Self-Service Site Management for a Web app explicitly, as outlined in the Enabling Self-Service Site Management.pdf file in the companion material.

SharePoint Customizations and Branding
Sharepoint Resources
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services Developer Center
  • Microsoft SharePoint Products and Technologies Team Blog
  • Logical Architecture Components
  • Design Server Farms and Topologies

At this point, it is a natural desire to include the company's logo, name, and corporate colors in the SharePoint user interface. Be aware, however that you are about to take your SharePoint project to the ASP.NET developer level. At a minimum, you need a development system, such as a standalone WSS 3.0 server with Microsoft Office SharePoint Designer 2007 (see the SharePoint Designer Installation.pdf in the companion material) so that you can create and test your customizations without affecting the production environment. Also, you should visit the Windows SharePoint Services Developer Center at msdn2.microsoft.com/sharepoint to learn more about the abundance of customization options that SharePoint offers.
While SharePoint development is outside the scope of this column, let me point out a few aspects you should take into consideration. SharePoint stores customized pages in the content database of the corresponding site collection. In other words, any customizations that you apply to site pages, application pages, Master Pages, style sheets, and so forth, in a SharePoint site only apply at the site collection or site level. This is great for individual site collection administrators who want to adjust the look and feel of their sites using SharePoint Designer 2007, but it's not so great for the farm administrator who wants to enforce corporate identity across all Web applications, site collections, and sites in a Web farm.
You can create custom site themes or custom site definitions based on a copy of a standard SharePoint theme or site definition. You can also create custom Master Pages and add these to the Master Page Gallery. However, none of these options enforces global branding if Self-Service Site Management is enabled because a user with the permissions to create site collections or sites can still select a standard site template that does not show the corporate identity.
Global branding requires you to replace the default SharePoint components so that your custom components are used instead. Developers go to great lengths to accomplish this without modifying the original files. One approach is to change the configuration of the virtual directories in IIS Manager and point them to new folders with customized files. Another method is to implement a custom HTTP module or ISAPI filter that rewrites URLs to redirect requests for specific default pages to customized versions.

Conclusion
I've focused on the essentials of establishing a SharePoint infrastructure with WSS 3.0. I did not cover other features, such as workflows, surveys, messaging integration, and antivirus, nor MOSS 2007-specific functionality such as portals, site directories, and business data catalogs. The customizations for site administration and company branding also only touched at the possibilities within SharePoint. You can perform further customizations with WSS 3.0 by programming custom applications in Visual Studio®.
The infrastructure is robust enough to handle future growth if you add more Web servers or database servers. And with the pilot rollout of a few customizations, users can create individual sites and generally become familiar with SharePoint. In this way, you establish the core components of user adoption as well as hardware and software, which are flexible enough to accommodate change and serve as the foundation for a full-fledged production rollout.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation.


 Windows PowerShell: Automating Directory Management
Windows PowerShell
Automating Directory Management
Don Jones

One of the most unfortunate things about the first version of Windows PowerShell is its timing. The Windows PowerShell team was under a certain amount of pressure to ship the product (there was this little product called Exchange Server 2007 launching and that was depending on Windows PowerShell) and the Active
Directory team had a lot on its hands at the time (another little product called Windows Server® 2008 was also in the works). So Windows PowerShell shipped with less than superior Active Directory® management capabilities.
To be clear, Windows PowerShell® doesn't completely lack Active Directory features. In fact, the Windows PowerShell team made some heroic last-hour efforts to put in decent support for Active Directory Services Interface (ADSI), a scripting-friendly technology already well-known to users of VBScript.

The ADSI Way
ADSI is similar to Windows® Management Instrumentation (WMI) in the way it works. You issue a query, which is written using a special syntax. The query is transmitted to a remote computer (such as a domain controller) and then executed. The result of the query is an Active Directory object or collection of objects (such as a user or a group), and you get a reference to that object that you can then work with. You can modify properties of the object or execute methods to save your changes, create new objects, delete objects, and so forth. For example, to create a user, you query the organizational unit (OU) or container that you want the user to live in. The object you get back has a Create method, which can be used to create the user.
On a very basic level, using ADSI in Windows PowerShell appears simple and straightforward. For example, this command will retrieve a user and display his Company attribute:
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
You can pipe the user to Get-Member to see its properties and methods. Sadly, Windows PowerShell 1.0 doesn't really do a good job of implementing these directory objects. As Figure 1 shows, the shell doesn't enumerate the object's directory attributes, nor does it display the methods of the object—such as the Get method I used.
Figure 1 Piping the user to Get-Member to see its properties
Figure 1 Piping the user to Get-Member to see its properties
This support is somewhat improved in the Community Technology Preview (CTP) of Windows PowerShell 2.0, but only to a certain extent. The bottom line is that the underlying Microsoft® .NET Framework doesn't make it easy for administrators to see what they want—the Framework was, after all, originally designed for developers. The other problem is that the Windows PowerShell team can only do so much, and great Active Directory support needs to come from the folks who know directories best. In other words, the Active Directory team. I'm sure that will happen in time—after all, Windows PowerShell is still young. But what are you supposed to do in the meantime?
You may recall that I discussed using the ADSI technologies included in Windows PowerShell in the June 2007 installment of this column (technetmagazine.com/issues/2007/06/PowerShell). I suggest you go back and read that column if you want more details on that "native" technique. For this installment, I want to show you some other approaches.

A Rich Ecosystem
Windows PowerShell architect Jeffrey Snover often refers to the rich ecosystem surrounding Windows PowerShell. This simply means that the team did a great job of making sure anyone, not just programmers within Microsoft, can extend the capabilities of Windows PowerShell. A number of companies are already doing so by creating native Windows PowerShell cmdlets that allow you to administer their products from the command line—VMWare, IBM, Citrix, and Foundry are just a few of the major companies so far.
One of my favorite examples of this rich ecosystem is from Quest software. The company offers a set of free, noncommercial cmdlets designed for Active Directory management. You can download them from quest.com/powershell. They also offer PowerGUI (powergui.org), a free, noncommercial graphical UI that sits on top of Windows PowerShell for folks who aren't quite ready to commit to the full command-line experience yet. PowerGUI can make it easier to learn how to use the Active Directory management cmdlets. And believe me—you'll want to use them. These cmdlets give you an ease and power for Active Directory management that is simply unprecedented. (In case you want to read more about PowerGUI, it was actually included in the January 2008 installment of the Toolbox column, which you can find at technetmagazine.com/issues/2008/01/Toolbox.)

The Windows PowerShell Way
Anything involving cmdlets is truly the Windows PowerShell way of doing things. You don't have to deal with traditional-looking scripts or fancy programming objects. Here is my favorite one-liner in the universe. It's a single command line that imports a CSV file and uses the information in it to create dozens or even hundreds of new Active Directory users:
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
This is indeed a long command, but it's amazingly powerful. It starts with Import-CSV, a native shell cmdlet that simply reads a CSV file and returns objects. Each line in the CSV file is a single object, and the columns of the CSV file become properties of the object. In my Provision1.csv file, the column names are things like "Logon Name" and "First Name"—this is interesting because the column names don't map directly to Active Directory user attributes. I find that it's common for files like this to use more familiar-sounding column names instead of names that are specific to Active Directory. After all, you might be receiving this file from someone in your company's personnel department, and they're unlikely to know that the Last Name is really the sn attribute in Active Directory.
Once all of the data in the CSV file has been imported and also turned into objects, those objects are piped to the ForEach-Object cmdlet, which executes a block of code—inside the curly braces in my one-liner—for each object. That is, for each line in the CSV file, this script will execute once. Within the script, the special $_ variable is a reference to the current object—or, the current line of the CSV file.
You can see that for each object, I'm executing the New-QADUser cmdlet. That's one of the dozen or so cmdlets in the Quest add-in. The name QADUser is worth noting. The Q, as you might have guessed, stands for Quest. This naming convention is designed to avoid a conflict with the eventual New-ADUser cmdlet that the Microsoft Active Directory team will likely produce in the future. That way, if both cmdlets are loaded into the shell at the same time, both you and the shell will be able to tell them apart more easily.
The remainder of the one-liner consists of parameters for the New-QADUser cmdlet. It starts by specifying the organizationalUnit, which is where you want all of the new users to be created. Next is the name attribute, which I've set to be the contents of the First Name column, a period, and then the contents of the Last Name column.
One last interesting fact here: The city parameter will actually change the l attribute (or Locality-Name) in Active Directory. The cmdlet also accepts a parameter named l, which does the same thing. For the most part, parameters that refer to Active Directory attributes can use either the attribute name or the text label from the Active Directory Users & Computers tool.

The Other Windows PowerShell Way
Active Directory is a hierarchical store, and one of the strengths of Windows PowerShell is its ability to expose any hierarchical store as a disk drive, allowing you to use a familiar set of commands like Dir, Del, Ren, Copy, and so forth to manage a variety of stores. Unfortunately, Windows PowerShell 1.0 didn't ship with a PSDrive Provider for Active Directory, meaning the shell has no way to expose Active Directory itself as a drive.
Fortunately, that rich ecosystem comes back into play with the PowerShell Community Extensions. This is a free, open-source add-in available from codeplex.com/powershellcx. Once you have it installed, the PowerShell Community Extensions let you simply direct the shell to your domain name to begin managing the directory as if it were a drive:
CD COMPANY:
CD SINGERS
DIR
These commands will change to the COMPANY domain, change to the Singers OU, and then display a list of objects, as shown in Figure 2. From there I can use commands like Del to delete a user, Md to create a new OU, and so forth. There are a few catches in the Community Extensions PSDrive Provider. These essentially have to do with functionality that you might expect to be implemented, but isn't available because things don't map to the way Active Directory itself works. And you do have to be exceedingly careful: changing to the root of your domain and running del * -recurse will, in fact, delete every object in the domain, provided you have permission. It won't even ask "are you sure," by default. Yes, the command line is powerful, and with that power comes a risk for someone who isn't skilled and careful.
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory

Start Using the Shell Today
Students in my classes always ask what they can do with Windows PowerShell today. After all, not every Microsoft product has been redesigned to use Windows PowerShell, and offhand you might think that Windows PowerShell is still waiting around for things to get really exciting.
The fact is, things are already exciting. Even though Microsoft hasn't yet instrumented Active Directory for command-line management, others have taken a stab at it and done quite well. You can use Windows PowerShell to perform many administrative tasks, including automating some of the most time-consuming and burdensome tasks, such as creating batches of new users. The trick is to discover some of the things that the community is doing to make Windows PowerShell more useful now. (You might want to explore PowerShellCommunity.org, a site co-sponsored by Microsoft that I help administer.) With the right tools loaded into Windows PowerShell, you can begin scripting some of the most time-consuming administrative tasks that you don't want to be doing, and start to become a more effective and efficient administrator.

Don Jones is the co-author of Windows PowerShell: TFM, 2nd Edition, author of VBScript, WMI, and ADSI Unleashed, and director of PowerShellCommunity.org.


 Hey, Scripting Guy!: Raising Eyebrows on Regular Expressions
Hey, Scripting Guy!
Raising Eyebrows on Regular Expressions
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2008_05.exe (150KB)

Back in November 2007 , the Scripting Guys got to spend a day in Paris while en route to the Tech•Ed IT Forum conference held in Barcelona. During our one-day layover, we took the opportunity to visit the Louvre, the city's world-famous museum of art.
So how did the Scripting Guys find the Louvre? That's easy: we walked up to Notre Dame and then took a left.
Oh, you mean did we enjoy the Louvre? For the most part, yes. The only problem we had is that the Louvre, like many museums, operates on a look-but-don't-touch basis. Everyone knows that the Mona Lisa would look way better if she had eyebrows, but, for some reason, the people who run the Louvre get very upset if you try to fix any of the paintings.
Note: actually, both of the Scripting Guys liked the Mona Lisa. That was a pleasant surprise, too; after all the hype and buildup we were afraid it might be just another painting. But it wasn't; it was very cool. (Although it could use a few eyebrows.) Interestingly, however, we were both disappointed in the equally hyped Venus de Milo. Neither of us found the workmanship to be all that spectacular, and the Scripting Guy who writes this column was perplexed by the whole idea of the Venus de Milo. A statue of a woman who has no arms? How is she supposed to mop the floor or wash the dishes!?!
Note to our female readers (assuming there are any left): obviously that was a typo. What we meant to say was this: a statue of a woman who has no arms? And yet she can still do twice the work of any man, and do the work correctly to boot.
The Scripting Guys apologize for any misunderstanding our original statement might have created.
At any rate, at the moment we set eyes on the great treasures of the Louvre, the two Scripting Guys were struck by an identical thought: where are the restrooms? While searching, the Scripting Guy who writes this column had another thought: the Scripting Guys are hypocritical. After all, we're miffed that the Louvre won't let us fix the Mona Lisa. And yet, we're guilty of a similar sin. In the January 2008 issue of TechNet Magazine, we wrote an article about using regular expressions in a script. That stands as a prime example of look-but-don't-touch: we showed you how to use regular expressions to identify problems in a text file, but we didn't show you how to fix those problems. Zut alors!
Note: so if the Scripting Guys went to the Louvre in November 2007, how could the Scripting Guy who writes this column have had a sudden thought regarding an article that didn't appear in TechNet Magazine until January 2008? Wow; that is a conundrum, isn't it? Must have something to do with time zone differences between Redmond and Paris.
Fortunately, though, and unlike the folks who run the Louvre, the Scripting Guys are willing to admit when they've made a mistake. We were wrong to show you how to only search for things using regular expressions; we should have also shown you how to replace things using regular expressions. In fact, we should have shown you a script like the one in Figure 1.
Figure 1 Search and replace (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
Now, to tell you the truth, this is actually a pretty mundane use of regular expressions: all we're doing here is replacing all instances of the string value Mona Lisa with La Gioconda (Italian for "Now where did I put those eyebrows?"). Admittedly, we could have performed this replacement much more easily just by using the VBScript Replace function. But, fear not: we'll use this simple little script to explain how to perform search-and-replace operations using regular expressions, and then once that's done, we'll show you a few of the fancier things you can do with these expressions.
As you can see, there's really not much to this script. We begin by creating an instance of the VBScript.RegExp object; needless to say, that's the object that enables us to use regular expressions within a VBScript script. After creating the object, we then assign values to three of the object's properties:
Global By setting this property to True, we're telling the script to search for (and replace) every instance of Mona Lisa it finds in the target text. If the Global property were False (the default value), the script would search for and replace only the first instance of Mona Lisa.
IgnoreCase Setting IgnoreCase to True tells the script that we want to perform a case-insensitive search; in other words, we want to treat mona lisa and Mona Lisa as being identical. By default, VBScript does a case-sensitive search, meaning that—thanks to the uppercase and lowercase letters—mona lisa and Mona Lisa are seen as being completely different values.
Pattern The Pattern property holds the value that we're looking for. In this case, we're just looking for a simple string value: Mona Lisa.
Next, we assign the text we want to search to a variable named strSearchString:
strSearchString = "The Mona Lisa is in the Louvre."
Then we call the regular expression method Replace, passing this method two parameters: the target text we want to search (the variable strSearchString) and the replacement text (La Gioconda). That's what we're doing here:
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
And that's it. The modified text gets stored in the variable strNewString. If we now echo back the value of strNewString, we should get the following:
The La Gioconda is in the Louvre.
The grammar might be a little questionable, but you get the general idea.
As we noted earlier, that's all well and good, but it's definitely overkill; we could have accomplished the exact same thing by using these lines of code (in fact, we could even do it all in one line if we wanted to):
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
In other words, let's see if we can do something interesting with regular expressions that we can't do with the Replace function in VBScript.
No one has any ideas, huh? Well, here's one. Often we Scripting Guys end up having to copy text from one type of document to another. Sometimes that works pretty well; sometimes it doesn't. When it doesn't work, we often get odd problems with word spacing, problems that result in text that looks like the text below:
Myer Ken, Vice President, Sales and Services
Yikes; just look at all those extraneous blank spaces! And, in this case, the Replace function is of limited use. Why? Well, we have a seemingly random number of extraneous blank spaces: there might be 7 blank spaces between words, there might be 2 blank spaces between words, or there might be 6 blank spaces between words. That makes it difficult to fix the problem using Replace. For example, if we try searching for 2 consecutive blank spaces (replacing those 2 with a single blank space) we end up with this:
Myer Ken, Vice President, Sales and  Services
That's better, but not by much. There is a way we could do this, but it requires us to search for an arbitrary number of blank spaces (say, 39); make the replacement; subtract 1 from the starting number; search for 38 blank spaces; make the replacement; and so forth, and so on. Alternatively, we could use this far simpler (and far more foolproof) regular expressions script:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
The key to this script (and the key to most regular expression scripts) is the Pattern:
objRegEx.Pattern = " {2,}"
What we're doing here is looking for 2 (or more) consecutive blank spaces. How do we know that this Pattern looks for 2 (or more) blank spaces? Well, inside our double quote marks we have a single blank space followed by this construction: {2,}. In regular expressions syntax, that says look for at least 2 consecutive instances of the preceding character (in this case, a blank space). And what if there are 3 or 4 or 937 consecutive blanks spaces? That's fine; you would grab all of those as well. (If, for some reason, we wanted to grab at least 2 blank spaces but no more than 8, then we'd use the syntax {2,8}, with the 8 specifying the maximum number of matches.)
In other words, any time we find 2 or more blank spaces, one right after another, we're going to grab all those consecutive spaces and replace them with a single blank space. What will that do to our original string value, the one with all the extraneous blank spaces? This:
Myer Ken, Vice President, Sales and Services
See? The Scripting Guys really can make things better. Now if only the folks at the Louvre would give us a crack at the Mona Lisa.
Here's an interesting—and not uncommon—scenario. Suppose your company has a telephone directory, and all the phone numbers are formatted like this:
555-123-4567
Now, however, your boss has decided that all the phone numbers should be formatted to look like this:
(555) 123-4567
How in the world are you supposed to reformat those phone numbers? Well, if we might be so bold, may we suggest that you use a script similar to this one:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
What we're doing here is searching for 3 digits (\d{3}) followed by a dash, followed by 3 more digits and a dash, followed by 4 digits. In other words, we're searching for the following, where each X represents a number from 0 to 9:
XXX-XXX-XXXX
Note: so how did we know that \d{3} would tell the script to look for three numbers back-to-back-to-back? Well, as best we can recall, we read it somewhere. In fact, it had to be either the shocking final chapter of The Da Vinci Code or the VBScript Language Reference on MSDN® online (see go.microsoft.com/fwlink/?LinkID=111387).
Now, it's pretty cool that we can search for an arbitrary phone number using regular expressions. We still have a major problem here, however. After all, we can't replace that arbitrary phone number with an equally arbitrary phone number; instead, we have to use the exact same phone number, just formatted a little bit differently. How in the world do we do that?
Why, by using the following replacement text:
"($1) $2-$3"
$1, $2, and $3 are examples of a regular expression "back reference." A back reference is simply a portion of the found text that can be saved and then reused. In this particular script, we're looking for three "sub-matches":
  • A set of 3 digits
  • A set of 3 more digits
  • A set of 4 digits
Each of these sub-matches is automatically assigned a back reference: the first sub-match is $1; the second is $2; and so on, all the way through $9. In other words, in this script the three parts of our phone number are automatically assigned the back references shown in Figure 2.
Figure 2 Phone number back references (Close Figure 2)

Phone Number Portion | Back Reference
555 | $1
123 | $2
4567 | $3
In our replacement string, we use these back references to ensure that the correct phone number is reused. Our replacement text simply says this: take the first back reference ($1) and enclose it in parentheses. Leave a space, then insert the second back reference ($2) followed by a dash. Finally, tack on the third back reference ($3).
What will all that give us? That will give us a phone number that looks like this:
(555) 123-4567
Not bad, not bad at all.
Here's a variation on the phone number script. Suppose your organization has installed a brand new phone system and, as part of the changeover, all your phone numbers will now have the same prefix; where numbers might have originally started with 666, 777, or 888 all numbers will now start with 333. Can we reformat the phone numbers and change the phone number prefix, all at the same time? Why, of course we can:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
See what we did here? We simply removed the old prefix (back reference $2) in our replacement text; in its place we substituted the hardcoded, and now standard, prefix value 333. What will the phone number 555-123-4567 look like after we run this modified script? It should look a whole heck of a lot like this:
(555) 333-4567
Here's another common use for back referencing. Suppose we have a string value that looks like this:
Myer, Ken
Is there any way to flip that value around and display the name like this:
Ken Myer
Well, we'd look pretty silly if there wasn't, wouldn't we? Here's a script that does that very thing:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
In this particular script, we're looking for a word—(\S+)—followed by a comma, followed by a blank space, followed by another word. (In this case, we're using \S+ to represent a "word.") The construction \S+ means any consecutive set of non-white-space characters. In other words, we could have a letter, a number, a symbol; in fact, we could have just about anything other than a space, a tab, or a carriage return-linefeed. As you can see, we expect to find two sub-matches here: one representing the last name ($1) and one representing the first name ($2). Because of that, we can display the user name as FirstName LastName by using this syntax:
"$2 $1"
Where's the comma? Well, obviously we didn't need it, so we simply threw it out.
Note: that's funny; for some reason we started thinking about the Scripting Editor, too. Hmmm ...
Let's show you one more before we call it a day. (Well, OK, before we call it a month.) This is not 100 percent foolproof; after all, we don't want an introductory article like this one to get too complicated. (And regular expressions do have the potential to get extremely complicated.) Nevertheless, here's a script that—in most cases—will remove the leading zeroes from a value like 0000.34500044:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
As usual, the only reason this works is because of the pattern: "\b0{1,}\." We start off looking for a word boundary (\b); that ensures that we don't remove the zeroes in a value like 100.546. We then look for one or more zeroes—0{1,}—followed by a decimal point (\.). If the pattern is found, we replace those zeroes (and the decimal point) with a single decimal point ".". If all goes according to plan, that's going to transform our string into this:
The final value was .34500044.
That's about all the time we have for this month. Before we go, we might note that, since before the paint even dried, the Mona Lisa has been the subject of considerable controversy. Who is the mysterious woman? Why is she smiling like that? Why doesn't she have eyebrows? Several art historians have suggested that Mona Lisa isn't even a woman, that the painting is—instead—a self-portrait of Leonardo da Vinci. (If that's true, he could really stand to find a new tailor.) Meanwhile, the Unarius Educational Foundation has gone a step further, claiming that the painting is actually that of Leonardo's "twin soul" in the "higher world," and that this twin soul guided Leonardo's hand. By remarkable coincidence, that's exactly how this month's Hey, Scripting Guy! was written.
Which means that all complaints should be addressed to the-twin-soul-of-the-scripting-guy-who-writes-that-column@the-other-microsoft.com. Thank you.

Dr. Scripto's Scripting Perplexer
The monthly challenge that tests not only your puzzle-solving skills, but also your scripting skills.

May 2008: Script-doku
This month, we're playing Sudoku, but with a bit of a twist. Instead of the numbers 1 through 9 in the grid, we have the letters and symbols that make up a Windows PowerShell™ cmdlet. In the final solution, one of the rows read across will spell out the cmdlet name.
Note: if you don't already know how to play Sudoku, there are probably several thousand Web sites on the Internet to get the instructions, so we're not going to repeat them here, sorry.

Dr. Scripto's Scripting Perplexer
Answer: Script-doku, May 2008

The Microsoft Scripting Guys work for—well, are employed by—Microsoft. When not playing/coaching/watching baseball (and various other activities) they run the TechNet Script Center. Check it out at www.scriptingguys.com.


 Security Watch: Principles of Quantum Security
Security Watch
Principles of Quantum Security
Jesper M. Johansson

It can be a lot of fun to toss something unexpected, but valuable, into a conversation. For a while now, I've been using the Heisenberg Uncertainty Principle to explain security concepts. (Those who have heard my unicorn story know that I like to bring in fundamental theories from other disciplines to make a point.) Strange
as it may seem, there do exist information security corollaries to some of the fundamental concepts in other branches of science.
The Heisenberg Uncertainty Principle, which comes from quantum physics, is based on the equation shown in Figure 1. The principle itself states that the position of a particle (p) and the momentum of a particle (x) are related such that if you increase your precision of measuring the position, you decrease the precision of measuring the momentum. The boundary on the precision of the two factors is a small fixed multiple of Planck's constant. In more comprehensible language, this principle says that you cannot observe with full precision certain facts about a single particle at the same time.
Figure 1 Heisenberg Uncertainty Principle
Figure 1 Heisenberg Uncertainty Principle
This directly relates to predicting uncertainty bands, which essentially allow you to predict how uncertain you are about the state of a couple of facts about a particle. While you cannot (yet) predict the bands, the fact that you cannot predict with certainty how two variables on a single computer network will affect the security of that network is important.
You also have to make trade-offs. While you may not be bounded by Planck's constant in information security, you are bounded nonetheless. The most salient trade-off you have to make is between security and usability or usefulness. If you ignore availability for a moment—and, quite frankly, I believe security personnel should not be responsible for availability other than in the face of denial of service attacks—the easiest way to secure something is to turn it off. That way, it can no longer be hacked. Usefulness takes a nose dive, though.
Likewise, while it costs significantly more, you can prevent far more confidential data leakage by implementing an expensive data loss prevention product than you can by sending an e-mail to all employees once a year reminding them that instant messaging applications are not for business use. But is your organization willing to pay for the data loss prevention tool? Now you can see where quantum physics is more relevant to security than you may have thought.

Schrödinger's Cat
A related, but different, quantum physics concept is explained in the parable of Schrödinger's Cat. The story goes that Erwin Schrödinger, a prominent 20th century physicist, had a long-running argument with Albert Einstein (another prominent 20th century physicist you may have heard of) about the concept of superposition. Schrödinger found the areas of quantum mechanics that had elements existing in a superposition of two states quite absurd.
To make his point, Schrödinger posed a thought experiment in which a cat was stored in a hermetically sealed box. The other item in the box was a container of poison, the release of which was controlled by means of some (imaginary) subatomic radioactive particle. If the radioactive particle decayed, the poison would be released, and the cat would die.
The subatomic particle, being subject to the laws of quantum mechanics, exists in a superposition of states. The decidedly atomic cat, its state being entirely dependent on the state of the subatomic particle, therefore also exists in this superposition of states. Only by actually observing the state of the cat do we finally put it into a specific state of aliveness or deadness.
Schrödinger, of course, intended for this to illustrate how absurd some of the laws of quantum mechanics are when applied to atomic systems. Nevertheless, his example is often credited with giving rise to what in laymen's terms is called the "observer effect." The observer effect, while it does not apply to the subatomic systems of interest in quantum mechanics, is interesting to us as security professionals. Simply put, it states that by observing something, you change it.
The Observer Effect
To explain it a bit more, consider the example of a cup of tea. To find out how hot the tea is, you put a thermometer in the cup. Let's say the tea was 80 degrees Celsius when you put the thermometer in, and the thermometer itself was 22 degrees (room temperature). As soon as you put the thermometer in the tea, it starts absorbing heat from the tea, and the tea gives up some of its heat to heat up the thermometer. Eventually, the thermometer and the tea will have the same temperature. However, that temperature will not be 80 degrees, nor will it be 22 degrees—it will be something in between. Thus, by measuring the temperature of the tea, you changed it.
The observer effect is also relevant to infosec. Every time you do something to mitigate a security issue, you potentially modify your security posture since you modify the system. I'll call this the Security Posture Fluidity Effect (SPFE) for lack of a better term.
One of the simpler examples is in the case of service account dependencies. In Chapter 8 of Protect Your Windows Network (protectyourwindowsnetwork.com), I discuss installing an Intrusion Detection Service (IDS) on your systems to detect attacks. However, the IDS logs to a central system and requires highly privileged access to the monitored systems. Most of the time that means the service runs in a highly privileged service account.
If any one of those systems gets compromised, the attacker can get access to the service account credentials and access all the other systems, in addition to disabling the IDS itself. This is a perfect example of the SPFE. By installing something to provide security in your environment, you create a new potential security issue.
Other examples of the SPFE abound. Steve Riley's description of why 802.1x has certain problems on wired networks (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx) is another great example. Obviously, using host-based firewalls is very desirable in many environments. However, if used in conjunction with 802.1x, the combination makes a particular attack possible where it was not possible before. Again, a security technology modifies the security posture of the environment and enables an attack that was not otherwise possible.
None of this means that these measures are inherently useless and should be avoided. What it means is that you need to consider the implications of what you do in terms of security across the board. When you do risk management, you have to consider what your actions and preventions really mean for risk. When mitigating a problem, you cannot simply stop after you have implemented counter measures. In a very real sense, security is a process. You need to use the defense-in-depth strategy, but consider how the defenses will change your security posture and how you will meet the new threats that emerge due to your strategy.

A Maturing Hardening Strategy
I have been working on hardening guidance for more than 10 years. Looking back at the first few guides I worked on, I find they were nothing more than lists of settings that my colleagues and I thought you should turn on. Back then, the general strategy behind security was naïve—basically, if something was intended to provide security, the logic was that it must be turned on. The fact that there may have been legitimate reasons for it to be turned off in the first place did not occupy much though.
Eventually, I learned that to do hardening effectively, you have to put a lot of thought into the hardening and consider the threats that the system is subject to. This revelation lead to the list of scenarios that you see in the Windows 2000 Security Hardening Guide (go.microsoft.com/fwlink/?LinkID=22380). The natural progression from there was to split the guidance into different threat levels, which is what you see in the Windows Server 2003 Security Guide (go.microsoft.com/fwlink/?linkid=14846).
All that time, I was nagged by the fact that it was still possible to break into a system even with all the guidance turned on and in place. This was because either there were missing patches, some operational practice let me in, or some insecure third-party software was installed.
It turns out that the hardening in those two guides did not do much to help the aggregate security posture. It all came down to just a few key things. In fact, the most secure system I ever built (msdn2.microsoft.com/library/aa302370) employed only four or five of the tweaks in those security guides, and none of them actually stopped any of the attacks it was subjected to. Unfortunately, people just want a big blue "Secure Me Now" button that will harden systems automatically, but security is more complicated than that.

How to Approach Risk
To be protected (as opposed to the finite state of secure), you must take a reasonable approach to risk. You must understand what risks you are facing, decide which you want to mitigate, and then you must understand how to mitigate them, and that is seldom done by simply throwing switches.
Generally, these security switches are designed for specific scenarios and don't necessarily create the best configuration for your scenario. Instead, they create a good baseline starting point and are available mainly because much of the marketplace demands these quick hardening tweaks. Most are already on by default in modern software; and the ones that are not are likely to have significant side effects.
Moreover, throwing bunches of switches may produce an unsupportable and unstable system that may not perform the tasks you need it to perform—all to mitigate threats you have not enumerated yet. The SPFE, and quantum physics, tells us to reanalyze after we secure things, but too many organizations fail to do this. In fact, they fail to analyze the threats in the first place. If you start by actually analyzing the threats, you will find that the things that really make a difference are not anonymous restrictions on listing account names and wholesale access control list changes.
Rather, what really makes a difference is determining whether your system should be providing a particular service, if so to whom, and then enforcing that policy. What makes a difference is ensuring that only those systems and users who absolutely need to communicate with you are allowed to do so. What makes a difference is ensuring that all applications and users run with the least possible privilege. In short, what makes a difference is taking a sensible approach to security and doing the difficult analysis so that you enable each system to take responsibility for its own security.
This is why the current approach to security now employs such tools as Server and Domain Isolation (microsoft.com/sdisolation), the Security Configuration Wizard (SCW) in Windows Server® products, and the Server Manager tools for managing roles in Windows Server 2008. These tools walk you through the process of understanding the scenarios you have to support and then help you lock down your systems appropriately. Granted, these tools don't offer the panacea everyone wants, but they produce a supportable configuration that actually performs the tasks for which you purchased the software.

Apply Security where It's Needed
What all this means is that you can't rely on other entities or simple tweaks for security. Each asset must be capable of defending itself because concepts such as "perimeter" and "internal network" are meaningless today.
The vast majority of organizational networks are at best semi-hostile. You need to understand that and take the appropriate steps, without relying solely on knee-jerk hardening guidance. To start with, you must understand your needs. And you should look for guidance from others who also understand your needs.
A guest on a webcast recently recommended that small-business users go to the Department of Homeland Security site and download a hardening guide for Internet Explorer®. Why should you expect a government agency that is charged with protecting the military and national security establishment to provide sensible guidance on how to secure a Web browser in a small business? This is a perfect example of some of the poor logic still prevalent in the field of computer security. The assumption is that since the guidance was issued by a three-letter government agency, the results must therefore be highly secure.
The choice is usually presented as a binary decision: you can either have "high security" or "low security." A better way to present this choice is between "high security" or "appropriate security." Security isn't one-size fits all.
In fact, high security is not for everyone—and it typically is not for most! It is not an end goal toward which you should strive. It is a specialized configuration for systems where people will die if the system is compromised. If that fits your risk profile and threat model, then use high security.
If that is not your risk profile and threat model, then you should use something more appropriate. More than likely, any of the tweaks you can configure are already appropriately set to the level of a moderate risk profile by default. This default state, used in most Microsoft products today, provides a reasonable trade-off between security and usability, usefulness, and performance. As far as hardening goes, it is typically done for you.
Now you need to consider other security steps. A good place to start would be the TechNet Security Center (microsoft.com/technet/security) and, of course, books such as the Windows Server 2008 Security Resource Kit.

It's All Risk Management
By now you have probably realized where I am going with this: risk management. The key message in the Heisenberg Uncertainty principle is that you have trade-offs. That part of the principle is not rocket science.
The message from the Schrödinger's Cat story, however, is something that most people fail to take into account. Not only is it important for you to analyze all sides of the issue and make a decision on the trade-offs, you also have to consider the changes introduced by your solutions. A sound risk management strategy considers how those changes affect the system and whether those changes were implemented as part of a risk mitigation strategy or for any other reason.

Annualized Loss Expectancy
The common way to quantify risk, and the method you learn in many security certification courses, is the Annualized Loss Expectancy (ALE) equation, shown in Figure 2. The standard ALE is straightforward. You determine the probability of an incident and the cost of each occurrence and then multiply the two values. This gives you the amount you should expect to pay for security incidents per year. If the cost of the risk is high enough, you implement the mitigation.
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
The problem with this is that the standard ALE fails to do justice to the cost of the mitigation. Not only does the mitigation have a cost in and of itself, but many mitigations also have side effects, which have a cost associated with them as well.
Consider one of the most standard security tweaks: account lockout. Many organizations deploy account lockout, ostensibly to prevent attackers from guessing passwords. You can mathematically calculate the probability that an attacker will guess any single password. If you are creative, you can also figure an average cost of the breach resulting from an attacker successfully guessing a password. Based on those two numbers, many organizations have decided that the ALE is unacceptable and therefore implemented account lockout.
However, this particular mitigation has a cost that you may not be taking into account. There is the cost of implementing the mitigation itself, of course, though this is fairly minimal. To be accurate, the calculation should also include the costs of side effects resulting from the mitigation.
First, there is a cost associated with the help desk unlocking accounts for users. If an account is locked out only for a small period of time, say 15 minutes, there is still a cost of lost productivity in that time period. This factor is counted as the cost of each incident, multiplied by the likelihood of that incident occurring in the given time period. In this case, you would multiply the cost by the expected number of lockout events—a number that your logs may already be able to provide.
You also have to take into consideration the user aggravation factor. Anecdotal evidence indicates that users will use less-complicated passwords if they are subject to account lockout because those are less likely to be mistyped. Therefore, the probability of the incident we wished to avoid does not entirely go to zero after implementing the mitigation.
Finally, there may be vulnerabilities introduced by the mitigation that were not present in the system prior to the introduction of the mitigation. In the case of account lockout, an attacker can use that feature to disable all accounts in the network simply by repeatedly guessing their passwords incorrectly. There is a probability of that occurring as well, along with an associated cost of each incident.
Taking all of these factors into account, it is clear that you must modify your loss expectancy equation. First, you must modify the probability of the incident. This incident should now be less likely to occur than it was before, although the probability, as you saw above, may not have gone entirely to zero. The cost of each incident may also have changed. To that product you need to add the cost of the mitigation itself. That cost is composed of the implementation cost plus the sum of the annualized cost of all the side effects. Each of those annualized costs is the product of the probability of the side effect occurring and the cost of each incident of that side effect. Simplifying the equation presentation a bit, you now have the more accurate risk analysis equation that is in Figure 3.
The improved equation in Figure 3 offers a much more accurate way to analyze the risk of a particular issue. Many organizations have already analyzed their risks in this way. But too many still have a simplified view of risk that does not adequately point out the need to analyze the impact of mitigations. By using the modified ALE equation, you are placing that need front and center.
Figure 3 Considering the additional costs of mitigation
Figure 3 Considering the additional costs of mitigation

What It All Means
If you only do one thing after reading this article, it should be to question the conventional wisdom behind security strategies. Far too much of what we do in the field of information security is based on a flat stereotypical view of the world. And many of the assumptions are now outdated.
Attacks have changed. The attackers are now professionals, in it for the money, for national supremacy, and for ideology. You cannot afford to waste time and money on security tweaks that don't improve security. That also means that you must take a much more sophisticated approach to risk management.
First, it is important that you realize that everything you do has a trade-off. You cannot know everything with perfect certainty.
Second, you must understand that you operate in an interdependent system. By introducing security changes into that system, you modify the system itself, which means you must then reanalyze the system.
Preferably, this should be done prior to actually implementing those changes because far too often the changes have such a tremendous impact on the system that they do more harm than good. By using better analysis tools that remind you to analyze those changes, you will be much less likely to forget about them.
Finally, do not ever forget the human factor. Everything you do in information security is to enable the business, and the users within the organization, to operate as safely as possible.
In a recent presentation, I pointed out that there is not a single user today that bought his computer so he can run an antivirus program. Security is your main objective, but it's not the company's main objective. Organizations that merely tolerate security because it's in their best interests do so at the moment. Never forget that the information security group is there to serve the business, not the other way around. If you ignore that fact, your users will do anything to get their jobs done, even if it means circumventing security controls that they do not understand or agree with.

Jesper M. Johanssonis a Software Architect working on security software and is a contributing editor to TechNet Magazine. He holds a PhD in Management Information Systems, has more than 20 years experience in security, and is a Microsoft Most Valuable Professional (MVP) in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit.


 The Desktop Files: Leaving the Administrator Behind
The Desktop Files
Leaving the Administrator Behind
Wes Miller

More than three years ago, I began the process of taking my user account on my primary Windows system from local administrator account to local user account. I had worked at Microsoft for more than seven years, always running as a fully privileged administrator. Sure, it was convenient—but that scary lack of security
highlights the amazing luck I had (that so many of us have) that running as an administrator every day isn't more caustic to more systems more often.
I often wish that there was a way to get a good statistic on this, but both my gut and the industry tell me that too many organizations—and too many IT pros themselves—are running as local administrators today. At Winternals, when I switched to running as a user, it was with the premise of learning both how hard it was (as a "prosumer") and to get some understanding of how our product, Winternals Protection Manager, could help in an average organization. Given that most organizations were, and still are, running with a good percentage of users as administrators, our goal was to enable administrators to run as users, but to make the transition—or at least the pain points—as minimal as possible. Regardless of the technology you use, it isn't easy to move your organization from one where users are administrators to one where they are users, but it is the single most effective way to reduce the attack surface within your organization. Think of it as an intra-system firewall, because that's really what it is.

How Did We Get Here?
My Challenge to You: Feel the Pain
If you haven't yet begun thinking about moving your administrators to users, you should. And I'd encourage you to start by experimenting with it yourself. Not on a secondary machine—that's cheating. Try it on your primary system, the one you use every day. I'd also encourage you to even try it without using User Account Control (UAC) if you are running Windows Vista®. When you begin evangelizing an effort within your organization to change something, it's a good idea to be a practitioner of it before you preach. I think you'll find that running as non-admin isn't really all that difficult—and that with the added security of doing so, you'll really change your organization's attack surface.

That most users act as administrators is rooted in Windows® history. With the first versions of Windows, before Windows NT® 3.1, every interactive user was as empowered as the next—functionally, there was no security. In the home, this wasn't terrible; it meant that all software installed the same way. The assumption was that the user owned the computer and that all software was installed for all users of that computer.
When Windows NT first appeared, it certainly didn't immediately own the enterprise (let alone the consumer) market. And because of the Win32® compatibility between 32-bit Windows and Windows NT, most application vendors didn't rebuild their applications just for the sake of the security infrastructure of Windows NT. In fact, it really wasn't until Windows 2000 that many consumer-oriented independent software vendor (ISVs) started paying attention to Windows NT. It was Windows XP, of course, that forced the issue as it ended the 9x family of Windows.
But still, applications rolled on, assuming that every user on the system had access to write to Program Files (users don't), and HKEY_LOCAL_MACHINE (HKLM) in the registry (users don't), and HKEY_CLASSES_ROOT (users don't). Games are often among the worst offenders in assuming access; see Matt Clapham's article on this topic at technetmagazine.com/issues/2007/02/Gaming.
This is problematic because most cross-system apps store their files and registry settings in those locations and you need to be able to read and write to those locations in order to be able to install them. Unfortunately, some apps then insist on writing to those keys after installation. For example, my daughter has a game that is Flash-based. It attempts to install a custom player every time you run it—meaning that when my daughter runs as a user, not an administrator, the application fails to start, with a fatal error. While this is extreme, and it is a consumer application, the reality is that many non-consumer applications still don't play well in the world of non-administrative users. In fact, if you follow up on my challenge (see the sidebar, "My Challenge to You: Feel the Pain"), you'll discover just how much Windows itself isn't tolerant of running as a user.
If you take a look at Figure 1, you'll see what running IPConfig /release as a user looks like on Windows XP. If you compare that to Figure 2, you'll see that the same command under Windows Vista is not that much better, but at least you know why the command is failing. Note that the networking tools as a whole have been improved to allow users to refresh their IP addresses. Similarly, trying to run Computer Management (compmgmt.msc) as a user under either version lets you perform a limited number of tasks—but generally results in frustrating dead-ends, as Figure 3 shows. While Windows Vista doesn't initially enable many of the tools in Computer Management, it does present clearer access denied messages.
Figure 1 Running as a user under Windows XP
Figure 1 Running as a user under Windows XP
Figure 2 Running as a user under Windows Vista
Figure 2 Running as a user under Windows Vista
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP

Why It Matters
So why should you care? Because we, as IT professionals, should begin forcing applications to adjust to least-privileged users, instead of vice versa where applications assume the interactive user owns the system.
Unfortunately, the same policies that allow administrators to write to registry keys also grant any malware run in their user context full access to anything they have not been explicitly denied via access control lists (ACLs). In the world of UNIX, people follow the rule regarding not running as root (the functional equivalent of the Windows Administrator account), mostly because the ecosystem of software that pushes the boundaries of the security model is tiny to nonexistent.
Still, the best thing you can do is to follow that same wisdom and only run as an administrator when it is explicitly required—or better yet, only run individual applications as an administrator. By doing so, you raise that intra-system firewall I mentioned earlier. Then, when malware or spyware attempts to do something it shouldn't, it fails—because it can't write to the registry or file system locations it needs in order to really infect your system (such as installing a service or driver, or installing for all users). In addition, doing so allows anti-malware software to contain malware that it recognizes, without risking the entire system first.
Note, however, that users aren't impervious to attack. Though this class of malware doesn't exist widely yet, there is the potential for malware to successfully infect an individual user's context or destroy his data. But the attack vector posed by such software is limited. As a result, the same thing that keeps malware instances low on Linux or the Macintosh (the lower number of potential victims making it a less appealing playground for malware authors) can help ensure the general safety of your end users—and yourself—today.

Wither Power Users?
When we were developing Protection Manager, one of the comments we heard from customers was, "We're running Windows XP with all of our users as power users, not administrators, so we're secure." The reality, though, is that power users are just a few steps away from administrators. There are several potential holes that would, with a little work, allow a power user on Windows XP to become an administrator. In fact, the power users group was eliminated on Windows Vista and Windows Server® 2008; only a system upgraded from an earlier version of Windows will have a power users group. All in all, you should always avoid using the power users﻿ group, even if ﻿you are using Windows XP.

Lossy Permissions
If you read my March column on Windows thin clients (technetmagazine.com/issues/2008/03/DesktopFiles), you'll recall I spoke against the prospect of thinning out Windows XP to save space. In the same vein, there is a common practice to enable administrators transitioning to users that you will need to consider, but do so carefully. That is the practice of adjusting ACLs on the registry and file system so that users can write to locations they are not normally able to—thus enabling problematic applications.
Obviously, the best choice is to get an updated version of an application that doesn't require such a change, but that's not always possible. If you must change permissions (that is, drop them), proceed very carefully. Remember that the firewall between a user and an administrator is defined largely by registry and file system permissions. Opening them up lowers your protection and potentially widens the attack surface posed by malware—so please proceed judiciously.

What about UAC?
No discussion of transitioning users from administrators to users is complete without addressing User Account Control (UAC) in Windows Vista. UAC, like similar functionality on the Mac OS X, lets you run "as an administrator" without putting yourself at so much risk.
How does this work? Take a look in Figure 4 at what Process Explorer is showing about cmd.exe. The instance of cmd.exe on the right was started without elevation, with me running as an administrator. As a result, even though the user on the right is identical to the one on the left (where the cmd.exe was started with elevation), the application itself does not contain the necessary privileges and tokens for it (and the user running that instance) to perform any tasks that require administrative rights. UAC works by lowering the attack surface within a user's interactive context. The only problem is that something has to tell Windows that this task requires administrative privileges and that the user is OK with allowing the elevation required to complete this task.
Figure 4 Two instances of cmd.exe with different privileges
Figure 4 Two instances of cmd.exe with different privileges
The small shields in Windows Vista show you which tasks require elevation (see Figure 5). These tasks require elevation every time you run them—and this is one of the sore points the press has chosen to highlight with Windows Vista. The alternative, letting the credentials be more "sticky," poses a potential security threat that could be used to more easily exploit the system.
Figure 5 Shields in Windows Vista indicate the need for elevation
Figure 5 Shields in Windows Vista indicate the need for elevation
If UAC is enabled and your users are running simply as users, they will be prompted for a set of administrative credentials when an application requires administrative privileges. Note in this case, like when using runas or psexec, that the app runs literally in the context of the user you launched it as, unlike under UAC as an administrator. In that case, the tasks run in your context, but with elevated privileges.

Running Windows Vista as a User?
My personal preference when running Windows Vista is to actually run as a user, not an administrator with UAC, because I believe that in the average enterprise, this is still the best idea. After all, your users have full control over their systems and you may have decreased the window of opportunity for malware.
Moreover, if you are intending to manage your users with Group Policy, anti-virus, anti-malware, or other software and you want central control over whether these tasks actually get enforced or completed, ensuring your end users are not administrators is a critical step. If your users are administrators, they can stop services, add or remove drivers, and more. Of course, a crafty end user running as a user can use Windows PE to bypass some security hurdles. BitLocker® can make that more difficult, but again, remember that end users with physical access can do whatever they want to their machine, given enough time, knowledge, and dedication.
Running Windows Vista as a user isn't all that much different from running Windows XP as a user. I use the same tools—PSExec, RunAs, (and now UAC) to run tasks as an administrator as needed. The nice thing is that quite a few tasks in Windows XP that used to require administrative privileges no longer do. For example, a Windows Vista user can install a local printer. (Network printers could be installed by users in Windows XP, but installing a local printer required administrative privilege.) In Windows Vista, as long as the user is physically at the machine and the printer driver is in the driver store, a user can install a printer and manage print jobs on it (see go.microsoft.com/fwlink/?LinkId=111534 for more information). Note that this functionality is disabled in Windows Server 2008.
Of course, people make fun of the clock functionality (or lack thereof) when running as a user in Windows XP—try double-clicking on the clock as a user (something people often do to see what the date is, whether or not it was designed to work that way)—you get the error shown in Figure 6. Not very friendly. In Windows XP, you can modify policy so that users can do this, but in Windows Vista, it was changed to just work that way. So all in all, running as a user—whether you're using UAC or running as a formal user and elevating as another user, is generally more palatable on Windows Vista than it was on Windows XP.
Figure 6 In Windows XP, non-admins couldn't change the time
Figure 6 In Windows XP, non-admins couldn't change the time

Remember the Limits
Remember that moving your users to be non-admins isn't a panacea. Dedicated end users are still physically located on their own PCs, and they can work pretty diligently to exploit their own systems, especially if the policy or user privileges are inconveniencing them or preventing them from getting their work done.
If your users are running as administrators, it doesn't take much work to bypass any Group Policy in place. Of course, with a little more work, users can boot to Windows PE and modify permissions that they wouldn't normally have privileges to—though if you use BitLocker or other drive/volume encryption, you can make that impossible, or at least more difficult.
The most important thing you can do if your organization has not yet begun transitioning end users to run as users is to familiarize yourself with the reasons why you and the organization should spend time, money, and effort to move away from having users running as administrators.
Sure, legacy applications can be hard to let go of, but if you have an application that simply cannot be run as a user, it's just a bad idea to hold on to it at the expense of your organization's security. You should consider virtualizing the application—literally moving it into a Virtual Machine where the user is indeed an administrator. This lets the application be used as needed, but still allows you to secure the rest of the system by moving the administrators to users.
Note that through this entire column, I have not used the word "lockdown" or any derivative of it. Many people consider moving administrators to users a part of a task often described using that word. Perhaps it's my psychology background or my current marketing world, but I think it's important to not use words that make your end users feel like their privileges are being taken away (even though at a semantics level, they are).
Instead, focus on the security benefits to the organization and make sure you have a good plan for edge cases where either a specific user absolutely cannot run as a user or there is a particular task that requires admin privileges. Whether you use something manual like my Run.vbs script (which you'll find at technetmagazine.com/issues/2007/03/DesktopFiles) or use a commercial solution to help you make the transition (that lets you hide the details from your end users and makes things "just work"), it's important to start heading down the non-admin road as soon as you can. Frequent TechNet Magazine contributor Aaron Margosis is the evangelist when it comes to running as a non-administrator. If you aren't familiar with his blog, you should be—it's the best place to go for in-depth information on this topic (see blogs.msdn.com/aaron_margosis)﻿. 

Wes Miller is currently a Senior Technical Product Manager at CoreTrace (www.CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.


 Field Notes: Multiple Mice, One PC
Field Notes
Multiple Mice, One PC
Kentaro Toyama

India today is a country of contrasts. On the one hand, it's an IT superpower with well-educated minds developing technology for the world's computing needs. On the other hand, 70 percent of the country still lives on less than $2 a day. These poles meet in the occasional computer classroom in poor government schools where one will find, at most, a handful of PCs. These computers are usually donated, as the schools themselves do not have budgets to afford them.
In these environments, students almost always outnumber computers. It's commonplace to find groups of up to 10 children crowding around a PC, and frequently the local bully takes over. Of course, the "personal" in personal computer means that PCs were designed for single-person use. We at Microsoft Research India wondered what we could do to provide computer access to more children.
The solution was surprisingly simple: MultiPointTM allows multiple USB mice to be plugged into a computer, so that each mouse corresponds to a different colored cursor on-screen (research.microsoft.com/users/udaip/multipoint.htm). Effectively, it creates a multi-person environment—just like a gaming console—so that educational software written for the multiple-mouse paradigm allows many children to interact with a PC simultaneously.
Young students immediately took to the paradigm, despite adult worries of total on-screen chaos. In rigorous studies with 7th grade students that compared five-person MultiPoint-PC configurations with single-student, single-PC configurations, researchers discovered several things. First, children would engage with the PC and with each other for much longer periods of time when they were each allowed access to a mouse, likely due to the additional fun factor. Second, it is important to design software apps that encourage collaboration rather than outright competition, or else some children—particularly boys—would regress to a "fast-twitch" competition with little educational value. Finally, if collaboration was built-in, students learned as much in a MultiPoint application as they did with a PC all to themselves, at least for simple vocabulary retention tasks. More information on the research is available on the previously provided MultiPoint link.
Purchased in bulk, mice cost just a few dollars each, which means that by providing MultiPoint educational applications to schools, the per-child cost of computing can be lowered significantly. For example, a $500 PC shared by five students with $5 mice comes to $105 per child—and anything that lowers the per-student cost is welcome to those who budget for education.
The Unlimited Potential (microsoft.com/unlimitedpotential) and Education (microsoft.com/education) groups at Microsoft recognized the value of MultiPoint for resource-strapped schools. To facilitate rapid and widespread adoption, they released a software development kit that allows educational content developers to apply this multiple-mouse paradigm in their C# applications easily. The SDK can be downloaded and used free of charge, and any Windows®-based computer can run MultiPoint applications (microsoft.com/downloads).
As one of the programs under the Unlimited Potential banner, the goal of the MultiPoint SDK is to extend the value of the PC to as many students as possible, and to do this, we need your help. Should you try your hand at an educational application with MultiPoint, please let us know. We will feature links to the best submissions on MultiPoint Web sites.
As for what's next, Microsoft Research India and the Terminal Services product team are considering another way to share a PC: Split Screen, where two people, two keyboards, and two mice share a PC and a monitor. The latter is split down the center so a separate session of the operating system can run on each side. 

Kentaro Toyama is the Assistant Managing Director of Microsoft Research India (research.microsoft.com/india) and Principal Researcher of the Technology for Emerging Markets group (research.microsoft.com/research/tem), which develops technologies for economically poor communities worldwide.


 Windows Confidential: 16-Bit Icons Are So Pass&#233;
Windows Confidential
16-Bit Icons Are So Passé
Raymond Chen

As I noted in the February 2008 Windows Confidential column, features do disappear from Windows®. They typically do so slowly and largely imperceptibly, with a product team quietly celebrating the event each time it occurs. Another feature that vanished in Windows Vista® is the ability for 32-bit code to access icons stored in 16-bit modules—mostly 16-bit EXEs and 16-bit DLLs.
Before you get all worked up, bear in mind that 16-bit code can access icons stored in 16-bit modules just fine; that all happens inside the 16-bit emulation layer. What is gone is the ability to access those icons from 32-bit code, or more specifically the ability for 32-bit icon extraction functions like the ExtractIcon function to load those icons from your 16-bit DLL.
The 32-bit code that extracts icons from 16-bit modules doesn't have the luxury of using kernel functions such as FindResource to locate the icon in the file. Instead, the code must implement its own mini-loader that parses the 16-bit module header, seeks to the resource table, and then parses the resource table looking for the desired icon resource. Only after doing all that can the 32-bit code finally convert the pixels into an icon.
As you can imagine, the code that does this is very old and fragile. There are plenty of opportunities for error when parsing binaries that could be corrupted, either by mistake or with malicious intent. The performance team will ask for changes to the way the file is opened in order to improve the performance over networks, since different open and sharing modes have different consequences for network caching effects. And the reliability team may ask for the parsing code to be rewritten to avoid using memory-mapped files. Eventually, the cost of maintaining this kind of code starts to exceed the value it offered. I mean, really, who writes 16-bit programs anymore, right?
Now, your 16-bit programs will still run as long as the 16-bit emulation layer is there. (Yes, 64-bit Windows Vista does not have a 16-bit emulation layer, but this isn't a step backward from Windows XP; 64-bit Windows XP didn't have a 16-bit emulation layer either. It didn't get better, but it didn't get any worse.)
All that you're losing on Windows Vista is the ability to do an ExtractIcon from your 32-bit program and obtain an icon from a 16-bit DLL. If you have a shortcut to a 16-bit program on your Start menu, the icon for that shortcut will now come up as a generic program icon since Windows Explorer can no longer extract the 16-bit program's icon from its main EXE. No big loss. But if this really bothers you, you can edit the shortcut's properties and give it an icon from a 32-bit module.
The only place I've seen this lost feature become a problem is in icon libraries that are produced by one particular icon editing tool. For some reason, that program defaults to saving its icons as resources in 16-bit DLLs, which means that you can't access those icons from 32-bit code anymore. The easy workaround, of course, is to resave those icon libraries as resources in 32-bit DLLs.
I'm sure that eventually—if not already—somebody will write a little program to extract all the icons from a 16-bit DLL and then create a 32-bit resource-only DLL with those icons, just so people who have old icons lying around in 16-bit DLLs can continue to use them in shortcuts on their Start menu. But I have to admit, if you write this program, you probably won't find anybody who actually needs it. The number of requests for such a program that have come to the Windows user interface team: zero.

Raymond Chen's Web site, The Old New Thing, and identically titled book deal with Windows history and Win32 programming. He stands clear of the closing doors.