 TechNet Magazine March 2008

TechNet Magazine March 2008

Special Coverage: Windows Server 2008: Inside Windows Server 2008 Kernel Changes

Dive in to our detailed tour of key changes in the Windows Server 2008 kernel that improve reliability, performance, and scalability. Find out how Windows Server 2008 makes better use of thread pools, streamlines recovery from hardware failures, improves virtualization with Hyper-V, and more.

Mark Russinovich Special Coverage: Windows Server 2008: What's New in Active Directory Domain Services

Windows Server 2008 introduces some substantial enhancements to Active Directory Domain Services. Take a close look at how read-only domain controllers and Windows Server Core improve security in your environment, how the new Server Manager and revamped backup simplify management, and how the new auditing tools help ensure compliance.

Gil Kirkpatrick Special Coverage: Windows Server 2008: Getting Started with IIS 7.0

IIS 7.0 is packed with new features—too many to include in a single article. The new version builds on the solid, securityfocused design you got with IIS 6.0, providing enhancements that greatly improve the manageability and extensibility of the platform. Get an overview of some of the most important changes in IIS 7.0.

Isaac Roybal Special Coverage: Windows Server 2008: Policy-Driven Network Access with Windows Server 2008

How do you allow network access to those who need it without sacrificing security? See how new technologies in Windows Server 2008, such as Windows Firewall with Advanced Security and Network Access Protection, let you implement a policy-based approach to help you achieve this goal. Ian Hameroff and Amith Krishnan 62 Configuring Roles with Server Manager A DNS server need not be a print server. One approach Windows Server 2008 takes to improve security and manageability is to simplify server roles so you can easily install only the tools and services you need, and nothing more. Here's an introduction to using Server Manager for configuring roles and simplifying deployments.

Ian Hameroff and Amith Krishnan Special Coverage: Windows Server 2008: Configuring Roles with Server Manager

A DNS server need not be a print server. One approach Windows Server 2008 takes to improve security and manageability is to simplify server roles so you can easily install only the tools and services you need, and nothing more. Here's an introduction to using Server Manager for configuring roles and simplifying deployments.

Byron Hynes Special Coverage: Windows Server 2008: Deploying Windows Server 2008 with System Center

It used to be that server administrators would install Windows Server manually using the CD or DVD and then spend several hours configuring the server. With the release of System Center Configuration Manager 2007 and the new Microsoft Deployment Toolkit, server administrators can now use the same tools that desktop administrators have been using for years to automate deployments.

Tim Mintner Special Coverage: Windows Server 2008: Auditing and Compliance in Windows Server 2008

Auditing change is now a core responsibility for IT departments. It is an essential part of understanding and managing systems and data in a distributed environment. This article discusses common challenges, the landscape of compliance and regulation, some of the basics of auditing, and how you can create a comprehensive auditing strategy.

Rob Campbell and Joel Yoker From the Editor: Here's to Windows Server 2008

Joshua Hoffman Letters: Readers Speak Out

Toolbox: New Products for IT Pros

Greg Steen Utility Spotlight: Windows Server Logo Certification

To help ISVs and customers gauge application compatibility, Microsoft created the "Works with Windows Server 2008" program. Here's a look at the free supporting test tools made available through the program that can help you ensure that applications will deliver a predictable experience.

Venkat Krishnamachari The Cable Guy: Migrating Your Intranet to IPv6 with ISATAP

Getting ready to move to IPv6? The Cable Guy explains how you can use an IPv6 transition technology to get IPv6 connectivity and migrate to an IPv6-capable intranet.

Joseph Davies Windows PowerShell: Progress Report

For your users with attention span issues—and even those without—providing status feedback in your scripts is a good idea. Here's all you need to know to provide status in Windows PowerShell.

Don Jones Hey, Scripting Guy!: Our Favorite Shell Games

The Scripting Guys demonstrate how you can change the last-modified date of a file with some script and the Shell object.

The Microsoft Scripting Guys Security Watch: Using SCW on Windows Server 2008

You've heard about the new Server Manager tool in Windows Server 2008. But the Security Configuration Wizard (SCW) is still available, as well. Find out why you will still want to use SCW.

Jesper M. Johansson The Desktop Files: You Can't Be Too Rich or Too Thin

Thin clients come and thin clients go, but there always seems to be some scenario that can benefit from them. Today, they're used in kiosks and in environments where Web browsing is all that is needed. Here's a look at how you can repurpose old hardware with a client app to save some money.

Wes Miller Field Notes: Preparing for IT 2.0

Here's a look at the importance of learning from the past in order to address the challenges that the future holds for IT.

Romi Mahajan Windows Confidential: How Betas Became RCs

Raymond Chen discusses the intriguing backstory of how naming conventions for non-final releases have changed. And he gives a gentle plea for companies to take beta testing more seriously.

Raymond Chen


 Special Coverage: Windows Server 2008: Inside Windows Server 2008 Kernel Changes
Special Coverage: Windows Server 2008 Mark Russinovich

Inside Windows Server 2008 Kernel Changes
At a Glance:
  • Memory Management and SMB 2.0
  • NTFS self-healing, Windows Hardware Error Architecture, and the driver verifier
  • Scalability with I/O completion ports, thread pools, and NUMA
  • Hyper-V virtualization

Windows Server 2008 is the latest release of the Microsoft server platform, and it includes system-level changes that span every functional area of the operating system, from memory management
to thread scheduling and from networking to security, just to name a few.
Because Windows Server® 2008 shares the same kernel as Windows Vista® SP1, it includes many of the enhancements that I covered in my previous TechNet Magazine articles: "Inside the Windows Vista Kernel," Parts 1-3 (February, March, and April 2007) and "Inside Windows Vista User Account Control" (June 2007). Only a handful of the features I described in those articles are exclusively client-focused and not included in Windows Server 2008, such as SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot, and the Multimedia Class Scheduler Service (MMCSS).
Rather than repeat coverage of the important kernel changes introduced in Windows Vista that are also in Windows Server 2008, such as I/O prioritization, the new boot architecture, BitLockerTM, code integrity, and mandatory integrity levels, I'm going focus on the key changes that I didn't cover in those articles, including ones related to reliability, performance, scalability, as well as the new Microsoft hypervisor machine virtualization technology, Hyper-VTM.
Also, like the previous articles, the scope of this one is restricted to the operating system kernel, Ntoskrnl.exe, as well as closely associated system components. It does not cover changes to installation (WIM, or Windows® Imaging Format, and Component-Based Servicing), management (Group Policy and Active Directory® improvements), general diagnostics and monitoring (Windows Diagnostic Infrastructure), core networking (the new firewall and TCP/IP implementation), Server Core, or Server Roles, for example.
Working on Multiprocessor Systems
One of the low-level changes to the system is that Windows Server 2008 only includes a version of the kernel designed to work on multiprocessor systems. In the past, Windows used a version specific to uniprocessors on machines with a single CPU because that version could achieve slightly better performance by omitting the synchronization code required only in multiprocessor environments. As hardware has become faster, the performance benefit of the optimizations has become negligible, and most server systems today include more than one processor, making a uniprocessor version unnecessary.
Figure 1 shows the variants of the Windows Server 2008 kernel, where the version used on a system depends on whether it's the debug (Checked) or retail version of the operating system, whether the installation is 32-bit or 64-bit (Itanium, Intel 64, or AMD64), and, if it's a 32-bit installation, whether the system has more than 4GB of physical memory or supports Data Execution Prevention (DEP). Windows Server 2008 is also the last Windows Server operating system that is expected to offer a 32-bit version.
Figure 1 Windows Server 2008 kernel variants (Close Figure 1)

Kernel | 32-bit | 64-bit
Multiprocessor | Yes | Yes
Multiprocessor Checked | Yes | Yes
Multiprocessor Physical Address Extension (PAE) | Yes | No
Multiprocessor PAE Checked | Yes | No
Every release of Windows Server focuses on improving the performance of key server scenarios such as file serving, network I/O, and memory management. In addition, Windows Server 2008 has several changes and new features that allow Windows to take advantage of new hardware architectures, adapt to high-latency networks, and remove bottlenecks that constrained performance in previous versions of Windows. This section reviews enhancements in the memory manager, I/O system, and the introduction of a new network file system, SMB 2.0.

Memory Management
Experiment: Seeing Large Disk I/Os
You can use a file system monitoring tool like TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx) to look for large file I/O operations on a Windows Server 2008 system.
There are several ways to go about generating large I/Os. If you have a second system running either Windows Vista Service Pack 1 or Windows Server 2008, then you can run Process Monitor on the server and monitor file copies to the second system. You can also usually generate large paging file I/Os by running a memory-intensive program that causes the memory manager to write pages out to the paging file.
Figure A shows Process Monitor after running a memory-intensive program on a Windows XP system, with the Enable Advanced Output option checked in the Process Monitor Options menu and a filter set to only show writes to the paging file, pagefile.sys. The Detail column shows that the writes are 64KB in size.
Figure A
When you run the same steps on Windows Server 2008, you'll most likely see something similar to what is displayed in Figure B, which shows most of the writes to be approximately 1MB in size.
Figure B

The memory manager includes several performance enhancements in Windows Server 2008. For example, it issues fewer and larger disk I/Os than it does on Windows Server 2003 when fetching data from the paging file or performing read-ahead I/Os on mapped files. The larger file I/Os are facilitated by changes in the I/O system that remove a 64KB I/O-size limit that's been present since the first release of Windows NT®.
Also, it's important to note that data reads for read-ahead (speculative reads) from mapped files by the Cache Manager are typically twice as large on Windows Server 2008 than they are on Windows Server 2003 and go directly into the standby list (the system's code and data cache). This behavior occurs instead of requiring the Cache Manager to map virtual memory and read the data into the System's working set (memory assigned to the System by the memory manager), which might cause other in-use code or data to be needlessly evicted from the working set.
The memory manager also performs larger I/Os when writing data to the paging file. Whereas Windows Server 2003 often performed writes of even less than 64KB, on Windows Server 2008 the memory manager commonly issues 1MB writes.
Besides improving performance by reducing the number of writes to the paging file, the larger writes also reduce fragmentation within the paging file. This in turn causes a reduction in the number of reads and disk seeks that are required to read back multiple pages, since they will more often than not be adjacent.
The memory manager also tries to write out other modified pages that are close to the one being written out in the owning process's address space, and it targets the area of the paging file where other neighboring pages already reside. This also minimizes fragmentation and can improve performance because pages that might eventually be written out to the paging file have already been written. In addition, it reduces the number of paging reads required to pull in a range of adjacent process pages. Look at the sidebar "Experiment: Seeing Large Disk I/Os" for more information on the Memory Manager's use of large I/Os.

SMB 2.0
The Server Message Block (SMB) remote file system protocol, also known as Common Internet File System (CIFS), has been the basis of Windows file serving since file serving functionality was introduced into Windows. Over the last several years, SMB's design limitations have restricted Windows file serving performance and the ability to take advantage of new local file system features. For example, the maximum buffer size that can be transmitted in a single message is about 60KB, and SMB 1.0 was not aware of NTFS client-side symbolic links that were added in Windows Vista and Windows Server 2008.
Windows Vista and Windows Server 2008 introduce SMB 2.0, which is a new remote file serving protocol that Windows uses when both the client and server support it. Besides correctly processing client-side symbolic links and other NTFS enhancements, SMB 2.0 uses batching to minimize the number of messages exchanged between a client and a server. Batching can improve throughput on high-latency networks like wide-area networks (WANs) because it allows more data to be in flight at the same time.
Whereas SMB 1.0 issued I/Os for a single file sequentially, SMB 2.0 implements I/O pipelining, allowing it to issue multiple concurrent I/Os for the same file. It measures the amount of server memory used by a client for outstanding I/Os to determine how deeply to pipeline.
Because of the changes in the Windows I/O memory manager and I/O system, TCP/IP receive window auto-tuning, and improvements to the file copy engine, SMB 2.0 enables significant throughput improvements and reduction in file copy times for large transfers. Since both operating systems implement SMB 2.0, deploying Windows Server 2008 file servers with Windows Vista clients enables the use of SMB 2.0 and the realization of these performance benefits.

Reliability with NTFS Self-Healing
Reliability is a key server attribute, and Windows Server 2008 delivers various improvements that help administrators keep their server running smoothly, including online NTFS consistency repair, a new hardware error-reporting infrastructure, and extensions to the Driver Verifier.
With today's multi-terabyte storage devices, taking a volume offline for a consistency check can result in a multi-hour service outage. Recognizing that many disk corruptions are localized to a single file or portion of metadata, Windows Server 2008 implements a new NTFS self-healing feature to repair damage while a volume remains online.
When NTFS detects corruption, it prevents access to the damaged file or files and creates a system worker thread that executes Chkdsk-like corrections to the corrupted data structures, allowing access to the repaired files when finished. Access to other files continues as normal during this operation, minimizing service disruption.

WHEA Infrastructure
The Windows Hardware Error Architecture (WHEA) infrastructure included in Windows Server 2008 promises to simplify the management of hardware failures and enable proactive response to non-fatal errors. Servers often have strict uptime guarantees, so identifying and responding to errors in a timely manner on such systems is critical.
Analysis of crashes submitted to Microsoft via Online Crash Analysis (OCA) shows that roughly 10 percent of operating system crashes are in response to a hardware failure, but determining the root cause of these crashes has been difficult or impossible because there's insufficient error information provided by the hardware for capture in a crash. In addition, prior to Windows Server 2008, Windows had not provided built-in support for monitoring the health of devices or implemented remediation or notification of imminent failure. The reason behind this is that hardware devices don't use a common error format and provide no support for error management software.
WHEA provides a unified mechanism for error-source discovery and reporting for platform devices, including processors, memory, caches, and busses like PCI and PCI Express. It does so by implementing the architecture shown in Figure 2, where the core is a kernel API that error sources call to report errors. The API requires all errors to be formatted in a common way, and it logs errors using Event Tracing for Windows (ETW) events (fatal errors are logged after a reboot).
Figure 2 WHEA error-reporting infrastructure
Figure 2 WHEA error-reporting infrastructure
ETW was introduced in Windows 2000, and the WHEA use of ETW makes it easy for hardware manufacturers and software vendors to develop device diagnostics management applications that consume WHEA events. If an event is severe enough to warrant a system crash, WHEA ensures that the fatal error record is stored in the crash dump file so that administrators can determine the crash's root cause.
Another key piece of WHEA is the Platform Specific Hardware Error Driver (PSHED) found in %Systemroot%\System32\Pshed.dll. The kernel links with PSHED, and it interfaces with platform and firmware hardware, essentially serving as a translation layer between their error notifications and the WHEA error-reporting API. There's a Microsoft-supplied PSHED for each platform architecture (x86, x64, Itanium), and PSHED exposes a plug-in model so that hardware vendors and manufacturers can override the default behaviors with ones specific to their platforms.
Finally, components of the system that interface with other error sources—including device drivers, the Hardware Abstraction Layer (HAL), and the kernel—can implement Low-Level Hardware Error Handlers (LLHELs) that initially handle an error condition. An LLHEL's job is to extract error information from the device, notify PSHED to allow it to collect additional platform error information, and then call the kernel's WHEA error-reporting API.

Driver Verifier
The Driver Verifier, a powerful tool for tracking down buggy device drivers and faulty hardware, has been included in every copy of Windows since Windows 2000. Administrators commonly configure the Driver Verifier (%Systemroot%\System32\Verifier.exe) to closely monitor the behavior of device drivers suspected of causing system crashes. The Driver Verifier catches illegal driver operations so that a crash dump file points directly to the guilty party.
A drawback of previous Driver Verifier implementations is that most configuration changes require restarting the system, something that is obviously undesirable on a production server. The Windows Server 2008 implementation of Driver Verifier improves this process by removing the restart requirement for the most useful verifications, making it possible to troubleshoot a problematic server without having to restart it.
In addition, Driver Verifier introduces three new verifications, visible in Figure 3. Security checks ensures that device drivers set secure permissions on the objects they use to interface with applications. Force pending I/O requests tests a driver's resilience to asynchronous I/O operations that complete immediately rather than after a delay. And Miscellaneous checks looks for drivers improperly freeing in-use resources, incorrectly using Windows Management Instrumentation (WMI) registration APIs, and leaking resource handles.
Figure 3 Driver Verifier with Windows Server 2008 options checked
Figure 3 Driver Verifier with Windows Server 2008 options checked

Scalability
Scalability refers to the ability of an operating system or application to effectively utilize multiple processors and large amounts of memory. Every release of Windows improves scalability by minimizing or eliminating the use of locks that reduce parallelism on multiprocessors, and Windows Server 2008 is no exception to this trend.
A relatively small but significant improvement is in the code that executes timer expiration, which no longer acquires the dispatcher lock, a systemwide scheduler lock used by all low-level synchronization operations. The resulting reduction in CPU synchronization overhead enables Windows Server 2008 terminal server systems to support about 30 percent more concurrent users than Windows Server 2003.
Other scalability improvements in Windows Server 2008 include completion port enhancements, a new threadpool implementation, more efficient use of Non-Uniform Memory Access (NUMA) hardware, and dynamic system partitioning.

Improved I/O Completion Port Handling
Most scalable Windows server apps, including IIS, SQL Server®, and Exchange Server, rely on a Windows synchronization API called a completion port to minimize switching between multiple threads of execution when executing I/O operations. They do this by first associating notifications of new request arrivals, such as Web server client connections, with a completion port and dedicating a pool of threads to wait for the notifications. When a request arrives, Windows schedules a thread, which then usually executes other I/O operations like reading a Web page from disk and sending it the client to complete the request.
So that the same thread can return to waiting for more client requests as quickly as possible, the thread issues I/Os asynchronously and associates I/O completions with the completion port. The thread then returns to waiting on the completion port, which will schedule the thread when either a new request arrives or one of the I/Os completes. In this way, the same thread remains active on a CPU, alternately processing client requests and waiting on the completion port.
A drawback of the completion port implementation of prior Windows releases is that, when an I/O completed, the I/O system caused the thread that issued the I/O to immediately perform a small bit of completion processing, regardless of whatever else it was doing. If other threads were active, that often caused the scheduler to preempt an active thread and context switch to the issuer.
Windows Server 2008 avoids these context switches by deferring completion processing to the next thread to wait on the completion port with which the I/O is associated. Thus, even if a different thread is the next to wait on the completion port, it will perform the completion processing before executing other code, and the scheduler does not need to switch to the issuing thread. This minimization of context switches can dramatically improve the scalability of heavily loaded server applications.

More Efficient Thread Pools
Writing applications that take advantage of multiple CPUs can be difficult, so Windows XP introduced worker thread pools, an infrastructure and associated API that abstracts the details of executing small units of work across CPUs. An application specifies the work items to the thread pool API, which then executes them on one of a number of threads that it creates and manages for each CPU in the system.
The goal of the thread pool is to minimize context switches by using the same threads to execute multiple work items in succession. When that's not possible because one of its threads is busy already performing other work, it executes the work item using a different thread on a different CPU.
The Windows Server 2008 thread pool implementation makes better use of CPUs indirectly because it benefits from the completion port improvements and directly by optimizing thread management so that worker threads dynamically come and go when needed to handle an application's workload. Further, the core of the infrastructure has moved to kernel mode, minimizing the number of system calls made by applications that use the API. Finally, the new API makes it easier for applications to perform certain operations, such as aborting queued work units during application shutdown.

NUMA Optimizations
Windows Server 2003 introduced optimizations for NUMA machines in the thread scheduler and memory manager, but Windows Server 2008 adds NUMA optimizations in the I/O manager and extends the memory manager's NUMA optimizations.
NUMA systems are typically multiprocessor systems where memory has different latency depending upon which processor accesses it (see Figure 4). Memory is divided into nodes, where the latencies between CPUs and nodes can vary and each CPU is considered part of a node to which it has the fastest access.
Figure 4 Example NUMA system
Figure 4 Example NUMA system
NUMA systems, especially ones with more than eight CPUs, are often more cost and performance efficient than uniform-memory access systems. While a uniform-memory access system must make memory equally available to all CPUs, a NUMA system can implement high-speed interconnections for memory directly connected to a CPU and cheaper higher-latency connections for CPUs and memory that are further apart.
To scale effectively on a NUMA system, an operating system or application must be aware of the node topology so that computation executes near the memory containing the computation's data and code. For example, the Windows scheduler assigns each thread a so-called ideal processor, which is the CPU on which the scheduler tries to always execute the thread. Doing this makes it more likely that data the thread places in the CPU's cache is going to be available to the thread every time it runs.
In Windows Server 2003, the scheduler expands this concept by considering the node containing the ideal processor to be the thread's ideal node, and it tries to schedule the thread on another CPU in the ideal node when the ideal processor is busy executing a different thread. The Windows Server 2003 memory manager also became NUMA-aware and, when possible, directs a thread's memory allocations to the memory of the node on which the thread is executing.
In Windows Server 2008, the memory manager divides the kernel's non-paged memory buffers (memory used by the kernel and device drivers to store data that is guaranteed to remain in RAM) across nodes so that allocations come from the memory on the node on which the allocation originates. System page table entries (PTEs) are allocated from the node from where the allocation originates, if the allocation requires a new page table page to satisfy it, instead of from any node, as it does in Windows Server 2003.
In Windows Server 2003, when a thread makes a memory allocation, the memory manager would prefer the node on which the thread is executing at the time of the allocation. If the thread was momentarily scheduled onto a non-ideal node, any allocations performed during that time would come from the non-ideal node. So when the thread eventually executes on its ideal node, it won't be as close as it could be to the data or code stored in the allocated memory.
To address this, the Windows Server 2008 memory manager prefers a thread's ideal node for all of a thread's allocations, even when the thread is executing close to a different node. The memory manager also automatically understands the latencies between processors and nodes, so if the ideal node doesn't have available memory, it next checks the node closest to the ideal node. In addition, the memory manager migrates pages in its standby list to a thread's ideal node when a thread references the code or data.
Applications that want to control the locality of their allocations can use new NUMA memory APIs that allow them to specify a preferred node for memory allocations, file mapping views, and file mapping objects. For an allocation related to a file mapping, the memory manager checks to see whether the mapping operation specifies a node, then checks whether the file mapping object specifies one, and finally it falls back on going to the thread's ideal node if neither do.
Prior to Windows Server 2008, the interrupt and associated deferred procedure call (DPC) for a storage or network I/O can execute on any CPU, including ones from a different node than the one on which the I/O initiated, potentially causing data read or written in the I/O operation to be in a different node's memory than the one where the data is accessed.
To avoid this, the Windows Server 2008 I/O system directs DPC execution to a CPU in the node that initiated the I/O, and systems that have devices that support PCI bus MSI-X (an extension to the Message Signaled Interrupt standard) can further localize I/O completion by using device drivers that take advantage of Windows Server 2008 APIs to direct an I/O's interrupt to the processor that initiated the I/O.

Dynamic Partitioning
One of the ways a system can be more scalable is for it to support the dynamic addition of hardware resources such as CPUs and memory. This same support can also make the system more available when those resources can be replaced without requiring a system reboot.
Windows Server 2003 included hot-memory add, allowing servers with dynamic memory support to use RAM as an administrator adds it. Windows Server 2008 extends dynamic memory support by allowing memory to be replaced.
RAM that becomes more reliant on Error Correcting Code (ECC) corrections is at risk of failing altogether, so on a server with hot-replace support, Windows Server 2008 can transparently migrate data off failing memory banks and onto replacements. It does so by migrating data that's under control of the operating system first, then effectively shutting down hardware devices by moving them into a low-power state, migrating the rest of the memory's data, then re-powering devices to continue normal operation.
Windows Server 2008 also supports hot addition and hot replacement of processors. For a hot replacement, the hardware must support the concept of spare CPUs, which can be either brought online or added dynamically when an existing CPU generates failure indications, something currently only available in high-end systems. The Windows Server 2008 scheduler slows activity on the failing CPU and migrates work to the replacement, after which the failing CPU can be removed and replaced with a new spare.
Windows Server 2008 support for hot processor addition allows an administrator to upgrade a server's processing capabilities without downtime. However, the scheduler and I/O systems will only make a new CPU available to device drivers and applications that request notification of CPU arrival via new APIs because some applications build-in the assumption that the number of CPUs is fixed for a boot session. For instance, an application might allocate an array of work queues corresponding to each CPU, where a thread uses the queue associated with the CPU on which it's executing. If the scheduler put one of the application's threads on a new CPU, it would try and reference a non-existent queue, potentially corrupting the application's data and most likely crashing the application.
Microsoft server-based applications like SQL Server and Exchange Server are CPU addition capable, as are several core Windows processes, including the System process, Session Manager (%SystemRoot%\System32\Smss.exe,) and Generic Service Hosting processes (%Systemroot%\System32\Svchost.exe). Other processes can also request notification of new CPU arrival using a Windows API. When a new CPU arrives, Windows notifies device drivers of the impending arrival, starts the CPU, and then notifies device drivers and applications written to take advantage of new CPUs so that they allocate data structures to track activity on the new CPU, if necessary.

Machine Virtualization
Prior to Windows Server 2008, Microsoft virtualization products, including Virtual Server 2005, have been implemented using hosted virtualization, as shown in Figure 5. In hosted virtualization, virtual machines are implemented by a Virtual Machine Monitor (VMM) that runs alongside a host operating system, typically as a device driver. The VMM relies on the host operating system's resource management and device drivers, and when the host operating system schedules it to execute, it time-slices the CPU among active virtual machines (VMs).
Figure 5 Hosted machine virtualization
Figure 5 Hosted machine virtualization
Hyper-V, previously code-named "Viridian," is implemented using hypervisor virtualization. The hypervisor is in full control of all hardware resources, and even the Windows Server 2008 operating system that boots the system and through which you control VMs is essentially running in a virtual machine, as seen in Figure 6.
Figure 6 Hyper-V architecture
Figure 6 Hyper-V architecture
The hypervisor can partition the system into multiple VMs and treats the booting instance of Windows Server 2008 as the master, or root, partition, allowing it direct access to hardware devices such as the disk, networking adapters, and graphics processor. The hypervisor expects the root to perform power management and respond to hardware plug and play events. It intercepts hardware device I/O initiated in a child partition and routes it into the root, which uses standard Windows Server 2008 device drivers to perform hardware access. In this way, servers running Hyper-V can take full advantage of Windows support for hardware devices.
When you configure Windows Server 2008 with the Hyper-V server role, Windows sets the hypervisorimagelaunchtypeboot Boot Configuration Database (BCD) setting to auto and configures the Hvboot.sys device driver to start early in the boot process. If the option is configured, Hvboot.sys prepares the system for virtualization and then loads either %Systemroot%\System32\Hvax64.exe or %Systemroot%\System32\Hvix64.exe into memory, depending on whether the system implements AMD-V or Intel VT CPU virtualization extensions, respectively.
Once loaded, the hypervisor uses the virtualization extensions to insert itself underneath Windows Server 2008. User-mode applications use the x64 processor's Ring 3 privilege level and kernel-mode code runs at Ring 0, so the hypervisor operates at conceptual privilege level Ring minus 1, since it can control the execution environment of code running in Ring 0.
When you use the Hyper-V management console to create or start a child partition, it communicates with the hypervisor using the %Systemroot%\System32\Drivers\Winhv.sys driver, which uses the publicly documented hypercall API to direct the hypervisor to create a new partition of specified physical-memory size and execution characteristics. The VM Service (%Systemroot%\System32\Vmms.exe) within the root is what creates a VM Worker Process (%Systemroot%\System32\Vmwp.exe) for each child partition to manage the state of the child.
One way Windows improves the performance of child VM operating systems is that both Windows Server 2008 and Windows Vista implement enlightenments, which are code sequences that activate only when the operating system is running on a hypervisor that implements the Microsoft hypercall API. By directly requesting services of the hypervisor, the child VM avoids virtualization code overhead that would result if the hypervisor had to guess the intent of the child operating system.
For example, a guest operating system that does not implement enlightenments for spinlocks, which execute low-level multiprocessor synchronization, would simply spin in a tight loop waiting for a spinlock to be released by another virtual processor. The spinning might tie up one of the hardware CPUs until the hypervisor scheduled the second virtual processor. On enlightened operating systems, the spinlock code notifies the hypervisor via a hypercall when it would otherwise spin so that the hypervisor can immediately schedule another virtual processor and reduce wasted CPU usage.
Another way Windows Server 2008 improves VM performance is to accelerate VM access to devices. Performance is enhanced by installing a collection of components, collectively called the "VM integration components," into the child operating system.
If you run a VM without installing integration components, the child operating system configures hardware device drivers for the emulated devices that hypervisor presents to it. The hypervisor must intervene when a device driver tries to touch a hardware resource in order to inform the Root partition, which performs device I/O using standard Windows device drivers on behalf of the child VM's operating system. Since a single high-level I/O operation, such as a read from a disk, may involve many discrete hardware accesses, it can cause many transitions, called intercepts, into the hypervisor and the root partition.
Windows Server 2008 minimizes intercepts with three components: the Virtual Machine Bus Driver (%Systemroot%\System32\Drivers\Vmbus.sys), Virtual Service Clients (VSCs), and Virtual Service Providers (VSPs). When you install integration components into a VM with a supported operating system, VSCs take over the role of device drivers and use the services of the Vmbus.sys driver in the child VM to send high-level I/O requests to the Virtual Machine Bus Driver in the Root partition via the hypercall and memory-sharing services of the hypervisor. In the root partition, Vmbus.sys forwards the request to the corresponding VSP, which then initiates standard Windows I/O requests via the root's device drivers.
As you can see, Windows Server 2008 plays a key role in the Microsoft machine virtualization strategy with its introduction of Hyper-V hypervisor-based virtualization. Look for more information on these and other features in the next edition of my book, Microsoft Windows Internals, scheduled for publication later this year.

Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He's coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences, including Microsoft TechEd and the Professional Developer's Conference. Mark joined Microsoft with the acquisition of the company he co-founded, Winternals Software. He also created Sysinternals, where he published many popular utilities, including Process Explorer, Filemon, and Regmon.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Special Coverage: Windows Server 2008: What's New in Active Directory Domain Services
Special Coverage: Windows Server 2008 Gil Kirkpatrick

What's New in Active Directory Domain Services
At a Glance:
  • Using the new Server Manager with ADDS
  • Running domain services on Server Core
  • Read-Only Domain Controllers
  • Changes to passwords, backing up, and auditing

With Windows 2000, Microsoft introduced the world to Active Directory. The next major release, Windows Server 2003, brought significant improvements to Active Directory, but no
earth-shattering changes. Today, Active Directory® is a very mature, robust directory service. Even so, the Active Directory team has provided several substantial advancements in the latest version to improve the security and manageability of this core network service.
Back around the turn of the century, Active Directory was the thing that authenticated a user when he logged in, applied group policies to the user and his computer, and helped him find the printer he was looking for. Just a few years later, Microsoft released a standalone variant called Active Directory Application Mode (ADAM).
By 2006, this had all changed. Active Directory was no longer a specific technology. It's now a brand name that identifies a collection of in-the-box Windows® identity and access control services. Figure 1 provides a quick rundown of what makes up the Active Directory brand.
Figure 1 Active Directory components (Close Figure 1)

Current Active Directory Technology | Previously Called | Description
Active Directory Domain Services (ADDS) | Active Directory | What we used to call Active Directory. It provides Kerberos and NTLM-based authentication for domain users and computers, and manages OUs, users, groups, group policies, and much more.
Active Directory Lightweight Directory Services (ADLDS) | Active Directory Application Mode (ADAM) | A high-performance LDAP server based on the same source code used by ADDS.
Active Directory Certificate Services (ADCS) | Certificate Service | Provides strong authentication using X.509 certificates.
Active Directory Rights Management Services (ADRMS) | Rights Management Server | Protects digital assets, such as documents and e-mail, from unauthorized use by creating rights-protected files and containers.
Active Directory Federation Services (ADFS) | Active Directory Federation Services | Provides Web single-sign-on and identity federation for WS-* compliant Web services.
So, to use the proper terminology, this article is about Domain Services. But to be clear, this is still the same Active Directory you've grown to love since 2000.

Server Manager in Windows Server 2008
The first two improvements for Active Directory I am going to discuss really aren't changes in Active Directory Domain Services (ADDS); rather, they are changes in Windows that will change the way you manage Active Directory. The first, the new Server Manager, shows up as soon as you boot your Windows Server® 2008 server for the first time. (The second is the Server Core installation, which I'll get to in a moment.)
Server Manager will probably look familiar to you from the Configure Your Server Wizard in Windows Server 2003, which comes up by default after you install Windows Server 2003. That version, however, isn't very useful for day-to-day administration, and everyone I know checks the "Don't display this page at logon" box.
Server Manager in Windows Server 2008, on the other hand, is quite useful (see the article by Byron Hynes in this issue of TechNet Magazine for an overview of Server Manager). First, as you can see in Figure 2, Server Manager is now a Microsoft® Management Console (MMC) snap-in rather than a Microsoft HTML Application (HTA). This means it has a full-featured user interface that is familiar and easy to customize. Out of the box, Server Manager lets you manage the installation of server roles (major services such as DNS, ADDS, and IIS) and features (software components, such as the Microsoft .NET Framework, BitLockerTM drive encryption, and Windows PowerShellTM). Beyond the ability to add and remove software, Server Manager also provides a single point of contact for running diagnostic tools (such as the Event Viewer and PerfMon) and system configuration utilities (such as Device Manager and the Windows Firewall snap-in). If you add in the MMC snap-ins for Active Directory—for instance, Users and Computers, Domains and Trusts, and Sites and Services—you'll have a pretty nice interface to perform day-to-day management of your Windows Server 2008 domain controller (DC).
Figure 2 Server Manager in Windows Server 2008
Figure 2 Server Manager in Windows Server 2008

Windows Server 2008 Server Core
Windows Server Core is a new Windows installation option that provides a trimmed-down version of Windows containing only the components necessary to run certain key server roles, including Active Directory Domain Services. (Figure 3 lists the roles supported by Server Core.) Although a Server Core installation has a graphical UI, it doesn't run the Windows desktop shell and almost all of the graphical tools for managing and configuring Windows are absent (see Figure 4). In their place, you get a command window and a terrible feeling in the pit of your stomach that you don't know what to do next. How do I change the computer name? How can I configure a static IP address?
Figure 4 There's not much to see in the Server Core UI
Figure 4 There's not much to see in the Server Core UI
The first few minutes in front of a Server Core installation can be unsettling. But after a little time re-familiarizing yourself with WMIC, NETSH, and NETDOM, you'll be able to do all the usual setup and configuration tasks with no difficulty. And you still get Regedit and Notepad to satisfy your graphical tool needs.
The main advantage to Server Core is that much of the code you get with a typical Windows installation, which you may not need for these core server roles, is removed. This reduces the potential attack surface for malware (a good thing) and reduces the amount of patching and rebooting you'll have to perform on your DCs (an even better thing). And you get a much smaller disk footprint and reduced hardrive requirements—these aren't usually a big deal, but it can be a help in virtualized server environments.
Will the lack of graphical utilities make managing ADDS difficult? Not at all. You can perform almost all of your management tasks remotely by running the utilities on your workstation and connecting to the domain controller over the network. I expect that the vast majority of DCs will eventually be running on Server Core installations.

DCPROMO Changes
The first change you'll notice in ADDS itself is the new DCPROMO. It works the same as DCPROMO in Windows Server 2003, but it's been completely rewritten to make it easier to use. For instance, you don't have to enter your domain administrator credentials—DCPROMO can use the credentials of your current login to promote the server. Nor do you have to type DCPROMO /ADV to get the Advanced Mode DCPROMO options—now there's a checkbox on the first DCPROMO dialog to enable these options. Advanced mode also lets you select the existing domain controller to replicate from. This means you can keep the replication load of DCPROMO off of your production DCs.
When you promote a DC into a new domain or forest, DCPROMO gives you the option to set the forest and domain functional level, rather than having you do this later. You can also specify the Active Directory site you want to place the DC in during the promotion process, which is very useful in the unattended DCPROMO scenario. DCPROMO will even suggest the best site for the DC based on the DC's IP address.
The new DCPROMO also collects all of the configuration options onto a single page, providing one place where you choose whether the new DC will be a global catalog (GC), a DNS server, or a read-only DC. You don't have to go to an obscure location in the Active Directory Sites and Services snap-in to mark the DC as a GC.
But perhaps the nicest feature in the new DCPROMO is the ability to save all the DCPROMO settings in a response file just before the promotion process starts. This is much simpler—and less error-prone—than cobbling up the response file by hand. You can then use the response file to perform unattended DCPROMOs on other servers. And for you script fanatics, all of DCPROMOs options are now accessible from the command line.

Read-Only Domain Controllers
In the early days of Active Directory, enterprises often deployed domain controllers at every site at which users might log in. This was common in banks, for instance, placing a DC in every branch office. The logic was that users at the branch office would be able to log in and access local network resources even if the WAN failed.
At the time, the need for physical security of DCs wasn't well understood. I saw domain controllers tucked beneath desks where they could easily be accessed by people walking by. It wasn't until a few years later that Active Directory architects fully comprehended the security risk that an unsecured DC creates, and IT organizations started consolidating their DCs back into more centralized datacenters. Branch office users then had to authenticate over the WAN, but it was a worthwhile trade-off for the added security.
Active Directory in Windows Server 2008 changes the equation with respect to branch office deployments by introducing read-only domain controllers, or RODCs. These represent the biggest change in Windows Server 2008 Domain Services.
The Active Directory team focused on the requirements of the branch office scenario when they designed the RODC and they adopted the goal of "What happens in the branch office, stays in the branch office." The point is that if you deploy a DC in a physically insecure branch office, there's ultimately nothing you can do to prevent the DC (and the machines that trust that DC) from being compromised, but you can prevent that compromise from spreading from the branch office out to the rest of the domain.
Note that even though they constitute a huge change to the ADDS infrastructure, RODCs are quite straightforward to implement. Your domain must be at Windows Server 2003 forest functional level, and there must be at least one Windows Server 2008 DC in the domain. And beyond simply being a branch-office solution, RODCs make sense in Internet-facing environments and in situations where the DC is placed in the network perimeter.

DC Gone AWOL
There are several classes of threats to consider in a branch office. The first is the "stolen DC" scenario, where someone walks off with the DC or the disk of the DC. Beyond the local service disruption, the risk is that the attacker ultimately gains access to all of the user names and passwords in the domain and from there elevates his privileges to gain access to protected resources or cause a denial of service. To address this threat, RODCs, by default, don't store the password hashes in the Directory Information Tree (DIT) of the RODC. So to authenticate a user to the domain, when a user first authenticates to a particular RODC, the RODC passes the request to a full domain controller (FDC) in the domain. The FDC processes the request and, if successful, the RODC issues a replication request for the password hash.
A compromised RODC could potentially request password hashes for sensitive accounts. To prevent this, the domain administrator can configure a password replication policy for each RODC. The password replication policy is made up of two attributes on the RODC's computer object. The msDS-RevealOnDemandGroup attribute contains the distinguished names of groups, users, or computer accounts whose passwords may be cached on the RODC (these are typically the users and computers in the same site as the RODC). The msDS-NeverRevealGroup contains the distinguished names of groups, users, or computer accounts whose passwords may not be cached on the RODC (for instance, the domain administrator account should never have its password hashes cached on an RODC). When the RODC requests the password hash for a particular account, the FDC evaluates the request against the password replication policy to determine whether the password hash should be replicated to the RODC. When a DC is stolen, this limits the vulnerability to those passwords that happen to have been cached on the stolen RODC at the time it was removed from the network, and it eliminates the possibility of a critical password being compromised.
The RODC computer object contains two other attributes to help you determine exactly which accounts should have their passwords cached. The msDS-AuthenticatedAtDC attribute lists the accounts that have been authenticated to the RODC, and the msDS-RevealedList attribute names the accounts whose passwords are currently stored by the RODC.
User and computer password hashes are not the only secrets stored on a DC. The KrbTGT account contains the keys for the Kerberos Key Distribution Center (KDC) service running on each domain controller. In a typical scenario, each KDC in the domain shares the same KrbTGT account, and it is possible that an attacker could retrieve these keys from a stolen DC and use them to attack the rest of the domain. However, each RODC has its own KrbTGT account and keys, eliminating that possibility.
It is also not unusual for applications to store passwords or other secrets in the DIT. If an attacker were to steal a DC, she could possibly steal these application passwords and use them to gain access to the applications. To mitigate this risk, Windows Server 2008 Domain Services allows administrators to define the Read-Only DC Filtered Attribute Set (RO-FAS). Attributes that are part of the RO-FAS are never replicated to RODCs, and thus they can't be retrieved from a compromised DC. You assign attributes to the RO-FAS by setting bit 9 (0x0200) of the searchFlags attribute of the corresponding attributeSchema object in the schema.

Barbarians inside the Gate
Another class of threat for branch office domain controllers is the case of a local server administrator elevating his privilege by leveraging the DC's privileges to gain access to other domain resources or to engineer a denial of service attack. Again, if the local administrator has physical access to the domain controller, there's little that can be done to prevent compromise. But it is possible to prevent the attacker from using the branch office domain controller to compromise other DCs in the domain.
RODCs are not trusted as domain controllers by the full DCs in the domain. From a trust standpoint, FDCs treat RODCs as member servers in the domain. An RODC is not a member of the Enterprise Domain Controllers or Domain Controllers groups. The RODC account has very limited ability to update anything in the directory, and therefore even if an attacker does compromise the RODC account, she'll gain almost no useful privileges.
RODCs don't even show in the normal DS replication topology. Because RODCs look like normal member servers rather than domain controllers, the Knowledge Consistency Checker (the KCC, which is the process on each DC responsible for calculating the DS replication topology) won't build connection objects from RODCs. No full DC or RODC will try to replicate from an RODC. On the other hand, the RODC will create a connection object representing an inbound replication agreement from a full DC, but this connection object only exists in the RODC's replica; no other DC has a copy of that connection object. From a replication standpoint, RODCs are like Roach Motels for directory objects. Objects replicate in, but they don't replicate out.

Administrative Role Separation on RODCs
It's very common for a branch office DC to be managed by a local server administrator who does everything from running backups on the domain controller to cleaning keyboards. But it is a security risk to grant a remote site administrator the rights necessary to do general maintenance on a domain controller, and the site admin can potentially elevate her privileges in the domain. RODCs provide two kinds of administrative role separation to mitigate this threat.
With the first form of role separation, the domain administrator can promote the RODC in the normal way using DCPROMO, or she can use a two-step process where the actual promotion process is securely delegated to the branch site administrator, without granting any domain administration rights. The domain administrator pre-creates the RODC computer account in the domain using the Active Directory Users and Computers MMC snap-in, as shown in Figure 5.
Figure 5 Pre-creating the RODC computer account
Figure 5 Pre-creating the RODC computer account
Selecting "Pre-create Read-only Domain Controller account" runs an abbreviated version of DCPROMO that performs all the tasks that require administrative access to the domain, including creating the computer account, assigning the RODC to a site, specifying the DC's roles, specifying the password replication policy, and defining the user or group that will need the rights to complete the DCPROMO operation on the RODC. The delegated administrator or group is stored in the managedBy attribute of the RODC computer object.
The delegated administrator can then run DCPROMO on the server itself. DCPROMO will detect the pre-created account and turn the server into an RODC. Running DCPROMO in this way does not require domain administrator credentials.
The second way RODCs provide administrative role separation is by creating local administrative roles on the RODC itself. These roles look like machine local groups—they are stored in the registry of the RODC, and they can only be evaluated on the RODC. But instead of using the Computer Management MMC snap-in to manage them, the administrator manages local RODC roles using NTDSUTIL. Figure 6 lists the local administrative roles on an RODC. These roles correspond one-for-one with the built-in groups in Windows.
Figure 6 Local RODC administrative roles (Close Figure 6)

Account Operators
Administrators
Backup Operators
Certificate Service DCOM Access
Cryptographic Operators
Distributed COM Users
Event Log Readers
Guests
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Terminal Server License Servers
Users
Windows Authorization Access Group

RODC Oddities
Because RODCs are read-only and no other domain controller will replicate from them, RODCs exhibit some unexpected behaviors. For instance, lingering objects—meaning objects that have been deleted everywhere else but on a particular DC because the DC was unable to replicate for longer than the tombstone lifetime of the forest—are normally detected by the outbound replication partners of the DC. But since RODCs have no inbound replication partners, there is no lingering object detection for them.
RODCs will not service LDAP update (add, modify, delete, rename, or move) operations. Instead, RODCs return an error with an LDAP referral to a writable DC that can service the operation. If the application that issued the LDAP update doesn't properly handle the referral operation, the application could fail.
Finally, if a user from another domain in the forest attempts to authenticate to an RODC, the RODC must be able to access a full DC in its own domain in order to obtain the trust password to properly pass the authentication request to the DC in the user's domain. If the network connection between the RODC and the full DC in its domain is unavailable, the authentication will fail.

Fine-Grained Password Policies
The ability to define more than one password policy in the domain was probably the most-requested feature for Windows Server 2008 ADDS. As you probably know, in Windows 2000 and Windows Server 2003 Active Directory, each domain supports only a single password policy that is applied to all security principals in the domain. If you need a separate password policy for a specific group of users, you have to create a separate domain. But now a new feature in Windows Server 2008 ADDS, called Fine-grained Password Policies, lets you define multiple password policies in a domain.
The new strategy uses groups to apply fine-grained password policies to users. You first define the fine-grained password policy by creating a new msDS-PasswordSettings object in the CN=Password Settings Container, CN=System, DC=<domain> container. The msDS-PasswordSettings object (PSO for short) contains attributes that parallel the password policy setting in Group Policy (see Figure 7).
Figure 7 Attributes in the mSDS-PasswordSettings object (Close Figure 7)

Attribute | Description
mSDS-PasswordReversibleEncryptionEnabled | Boolean indicating whether passwords are encrypted using reversible encryption.
mSDS-PasswordHistoryLength | Number of entries maintained in password history.
mSDS-PasswordComplexityEnabled | Boolean indicating whether password complexity restrictions are enabled.
mSDS-MinimumPasswordLength | Integer defining minimum length of password.
mSDS-MinimumPasswordAge | INTEGER8 indicating minimum password age before it can be changed.
mSDS-MaximumPasswordAge | INTEGER8 indicating maximum password age before it must be changed.
mSDS-LockoutThreshold | Integer indicating number of failed logins before lockout.
mSDS-LockoutObservationWindow | INTEGER8 indicating number of nanoseconds within which consecutive failed logins have to occur to trigger lockout.
mSDS-LockoutDuration | INTEGER8 indicating number of nanoseconds account is locked out.
You then assign the password policy to users or groups by adding the user or group names to the multi-valued mDS-PSOAppliesTo attribute of the PSO. Once you accept the idea that you don't apply password policies to OUs, it's pretty straightforward. But there is some additional complexity.
Users are usually members of many groups. So what happens if there are multiple conflicting password policies associated with a user because of these group memberships? In this case, ADDS uses a precedence evaluation to determine which password policy should be applied. It works like this:
  1. If a password policy is linked directly to a user object (not via group membership), that password policy will be applied.
  2. If there are multiple password policies linked directly to the user, the policy with the lowest precedence value (as determined by the value of the msDS-PasswordSettingsPrecendence attribute of the PSO) will be applied.
  3. If there are multiple PSOs with the same precedence, the one with the lowest objectGUID value will be applied.
  4. If no PSOs are linked directly to the user, ADDS will evaluate the PSOs linked to the user's groups. If there is more than one PSO, the PSO with the lowest value in the msDS-PasswordSettingsPrecedence attribute will be applied.
  5. If there is more than one PSO with the same precedence value, the one with the lowest objectGUID value will be applied.
  6. If no PSOs are associated with the user, the domain password policy will be used.
User objects have a new attribute called msDS-ResultantPSO to help sort out exactly which PSO applies to a user. This attribute contains the distinguished name of the PSO that governs the password of that user.
Fine-grained password policies give you more flexibility than you could ever need, but you must manage these policies carefully and keep them simple. There is no in-the-box utility for defining fine-grained password policies; you will either need to use ADSIEdit or find a third-party utility.

Restartable Active Directory Service
Every time you take a domain controller down for DIT maintenance you cause some disruption in your network service levels. Windows Server 2008 DCs have a new feature that lets you stop the directory service without completely shutting down the DC.
The NET STOP NTDS command stops ADDS on a Windows Server 2008 DC. When you do this, the Local Security Authority (LSASS) process on the DC continues to run, but it unloads all the ADDS-related DLLs and the directory service becomes unavailable. LSASS then behaves essentially as it would on a member server by forwarding domain authentication requests to a DC. Because the DLLs that handle ADDS are unloaded, you can apply ADDS-related patches or perform an offline defrag of the DIT. Starting ADDS is as simple as NET START NTDS. Restoring the DIT from a system state backup still requires you to boot into directory service repair mode, however.
It's important that you understand that the directory service is not a real Windows service. It is still an integral component of LSASS and you can't stop LSASS without shutting down the machine. But the ability to start and stop the directory service in Windows Server 2008 is a convenient option.

Backup and Recovery
The entire backup and restore mechanism has been revamped in Windows Server 2008. I won't go into all the details here, but the new Windows Server Backup has some changes that affect ADDS.
Windows Server Backup is a volume-based backup solution, meaning it backs up entire disk volumes at a time. It also only backs up to disk (or disk-like) devices—there is no tape support.
There is a system state backup option for the WBADMIN command line backup utility. Using the WBADMIN START SYSTEMSTATEBACKUP command, you can now create a backup image that contains all the critical system files necessary to restore Active Directory on a domain controller. There is, however, a potential for as many as five volumes in the backup set, but the volumes in the backup set will contain only the files needed for a system state restore. Even more annoying is that, as of the RC0 build of Windows Server 2008, you cannot perform a system state backup to a network share. You must have a local disk volume available to store system state backup images, and that volume must not be part of the system state backup volume set. You may have to add a new disk volume to every domain controller on which you perform system state backups.
Performing a system state restore is simple. Just boot the DC into Directory Services Restore Mode and run the WBADMIN START SYSTEMSTATERECOVERY command. The result is a non-authoritatively restored DIT, on which you can authoritatively restore specific objects using NTDSUTIL, just as you did in Windows Server 2003.
One aspect of Windows Server Backup deserves special mention: it stores backup images in Virtual Hard Disk (VHD) format. This is the same format that Microsoft Virtual Server 2005 uses to store its virtual disk images. This means you can take a backup image created with Windows Server Backup and mount it as a disk drive in a virtual machine running under Microsoft Virtual Server. You can then browse the backup contents as if it were a normal disk drive!
Another change regarding ADDS backup is the ability to use the Volume Shadow Copy Service to create point-in-time snapshots of Active Directory. When you create a snapshot using NTDSUTIL, the Volume Shadow Copy Service saves the before-image of each disk block of the DIT before it is overwritten by an update operation. By combining the saved before-images with the current version of the DIT, the Volume Shadow Copy Service can construct a complete snapshot of the DIT with very little overhead. A typical snapshot takes only a few seconds to create, regardless of the size of the DIT.
By itself, this is an interesting capability, but not all that useful. However, in Windows Server 2008, ADDS includes a command-line utility called DSAMAIN that mounts the snapshot image in read-only mode. This provides a standalone LDAP server, much like an ADLDS instance that contains the contents of your directory at the time of the snapshot. You can browse the directory using the LDP utility or other LDAP tools and retrieve versions of directory objects from an earlier point in time.

SYSVOL Replication with DFS-R
Windows Server 2003 R2 featured a revamped Distributed File Service (DFS) that incorporated a brand-new file replication mechanism called DFS-R. It uses remote differential compression, which substantially reduces file replication traffic by determining which blocks of a target file need to be replicated to bring it into sync with the source file. However, Windows Server 2003 R2 still uses File Replication Service (not DFS-R) to replicate SYSVOL between domain controllers. Because of this, SYSVOL replication continued to be a source of problems for Active Directory administrators.
When running at the Windows Server 2008 domain functional level, Windows Server 2008 can replicate SYSVOL using DFS-R, improving the speed and robustness of SYSVOL replication. And this makes it reasonable to place large files in SYSVOL to make them available on all DCs. To use DFS-R for SYSVOL, you must first migrate the old SYSVOL data to DFS-R using the DFSRMIG utility. This process has four steps:
  • Create the Active Directory objects required by DFS-R.
  • Create the new file structure for SYSVOL on each domain controller.
  • Switch over all domain controllers to use the new SYSVOL.
  • Remove the old SYSVOL.
Depending on the size of your SYSVOL and the number of domain controllers you have, this process may take a while, but the improved performance and reliability make the effort well worth your while.

Auditing Improvements
The auditing system in Active Directory for Windows Server 2003 is both a blessing and a curse. On the one hand, it provides a pretty comprehensive, flexible, and secure solution for tracking changes in the directory. But some may argue that it suffers from several significant usability problems.
Enabling auditing of directory changes on a Windows Server 2003 domain controller is pretty much an all-or-nothing affair—it's either on or it's off. And the volume of audit traffic on a busy enterprise DC can render auditing impractical. Configuring the auditing system to produce the messages that you really need by fiddling with individual security descriptors is tedious and prone to error. The audit messages themselves are often cryptic, and in many cases don't contain the information you need, such as the before and after values of changed attributes. And collecting, correlating, and archiving the messages from multiple domain controllers is not really feasible using the native Windows tools.
The directory services auditing system in Windows Server 2008 addresses some of these problems. First, there are four new audit subcategories for directory service auditing: DS Access, DS Changes, DS Replication, and Detailed DS Replication. So if you want to just audit directory changes, you don't have to wade through all of the read and replication events. But, if you want to include object deletions in your audit log, you must enable DS Access. This generates messages for all DS object accesses, essentially putting you back to generating too many messages. And it is still up to you to configure the security descriptors to generate the audit messages that you want for the objects you care about.
The audit messages have been substantially cleaned up so that they are both readable and contain the data you need. In particular, directory changes generate audit log entries that contain the old and new values of changed attributes. This is a huge improvement. The only downside here is that the old and new values appear in separate audit log entries, so you have to correlate them to really understand the change that was made. Many add-on audit-log collection products, including the Microsoft Audit Collection Services, support this kind of correlation.

UI Improvements
The Active Directory Users and Computers, Sites and Services, and Domains and Trusts MMC snap-ins have always been adequate for managing Active Directory. In Windows Server 2008, the basic admin tools have been cleaned up and introduce a couple of nice new features. If you enable Advanced Features, the Properties dialog for each object displays an additional tab titled Attribute Editor. This is the same attribute editor tab used by ADSIEdit, which lets you inspect and edit all of the attributes of the object. The tab itself now offers better decoding of encoded attributes, such as the userAccountControl attribute. Figure 8 shows how seamlessly the attribute editor is integrated.
Figure 8 Attribute Editor in Active Directory Users and Computers
Figure 8 Attribute Editor in Active Directory Users and Computers

Wrapping Up
Aside from the key points I've discussed in this article, there are many other improvements you'll find in ADDS in Windows Server 2008. For instance, the KDC uses the 256-bit Advanced Encryption Standard (AES-256) if the domain is in Windows Server 2008 domain functional level. You can enable Accidental Deletion Prevention of objects by checking the appropriate box on the Object tab for any DS object. The Extensible Storage Engine that provides the data management service has been enhanced to use single-bit error correction, reducing the likelihood of a hardware or software error in the disk subsystem from corrupting the DIT. The DNS service starts processing requests before it has completely loaded the DNS database. The DC Locator module has been enhanced so that if it fails to find a DC in the desired site, it will try to locate a DC in the next nearest site instead of simply using any DC it can find in the domain. And NTDSUTIL now supports RODCs and Volume Shadow Copy Service snapshots.
Clearly, Windows Server 2008 provides a substantial number of improvements in Active Directory Domain Services. Taken together, these changes will significantly improve the security and manageability of ADDS. The best thing, however, is that integrating Windows Server 2008 into your Active Directory environment doesn't involve a massive migration—it's an easy and incremental process.

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 (go to www.dec2008.com).


 Special Coverage: Windows Server 2008: Getting Started with IIS 7.0
Special Coverage: Windows Server 2008 Isaac Roybal

Getting Started with IIS 7.0
At a Glance:
  • IIS 7.0 Architecture changes
  • Managing IIS 7.0
  • Backward compatibility
  • IIS 7.0 troubleshooting

Every IT shop is different; each has its own unique set of needs and objectives, especially when it comes to the hosting of Web sites or services. Web servers may need a sprinkle of this or a dash of that to meet the requirements of the organization, and then there's the challenge of
replicating that recipe to multiple servers while at the same time managing them all efficiently. Some of the biggest changes in IIS 7.0 aim to help IT shops do exactly that when building a Web server or Web farms.
As I ran down the list of all the great features in IIS 7.0, I became very excited to share the details of these features with you. When I realized I couldn't possibly cover all of them here, I decided to focus on some of the most significant features and biggest changes in IIS 7.0. For even more information, visit the IIS community Web site at IIS.net.

New Architecture
Core changes in IIS 7.0 relate to the architecture, request processing, PHP application framework support, and the configuration store. With IIS 6.0, the features were basically an all-or-nothing proposition. You had to install all of the features and could only customize IIS using ISAPI.
IIS is built on the premise that a Web administrator wants to start from a base set of functionality, then layer on only the required additional functionality desired in his environment. You know your environment the best, so IIS 7.0 gives you the building blocks to create your own custom Web server. By doing so, it lowers your administrative overhead by reducing the attack surface of your server and eliminating the need for updates to components that are not used. The key to this new approach is the modular architecture of IIS 7.0.
IIS 7.0 has a new design that lets you choose the functionality, known as modules, to be installed on the server. These modules plug directly into the integrated request pipeline. This new modular design has several benefits, including reducing both the attack surface and the footprint of your Web server.
IIS currently has 40 default modules—for example, basic, anonymous, and Windows® authentication are now individual modules that can be added to the request pipeline independently. For simple classification, the modules are grouped in eight subcategories (see Figure 1).
Figure 1 IIS 7.0 modules are classified into eight functional areas
Figure 1 IIS 7.0 modules are classified into eight functional areas
This means you now have the ability to build a customized Web server exactly tailored to your environment. But what if you need functionality that the 40 default modules don't supply, perhaps some sort of custom authentication or content modifier? No problem. You can write a module in native or managed code to fill this need and plug it right into the pipeline. This also allows Microsoft to write and release new modules individually so you don't have to wait for the next service pack or major product release. IIS 7.0 also grants you the ability to overwrite any of the 40 default modules with your own custom modules. For more information on how to build your own module, see IIS.net.

Integrated Request Pipeline
Think of the integrated request pipeline as the essential set of linear steps that must occur every time a page is served up (as seen in Figure 2). Typically, some sort of authentication must take place, followed by authorization to retrieve content, determination and execution of the handler needed for that content, performance of any necessary logging, and finally sending a response. The integrated request pipeline provides IIS 7.0 the flexibility to run different application frameworks at the same time. For example, you can run Forms authentication on top of PHP content with a custom logging module, all together in the same pipeline.
Figure 2 IIS 7.0 integrated pipeline and modules
Figure 2 IIS 7.0 integrated pipeline and modules
Each Web site on the server has an integrated request pipeline and can be run in one of two modes, Integrated and Classic. Integrated, the default, allows particular pieces of functionality to be plugged into the pipeline, giving you granular control over the request process. For compatibility, Classic mode reproduces IIS 6.0/ISAPI functionality through an ISAPI module into the pipeline. This is very helpful when migrating your applications to IIS 7.0.

Default Installation
Now let's talk about setting up your new modular Web server. If you look at a default install of IIS 7.0, you'll notice that only 10 modules (if you include the Windows Process Activation Service) are included. IIS 7.0 setup provides the base functionality of IIS when installing the Web Server Role, specifically only the modules needed to serve up static content, like plain HTML or classic ASP. What is installed on the server after this is strictly up to you. Here is the functionality included in a default installation:
  • Common HTTP features including Static Content, Default Document, Directory Browsing, and HTTP errors
  • Health and Diagnostics features such as HTTP Logging and Request Monitor
  • Security features such as Request Filtering
  • Performance features such as Static Content Compression
  • Management Tools including IIS Management Console
  • Windows Process Activation Service
As you can see, this is a bare minimum server that doesn't include ASP.NET or other new IIS 7.0 functionality like the diagnostic and troubleshooting features. To enable additional functionality on the server, such as the ability to deliver dynamic content like ASP.NET and FastCGI (PHP), is simple. Select the set of modules that you would like to install from the Web role's "Add Role Services" within Windows Server® Manager.

New Configuration Store
Another key change to IIS 7.0 that will make your life easier is the new configuration store. The metabase, now an optionally installed component for backward compatibility, has been replaced by an XML configuration system. I can hear you already, "But the metabase was XML!" Yes, it was. But it was cumbersome and not easy to read (at least not by humans). It has been replaced with a more flexible XML system. Like ASP.NET, IIS 7.0 uses .config files—clean, simple, portable, and easy-to-read .config files.
Moving to this format means that the configuration system is now machine-independent, unlike the metabase that was keyed to an individual machine. As a result, you can now easily port the config system over to other servers with a simple drag and drop or xcopy, and away you go.
This new config system also works wonders for Web farms by utilizing a new feature in IIS 7.0 called Shared Configuration. Since this new config system is portable, you can share one master .config file among all nodes in the farm. Shared Configuration allows you to export the config of a known good pre-production server and then share it across your production or "live" environment.
When exporting the .config file you must provide it with an encryption key password. This protects the .config file from a rogue Web server attempting to mimic your server's .config without authorization.
Enabling Shared Configuration is simple. In the server node of IIS Manager, select Shared Configuration, which is located under the Management section of the task pane. Simply check "Enable shared configuration," provide the physical path of the configuration you are going to share (typically this will be a UNC share), enter the credentials needed to access the physical path, and click Apply. When the .config is found, you will be prompted its the encryption password. Once this process is completed, restart IIS Manager so it will pick up the new .config.
The structure of the new configuration system is different from that which you're used to, so let's go over the basics. As Figure 3 shows, the configuration of IIS 7.0 has been broken into two categories, server-wide settings and site-specific settings. All server-wide settings are stored within applicationhost.config, which is located in %systemroot%\windows\system32\inetsrv\config. This includes all modules installed, sites on the server, and so forth. Site-specific settings are stored in individual web.config files.
Figure 3 There is one .config file for server-wide settings and separate individual ones for each Web site on that server
Figure 3 There is one .config file for server-wide settings and separate individual ones for each Web site on that server
If you've used ASP.NET, you're probably familiar with web.config files. IIS 7.0 uses web.config files to store settings specific to individual Web sites, such as a site's default document and application settings, as well as ASP.NET settings. This means you will have a web.config file for each site on your server.
A site's web.config file is located in the physical path of the site, such as %systemroot%\inetpub\wwwroot, for example. This design yields the same portability benefits noted earlier but at the site level. You can easily develop a site on a test server, for example, and then simply drag and drop, or xcopy, the site's web.config and application files over to a production server.
Whenever porting or sharing .config files, watch for machine-specific information like IP addresses and drive letters. IIS 7.0 provides a remedy for this possible oversight with support for OS environment variables (such as %systemroot%). Also ensure that the same set of modules is installed across the test and production servers. This will help avoid unexpected application errors. Errors can also occur if the web.config references a module that isn't installed or if a default module conflicts with a custom module.

Managing Your Web Server
So now you have this great, new, customizable, flexible, and portable Web server. How are you going to manage it? Management was a big part of the planning and building of IIS 7.0, and there are several ways to handle administrative chores.
Management preferences typically fall into at least one of three categories: point-and-click administration from the UI, entering commands at the command line, and writing scripts to automate as much as possible. Let's start with the UI.
In IIS 6.0, the UI Microsoft® Management Console (MMC) snap-in had two basic, familiar views, Tree view and Tab view. To drill into a setting, you'd right-click, select Properties, and then you'd be presented with a bunch of tabs, not to mention the Radio buttons and checkboxes.
Happily, the UI in IIS 7.0 has been completely revamped. This UI, named IIS Manager, was designed to enable a task-oriented approach, as Figure 4 shows. There's also a Remote Manager for down-level clients such as Windows XP and Windows Server 2003. You can download it via IIS.net/downloads.
Figure 4 New UI in IIS 7.0
Figure 4 New UI in IIS 7.0
The new user interface consists of the Connections pane on the left, the Actions pane on the right, and the task pane or workspace in the middle. The connection manager tree on the left is similar to the IIS 6.0 tree view with parent and child nodes. New to the tree view is the ability create new connections, save current connections, or delete existing connections. The task pane is the UI's biggest improvement, with two views to work from. The feature view takes all configurable properties of IIS out from the old "tabs" view and groups them by administrative area, such as IIS, management, and security.
ASP.NET properties have also been integrated into IIS Manager, eliminating the need to use an additional MMC snap-in. Each configurable property has its own icon, making it easy to locate. And because IIS Manager was built as a Windows Forms application, you can easily add plug-in icons for any custom modules or functionality you write.
The task pane's second view is content view, which is very similar to IIS 6.0 in that you see what is in a site's content directory and can perform actions against that content. What is new here is the ability to select a specific piece of content, say a specific Web page, then switch to feature view to invoke certain settings on the selected content, which gives you granular control down to the page level.

Other Ways to Manage
For those who prefer the command line, there's a powerful new tool named APPCMD.exe that lets you perform simple tasks such as stopping a site or backing up the current .config file, as well as more complex tasks such as searching the configuration's schema. The syntax is very simple:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
To list all objects available to APPCMD, type:
APPCMD /?
Or, if you want to see the commands available for a certain object type, enter:
APPCMD (object-type) /?
For all the coders out there, a managed code API called Microsoft.Web.Administration and a new Windows Management Instrumentation (WMI) provider have been added to IIS 7.0. These two methods open up a ton of options to script, automate, and write tools to manage IIS 7.0. Both can be used with Windows PowerShell®, and the WMI provider can also be used with VBScript and JScript®. For additional information, see blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Remote Management and Delegated Administration
IIS 7.0 provides new ways to remotely manage your server, sites, Web applications, and securely delegated administration rights for non-administrators. First let's talk about the new remote management capabilities and how they can make your life easier.
In the past, there were two ways to manage an IIS server remotely: by using the remote management Web site or by using remote desktop/terminal services to access the UI. But if you were outside your firewall or not on-site, these options were not very useful. IIS 7.0 remedies this by building remote management capabilities directly into the UI that work via firewall-friendly HTTPS.
Remote management in IIS 7.0 makes life easier in several ways. First, you get the same UI experience as if you were logged on locally. Second, there's no need to open ports on your firewall since communication happens via HTTPS. Lastly, you can now manage several servers from a single UI. No need to have multiple Remote Desktop or remote Web site windows open at the same time.
The actual remote management service within IIS 7.0 is essentially a small Web application which runs as a separate service, under a Windows NT® local service account named NT Service\WMSVC. This design maintains the remote management functionality even if the IIS server itself is unresponsive.
Like most features within IIS 7.0, for security purposes, remote management is not installed by default. To install the remote management features, add role services for the Web Server role in the Windows Server 2008 Server Manager, which can be found under Management Tools. Once this feature is installed, you then have to enable remote connections and start the WMSVC service since it's stopped by default.
The WMSVC service's default startup setting is manual. If you want the service to start automatically after a reboot, you will need to change the setting to automatic. You can do so via the command line by typing:
sc config WMSVC start=auto
When enabling remote connections via the management service, you'll see a list of settings such as Identity Credentials, Connections, and IPV4 Address Restrictions. The only decision that is critical at this point is determining which set of identity credentials to grant permission to connect to IIS 7.0: Windows credentials only or Windows and IIS Manager credentials.
The first option is fairly oblivious, indicating that you want to allow only Windows user accounts, whether local or domain. The second option involves both Windows users and a type of account that's completely new in IIS 7.0 and is not associated with Windows user accounts: IIS Manager Users. With IIS Manager Users, administrators have the ability to create user accounts that are known only in the context of IIS 7.0 and have no access to the OS. Lastly, by default, IIS provides a self-signed certificate to get started, but it is recommended that you add a valid signed SSL certificate. Now just apply your setting and start the service.
For additional control and security, IT administrators have the ability to securely delegate administration tasks of individual sites or Web applications to non-admins.
Delegated Administration is essentially remote administration, but it limits the scope of access to individual sites or Web applications. The IIS Manager Users feature is particularly handy here. You can create IIS users for those one-off site owners and delegate permission to administer their own site or application. They have no access to server-wide settings and are limited to settings only for their specific site or Web app.
You can also specify what features and settings users can change and even which appear in the UI. For example, if you don't want someone to change the type of authentication used for his site, you can set that feature to either read-only or not inherited. When a feature is read-only, users can still access the feature and determine the setting but not make changes; and with the not-inherited setting, the feature icon will not appear in the delegated user's IIS Manager view. This kind of feature delegation lets you provide strictly controlled access to others without providing administrative control over the Web server.

Moving Forward to IIS 7.0
When designing IIS 7.0, the team wanted to ensure the transition to it was as fluid as possible by allowing the use of some of your existing investments in management tools and scripts for IIS 6.0. A lot of thought was put into the backward compatibility of IIS 7.0 so it would work with your IIS 6.0 scripts. There is an entire set of tools—ranging from IIS 6.0 metabase compatibility to the actual IIS 6.0 management console—that you can install under the IIS 6.0 management compatibility node in setup.
The IIS 6.0 metabase compatibility infrastructure uses a component called ADOMapper. It allows you to run your IIS 6.0 Admin Based Object (ABO) and ADSI (Active Directory Services Interface) metabase scripts against the new config system, limiting it to only what IIS 6.0 could do. Thus, it can't read or write new IIS 7.0 properties, access new runtime data, or read or write ASP.NET properties or web.config files.

Troubleshooting and Diagnostics
Troubleshooting and diagnostics have always been time-consuming chores. Digging through logs and trying to reproduce a problem in a large Web farm or even a single server can be tough. IIS 7.0 has a tool called Failed Request Tracing to help relieve some of that pain and wasted time. It can be helpful in many situations, including when a request hangs or produces errors and for investigating authentication and authorization problems.
Failed Request Tracing uses tracing rules as a criterion to search for errors. Tracing rules can be created to look for types of behavior or errors by specifying the type of content you'd like to trace (such as all content on the server, only ASP.NET content, or custom content such as PHP) and under what conditions the trace should begin (such as a certain returned status code, time taken to serve the page, event severity, or a combination).
Suppose, for example, users report that a site is taking too long to load. That's a tough scenario to reproduce in any case but especially if you have thousands of hits per hour. With Failed Request Tracing, you simply add a tracing rule to start logging when a page takes more than the desired amount of time to load—for this example, I'll say two seconds—and wait for the server to reproduce the problem on its own (see Figure 5).
Figure 5 Using Failed Request Tracing for troubleshooting
Figure 5 Using Failed Request Tracing for troubleshooting
The difference between Failed Request Tracing and traditional logging is that the former only logs when a particular failed request criterion is detected. The log file itself is XML topped with an XML style sheet, making it clean and easy to read. Like most other IIS 7.0 features, this is not installed by default and can be found under the health and diagnostics section of setup. You must also enable it within IIS Server Manager.
IIS 7.0 is a great leap forward for all administrators. It's new architecture and capabilities provide the agility and flexibility needed to adapt to your ever-changing environment. With the management features, backward compatibility tools, and troubleshooting capabilities, it is ready to be deployed today and work with your existing environment.

Isaac Roybal is a Product Manager in Windows Server at Microsoft. His responsibilities cover all things Web-related with Windows Server. Isaac has worked with Windows Server since Windows NT 3.51 and IIS 4.0. Before that he was an Operations Program Manager for the Office Internet Platoform & Ops group. He has an MCSE certification in Windows NT 4.0, Windows 2000, and Windows Server 2003.


 Special Coverage: Windows Server 2008: Policy-Driven Network Access with Windows Server 2008
Special Coverage: Windows Server 2008 Ian Hameroff and Amith Krishnan

Policy-Driven Network Access with Windows Server 2008
At a Glance:
  • Balancing network access and security
  • A policy-driven approach to network access
  • New security technologies in Windows Server 2008

Much has been written about the disappearance of traditional network perimeters brought about by an increasingly mobile workforce and the growing diversity of users and devices requiring
access to an organization's IT resources. To boost productivity, users and line-of-business owners alike are driving demand for a connected experience that is both fluid and free from tedious procedures. Adding to this already complex situation are increasing regulatory compliance burdens, the evolving threat landscape, and the risks associated with the decentralization of data.
This tends to leave Windows® administrators smack-dab in the middle of a challenging security balancing act: how to enable easy access to resources while still meeting ever-increasing information and network security requirements.
Though there may not be a single solution to all these challenges, as Windows administrators you do have a number of tools at your disposal that can help augment the security controls—like edge firewalls—you already have in place. A great way to help strike the appropriate balance between access and security is to shift from traditional connectivity models to one that seeks to define network access in a more logical and policy-centric fashion.

A Policy-Driven Network Access Approach
Networking Resources
  • IPsec
  • Windows Firewall with Advanced Security
  • Server and Domain Isolation
  • WNetwork Access Protection (NAP) for Windows Server 2008

Policy-driven network access aims to remove the existing limitations encountered when trying to base trust primarily on network topology edges. For instance, can you really determine that a device is trusted and authorized to connect to the servers that run your Customer Relationship Management (CRM) application, just because it is plugged into one of your Ethernet switch ports behind the corporate firewall?
Instead, the new model drives access decisions by authenticating both the security posture of the device and the identity of the user requesting the access, no matter where he is connecting from. Once authenticated, this same framework can then be used to authorize what information and resources may be accessed.
Making the shift from a defensive posture to one that is more access-focused involves a number of key ingredients, including having in place mechanisms that can validate the identity and policy-compliance of the connecting hosts, issue a trusted user identity, and dynamically control network access based on these attributes. To simplify the management of these various moving parts, a centralized policy store is also an important component.
Adopting a policy-driven approach can help you weave together a number of potentially disparate network access and host security controls into a more comprehensive solution. This in turn enables you to set network access ground rules at a logical layer above the connectivity fabric, thus evolving traditional defense-in-depth best practices.
For example, when a user connects his laptop to the organization's wireless network, the device can be checked for compliance with the latest security configuration requirements. Once it's determined that the laptop has all the current antivirus updates and critical security patches, and has all of its endpoint security controls enabled—like a host firewall—access to the corporate network can be granted. Then, when the user attempts to access a business application, the combination of the laptop's health state and the user's network identity can be used to determine if he is authorized to connect to the resources that host the application. By operating at this logical layer on top of the physical network infrastructure, the policies can be continually enforced, even if the user moves from wireless to a wired or even a remote-access connection.
When implemented, policy-driven network access can deliver a more seamless connected experience for users, without sacrificing security in the process. For administrators, up-leveling network access controls from switch ports or remote access gateway configurations can provide a simpler management experience. In both cases, the end result is increased productivity and an overall improvement of the health of the organization's network, even when the networks may play host to parties with differing access rights, such as guests (invited or otherwise), vendors, partners, and employees.
As with any security project, the first step in implementing policy-driven network access means developing a set of holistic operational policies. This normally includes guidelines for:
  • Device security compliance—what does it mean for a device to be healthy?
  • Logical network zoning—how will you segment unhealthy devices from authorized ones?
  • Information risk management—how is sensitive data classified and protected from compromise?
Luckily, a variety of policy-development resources are available at the Microsoft® TechNet Security Center (microsoft.com/technet/security).
Once you've developed the access policies, you will need to select technologies that can both easily distribute and effectively enforce them. For this, you need to look no further than Windows Server® 2008. That's because Windows Server 2008 is not only the most secure Windows Server to date; it also offers administrators a hardened security platform that can form the cornerstone of a policy-driven network access solution. Among its long list of new and enhanced features, Windows Server 2008 delivers many of the ingredients necessary to implement secure, policy-based access to your network, helping to ensure that sensitive information is safeguarded from compromise.

Next-Generation Networking
At the core of the network security advancements in Windows Server 2008 is the Next-Generation TCP/IP Stack, a major update to the platform's networking functionality and related services. Besides delivering improved network performance and increased scalability, Windows Server 2008 boosts security through a series of integrated network features that provides a solid foundation on which a policy-driven network access solution can be built.
Internet Protocol security (IPsec) is one such feature that was significantly upgraded in Windows Server 2008 so it could play a key role in a policy-driven network access approach. Now, this isn't about using IPsec as a tunneling and encryption protocol but instead leveraging its host-to-host network authentication capabilities. In addition, since IPsec works at Layer 3, it can be utilized to enforce network access policies across a variety of network types.
To help make implementing IPsec-based network-access controls easier, Windows Server 2008 introduces a long list of improvements and new features aimed at simplifying policy creation, enforcement, and maintenance. For example, the number and types of available IPsec authentication methods have been increased. This was accomplished through the introduction of Authenticated IP (AuthIP), an extension to the Internet Key Exchange (IKE) protocol. AuthIP gives you the ability to author connection security rules (another name for IPsec policies in Windows Server 2008) that require communicating peers to successfully authenticate each other with not only machine credentials but optionally with user or health credentials. This added flexibility enables the design of very sophisticated logical networks without the need for upgrading your switching and routing infrastructure.

Windows Firewall with Advanced Security
The new Windows Firewall with Advanced Security builds on top of the IPsec features just described. By combining IPsec connection security rules with firewall filters into a single policy, the new Windows Firewall adds another policy-driven network access dimension: more intelligent authenticating firewall actions.
As shown in Figure 1, you now have three options to choose from when defining the specific action an inbound or outbound firewall filter should take: allow, block, or allow only if secure. When "Allow the connection if it is secure" is selected as the action, the Windows Firewall leverages the host-to-host network authentication capabilities of IPsec to determine whether a host or a user requesting to connect should be approved based on the policy you've defined. The firewall rule lets you stipulate which users, computers, and groups have the right to make the connection. It's worth noting that this adds an additional layer of protection, supplementing existing operating system- and application-level access controls.
Figure 1 Defining authenticating firewall rules
Figure 1 Defining authenticating firewall rules
By now, you should begin to see how it's possible to weave together these different network security controls through a centralized policy for a more effective and scalable means to manage network access.
Returning to the CRM example: the administrator could create an inbound rule for the servers running the company's CRM application (either via the program's executable or service ports) with the "Allow the connection if it is secure" option checked. Within the same firewall policy, the administrator can specify that only members of the "CRM Application Users" group can connect to this network application, as shown in Figure 2. If you take this same concept and scale to all network communications among all the managed computers on your network, you've now added a Server and Domain Isolation layer to your policy-driven network access strategy.
Figure 2 Admins can specify who can connect based on this policy
Figure 2 Admins can specify who can connect based on this policy

Server and Domain Isolation
With most organizations experiencing an increasing number of guests and other unmanaged devices connecting to their networks, having the means to separate and protect your trusted hosts has become ever more critical. The good news is there are many ways to isolate trusted and managed computers from the others on the network. However, you should know that many of these options are costly (running separate physical cabling systems, for example) and difficult to maintain (such as switched-based VLANs) as networks grow.
Server and Domain Isolation can provide a more cost-effective and manageable means to segment your environment into logically isolated and secure networks. As Figure 3 shows, you essentially use the same connection security rules (that is, the IPsec policies) mentioned earlier, but map them to all of your managed computers via Active Directory® Group Policy. This results in a network access policy that requires all peers to successfully authenticate with each other before any communications begin. Since this isolation occurs at Layer 3, the enforcement of these access controls spans hubs, switches, and routers across physical and geographical boundaries.
Figure 3 Defining authentication requirements to match your network access needs
Figure 3 Defining authentication requirements to match your network access needs
To create an isolated network, the various computers on the network should be separated according to the type of access desired. Policies can be defined such that computers on an isolated network are able to initiate communications with all of the computers on the network, including those not located on the isolated network. Conversely, computers that are not on the isolated network cannot initiate communications with computers that are on the isolated network. In fact, computers on the isolated network will ignore all requests for communication from computers outside the isolated network.
An Active Directory domain and domain membership are used to enforce the network policy. Domain member computers accept only authenticated and secured communications from other domain member computers. Optionally, it can also be mandated that all communication within the isolated domain be encrypted.
Server and Domain Isolation provides significant cost benefits since no major changes to the existing network infrastructure or applications have to be made. This solution creates a policy-enabled veil of protection that not only helps defend against costly network attacks and unauthorized access to trusted network resources but also does not require ongoing maintenance based on changes in network topology.

Network Access Protection
As described previously, the Server and Domain Isolation solution ensures logical separation of the various computers and servers on the network. While this solution helps prevent unauthorized access to the network, there is no guarantee that an authorized computer will not be the cause of a security threat.
Network Access Protection (NAP) is a built-in platform in Windows Server 2008 that helps ensure that computers connecting to a network or communicating on a network meet requirements for system health (that is, security and policy compliance) as you have defined it.
Even authorized users are often responsible for propagating viruses and spyware on the network. For example, when a user goes on vacation, his computer could fall out of compliance with the security requirements set by the administrator. This could have potentially serious repercussions if a mandated patch or signature released during the absence doesn't make it to the computer.
It is well beyond an administrator's available bandwidth to keep track of every user who connects to the network. What is needed is an automated tool that can verify the health compliance of every computer connecting to the network, remediating any that are found to be non-compliant, all based on a central policy. NAP does just that, adding yet another layer to your policy-driven network access solution.
The NAP agent—either built into the OS of the client computer (such as in Windows Vista®) or separately installable (for older versions of Windows as well as non-Windows operating systems)—reports any compliance issues to the Network Policy Server (NPS), which is the policy engine built into Windows Server 2008. It is in the NPS where you define the compliance policies that every device must adhere to.
While it is necessary to restrict devices that fail compliance checks, it's important to ensure they have the option to quarantine and remediate. NAP provides the option either to automatically remediate the device in cases where the firewall or antivirus solution is turned on or to manually remediate the device by forcing it into a quarantine zone. Here, the device has access to a remediation server with the latest patches, updates, and signatures. Once the user manually updates the device, it is granted access to the network, subject to passing the compliance verification.
With ubiquity, network access has become much simpler. However, this has created an added burden of ensuring that devices are healthy and compliant irrespective of the access mechanism. Computers can access the network via a regular 802.1X-compliant switch or wireless access point, or they may connect remotely from home using a VPN- or Terminal Services-based remote access connection. NAP not only ensures compliance for computers that connect via these different mechanisms but also provide enforcement at the DHCP server, 802.1X switch, VPN gateway, Terminal Service gateway, or 802.1X-compliant wireless access point.
In Figure 4, the network has already been isolated using the server and domain isolation solution. Using NAP with such an isolated network provides additional benefits to ensure health compliance for computers connecting to the network. The client, on startup, sends its statement of health (SoH) to the Health Registration Authority (HRA), which is a certificate server. The HRA passes the SoH to the NPS for policy validation. If the SoH is valid, the HRA issues the NAP client a health certificate and the client can now initiate IPsec-based secure communication with secure resources. If the SoH is not valid, the HRA tells the NAP client how to correct its health state and does not issue a health certificate. The NAP client cannot initiate communication with other computers that require a health certificate for IPsec authentication. However, the NAP client can communicate with the remediation server to bring itself back into compliance.
Figure 4 Network Access Protection using IPsec enforcement
Figure 4 Network Access Protection using IPsec enforcement

Bringing It All Together
While we have just skimmed the surface of these new features and functionality in Windows Server 2008, it's important to recognize how each component has built upon the previous. What transforms this from the traditional defense-in-depth approach is the underlying policy framework Windows Server 2008 offers through, for example, Active Directory Group Policy.
Thanks to this integrated experience, you will have a strong working foundation to define and deploy a policy-driven network-access solution without having to undo existing investments. By raising the access decision up to a more logical, policy-centric layer, you have the opportunity to tip the "Easy Access" versus "Increased Security" balancing act into your favor.
Microsoft has published a good deal of guidance that drills down into the technology areas mentioned in this article. We recommend first reviewing these articles and step-by-step guides to gain operational experience with the various features. (The links in the "Networking Resources" sidebar can help you get started.) Then, consider rolling out each stage in a way that it provides a strong foundation for the next stage.
For example, create a set of those authenticating firewall rules for your mission-critical applications, as outlined in the Windows Firewall with Advanced Security section. Once you're comfortable with this, you can expand the connection security rules to isolate your network domain, and then layer NAP on top of that. The benefits of implementing a policy-driven network access strategy can be quite significant, including helping you keep pace with the ever-changing world we call our corporate networks.

Ian Hameroff is a Senior Product Manager in the Security and Access Product Marketing group at Microsoft. He is responsible for the product management and marketing of the Windows Server platform networking technologies. Ian drives the go-to-market strategy for Windows Server networking and solutions focused around key security and networking initiatives, such as Server and Domain Isolation, Scalable Networking, and IPv6 adoption.
Amith Krishnan is a Senior Product Manager in the Security and Access Product Marketing group at Microsoft and holds product management and marketing responsibilities for the Windows Server networking and security initiatives such as Network Access Protection and Secure Wireless. He also develops the go-to-market strategy and drives awareness for these solutions.


 Special Coverage: Windows Server 2008: Configuring Roles with Server Manager
Special Coverage: Windows Server 2008 Byron Hynes

Configuring Roles with Server Manager
At a Glance:
  • The difference between roles and features
  • What you can do with Server Manager
  • Working with wizards
  • Managing roles and features from the command line

One of the themes that seems to permeate Windows Server 2008 is that less is more. I don't mean the idea of needlessly cutting out features. Rather, it is the strategy of simplifying and clarifying roles and tools so that you can install exactly what you need—and nothing more. Server Manager
is an important part of this concept in Windows Server® 2008.
There are two aspects to this. First is the crucially important concept of server roles and features, which are the building blocks of Windows Server 2008. Second is the Server Manager tool itself. This tool not only replaces several tools used in Windows Server 2003, but also brings much more functionality into one place so that busy administrators, like you, can get more done more quickly and easily.

Roles and Features
If you've been reading about Windows Server 2008, you've probably come across some terms that you haven't heard used in the context of Windows® before, such as "workloads" and "roles". I'll start by explaining what these terms mean to IT professionals.
At the beginning of the development cycle for Windows Server 2008, we spent a lot of time trying to find out exactly how our users use our server products. (This effort continues, by the way.) In general, we found that people deploy our servers to do specific things. This might not sound like rocket science, but it was a big eye-opener for some of us to learn that people don't buy our servers just to have a server. More importantly, they don't deploy servers to accomplish myriad tasks. Rather, they want a server to do something specific. Of course, there are exceptions, but in most cases, a server is provisioned to perform a particular function.
In response to these revelations, we grouped the "particular things" into broad classifications, called workloads. For example, there is a database workload and an application server workload. Since workloads are broad and sometimes a bit nebulous, we created subcategories within the workloads called roles. A role is a single, very specific thing that a server is expected to do. Think about how you (and the users in your organization) refer to servers on your network. If you're like most users, you probably think of them as the file server, the domain controller, the print server, the Web server, and so on. Since this is how people tend to think about servers, Windows Server 2008 takes the same approach for dealing with roles.
Broadly, there are three main categories of roles in Windows Server 2008: Identity and Access Management (those roles branded as part of Active Directory®), Infrastructure (this includes file servers, print servers, DNS, and so on), and Application (such as the Web Server role and Terminal Services).
There will be about 17 server roles shipping with Windows Server 2008 (these include roles such as Active Directory Certificate Services, Network Policy and Access Services, and Windows Server Virtualization). And additional roles, such as the Streaming Media Services role, will likely be available for download.
Each role really deserves its own article. Some of them are discussed more thoroughly in this issue of TechNet Magazine, some have already been covered, and some are still yet to come. You should explore each of them, starting with the information available at technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
As you start deploying Windows Server 2008, you need to choose which roles are installed on each server. This role-based deployment is an important concept for effectively using Windows Server 2008 and being agile when deploying your resources.
The list of roles doesn't include things like BitLockerTM Drive Encryption and Network Load Balancing (NLB). That is because these are features and although desirable, they are not things that users buy a system specifically to do. Roles, on the other hand, do represent tasks for which systems are bought in order to perform. For example, users don't buy servers in order to implement load balancing. They do, however, buy servers in order to serve a Web site. And while NLB may be an essential aspect of, say, a Web server, it's not the purpose for which the server exists.
Rather than have all of the features of the Server installed and active, an administrator chooses which features need to be installed. (The list of features included with Windows Server 2008 is shown in Figure 1.) By including only the roles and features that are needed, stability and security are improved. You don't have to worry about resources being consumed by features or roles that are not installed. And you don't have to worry about troubleshooting features or securing roles that are not installed.
Figure 1 Features included with Windows Server 2008 (Close Figure 1)

Microsoft .NET Framework 3.0 Features
BitLocker Drive Encryption
BITS Server Extensions
Connection Manager Administration Kit
Desktop Experience
Group Policy Management
Internet Printing Client
Internet Storage Name Server (iSNS)
LPR Port Monitor
Message Queuing
Multipath I/O
Peer Name Resolution Protocol
Quality Windows Audio Video Experience (qWave)
Remote Assistance
Remote Server Administration Tools
Removable Storage Manager
RPC Over HTTP Proxy
Services for NFS
SMTP Server
Storage Manager for SANs
Simple TCP/IP Services
SNMP Services
Subsystem for UNIX-based Applications
Telnet Client
Telnet Server
Trivial File Transfer Protocol (TFTP) Client
Failover Clustering
Network Load Balancing
Windows Server Backup
Windows System Resource Manager
Windows Internet Naming Service (WINS) Server
Wireless LAN Service
Windows Internal Database
Windows PowerShell
Windows Process Activation Service
The epitome of this concept is the Server Core installation option. Server Core is beyond the scope of this article, but you can see the logical extension of taking unused roles and features and not even copying them to the hard disk or making them available. One key difference between a normal installation and a Server Core installation is that a normal installation includes the resources required to install additional roles at any time, and it supports all the roles. Server Core, however, does not even have a GUI for its shell, and it only supports a limited number of roles.

Server Manager
The new Server Manager console in Windows Server 2008 makes it easier to manage and secure multiple server roles in an enterprise. Essentially an expanded Microsoft® Management Console (MMC), Server Manager lets you view and manage virtually all of the information and tools that affect your server's productivity. It provides a single source for managing a server's identity and system information, displaying server status, identifying problems with server role configuration, and managing all the roles installed on the server. (Note that it also replaces several features included with Windows Server 2003, such as Manage Your Server, Configure Your Server, and Add or Remove Windows Components.)
In some cases, Server Manager can also reduce the need for the administrator to run the Security Configuration Wizard (SCW) before deploying servers. Server manager will configure your server so that any installed roles are functional—for example, automatically configuring the Windows firewall. In cases, though, where roles have been added and then removed, or when you want to have more control over exact security settings, SCW is still a valuable tool. For more information, see Jesper Johansson's Security Watch column, "Using SCW on Windows Server 2008," in this issue (microsoft.com/technet/technetmag/issues/2008/03).
When working on Windows Server 2008, we took a hard look at how we expected administrators to perform tasks. We found ways in which tools and wizards made it easier to do your job, and we found cases in which there was too much jumping around from tool to tool. We set an important design goal for Windows Server 2008 in general—and Server Manager in particular—to make server administration more efficient by letting administrators perform many types of tasks all in a single place. As a result, with Server Manager, you can:
  • View and make changes to server roles and features installed on the server.
  • Perform management tasks that pertain to the server, such as starting or stopping services and managing local user accounts.
  • Perform management tasks that pertain to the roles installed on the server.
  • Check the server status, identify critical events, and analyze configuration issues.
  • Install or remove roles, role services, and features using a GUI or command line.
The Server Manager Console presents a lot of information and functionality packed into a small space. Figure 2 shows the Server Manager Console on the File Services role node. The main window of the console contains four collapsible sections: Server Summary, Roles Summary, Features Summary, and Resources and Support.
Figure 2 Server Manager Console showing the File Services Role
Figure 2 Server Manager Console showing the File Services Role
The Server Summary section includes two subsections, Computer Information and Security Information. The Computer Information subsection displays the computer name, domain, local administrator account name, network connections, and the product ID of the operating system. You can also use commands here to edit this information. The Security Information subsection displays whether Windows automatic updating and Windows Firewall are enabled, as well as whether the Windows Internet Explorer® Enhanced Security Configuration is turned on (either for administrators or other users). Similarly, there are commands available to edit these settings and to view all of the advanced options.
The Roles Summary section contains a table that indicates which roles are installed on the server. The commands in this section allow you to add or remove roles or go to a more detailed console through which you can manage a specific role.
The Features Summary section provides a table that shows which features are installed on the server. Here, as expected, you can add and remove features.
Finally, the Resources and Support section indicates whether the server participates in the Customer Experience Improvement Program and Windows Error Reporting and allows you to configure the server's participation in feedback programs. You can also quickly locate additional related help and research topics available in the Windows Server TechCenters and Technical Libraries.

Role Information
Each installed role has its own home page within Server Manager. For each of these role home pages, the Resources and Support section offers a menu of recommended configurations or scenarios in which the role or parts of the role work. Each recommended configuration links to a help checklist that guides you through the tasks you need to perform to create the best experience for the given role.
One particularly nice thing about Server Manager is that it bubbles up important information and commands, putting them right where you need them. When, for example, you are looking at the File Services role home page, you immediately see any events related to that role, without having to launch Event Viewer and construct a filter.
However, some roles can generate hundreds of events, so you can also make custom filters right from the role home page. You can choose Filter Events on the side menu and further narrow down the events being displayed. This dialog doesn't provide all of the filtering options available in the event log viewer, but it does allow you to quickly focus only on the events related to this particular role and not worry about filtering out the others.
Likewise, you can see the status of system services (services required by this role, but part of the overall system) and role services (services specific to this role). For some roles, you can choose which parts of a role are available and different sets of role services will be installed. Directly from the role home page, you can start and stop services, as well as specify which services should be monitored as system services for the role.

Working with Wizards
A well-designed wizard can save you time and help prevent errors, especially when dealing with tasks that are performed only occasionally. Previous versions of Windows Server required you to use Configure Your Server, Manage Your Server, and Add or Remove Windows Components to change components installed on your server. Dependency checks were limited, and Add or Remove Windows Components required that installation of one role had to be complete before you could add another role.
Now, using Server Manager wizards, you can install or remove multiple roles, role services, and features in a single session. But more importantly, dependency checks are performed as you progress through the Server Manager wizards, ensuring that all the necessary roles and role services are installed. And roles are configured with default recommended security settings—you can, however, use the Security Configuration Wizard to modify security settings. You can actually have your server completely ready for deployment after a single session in one of the Server Manager wizards.
Server Manager contains a number of wizards, including the Add Roles Wizard, Add Role Services Wizard, Add Features Wizard, Remove Roles Wizard, Remove Role Services Wizard, and Remove Features Wizard.
The Add Roles Wizard, which, as you might have guessed, is used to add roles to the server, automatically checks for dependencies between roles and verifies that all required roles and role services are installed for each selected role. For some roles, such as Terminal Services and Active Directory Certificate Services, the Add Roles Wizard also provides configuration pages that allow the user to specify how the role should be configured as part of the installation process. Figure 3 shows the Select Server Roles page of the Add Roles Wizard.
Figure 3 Using the Add Roles Wizard to select server roles
Figure 3 Using the Add Roles Wizard to select server roles
Most roles are composed of multiple subelements, which Server Manager refers to as role services. Once a complex role is installed, you can use the Add Role Services Wizard to add role services to the role.
Similar to the Add Roles Wizard, the Add Features Wizard allows you to install features. You can add one or more features to the system in a single session.
The Remove Roles Wizard, as its name implies, lets you remove roles from a server. The wizard automatically checks for dependencies to ensure that any roles or role services needed for roles not being removed will remain installed. You can also remove role services from an installed role, using the Remove Role Services Wizard. Meanwhile, the Remove Features Wizard lets you remove features from the system.

The Command Line
I sometimes meet an IT pro who simply loathes wizards. While few are so vehement in their opinion, many IT pros do like the option to use a command line. It can be more convenient, enabling simple repeatability and scripting. Server Manager offers a command-line tool, ServerManagerCmd.exe, which is notably easier than the earlier ocsetup and pkgmgr tools. You can use ServerManagerCmd.exe to install and remove roles, role services, and features. And you use simple parameters to display a list of all roles, role services, and features—indicating both those that are installed and those that are available for installation.
Conveniently, this command line enables you to perform unattended installation and removal of roles, role services, and features. You can also use the command line to install or remove a single role, role service, or feature in a command instance, or you can use an XML answer file with the Server Manager command to add or remove multiple roles, role services, and features in a single command instance. And you can view logs of operations, and run queries to display lists of roles, role services, and features that have been installed and those that are available to be installed.
A highlight of this command-line tool is the –whatif parameter, which lets you see exactly what changes would be made to your server if the specified role were installed. For instance, Figure 4 shows the results of running the following command:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Obviously, you can save this output to a file for further analysis.
Figure 4 Using the –whatif parameter to see what changes would be made to the server
Figure 4 Using the –whatif parameter to see what changes would be made to the server
For a more in-depth look at the details and syntax of ServerManagerCmd.exe, see the "Server Manager Technical Overview Appendix" available at go.microsoft.com/fwlink/?LinkId=107113.
I'd like to thank Gaby Kaplan for her contribution to this article.

Byron Hynes is an Enterprise Technology Strategist in the Enterprise and Partner Group at Microsoft. He has previously worked in the Windows Server division, and as a consultant and trainer. You can reach him at bhynes@microsoft.com.


 Special Coverage: Windows Server 2008: Deploying Windows Server 2008 with System Center
Special Coverage: Windows Server 2008 Tim Mintner

Deploying Windows Server 2008 with System Center
At a Glance:
  • Configuration Manager deployment features
  • Creating and customizing a server task sequence
  • Adding server roles
  • Setting computer-specific variables

With the release of System Center Configuration Manager 2007, server administrators can now take advantage of the same operating system deployment tools that client administrators have
been able to use for several years. In the past, server administrators often performed manual installations of Windows Server® using the CD or DVD, then spent hours configuring the server. Some administrators went a step further and built unattended setup routines by creating an unattend.txt file and perhaps using Remote Installation Services (RIS) to automate the install process to avoid having to be physically present at the server console. More advanced administrators took advantage of Automated Deployment Services (ADS) for Windows Server 2003 to completely automate the entire server build process. Now, with Windows Server 2008, the installation process for servers has substantially changed for the first time since Windows NT® 4.0.
Windows Server 2008 deployment uses the same underlying deployment tools and technologies as Windows Vista®. Because of this change, the tools that server administrators have used in the past will need to be updated or replaced. RIS has been replaced by Windows® Deployment Services (WDS), and ADS doesn't support Windows Server 2008 deployment. For more information about the technologies and tools that have changed with server and client deployment, see "10 Things You Need to Know about Deploying Windows Vista" at technetmagazine.com/ issues/2006/11/Deployment.
Since the underlying technologies for deploying Windows Server 2008 and Windows Vista are the same, wouldn't it be great if you could use the same tools and leverage the same knowledge to deploy both? System Center Configuration Manager and Microsoft® Deployment now provide that integrated toolset. This article will describe how you can use Configuration Manager along with Microsoft Deployment to start rolling out Windows Server 2008.

OS Deployment with Configuration Manager
Before beginning to deploy Windows Server 2008, let's review the OS deployment features of Configuration Manager. When you launch the Configuration Manager Console and go to Computer Management, you will notice a new landing area for Operating System Deployment, as shown in Figure 1.
Figure 1 The Operating System Deployment page
Figure 1 The Operating System Deployment page
On this page, you can view a quick summary of the operating system deployments that have occurred in your environment, and you can navigate to other Operating System Deployment nodes, such as Manage Task Sequences and Manage Boot Images. You'll find a list of Web Reports for viewing the status of deployments and the health of your deployment environment. There is also a quick help reference under Resources that will link you to the help documentation for operating system deployment.
If you look under the nodes in the navigation pane, you can see all of the items that must be configured to perform an OS deployment. Here is a summary of these items:
Boot Images Contains a list of boot images based on Windows PE 2.0 that will be used during the deployment process.
Computer Associations Primarily used for client deployments to map an existing computer to a new machine so that User State can be managed securely. It also contains a wizard to import unknown computer accounts into the Configuration Manager database so that it is possible to deploy bare metal servers.
Operating System Images Contains a list of packages that hold customized Windows Imaging Format (WIM) images for server and client deployment.
Operating System Install Packages Holds packages that contain the full set of source files for an OS deployment, such as the source files for Windows Server 2008.
Task Sequences Contains multiple steps, each of which define the command-line actions that will run without user interaction. Task Sequences are the driving engine of the operating system deployment process and can provide all of the steps needed to deploy and configure an operating system.
Drivers A central repository for managing all of the drivers needed for the various models of server and client computers.
Driver Packages Contains one or more sets of drivers that can be distributed to Configuration Manager Distribution Points and are used during the deployment of server or client computers.
Now that we have a basic understanding of Configuration Manager's Operating System Deployment features, let's gather all of the pieces we need to perform a Windows Server 2008 deployment.

Getting Ready to Deploy Windows Server 2008
What Is Microsoft Deployment?
Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. It brings together the tools and processes required for both desktop and server deployment into a common deployment console and collection of guidance. The product adds new deployment and task sequencing capabilities for desktops and servers using System Center Configuration Manager 2007.
Microsoft Deployment is available at the Microsoft Download Center, and guidance material can be read online in the Desktop Deployment and Server Deployment TechCenters on Microsoft TechNet. For more information and links to these destinations and other related content, visit microsoft.com/deployment.

In order to deploy Windows Server 2008 with Configuration Manager, you need the following items:
Microsoft Deployment Toolkit (MDT) Provides tools and best practices documentation for deploying server and client operating systems. It integrates directly with the Configuration Manager Console to streamline the deployment process. You can download the Microsoft Deployment Toolkit from microsoft.com/deployment.
Custom Boot Image Configuration Manager provides 32-bit and 64-bit boot images that are based on Windows PE 2.0 and includes support for VBScript, Windows Management Instrumentation (WMI), and HTML applications (HTAs). However, if you want your deployment process to request information from a separate SQL Server® database, you will need a custom boot image that has ADO support.
Operating System Install Package Contains the source files from the Windows Server 2008 DVD.
MDT Package Contains all of the scripts and supporting files needed for the Microsoft Deployment Toolkit.
Configuration Manager Client Package Contains the installation files for the Configuration Manager client.
Settings Package Contains the unattend.xml file used for an automated installation of Windows Server 2008 as well as the customsettings.ini file used with the Microsoft Deployment Toolkit.
Sysprep Package Used only when deploying Windows Server 2003 or Windows XP and provides the sysprep files that are needed to prepare a computer to capture an operating system image.
Drivers Contains all of the drivers needed for specific models of servers.
Network shares for Package Sources and Captured WIMs The Universal Naming Convention (UNC) locations where the packages listed above, along with the customized WIM image, will be stored.
It may seem like a lot of work is necessary in order to create all of these packages. The good news is that with the Microsoft Deployment Toolkit, one wizard will create all of them for you.
In order to use the Microsoft Deployment Toolkit with Configuration Manager, you must install it on the same computer as the Configuration Manager management console. After you do so, go to Start | All Programs | Microsoft Deployment Toolkit and choose Configure ConfigMgr Integration, then specify the name of your Configuration Manager Site Server and the Site code and click on Next. This adds extensions to the Configuration Manager Console provided by the Microsoft Deployment Toolkit. Now when you launch the Configuration Manager Console and right-click on Task Sequences, you will be able to see a new option, as shown in Figure 2.
Figure 2 Import Microsoft Deployment Task Sequence
Figure 2 Import Microsoft Deployment Task Sequence
Choose Import Microsoft Deployment Task Sequence and follow the steps below to create the necessary packages and the Windows Server 2008 Task Sequence:
  1. On the Choose Template Screen, select Server Task Sequence, and then click Next.
  2. Provide a Task Sequence Name and comments describing the task sequence, and then click Next.
  3. Fill in the details for joining a domain or a workgroup, including user account credentials for joining the server to the domain. Fill in your organizational information and product key, and provide a UNC path and file name for the custom WIM image that will be captured. Provide user credentials for connecting to the network share that will store the WIM file, and click Next.
  4. On the Boot Image screen, choose to create a new boot image package and provide a network location to use as the package source directory for the boot image package, and click Next.
  5. Provide a package name, version information, and comments for the Boot Image package, and click Next.
  6. Choose a platform (x86 or x64), ADO support, any optional fonts you need, a custom background for the boot image if needed, and any extra folders to include in the Windows PE image, and click Next.
  7. On the MDT Package screen, choose to Create a new Microsoft Deployment Toolkit Files Package, provide a UNC path to use as the package source, and click Next.
  8. Provide a name, version, language, manufacturer, and comments for the MDT package, and click Next.
  9. For the OS Image, choose to Create a new OS Install Package, provide the path to the Windows Server 2008 source files and a UNC location to use as the package source directory, and click Next.
  10. For the Client Package, choose to Create a new Configuration Manager client package, and click Next.
  11. For the Settings Package, choose to Create a new Settings Package and provide a UNC location to use as a package source for the Settings Package, and click Next.
  12. For the Sysprep Package, choose No Sysprep Files required, and click Next.
Now the wizard will create the boot image and all of the packages. If you expand Packages, Boot Images, Operating System Install Packages, and Task sequences, you will be able to see all of the packages and the task sequence that were created. After all of these packages are created, they should be deployed to Distribution Points.
In addition to these packages, you'll often need to add drivers for specific server hardware. You do this by adding drivers to the Configuration Manager driver store and creating a Driver Package that will be used during the deployment.
To import drivers into the Driver Catalog and create a Driver Package, go to the Configuration Manager Console, right-click on Drivers, and select Import. Choose to import all drivers in the specified UNC path, then type a UNC path that contains all of the drivers you have gathered for your specific server models. Once that is complete, click Next.
On the Drivers Details page, choose which INF files you want imported and optionally assign the drivers to a category. (A category could be based on a specific server model type.) Click Next, then, on the Add Drivers to Package page, click New Package. Specify a name, comment, and a UNC path that will be used as the package source for the Driver Package, and click OK. Choose Update distribution points when finished and click Next.
On the Add Driver to Boot Images page, choose the Boot Image you created previously and check the box for Update distribution points when finished. Click Next, then, on the summary page, click Next again to complete the wizard, import the drivers, and create the Driver Package.

Editing the Task Sequence
Now that you have finished creating all of the necessary packages and the task sequence to install Windows Server 2008, you will probably want to customize several of the actions in the default task sequence. To modify the task sequence, right-click it and choose Edit. The Microsoft Deployment Server task sequence template will then be displayed, as in Figure 3.
Figure 3 You can customize the default task sequence
Figure 3 You can customize the default task sequence
At a high level, a task sequence is a series of command-line items known as tasks that each perform specific operations. Each task may have specific properties that can be configured and may also have conditions set on the Options tab that evaluate whether specific tasks should be executed. For example, the first task in the task sequence has conditions set as shown in Figure 4.
Figure 4 You can disable a task or set conditions for it in the Options tab
Figure 4 You can disable a task or set conditions for it in the Options tab
In this example, the task is disabled by default because the "Disable this step" checkbox has been checked. If the task were enabled, it would only run based on the conditions that are currently specified.
A few of the more common tasks that you may need to modify before deploying Windows Server 2008 include Format and Partition Disk, Validate, Apply Operating System Image, and Apply Network Settings.
The Format and Partition Disk task lets you define how you want to create the disk partition structure for your server deployments. The default setting creates one partition that uses all of the space on the first disk. You may not want to deploy your servers with this configuration, so you can change this setting to specify the disk layout that you want to use.
The Validate task allows you to check for some basic requirements such as memory and processor speed. If, for example, your company standard for server deployments is 2GB of memory, you could set that as a requirement, and the installation will not continue if the server does not meet that requirement.
The Apply Operating System Image task allows you to configure the specific image to deploy. For example, when using source files for Windows Server 2008, you have the option of deploying Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core, and Server Datacenter Core. You will need to choose the appropriate image to use, and this depends on which version of Windows Server 2008 you want to deploy.
The Apply Network Settings task lets you configure static IP addresses for your network cards as well as change the settings to join a domain or workgroup. Although it is possible to set a static IP address using this task, doing so would make this task sequence only functional for one server. Later, you will see how you can set static IP addresses with variables so you can use a single task sequence for multiple servers.

Installing and Configuring Server Roles
So far you have seen how you can modify the task sequence to configure items related to the installation of the operating system. With the Microsoft Deployment Toolkit, however, you are also given the opportunity to install and configure server roles. For example, you can configure a task sequence to deploy Windows Server 2008 to a branch office server that will run a read-only domain controller and a file server.
To do this successfully, in the task sequence editor, navigate to the Install Software task and choose Add | MDT | Install Roles and Features. Then, in the newly created Install Roles and Features task, check both Active Directory Domain Controller and File Server, as shown in Figure 5.
Figure 5 Installing roles and features
Figure 5 Installing roles and features
Now you need to configure the settings for the read-only domain controller. In the task sequence editor, choose Add | MDT | Configure ADDS. In the newly created Configure ADDS task, choose to create a New read-only domain controller replica, and specify values for the following properties:
  • Existing domain DNS name
  • Replication source domain controller
  • Account
  • Recovery (safe mode) password

Working with Variables
It's important for you to understand that one of the most powerful features that task sequences offer users is the ability to set almost any property in the task sequence dynamically as a variable during deployment. Configuration Manager and Microsoft Deployment both provide several mechanisms to set and use variables.
Configuration Manager allows you to set the variables as a Computer variable, a Collection variable, or directly inside of the task sequence. Microsoft Deployment allows you to set variables through the customsettings.ini file, a back-end database, or a Web service. You'll find a list of variables that can be set at technet.microsoft.com/bb632442.aspx.
Let's use the example of setting a static IP address on a particular server. Earlier in the article you saw that you could set the static IP address directly inside the task sequence in the Apply Network Settings task. This is not the most ideal practice, however, because it makes that task sequence useful only for a specific server.
What you want to do instead is leave the task sequence alone and set the IP address through a variable. Here's the step-by-step process of how to set the static IP address as a Computer variable:
  1. In the Configuration Manager console, navigate to System Center Configuration Manager | Site Database | Computer Management | Collections.
  2. To assign a per-computer variable to a computer, locate and expand the collection the computer belongs to, right-click the computer, click Properties, and then click the Variables tab.
  3. To specify custom variables and their associated values, click the New icon to open the <New> Variable dialog box.
  4. In the <New> Variable dialog box, it is necessary to specify a name for the variable and whether this variable will be visible in the Configuration Manager 2007 console. For a static IP address, you would add the following variables:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
The configured variables should resemble those in Figure 6.
Figure 6 Using computer variables to set a static IP address
Figure 6 Using computer variables to set a static IP address

Deploying the Task Sequence
Now that you have the task sequence fully configured and have set up your variables, you are ready to deploy Windows Server 2008. Configuration Manager offers several mechanisms for deploying an operating system, such as Pre-Boot eXecution Environment (PXE), task sequence bootable media, standalone media, and through a standard advertisement for existing machines.
For simplicity's sake, I'll outline how to create a task sequence for bootable media. In the Configuration Manager console, navigate to Task Sequences, then choose Create Task Sequence Media from the Actions menu. On the Select Media Type page, choose Bootable Media and click Next. On the Media Type page, specify a CD as the type of media and a name for the media file. On the Security page, you can specify a password to protect the media or a self-signed certificate. Next you specify the boot image. Once that has been completed, you will go to the Confirmation page, where you will click Finish. For detailed instructions on how to deploy using this and other mechanisms, refer to the documentation at technet.microsoft.com/bb681029.aspx.

Wrapping Up
In this article, you have seen how to use System Center Configuration Manager and Microsoft Deployment to deploy Windows Server 2008, add roles such as a File Server and Domain Controller, set computer specific variables, and deploy the operating system using Task Sequence Bootable media. While actual server deployments can be much more complex, this article should help you get started in unifying your server and client deployment tools.

Tim Mintner is a Senior Software Development Engineer on the Microsoft Solutions Accelerator team, focusing on the Microsoft Deployment Toolkit. He has more than 14 years of experience working with customers to deploy Microsoft operating systems. Tim can be reached at tmintner@microsoft.com.


 Special Coverage: Windows Server 2008: Auditing and Compliance in Windows Server 2008
Special Coverage: Windows Server 2008 Rob Campbell and Joel Yoker

Auditing and Compliance in Windows Server 2008
At a Glance:
  • Increasing importance of compliance
  • Understanding change in your environment
  • Challenges of auditing security events
  • Technical aspects of auditing

In the world of information technology, change is constant. If your IT organization is like most, you are under increasing pressure to understand the changes that occur in your environment. As the complexity and scale of IT environments increases, so does the impact of
administrative errors and accidental data disclosures. Today's society demands accountability for such events, thus organizations are now being held legally responsible for safeguarding the information under their care.
As a result, auditing change in your environment has become important. Why? Auditing provides the means to understand and manage change in today's large, highly distributed IT environments. In this article, we'll cover common challenges most organizations face, the landscape of compliance and regulation in IT, some of the basics of auditing in Windows®, and how the functionality of Windows Server® 2008 and Microsoft® System Center Operations Manager 2007 Audit Collection Services (ACS) can complement a comprehensive auditing strategy.

Auditing Challenges
A quick glance at news headlines shows that data disclosure is becoming an everyday problem. Many of these incidents involve legal action, financial loss, and public relations issues for the organizations responsible. The ability to explain what changes occurred or identify issues quickly is the key to reducing the impact of data disclosure incidents.
For example, let's say your organization is responsible for managing personally identifiable information (PII) for a given customer base. While there are multiple ways to protect the information contained on the systems you manage, compromise can still happen. Proper auditing could allow the organization to know exactly which systems were compromised and perhaps what data was lost. Without auditing, the impact of the data loss could be much greater, largely because there would be no way to estimate the extent of the compromise.
So why aren't IT organizations doing this already? The fact is, most organizations do not fully understand the technical aspects of auditing. While senior management generally understands concepts such as backup and restore, the inherent complexity of auditing changes in the environment is a hard message to convey. As a result, questions about auditing often arise only after a significant incident occurs. For example, basic auditing may be enabled but if the system is not configured to audit for a particular change, due to a lack of planning, that information will not be collected.
Moreover, audited security events have some inherent issues that IT professionals must deal with. One such difficulty is the distribution of systems within today's large computing environments, which presents significant collection and aggregation challenges since change can occur on any system or set of systems at any given time. That leads to another challenge—correlation. Translating relationships between events on single and multiple systems is often necessary to provide true meaning to what is occurring.
Yet another issue is that auditing typically transcends traditional organizational boundaries. Different organization or team structures exist for different reasons and may not be easy to bridge. Many organizations have a directory services team, a messaging infrastructure team, and a desktop team, but there is likely only one security team responsible for all of these areas. What's more, the dedicated security people for your organization may not be physically present at all locations. For instance, branch offices often rely on a single person or small team for all tasks including Security event log management.
Finally, the sheer quantity of events is challenging. Audited security events occur with much higher volumes than other types of event logging. The number of events collected makes it difficult to effectively retain and review the logs. Furthermore, by stipulating retention requirements for this information, current and proposed regulations are not helping to reduce this burden in today's computing infrastructures.
In the past, auditing of access to information could be summarized as a desire to know and an attempt to be secure. Now, as organizations—and the senior management responsible for them—are being held legally accountable for loss of information or lack of proper safeguards, it is critical for IT administrators to familiarize themselves with the regulations that may be applicable to their environments. For global companies, the challenges are even more complex since each country has its own regulations concerning information and the protection thereof. Some examples of existing regulatory compliance legislation are listed in Figure 1, along with the associated expectations placed upon IT organizations.
Figure 1 Regulations and what they mean to IT professionals (Close Figure 1)

Regulation | Expectation
Sarbanes-Oxley Act of 2002 (SOX) | Section 404 recognizes the role of information systems and requires publicly traded companies to provide an annual review of their internal controls over financial reporting.
Health Insurance Portability and Accountability Act (HIPPA) | Addresses the security and privacy of health data; the "Security Rule" covers administrative, physical, and technical safeguards of that data.
Electronic Discovery (eDiscovery) | Defines standards for document retention and access, including accountability for who accesses documents and how.
Federal Information Security Management Act of 2002 (FISMA) | Federal mandate to provide a comprehensive Information Security (INFOSEC) framework for U.S. government systems, coordination with various law enforcement agencies, establishment of controls, acknowledgement of commercial products, and software capabilities. Section 3544 covers agency responsibilities, including IT controls.
Federal Information Processing Standards (FIPS) Publication 200 | Specifies the minimum security requirements for federal information and information systems and outlines the use of the recommendations found in NIST Special Publication (SP) 800-53. In NIST SP800-53, section AU-2 (Auditable Events) specifies that information systems must provide the capability to compile audit records from multiple components into a system-wide, time-correlated audit trail, to manage audited events by individual components, and to ensure the organization periodically reviews auditable events.
Given all the legal pressure, what are IT professionals to do? IT managers and technicians need to build a clear and concise story to present to those both inside and outside the organization. This includes developing a proper auditing strategy, which requires proactive measures and investments. The key concept here is that auditing cannot be an afterthought in design, as it too often is.
IT challenges such as these can typically be solved by a combination of people, process, and technology. With auditing, it's the process, that matters. Therefore, the first step should be to master the basics so you can respond to your organization's needs and requirements around regulatory compliance. Let's cover some of the fundamentals of auditing in Windows, then we'll dive into the changes in Windows Server 2008 and Windows Vista®.

Auditing Security Events
All audited events are recorded in the Windows Security event log. These events are usually not immediately actionable and are often informational in nature. Each event records a simple Audit Success or Audit Failure for a specific type of access that has occurred. This is different from the Application or System event logs, where problems can be identified via color coding (hint: look for the red events to home in on the problem).
The Security event log is different because audited events often are hidden by their volume, and as noted previously, correlation of security data can present a significant challenge. Even a simple data breach on a single system is problematic. The Security event log would need to be analyzed to identify which account was used to access the data, requiring an administrator to trace back through the log to try to find the account. Unfortunately, today's sophisticated attacks are often coordinated and distributed, making that sort of analysis quite difficult for the victim.
That said, it is important to understand the key elements that enable information to be recorded in the Security event log in Windows: Audit Policy and System Access Control Lists (SACLs). Audit Policies are configurable settings for a local machine through Group Policy or Local Security Policy and define the collection of success and failure events for specific types of access. The following primary Audit Policy categories have been present in Windows for many years (more on the new Granular Audit Policy in Windows Server 2008 later):
  • Audit account logon events
  • Audit account management
  • Audit directory service access
  • Audit logon events
  • Audit object access
  • Audit policy change
  • Audit privilege use
  • Audit process tracking
  • Audit system events
The need to define Audit Policy and these associated categories is typically well understood by most IT organizations, but Audit Policy represents only a portion of the solution. SACLs also play a significant role in the implementation of a holistic auditing plan. Two specific Audit Policy categories—audit directory service access and audit object access—are fully dependent on SACLs to return information in the Security event log. So what exactly are SACLs?
Each object—file, registry, or directory service—has an Access Control List (ACL) with one or more Access Control Entries (ACEs) divided into two types: a discretionary access control list (DACL) and a SACL (the latter defines settings that log access attempts to secured objects). Each ACE in a SACL specifies the types of access attempts by a specified trustee that should be logged in the Security event log. ACEs define logging of successful and/or failed access attempts against specified objects. Figure 2 shows the use of a SACL on an object to generate events for specific types of access.
Figure 2 Using a SACL on an object
Figure 2 Using a SACL on an object
Understanding the relationship between Audit Policy and SACLs is critical since configuration is necessary to capture the "correct" audited events as it relates to changes in the environment. As mentioned, the audit directory service access and the audit object access audit policies only enable the generation of audits in the Security event log for those specific categories, but events are only generated if an object has an auditing ACE configured in its SACL. Once these pieces are in place, security events are generated by the Windows Local Security Authority (LSA) and are written to the Security event log.
Events consist of two distinct areas: the header, which is static and is predefined for each event identifier (Event ID), and the body, which is dynamic and contains different details for different events. Figure 3 shows these two elements in a sample Windows Server 2008 security event. Understanding these event components is important for the analysis phase of any auditing project and is of particular interest with respect to how information is returned in tools such as ACS.
Figure 3 The header and body of an audited event
Figure 3 The header and body of an audited event

Windows Eventing 6.0
Now that we understand the problem, how does Windows Server 2008 help organizations face these challenges? Windows Server 2008 is the first server release to contain the new Windows Eventing 6.0 event subsystem, which vastly improves the landscape around security event management. Note that while we are focusing on Windows Server 2008 here, 95 percent of the new feature set also exists in Windows Vista.
One of the first things many people will notice with Windows Eventing 6.0 is the new user interface. The new Event Viewer Microsoft Management Console (MMC) snap-in offers an excellent Overview and Summary page, flexible Custom Views, and greatly enhanced Explain Text. These interfaces can help the end user or system administrator find event information and configure important event log options directly from the Event Viewer itself.
A key problem that often impacted security data within the event log was data retention. Previously, the Event Log subsystem (including all logs) faced scalability limits. If those limits were exceeded, the entire subsystem would stop logging events. That's not the case with Windows Eventing 6.0, however, and organizations are now limited only by the amount of available disk space. But note that very large event logs can be cumbersome to analyze since each individual log entry must be evaluated when filtering, so you'll definitely want to keep your log at a manageable size.
Of course, this still leaves it up to the IT administrator to develop an archiving plan for event logs over many systems. To help with this on the local server level, a feature that is now exposed in Windows Eventing 6.0 is the "Archive the log when full, do not overwrite events" option. In previous versions of Windows, this option could only be set directly via modification of the AutoBackupLogFiles registry value. While this supplies a mechanism for local archive of logs, it does not provide a solution for management of these files over time, nor does it address the aggregation problem that occurs across multiple systems. Audit Collection Services does provide a complete solution for this, which we'll get to in a bit.
The new interface is just the beginning. The real power of Windows Eventing 6.0 is the new Windows Event Log service and underlying XML-based engine. These components are what deliver the increased scalability, accessibility, and management options. Events are now stored in a flexible XML format that enables custom solutions that can tap into this information natively.
Windows Eventing 6.0 also provides the capability to associate administrative actions with specific events. It does this by integrating the Windows Event Collector service with the Task Scheduler to provide for task-based eventing. This is a new paradigm for the Task Scheduler, which was previously limited to triggering events based on time. The "Attach Task to this Event" wizard (available on the context menu of any event in the Windows Server 2008 Event Viewer) provides an easy way to start a program, send an e-mail, or display a message any time a specific event is logged. This can be very useful when attempting to identify specific actions taking place in your environment that can be isolated to a specific security event. For example, if you are auditing changes to the "Schema Update Allowed" registry key on your domain controllers, you can create a task that sends an e-mail to specific security administrators to notify them when this registry key is modified.
In addition to the new ability to collect and store a large number of event entries, you can also now better control what events are recorded in the event log. This is accomplished through a new feature called Granular Audit Policy (GAP). In previous versions of Windows, the nine broad audit categories often resulted in event overload. Those top-level categories can now be controlled by 50 granular subcategories, each of which represents a related subset of events.
This gives you the capability to filter non-critical information from the event log without losing visibility at the category level. For example, if on a particular system you want to monitor changes only to the registry, but not the file system, previously you could choose only to report success or failure on the Object Access category. With GAP, you can now filter out subcategories such as File System, Certification Services, and File Share and only report events on the Registry subcategory. To explore the GAP subcategories on a Windows Server 2008 system, you must run the Auditpol command from an elevated command prompt. To list the available GAP subcategories, type the following:
auditpol /list /subcategory:*
To get a list of GAP subcategories configured on your system, type this:
auditpol /get /category:*
Note that GAP is not configurable through the standard Group Policy user interface and must be managed through auditpol.exe. The Knowledge Base article at support.microsoft.com/kb/921469 has guidance on how to deploy GAP settings through Group Policy for Windows Server 2008 and Windows Vista systems.
Windows Server 2008 can also capture both old and new values of the specific types in the Security event log. In previous versions of Windows, the auditing subsystem only logged the name of the Active Directory® object attribute or registry value that was changed—it did not log the previous and current values of the attribute. This new capability applies to Active Directory Domain Services, Active Directory Lightweight Directory Services, and the Windows registry. By enabling Audit Success or Audit Failure on the subcategories of "Registry" or "Directory Service Changes" and setting the associated SACLs, detailed events will be raised in the event log for actions on these objects. This can be performed using the following auditpol commands:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
For registry changes, these appear as Event ID 4657 events as shown in Figure 4.
Figure 4 Before and after a registry change
Figure 4 Before and after a registry change
This feature is particularly useful when attempting to track changes on Active Directory objects. For Directory Service Changes, these changes appear in a pair of Event ID 5136 events, as shown in Figure 5. Each event has the directory service Object, Attribute, and Operation in the body of the event. For changes to attributes with existing data, we see two operations: Value Deleted and Value Added. For attributes which have not been populated, we would only see the Value Added operation when data is written to that attribute. For example, when a successful modify operation is performed on an attribute of a user object, such as telephoneNumber, Active Directory logs the previous and current values of the attribute in detailed event log entries
Figure 5 Before and after a Directory Service Change event
Figure 5 Before and after a Directory Service Change event
If a new object is created, values of the attributes that are populated at the time of object creation are logged. If an object is moved within a domain, the previous and new location (in the form of the distinguished name) is logged. This "old and new" feature is enabled by default when the appropriate Audit Policy settings are in place. If there is an attribute you want to keep private, such as employee ID number changes, you can specifically exclude attributes by making a simple schema modification. By modifying the searchFlags property of the attribute in the schema to 0x100 (value 256 -NEVER_AUDIT_VALUE), as shown in Figure 6, the Directory Services Changes event will not be raised when changes to the attribute occur.
Figure 6 Excluding an attribute from Directory Service Changes
Figure 6 Excluding an attribute from Directory Service Changes
Finally, one of the great new features in Windows Eventing 6.0 is Event Subscriptions. As mentioned before, accessing and reviewing the event log is a key system administration task. The new Event Subscriptions capability provides a way to forward events directly between systems. Event Subscriptions consist of an Event Collector that gathers events and Event Sources that are configured to forward events to specified hosts. The ability to consume events is provided by the Windows Event Collector service (new with Windows Eventing 6.0), and the subscriber functionality is built into the Windows Event Log service. A collector can be configured to gather events from many event sources, which can be either Windows Server 2008 or Windows Vista systems.
All data collected from event sources resides in a discrete Event Log, named Forwarded Events (ForwardedEvents.evtx) and managed by the Event Log service on the collector. Configuration on both endpoints (collector and source) is necessary and can be automated (winrm quickconfig –q on the source; wecutil qc /q on the collector). It is important to note that this event subscription capability was not designed for enterprises or to replace systems that deliver events to an external database.
One example where this capability may be leveraged is with a small Web farm. Suppose you have a small set of systems associated with a particular Web site (including Web servers and SQL servers). Those systems can consolidate their Security event log information on a single system using the new Event Subscription functionality. Larger environments will typically require a more advanced event log consolidation toolset.

Audit Collection Services
Given all of the new capabilities of Windows Server 2008, the real solution for long-term management and archiving of Security event log information is through a centralized database of auditing information. Audit Collection Services is a core feature of System Center Operations Manager 2007. ACS provides a mechanism for the forwarding, collection, storage, and analysis of security event data. Security events are collected in near real-time and stored in a central SQL repository. ACS also gives organizations a method of providing least privilege access to audit information since no physical access to the systems actually being audited is required. Let's look at how ACS works.
ACS has three main components. First, there is the Forwarder, which is the portion of the Operations Manager agent that transmits the event log data from the client to the ACS infrastructure. Forwarders transmit data to the second component, the Collector, which is the server-side listener. ACS Forwarders connect over TCP port 51909 to communicate with their assigned Collector in a secure fashion. Prior to transmission, the event log data is normalized into XML, meaning excess information is stripped and the event information is summarized into mapped fields based on event specific header and body information. Once the information reaches the collector, it is sent to the third and final component—the ACS Database. This becomes the repository for long-term storage of security event information. Once stored, the information can be mined directly through SQL queries or rendered using HTML reports using SQL Server® Reporting Services. ACS provides three default views, as shown in Figure 7.
Figure 7 ACS views (Close Figure 7)

ACS View Name | Purpose
AdtServer.dvHeader | Header information from collected events.
AdtServer.dvAll | Header and all body information from collected events.
AdtServer.dvAll5 | Header and the first five strings of body information from collected events.
From a performance perspective, a single ACS collector can handle a peak maximum of 100,000 events per second and a continuous maximum of 2,500 events per second. For planning purposes, a single ACS collector can support up to 150 domain controllers, 3000 member servers, or 20,000 workstations based on default Audit Policy settings. In one tested, real-world scenario, around 150 domain controllers showed a maximum of approximately 140 events per second with a peak average of 500,000 events per hour. In just 14 days (the default retention setting for ACS), over 150GB of security-event data was stored in the SQL Server database. A more aggressive Audit Policy and associated SACL configuration will obviously generate even more data (per hour, per day, and overall).
The important point to realize here is that with this volume of data, no human could possibly review every event in a typical large enterprise environment. Conversely, organizations should not be afraid of the numbers represented here. Understanding the changes that are happening in your environment comes at the cost of analyzing a large amount of data.
This is where ACS shines. Through SQL Server Reporting Services and ACS, you can turn issues typically buried within the Security event log into something that is as easily identifiable as the color-coded events found with the Application event log. While ACS includes a set of default reports, extending these for your environment's specific needs is simple.
Take the following scenario: due to the sensitivity of external trusts in the environment, management has asked that we develop a report detailing the creation of Active Directory Trusts. After doing some research, we know that a trustedDomain object is created in the cn=System container within the specific domain naming context in Active Directory when a Trust is created. After editing the SACL on this container to audit successful creation of any Trusted Domain object, we then have the ability to capture security events each time an object of this type is created. This is rendered in a 566 event in the Security event log on the DC the trust creation was performed on. We can then write a simple SQL query to retrieve this information from ACS:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
To get this into a report, use the version of Visual Studio® 2005 that is included with SQL Server 2005 Reporting Services as it is specifically provided for report development. After completing the wizard, reports very similar to the one in Figure 8 will be easy to create. What's more, any change in the environment that can be represented in the Security event log can be summarized into a similarly great looking report.
Figure 8 Sample ACS report
Figure 8 Sample ACS report

Developing an Audit Plan
Now that we understand the challenges as well as the legal and the technical aspects of auditing, how should IT administrators go about developing an "audit plan" for their organization? Like most things, developing a comprehensive audit policy is a multi-step process. The first step is to determine what should be audited. This includes analyzing your environment and determining what types of events and changes should generate audits. This could include simple items such as account lockouts, sensitive group changes, trust creation, or complex changes such as modifications of configuration elements within applications in your environment. The key here is that management must be involved in determining the "what" in an audit plan. This exercise needs to be done on paper and should be repeated at a regular interval—not just after significant incidents.
The second step involves identifying how audit information concerning specific changes is returned in the form of security events. Audit information is sometimes cryptic and not easily readable. Prior to implementation, correlations must be established between security events and various actions to understand what the security events really mean. After an incident is not the time to figure out the relationships of events to actions.
The third step is when the rubber meets the road, that is, when you implement your Audit Policy and SACLs. As discussed previously, you will need to define Audit Policy settings (to enable generation of security events) and SACLs (to generate audit trails for associated actions) in the directory, file system, and registry to get a complete picture of changes in these areas.
All this brings us to the fourth and final step—collection, triggers and analysis. Depending on the size and needs of your organization, these can be covered with the native Windows Server 2008 capabilities or with advanced solutions such as System Center Operations Manager's Audit Collection Services functionality. A common mistake made by most organizations is only setting Audit Policy without defining SACLs. The last step is all about implementing a technology solution for reporting and sharing data with the stakeholders within your organization. As mentioned before, most organizations have an established entity responsible for security, and an audit plan needs to be structured around existing organizational elements to be effective. The key to this final step is collecting and presenting information in a meaningful way to all those responsible for understanding change in the environment.
Most IT organizations are one significant event away from merely thinking about a comprehensive audit plan to actually requiring one. Windows Server 2008 provides enhanced mechanisms for collection and analysis of security event data compared to previous platforms. Advanced collection and reporting technologies such as ACS expose problems once obscured by event volume and distribution, making these changes instantly obvious.
Like most IT problems, process is the primary challenge. Additional configuration and analysis is always required to capture what IT managers expect, so developing a deep understanding of your environment's requirements and the capabilities of the Windows platform will allow you to meet these challenges head-on. Good hunting.

Rob Campbell and Joel Yoker Rob Campbell is a Senior Technical Specialist and Joel Yoker is a Senior Consultant on the Microsoft Federal team. Rob and Joel are both focused on developing and deploying security solutions for United States Federal government customers.


 From the Editor: Here's to Windows Server 2008
From the Editor
Here's to Windows Server 2008

Products launch all the time. And when you have a portfolio of hundreds of products (thousands, really, once you start to consider the Web), the notion of a product launch can get pretty mundane. Not so this time.
This February, Microsoft marks the launch of Windows Server 2008, and we couldn't be more excited. There's no question that this release has been a long time coming, but I think you'll find it was worth the wait. The number of major improvements—and the sheer amount of new functionality—is staggering. We could certainly talk about IIS 7.0 (and we do) or Network Access Protection (we do that, too). We could cover Server Manager, or new deployment techniques, or new compliance features (check, check, and check.) Heck, the list goes on for quite a while, but to tell you the truth, what strikes me most about this new release is how much effort was put into improving the manageability of Windows Server.
We spend a lot of time around here trying to focus on what we can do to make the life of an IT pro easier. Given that, it's really satisfying to see a product with so much focus on helping the IT pro do his job better. As an example, take the new Eventing infrastructure in Windows Server 2008, which Rob Campbell and Joel Yoker discuss in this month's issue. It's hard for even the geekiest among us to get energized about Eventing, but I have to tell you, I'm floored by what a difference it makes in this release. XML data, custom views, more detailed descriptions, easier reporting ... It's almost too much to handle.
All kidding aside, the major improvements to the bread and butter of our business through this release give good reasons to be excited. Enhancements to Active Directory, IIS, networking, security, virtualization, and more make this one of the most significant product launches in our history, so we dedicate this issue to everything you need to know about Windows Server 2008.
And as a special treat, we're very pleased to welcome back Mark Russinovich, Technical Fellow in the Platforms and Services Division and creator of the always popular Sysinternals tools. Mark has authored some of the most sought-after content in TechNet Magazine history, most notably his series, "Inside Windows Vista Kernel Changes" (from our February, March, and April 2007 issues). Mark reprises that series this month with a deep, technical look at the changes you'll find in the Windows Server 2008 kernel. Enjoy!
—Joshua Hoffman

Thanks to the following Microsoft technical experts: Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher, and Landy Wang.


 Letters: Readers Speak Out
Letters
Readers Speak Out

Windows Vista Complete PC Backup
Thank you for your great article in the September 2007 issue on Windows Vista® Complete PC Backup ("A Guide to Windows Vista Backup Technologies," technetmagazine.com/issues/2007/09/Backup). I can't get myself to actually try it, however, because when it asks me where to put the backup image, it says it will put the image on my external hard drive (which is what I would like to do). But it does not give me a choice of putting the file into a specific folder on my external hard drive, which makes me worry that it will overwrite all my other files already on that drive. Is this something that I need to be concerned about?
—Ben B.

We passed your question along to the author, Christine Fok, who said that Complete PC Backup will actually create a folder on the target for storing the image, so no need to worry—no data will be overwritten.

Mistaken Registry Key Reference
The December 2007 article "Track Down Elusive Network Problems" (technetmagazine.com/issues/2007/12/Network) contains a minor mistake when referencing a registry key to adjust the TCP/IP Stack in Windows®. On page 70, the author, Christopher Stoneff, mentions that you can adjust values in the HKLM\System\CurrentControlSet\Services\TCPIP key, when the correct key is, in fact, HKLM\System\CurrentControlSet\Services\TCPIP\ Parameters (he must have forgotten to add "Parameters").
—Ingmar K.

Christopher Stoneff confirmed that you are indeed correct. The key does include \Parameters at the end. Our apologies that the required portion of the registry path was omitted. We have corrected this in the online version of the article.

Encrypting Files
I'm very interested in learning more about the Encrypting File System (EFS) and I read your March 2007 Security Watch column "Deploying EFS: Part 2" (technetmagazine.com/issues/2007/03/SecurityWatch). I have a domain environment and some users are encrypting some files already. I then introduced certificate authority (CA) and EFS templates. My question is this: if those users who already had encrypted files using their own self-sign certificates need to encrypt new files, should they encrypt them using the old self-sign certificate or should they enroll for a new certificate from my CA? Also, if all my users have roaming profiles, where will the private keys of users be stored?
—Ammar H.

John Morello, who wrote the column on deploying EFS, sent an answer to your question:
Once the users enroll for the new EFS certificate, they'll start using it for new operations. However, any existing encrypted files will continue to be encrypted with the old keypair until they're updated. So, after the users have enrolled, you can run cipher /u, which will update all of those files with the new keypair.
If using roaming profiles, the keypairs will be roamed in the profiles. I recommend using Credential Roaming instead, which is more lightweight than roaming profiles. Look here for more information: go.microsoft.com/fwlink/?LinkId=107469.

Mistaken Regular Expression
Concerning the January 2008 Hey, Scripting Guy! column "There's No Mistaking Regular Expressions" (technetmagazine.com/issues/2008/01/HeyScriptingGuy), the example using
objRegEx.Pattern = "[^A-Z][^a-z]"
may not be what was intended. It was intended to find any character that was not a lowercase or uppercase letter. This pattern, however, is for an uppercase followed by a lowercase letter. It fails with a string such as "aBcde". Perhaps it should be this instead:
objRegEx.Pattern = "[^A-Z^a-z]"
—Roger R.

We passed your question along to The Scripting Guys, and here's what they had to say:
Hey, Roger. Thanks for pointing this out. It looks like we made a change to the column at some point and didn't catch this. In the original draft (which I still have lying around on my computer somewhere), we did say that this was intended to find an uppercase letter followed by a lowercase letter. We must have decided afterward that this wasn't as useful as finding characters that weren't letters, and while we changed the text, we forgot to change the sample code as well. We'll get this fixed in the online version. Sorry about that.


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

Manage SQL Databases
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
The larger and more complex your infrastructure, the more you need to be concerned with maintenance and operational tasks interfering with each other. This can lead to process flow havoc for your end users. Fortunately, there are a few tools available for the database and system administrator to help coordinate a complex environment's schedules.
One such tool that you may want to consider for your multi-database server environment is SQL Sentry Event Manager, a Microsoft® .NET Framework server application that utilizes a SQL Server® 2000 or SQL Server 2005 instance on the back end. You connect to the server application via the SQL Sentry Console UI, which gives you a unified view of the managed servers in your environment. The server app is agentless, but that, as usual, implies that it will need to run under a user context of a user that has the rights to connect to the machines and services you want to manage.
One of the most touted features of the application is that the console UI provides you with drag-and-drop rescheduling of your server tasks to help align maintenance and operational activity to avoid conflicts and downtime. While the UI can seem a bit convoluted at first, it lets you quickly spot potential problems and find a time slot to shift a conflicting task. It even offers a Microsoft Outlook®-like view of your SQL agent jobs and Windows® scheduled tasks for the servers you have chosen to monitor. And the calendar view highlights long-running and failed tasks to help you track down and resolve problems along the way.
In addition to the scheduling functionality, SQL Sentry also has a robust notification system that supplants the need for SQL Mail, MAPI, xp_sendmail, or sp_send_dbmail. It also routes all your event notifications from managed servers through its subsystem, giving you a centralized control over the types, frequency, and distribution of those notifications.
Notifications can be configured at the global, server, and task or job level, offering the granularity most administrators expect for that type of event. You can set up a number of different types of event conditions to trigger a notification, such as when a job takes too long or too short of a time to complete, when a performance indicator such as CPU utilization reaches a certain threshold, or when a SQL agent job is blocked for some reason. You can also configure SQL Sentry to notify you when the configuration changes, so you know when someone adjusts a schedule, pauses a monitor, and so on.
But SQL Sentry handles more than SQL agent jobs and the Windows task scheduler events. The application also supports events from maintenance plans, DTS packages, SSIS tasks, and the SQL agent log.
The powers that be usually like to see how well systems are performing, and if you have an uptime rating to be proud of, you probably would like to show that off as well. SQL Sentry has a number of reporting options built in for just such as task, letting you generate and print runtime and performance statistical graphs. You can also export the report data to XML, CSV, or HTML for inclusion in your own reporting documents and tools.
Note that the Professional Edition adds the ability to manage Oracle servers as well as such features as reporting services monitoring, SQL Agent job queuing, chaining of non-SQL server events, and calendaring for shared resources.

Price: Standard Edition starts at $395.
Scheduling maintenance with SQL Sentry
Scheduling maintenance with SQL Sentry

Manage Systems Remotely
Mobile Admin
rovemobile.com/products/ma/features
Since you can't be in more than one place at the same time, a mobile remote server administration tool is a good idea for the overextended IT professional. And one you should check out is Mobile Admin from Rove Mobile (formerly Idokorro Mobile).
Mobile Admin is a client-server setup where one communication server (which has access to the servers you want to manage) interacts with a set of wireless handheld devices. The server portion of the application is agentless, meaning you don't have to install anything on the servers that you want to manage. You do, however, need to give that machine and application context the appropriate remote administration rights to allow you to administer the machines in your infrastructure.
The server can be accessed by most of the major mobile platforms, including Windows Mobile® Pocket PCs and Smartphones, as well as BlackBerry smartphones. In addition, any Internet-connected computer that has a compatible browser can connect to Mobile Admin (assuming your security policy is set to allow it).
One of the first concerns any systems or network professional has with mobile administrations is security. For those of you with BlackBerry Enterprise Server deployed, you can choose to encrypt all communication with TDES (Triple Data Encryption Standard) or AES (Advanced Encryption Standard)—which are both compliant with the Federal Information Processing Standard (FIPS).
Also, Mobile Admin extends the "kill" functionality for a lost BlackBerry, removing the software and data from the phone remotely. For other handhelds, you can implement a VPN to secure your communications and/or configure Mobile Admin to use a Windows login, LDAP, RSA SecurID, RADIUS authentication, or a Mobile Admin-specific login.
Once connected, you can perform Windows administration tasks such as viewing and clearing event logs, rebooting machines, managing files and directories, and viewing and editing scheduled tasks.
In terms of Active Directory® integration, you can view, create, edit, disable, or delete users, groups, and computers. Meanwhile, for Exchange administration, you can change mailbox settings, and freeze and unfreeze message queues, and more.
With IIS, you can restart application pools or Web sites and change virtual directory settings. For your SQL servers, you can do such things as run T-SQL queries, modify logins, and start and stop SQL agent jobs. And if you are running Cluster Services, you can move groups, take resources offline, and fail over among other common administrative tasks.
Finally, Mobile Admin also has support for managing aspects of Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec, and more.

Price: Starts at $245 per server.

Book Review
Managing Windows Network Forensics and Investigation
sybex.com
You may have the hardware and procedures in place to detect and mitigate threats to your networks. But do you know the procedures or have in place the protocols you need for investigating and perhaps even prosecuting offenders after a security-related event takes place?
This is where the book Mastering Windows Network Forensics and Investigation (Sybex, 2007) comes into play. It is designed to teach you the skills to fully investigate Windows network intrusions, from small-scale, single-machine incidents (such as inappropriate usage of company services) to larger and more widespread attacks against sensitive systems.
The book guides you through the process of collecting evidence, covering everything from conducting interviews to tracing audited events and logs. It discusses where and how to collect evidence from Windows machines and networks using tools such as WireShark, LogParser, EnCase, and the SysInternals toolset.
In addition, the book explores the information you can get from the registry, the file system structure and contents, text-based logs, event logs, and processes on the machines in question. You also find out how to create a Live-Analysis CD, which contains the tools you need to track down the evidence you need. Finally, the book discusses how to present the results of your investigation, detailing guidelines and procedures for testifying in court.

Price: $59.99.

Gather System Data
MetaLAN
hammer-software.com/metalan.shtml
Centralized administration is one of the key components to successful systems administration. It eliminates a lot of running around, and it frees up some of your valuable time thus reducing the amount of stress you are under at work.
MetaLAN from Hammer Software is a tool to help you manage and support users and servers on your Windows network. This agentless application allows you to quickly gather information about, make changes to the configuration of, and generally manage your Windows machines. This, of course, requires the necessary user context and rights to do so.
MetaLAN has two modes of operation. You can choose to either run it directly in Administrator mode (which reaches out to the machines you wish to inquire about or modify the properties of) or you can use the free add-on agent/service, called ProbeServer, on the remote machine in tandem with MetaLAN running in server mode to continuously monitor your workstations.
Launching the app brings you to the MetaLAN Control Panel UI, which, in turn, gives you the option to probe your current network for domains to manage. Here, you can also launch the various tool components, such as the Help Desk Tool, Report Tool, Software Tool, and RegCast Tool.
The Help Desk Tool gives you a search and browse view to the machines in the domain you are managing. Selecting a computer brings up a bunch of useful information about the machine, including the manufacturer, IP addresses, processors, drives, MAC addresses, and server roles. From here, you can run Windows Management Instrumentation (WMI) queries, connect to real-time performance monitors, view installed software, and perform other useful administrative tasks.
The Report Tool gives you quick, exportable, and graphical views of your managed nodes. For example, you can generate a pie chart of the CPU speeds of all the machines in your network or verify which machines have Windows XP Service Pack 2 installed.
The Software Tool allows you to quickly view and export lists of the software that is installed on a group of one to N machines in your network—this is a great tool for audits.
And the RegCast Tool lets you view (and modify if you are a Domain or Enterprise Administrator) registry information on remote machines of a selected group of machines.
MetaLAN also includes a tool for remotely deploying and installing Microsoft Installer (MSI) packages (if they support silent install); a Storage Overview that shows you every drive on your machines and how much free space is available; and a Service Admin tool that lets you start, stop, and even remove services. As if that wasn't enough, there is even a cool Virtual Network Computing (VNC) remote control tool that will push down a small VNC executable that, when executed, gives you remote control over the machine (much like Remote Assistance).

Price: Starts at $75 for a 20-node license pack.
Help Desk Tool gives you a search and browse view
Help Desk Tool gives you a search and browse view

Automate Tasks
AutoHotkey
autohotkey.com
Automation can be an IT professional's best friend, helping him avoid those time-consuming, repetitive tasks. Among the many tools out there that help us in this capacity is the AutoHotkey utility. This free, open-source tool helps streamline desktop routines by automating almost any task that requires keyboard, mouse, or even joystick input. It's a script-based hotkey and macro tool on steroids.
AutoHotkey runs in your system tray, and upon startup it executes the script definition you have created. The program executes individual script commands as they appear in the script file. This is great for launching your favorite set of applications on startup, for example. But wait, there's more: you can also define any number of hotkeys and hotstrings.
Hotkeys, or shortcut keys, are any key combination you define to trigger an action, such as launching an app, bringing windows to the foreground, or even simulating the mouse wheel scroll action.
Hotstrings, on the other hand, are text abbreviations for often-typed commands or phrases. In addition, these hotstrings can be used to launch a scripted action similar to a hotkey. For example, you could create a hotstring with the simple key sequence of "td" that opens up Microsoft Word and writes today's date in the format that you desire. Or, if there is a particular paragraph response that you seem to always be sending to your users, you could create a simple hotstring to automatically dump that paragraph into a new Outlook message.
The scripting language itself supports variables, expressions for math and string operations, built-in global variables, functions, looping, and conditional statements, so you should be able to construct a script that suits your system administration needs. In total, there are well over 100 commands and language constructs to help you out. For example, you can simulate a mouse drag, show message boxes, run asynchronous operations, send e-mail messages, modify the registry, set timers within loops to have recurring checks, open applications, close windows, and kill processes, to name a few.
Another cool feature of AutoHotkey is that you can compile your scripts for reuse and distribution once you have them tailored to your needs. This way, users who do not have AutoHotkey installed can still take advantage of your shortcuts and scripts. And, due to the license of the open source project, you can distribute or sell them with no restrictions.
In your internal organization, you could easily distribute to your end users an executable script that performs some set of customizations that you would otherwise have to perform manually right at their desktop. Furthermore, if you need to tailor those scripts for each user, AutoHotkey also accepts command-line switches and parameters, so you really end up with something that is both useful and reusable across your domain.
Unlike many open-source projects, which often lack depth in the documentation, the AutoHotkey documentation is thorough and well-laid-out, showing you what you need to know to script out your automation tasks with many good and useful examples. In addition, on the project Web site, you'll find an active user forum to help with any questions and a wiki that contains scripts, tutorials, and a command reference. There is also a script showcase page, which offers a good set of usable user-contributed examples.

Price: Free.
AutoHotKey can compile scripts for reuse and distribution
AutoHotKey can compile scripts for reuse and distribution

Greg Steen is a technology professional, entrepreneur, and enthusiast. He is always on the hunt for new tools to help make operations, qa, and development easier for the IT professional.


 Utility Spotlight: Windows Server Logo Certification
Utility Spotlight
Windows Server Logo Certification
Venkat Krishnamachari
Download the code for this article: Works with Windows Server 2008 (KB)

With Windows Server® 2008 Software Certification, Microsoft is trying to help developers comply with best practices and let IT professionals evaluate applications before purchase, saving time and aggravation. To help customers gauge application compatibility, Microsoft created the "Works with Windows Server 2008" program, which includes free supporting test tools to help ensure an application delivers a predictable experience.
The "Works with" tool gathers data about the application's impact on the OS during its lifecycle by monitoring the state of the file system, registry, services, and drivers. Then the tool analyzes this data and reports specific test-case successes and failures. The "Works with" Test Framework document and additional tools, available at windowsservercatalog.com/ready, provides further details. These tools should help ISVs build in application compatibility while enabling IT pros to evaluate an app's readiness for deployment on Windows Server 2008.
To use these tools, first install the latest version of Windows Server 2008 on a test computer, download the "Works with" tool via windowsservercatalog.com/ready, and make sure you include the Application Verifier tool. The tool's GUI has four simple functions: Create a test pass; Resume an existing test pass; View test results; and Create a submission package (for ISVs seeking "Works with" validation from an authorized test vendor).
Text report showing results
Text report showing results
You create a test pass by walking an application through its lifecycle: installation, configuration, execution, and uninstall. The "Works with" tool primarily runs in the background, verifying OS stability and installer compatibility, and whether features execute properly given the platform's new security requirements and other configurable features. It's generally best to complete the test pass and generate the full report, which usually takes two to four hours. However, you can stop a test pass, generate a quick report, and resume the test later.
When you're finished, you'll have clear red or green status reports on every test case with detailed results, like those shown in the screenshot. Tests reported as green indicate compatibility. For red results, you can review a log file to understand the error condition. Be sure to save locally generated logs to another machine so you can reference them after you wipe your test computer. The "Works with" tool runs on any server application, and it can also evaluate client components and management tools designed for Windows Vista®.
If you're using commercial software, the "Works with" tool can help you plan migration around known compatible applications. You can use test results to query vendors about support plans while saving developers time discovering compatibility issues and prioritizing fixes. For custom apps, you can provide highly specific feedback to your development teams. You can also confirm ongoing compatibility as new patches are released and document application configuration data for your IT department. Some customers have used the tools to document files that system applications touch.
We're interested in your feedback on how we can improve the test cases or the tools to increase usability in your environment. Please drop a line to wslogofb@microsoft.com.

Venkat Krishnamachari has served as the Technical Lead for Windows Server Software Certification since 2005, prior to which he worked on the team that shipped SQL Server 2005.


 The Cable Guy: Migrating Your Intranet to IPv6 with ISATAP
The Cable Guy
Migrating Your Intranet to IPv6 with ISATAP
Joseph Davies
This article is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

A common misperception about Internet Protocol version 6 (IPv6) is that in order to use it, you must deploy native IPv6 addressing and routing, which requires a detailed analysis of IPv6 addressing schemes, router updates and configuration, and a rollout schedule. Although this should eventually be done for native
IPv6 connectivity, you can easily deploy tunneled IPv6 connectivity using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). With tunneled IPv6 connectivity, hosts that support ISATAP can communicate using IPv6 traffic that is encapsulated with an IPv4 header (the IPv4 Protocol field is set to 41). ISATAP traffic can traverse an IPv4-only intranet, so you can begin testing IPv6-capable applications immediately, without having to wait for a native IPv6 infrastructure.
ISATAP is an address assignment and automatic tunneling technology defined in RFC 4214 that provides unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4- only intranet. ISATAP hosts use a logical tunneling interface that is assigned ISATAP addresses, which have the form UnicastPrefix:0:5EFE:w.x.y.z (when w.x.y.z is a private IPv4 address assigned to the ISATAP host) or UnicastPrefix:200:5EFE:w.x.y.z (when w.x. y.z is a public IPv4 address assigned to the ISATAP host). UnicastPrefix is any 64-bit unicast address prefix, including link-local, global, and unique local prefixes. Examples of ISATAP addresses are 2001:DB8::98CA:200:131.107.28.9 and 2001:DB8::98CA:0:10.91.211.17.

Intranet Migration to IPv6 with ISATAP
An ISATAP deployment consists of one or more logical ISATAP subnets, which are IPv4-only networks assigned a 64-bit IPv6 subnet prefix. On a logical ISATAP subnet there are ISATAP hosts and ISATAP routers. An ISATAP host uses an ISATAP tunneling interface to encapsulate IPv6 traffic. This traffic can be sent directly to other ISATAP hosts on the same logical ISATAP subnet. To reach destinations that are on other ISATAP subnets or on native IPv6 subnets, the traffic is sent to an ISATAP router. An ISATAP router is an IPv6 router that advertises subnet prefixes to ISATAP hosts and forwards IPv6 traffic between ISATAP hosts and hosts on other IPv6 subnets. Figure 1 shows the components of ISATAP on a simplified intranet.
Figure 1 IPv4-only and IPv6-capable portions of your intranet
Figure 1 IPv4-only and IPv6-capable portions of your intranet
ISATAP allows you to deploy native IPv6 addressing and routing capabilities on your intranet in three phases.
Phase 1: IPv4-Only Intranet In this phase, your entire intranet can be a single, logical ISATAP subnet. Figure 2 shows an example with an IPv4-only intranet with an ISATAP router that is only advertising a global or unique local address prefix to ISATAP hosts.
Figure 2 An IPv4-only intranet
Figure 2 An IPv4-only intranet
Phase 2: IPv4-Only and IPv6-Capable Portions of Your Intranet In this middle phase, your intranet has an IPv4-only portion (the logical ISATAP subnet) and an IPv6-capable portion. The IPv6-capable portion of your intranet supports IPv4 and has been updated to support native IPv6 addressing and routing. You saw this configuration in Figure 1.
Phase 3: IPv6-Capable Intranet In this final phase, your entire intranet supports both IPv4 and native IPv6 addressing and routing. Note that ISATAP is no longer needed. Figure 3 shows an example.
Figure 3 IPv6-capable intranet
Figure 3 IPv6-capable intranet
With ISATAP, you can have IPv6 connectivity between hosts and applications during the first two phases of the transition from an IPv4-only to an IPv6-capable intranet.

Windows Server 2008 and Windows Vista
The IPv6 protocol for Windows Server® 2008 and Windows Vista® supports ISATAP as both an ISATAP host and an ISATAP router. There is a separate ISATAP tunneling interface for each LAN interface that is installed in the computer that has a different DNS suffix. For example, if a computer running Windows Vista has two LAN interfaces and they are both attached to the same intranet and are assigned the same DNS suffix, there is only one ISATAP tunneling interface. If these two LAN interfaces are attached to two different networks with different DNS suffixes, there are two ISATAP tunneling interfaces. For computers running Windows Server 2008 or Windows Vista SP1, the ISATAP tunnel interfaces are placed in a media-disconnected state unless the name "ISATAP" can be resolved.
By default, the IPv6 protocol for Windows Vista with no service packs installed automatically configures link-local ISATAP addresses (FE80::5EFE: w.x.y.z or FE80::200:5EFE:w.x.y.z) on the ISATAP tunnel interfaces for the IPv4 addresses that are assigned to the corresponding LAN interfaces.
The IPv6 protocol for Windows Server 2008 and Windows Vista SP1 configures link-local ISATAP addresses on ISATAP tunnel interfaces only if the name "ISATAP" can be resolved.
To receive a router advertisement message from the ISATAP router, the ISATAP host must send the ISATAP router a router solicitation message. On an Ethernet subnet, a native IPv6 host sends a multicast router solicitation message and then the routers on the subnet respond with a router advertisement message. Because ISATAP does not use IPv4 multicast traffic or require an IPv4 multicast-capable infrastructure, the ISATAP host must unicast the router solicitation message to the ISATAP router.
To unicast the router solicitation message to the ISATAP router, the ISATAP host must first determine the unicast IPv4 address of the ISATAP router's interface on the logical ISATAP subnet. For the IPv6 protocol for Windows Server 2008 and Windows Vista, an ISATAP host obtains the unicast IPv4 address of the ISATAP router through the successful resolution of the host name "ISATAP" to an IPv4 address or with the netsh interface isatap set router command.

Migrating Your Intranet: Phase 1
In order to deploy ISATAP on your intranet for phase 1 of your migration to IPv6, you need to perform the following steps.
Determine the ISATAP Subnet Prefix You must determine the 64-bit subnet prefix to assign to the logical ISATAP subnet corresponding to your intranet. You can obtain a 48-bit prefix from an ISP or Internet registry, or you can derive your own 48-bit unique local prefix (see RFC 4193 online at tools.ietf.org/html/rfc4193).
From the 48-bit prefix, choose a 16-bit subnet ID for the logical ISATAP subnet. The combination of the 48-bit prefix and 16-bit subnet ID is the 64-bit ISATAP subnet prefix. For example, the 48-bit unique local prefix FD8A:219C:052A::/48 and the subnet ID 1 form the 64-bit subnet prefix FD8A:219C:052A:1::/64.
Designate an ISATAP Router Computer Determine which computer will be the ISATAP router. Although many commercial routers support ISATAP router functionality, the information I present here is specific to computers running Windows Server 2008.
The ISATAP router computer does not need multiple LAN interfaces, nor does it need to be connected to an IPv6-capable portion of your intranet for phase 1; however, the computer should be chosen so that later it can be updated with an additional LAN interface that is connected to the IPv6-capable portion of your intranet.
Configure the ISATAP Router Computer On the ISATAP router computer, issuing the following command places the ISATAP tunneling interfaces on the ISATAP router computer in a media-connected state:
netsh interface isatap set router IPv4Address
IPv4Address is the IPv4 address assigned to the LAN interface of the ISATAP router computer that is attached to the logical ISATAP subnet.
Next, determine the name or interface index of the ISATAP tunneling interface that corresponds to the LAN interface of the ISATAP router computer that is attached to the logical ISATAP subnet, all from the output of this command:
netsh interface ipv6 show interfaces
Next, use this command to enable advertising on the ISATAP interface:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex is the name or interface index of the ISATAP tunneling interface.
Next, use this command to configure the ISATAP router computer to advertise the ISATAP subnet prefix to ISATAP hosts:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix is the determined ISATAP subnet prefix
Configure DNS In your DNS, add an address (A) record for the name ISATAP to the appropriate domains so that ISATAP hosts on your intranet can successfully resolve the name "ISATAP." For example, if your intranet hosts use the contoso.com DNS suffix, you must now add an A record to the contoso.com domain for the name isatap.contoso.com with the IPv4 address that is assigned to the ISATAP router's LAN interface on the IPv4-only intranet.
If the DNS server is running Windows Server 2008, use the registry editor (regedit.exe) on the DNS server to remove the ISATAP entry from the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList registry value.
Test ISATAP Hosts From an ISATAP host on your intranet, use the Ipconfig tool to view the assigned addresses. ISATAP hosts should have an address of the form ISATAPSubnetPrefix:: 5EFE:w.x.y.z or ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z. For example, if your ISATAP subnet prefix is FD8A:219C: 052A:1::/64 and an ISATAP host has the IPv4 address 10.1.31.97, the ISATAR host should have the address FD8A: 219C:052A:1::5FE:10.1.31.97 assigned to its ISATAP tunneling interface.
If an ISATAP host does not have an ISATAP address based on the ISATAP subnet prefix, verify that the host can resolve the name "ISATAP." If not, verify that the A records have been created in the appropriate domains and, for DNS servers running Windows Server 2008, verify that the GlobalQueryBlockList registry value has been modified to remove the ISATAP entry. If the name can be resolved, verify that the ISATAP router computer has been configured correctly. If it has, verify that the routers on your intranet allow the forwarding of IPv4 protocol 41 traffic.
When ISATAP hosts can successfully configure themselves with addresses based on the ISATAP subnet prefix, they register these ISATAP addresses as AAAA records in DNS and begin using them for IPv6-based connectivity.

Migrating Your Intranet: Phase 2
In phase 2 of your migration to IPv6, it is necessary for you to modify your ISATAP router configuration to perform forwarding between the IPv4-only and IPv6-capable portions of your intranet.
On the ISATAP router computer, issue the following command:
netsh interface ipv6 show interfaces
From the output of the command above, determine the name or interface index of the LAN interface attached to the IPv6-capable portion of the intranet and the ISATAP tunneling interface.
Use this command to enable forwarding on the ISATAP interface:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Use this command to enable forwarding on the LAN interface:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex is the name or interface index of the LAN interface.
Use the following command to add a default route to the ISATAP router:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress is the IPv6 address of a neighboring native IPv6 router on the IPv6-capable portion of the intranet.
To make the logical ISATAP subnet reachable from the IPv6-capable portion of the intranet, it is important that you configure the native IPv6 routers with a route for the ISATAP subnet prefix that points back to the ISATAP router computer.
To selectively disable ISATAP for computers on the IPv6-capable portion of the intranet, manipulate A records for the name ISATAP in your DNS so that computers on the IPv6-capable portion of the intranet cannot resolve the name ISATAP.
Another option that you have is to create and set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents registry value to 0x4 (DWORD type).

Migrating Your Intranet: Phase 3
For phase 3, when your entire intranet is IPv6-capable, you will need to remove the ISATAP deployment through DNS and reconfigure the ISATAP router computer. For DNS, remove all A records for the name ISATAP. This will prevent any host from determining the IPv4 address of the ISATAP router.
For the ISATAP router computer, run the following command:
netsh interface isatap set router default
This command resets the ISATAP component back to its default state.
Determine the name or interface index of the ISATAP tunneling interface from the output of this command:
netsh interface ipv6 show interfaces
Use this command to disable forwarding and advertising on the ISATAP interface:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Use this command to remove the ISATAP subnet prefix route from the ISATAP router computer:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix is the ISATAP subnet prefix.
For more information about ISATAP deployment, including details about redundant ISATAP routers and firewall considerations, see the "Intra-Site Automatic Tunnel Addressing Protocol Deployment Guide" at go.microsoft.com/fwlink/?LinkId=106926.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column. Read more about The Cable Guy at microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Progress Report
Windows PowerShell
Progress Report
Don Jones

I was recently writing a fairly long and complicated Windows PowerShell script that, as it was running, became fairly unresponsive. I had written it to be run as a scheduled task, so it didn't really produce much in the way of visible output. When I ran it for its first big test, I nevertheless started to get a bit worried that I'd
accidentally written an infinite loop or some other problematic bit of script.
As the shell just sat there, pathetically blinking its little cursor, I asked myself, "Did I kill it?" Apparently, I have no confidence in myself because I quickly hit Ctrl+C to break the script. Time to add some progress reporting.

Blather, Blather, Blather
Cmdlet of the MOnth: Tee-Object
This month, I want to take a look at one of my favorite troubleshooting cmdlets. Take this, for example:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
On the surface, this would seem to start all services that are set to start automatically but have not yet started for some reason. This doesn't actually work, though, and finding out why it doesn't work can be tricky since you can't peer inside the middle of the pipeline. That is, you can't peer inside the pipeline unless you use Tee-Object.
Tee-Object redirects objects to a file (or into a variable) and passes them down the pipeline. For example:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
This modification lets me see what happens after each pipeline command, and I quickly discover that my FilteredServices.csv file contains nothing! No wonder this script didn't work! A bit more research reveals the root cause of the problem—StartMode is "Auto" not "Automatic"—and Tee-Object let me pinpoint exactly where the problem was occurring.

The first thing I wanted to do was to add a bunch of status messages, letting me know exactly what the script was doing. The shell lets you do this quite easily with the Write-Verbose cmdlet. Go ahead and try it in the shell:
Write-Verbose "Test Message"
If you just tried this, you will have noticed that it didn't do anything. That's because Write-Verbose sends objects to the special Verbose pipeline, which, by default, doesn't display its output. A built-in shell variable, $VerbosePreference, controls this pipeline. The default value for this variable is SilentlyContinue, which suppresses verbose output. Setting it to Continue, however, opens the pipeline:
$VerbosePreference = "Continue"
Now I can add a bunch of Write-Verbose statements to my script and get a detailed look at what's going on as it runs. And the beauty of this technique is that, when I'm done testing and troubleshooting, I can shut off all that extra chatter by setting $VerbosePreference back to SilentlyContinue at the beginning of my script.
There's no need to go and remove all the Write-Verbose statements. In fact, since they stay there in the script, anytime I need to run the script manually, I can easily switch the Verbose pipeline back on if necessary.

But I Need Real Progress
Once I was satisfied that the script wasn't caught in an infinite loop and was, in fact, working perfectly, I shut off the Verbose pipeline and ran it again—just to be sure.
The problem now is that, despite knowing that the script is functioning perfectly fine, I just can't bear staring at a blinking cursor. (I have attention span issues. I desperately looked for some paint so I could sit and watch it dry instead.)
What I needed was a general indication of how far along the script had progressed and some idea of when it would be done. Basically, I wanted something like a progress bar.
Fortunately, Windows PowerShellTM includes the Write-Progress cmdlet. This cmdlet doesn't provide a graphical progress bar like you see in Windows®, but it does produce a nice progress bar nonetheless, as shown in Figure 1. It looks a bit like the file copy progress bar used by the text-based portion of Setup in Windows Server® 2003 or even Windows XP.
Figure 1 How far has your script progressed?
Figure 1 How far has your script progressed?
Using Write-Progress requires a bit of explanation. Actually, I think an example would be even better. Consider this script:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
It uses Write-Progress to display a progress bar. I've used Start-Sleep to make the script pause one second each time through the loop, so that it executes slowly enough for us to actually see the progress—without the pause, the loop counts from 0 to 100 so quickly that the progress bar merely flashes briefly on the screen.
As you can see, the Activity—which I've set to Working—shows up in the top of the progress bar. The Status is shown right below it, and the CurrentOperation is shown at the bottom. The shell only supports a single progress bar at a time. Any use of Write-Progress will either create a new progress bar if one isn't currently shown or update the bar that is currently shown.
What I haven't done here is told the bar to actually go away when it's finished. I can do that by simply adding this to the end of my script:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
Generally speaking, the progress bar will vanish by itself once your script is complete, but if your script has other things to do you'll want to hide the progress bar when you're done with it; the -Completed parameter simply removes the bar from the display.

Tick, Tick, Tick
Another common use for Write-Progress is to create a "seconds remaining" display, rather than an actual progress bar. Here's an example:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
All I've done here is change the loop to count from 100 to 1, and I used the SecondsRemaining parameter of Write-Progress, rather than PercentComplete. The result is shown in Figure 2. As you can see, the progress meter is gone, replaced by a countdown clock. The shell automatically converts the total number of seconds remaining into hours, minutes, and seconds, offering more user-friendly information. The percent complete shown here actually counts down from 100, since that's simply the CurrentOperation parameter I provided. There is no actual calculation of percent completed; the Windows PowerShell is simply displaying the current value of $a followed by the string "% complete."
Figure 2 How long until your script is complete?
Figure 2 How long until your script is complete?

Scripts that Communicate
I'm a big fan of writing scripts that communicate what they're up to. It can take the form of verbose output or just a simple progress bar. It can be intended for my own attention-deficient benefit or for the benefit of someone else who will need to run my script months from now. In the end, displaying some kind of status and progress information will be a huge benefit.

Don Jones is a contributing editor for TechNet Magazine and is the coauthor of Windows PowerShell: TFM (SAPIEN Press, 2007). He teaches Windows PowerShell (see www.ScriptingTraining.com) and can be reached through the ScriptingAnswers.com Web site.


 Hey, Scripting Guy!: Our Favorite Shell Games
Hey, Scripting Guy!
Our Favorite Shell Games
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2008_03.exe (150KB)

According to the old proverb, even the tiniest sparrow cannot fall to earth without the heavens knowing about it. Now, the Scripting Guys aren't suggesting that people go around knocking sparrows out of the sky. (Although if someone wants to take care of those stupid crows who sit on the roof and screech at 7:00 A.M. on a Saturday, well, that's a different story. [The Scripting Editor likes crows, and so we're sure that by "take care of" the Scripting Guy who writes this column means "make sure they stay healthy."-Ed.]) Nevertheless, it is comforting to know that if you do fall, someone cares, and that no matter how small and insignificant you might seem, someone somewhere is watching over you. [Even if it's just an editor.-Ed.]
What's true for sparrows turns out to be true for system administration scripting as well. It's safe to say that, in the scripting world, most of the attention is focused on the big scripting kahunas: Windows PowerShellTM, VBScript, WMI, ADSI, even the FileSystemObject. It's understandable that these technologies get the most hype and the most publicity; after all, they enable you to do a lot of really cool and useful things. But that doesn't mean that these are the only technologies available to scripters. Far from it.
Take the Shell object, for example. While the Shell object might not be as well-known or as widely publicized as Windows PowerShell, it's still important—and still useful.
There's a good chance that, sooner or later, someone will ask you to write a system administration script that uses the Shell object. That leads to an obvious question: what exactly can you do with the Shell object? As it turns out, there are a lot of cool things you can do with the Shell object, some of which (such as managing disk quotas and displaying a progress bar when you copy or move files) have been covered in the Microsoft® Windows® 2000 Scripting Guide (microsoft.com/technet/scriptcenter/guide). In this month's column, we're going to show you a few other nifty little things you can do with the Shell object, things you probably had no idea could be done at all, let alone by using the Shell object.

Changing the Last-Modified Date of a File
Many of you are probably looking at the preceding headline and thinking, "Hey, wait a second. You can't change the last-modified date of a file using a script, at least not using VBScript." To which we can say only one thing: where in the world did you ever get an idea like that?
Oh, right; we Scripting Guys probably have said that in the past, haven't we? Well, as it turns out, we were wrong. Shocking! You can change the last-modified date of a file using VBScript. And all you have to do is use the Shell object.
Note: Don't bother asking how the Scripting Guys could have been wrong about that; after all these years, that should be pretty obvious. A far more interesting question is this: how in the world do we ever manage to get something right?
So you say you want to change the last-modified date of a file, huh? Then just use this script:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
As you can see, there's nothing too terribly complicated about this. We start out by creating an instance of the Shell.Application object. (By the way, don't confuse Shell.Application with Wscript.Shell, the Windows Script Host Shell object. The Shell object we're working with today is the Windows Shell object.) After our instance of the Shell object is up and running, we use the Namespace method to bind to the folder C:\Scripts, then use the oddly named ParseName method to bind to a specified file within that folder. In this case, we're binding to a JPEG image with the file name Dr_Scripto.jpg:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
And what do we do after we bind to the file itself? That's easy; we simply assign a new date and time to the ModifyDate property:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
That's all we have to do.
You know, you're right. That is pretty cool, isn't it? Once we run the script, the last-modified date for the file will be set to January 1, 2008, at 8:00 A.M. (If you want, you can open the folder C:\Scripts in Windows Explorer to verify that for yourself.)
Of course, some of you might be thinking, "Cool. I can change the last-modified date of a file. But why in the world would I want to change the last-modified date of a file?" Well, lots of times people use the last-modified date as a sort of version control system; if you have multiple copies of, say, a script floating around, one way to track the official version is to double-check the last-modified date. By checking the last-modified date you can tell whether or not a particular copy of that script is an unmodified version of the original script.
Note: OK, sure, someone can run the script we just showed you and change the last-modified date. But short of code-signing everything you do, someone can always find some way to beat the system. Assuming you have ethical peers that you share scripts with, this approach is a reasonable one.
At some point you might decide that you want to update—and standardize—the last-modified date for all your scripts. How can you do that? Well, assuming all your scripts are in the folder C:\Scripts, you can simply run the following chunk of code:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
As you can see, this script starts off in a very similar fashion to the first script we showed you. However, in this case, after we bind to the C:\Scripts folder, we don't use ParseName to bind to an individual file in that folder. Instead, we use this line of code in order to return a collection of all the files found in that folder:
Set colItems = objFolder.Items
Once we have our collection, we then set up a For Each loop to loop through all the items in the collection. Inside the For Each loop, we use this handy line of code to change the value of the ModifyDate property of the first file in the collection to January 1, 2008, at 8:00 A.M:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
And then we simply loop around and repeat the process with the next file in the collection. When all is said and done, all the files in the folder C:\Scripts (well, except for any hidden files) will have the exact same last-modified date. See how easy that is? Now, who said you can't change the last-modified date of a file using VBScript?
Oh, right.

Speaking of Being Wrong ...
Back before the dawn of time, when the Scripting Guys first started working with system administration scripting, there was no way to access all the extended file information that gets attached to a file in the NTFS file system. For example, if you right-click on a .wav file and then click Properties, you'll see information similar to what's in Figure 1.
Figure 1 File properties summary
Figure 1 File properties summary
How do you retrieve values like Bit Rate or Audio sample size using a script? You can't. Well, not unless you use the Shell object, that is. (Or Windows Desktop Search 3.0, assuming you've downloaded and installed that software.) Somewhere along the way the ability to retrieve all the extended property information for a file was added to the Shell object, but the Scripting Guys somehow overlooked that fact. Consequently, we've been telling people, "You can't use a script to determine the bit rate of a .wav file," even though, as the code in Figure 2 demonstrates, you actually can.
Figure 2 Use a script to find the bit rate of a .wav file (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
How does this script work? Well, this one also starts out just like the first script we showed you: we create an instance of the Shell.Application object and we bind to the C:\Scripts folder, then we use the ParseName method to bind to the file in question (in this case, J0388563.wav).
At this point, things get a little tricky. To begin with, we set up a For Next loop that runs from 0 to 33; that's because files support as many as 31 different extended properties that have been given index numbers from 0 through 33. (Note that there are a few numbers, such as 27 and 28, that are valid index numbers but don't contain any property values.) In fact, files support the properties shown in Figure 3.
Figure 3 File properties (Close Figure 3)

Index | Property
0 | Name
1 | Size
2 | Type
3 | Date Modified
4 | Date Created
5 | Date Accessed
6 | Attributes
7 | Status
8 | Owner
9 | Author
10 | Title
11 | Subject
12 | Category
13 | Pages
14 | Comments
15 | Copyright
16 | Artist
17 | Album Title
18 | Year
19 | Track Number
20 | Genre
21 | Duration
22 | Bit Rate
23 | Protected
24 | Camera Model
25 | Date Picture Taken
26 | Dimensions
29 | Episode Name
30 | Program Description
32 | Audio Sample Size
33 | Audio Sample Rate
So what do we do inside that For Next loop? Well, the first thing we do is execute this line of code:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
What we're doing here is using the GetDetailsOf method to retrieve the name of property 0 (remember, our loop runs from 0 to 33). We then store that name in a variable named strHeader, and we use this line of code to retrieve the property value of item 0, storing the returned information in a variable named strValue:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
See how that works? Item 0 happens to be the Name property. So the first time through the loop, strHeader will be equal to Name. Meanwhile, the actual name (that is, the value of the Name property) for the first file is J0388563.wav. Therefore, the first time through the loop, strValue will be equal to J0388563.wav. When we put it that way, it doesn't seem so complicated after all, does it?
As you probably know, not all file types support all the extended properties. (For example, a .jpg file isn't going to have an Album Title or Audio Sample Rate.) Therefore, in the next line of code, we check to see whether a returned value is an empty string:
If strValue <> "" Then
If the value is an empty string, then we simply skip back to the top of the loop and repeat the process with the next extended property. If the value isn't an empty string, we echo back the property name and value, like so:
Wscript.Echo strHeader & vbTab & strValue
The net result? Something very similar to this:
Name    j0388563.wav
Size    169 KB
Type    Wave Sound
Date Modified   1/19/2004 8:56 AM
Date Created    3/6/2006 2:02 PM
Date Accessed   12/3/2007 10:41 AM
Attributes      A
Status  Online
Owner   FABRIKAM\kenmyer
Bit Rate        90kbps
Audio Sample Size       4 bit
Audio Sample Rate       11 kHz
Nice.
We're running a little short on time (and space) here, but if you're looking for an even easier way to return the most relevant property values, try the script in Figure 4 instead.
Figure 4 An easy way to return property values (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
What does this script do? Well, if you're in Windows Explorer and you hold the mouse pointer over a file, a tooltip will pop up and give you some useful information about the file, like the information shown in Figure 5. How can you get that tooltip information using a script? That's right. Use the script we just showed you:
Figure 5 Properties shown in a tooltip
Figure 5 Properties shown in a tooltip
Artist: Neil Young
Album Title: Harvest
Year: 1972
Track Number: 1
Duration: 0:04:35
Type: Windows Media Audio file
Bit Rate: 256kbps
Protected: Yes
Size: 5.31 MB
That's all the time we have for this month. Well, that and one last note about sparrows. One reason you might want to keep track of tiny sparrows is this: in some parts of the world, it's considered bad luck for a sparrow to enter your house. Why? Because that means that someone who lives in the house is going to die. (In some cases that's true only if the sparrow lands on a piano. But that's not a superstition, that's just weird.) But here's the interesting part: in other parts of the world, having a sparrow enter your house means that someone who lives in that house is going to get married. Talk about being between a rock and a hard place, huh?

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

March 2008: Cryptic Script
This month's puzzle is a cryptogram, meaning each letter has been replaced by a different letter. (We've left all symbols and numbers intact.) The same letter will always represent a replaced letter. For example, all occurrences of the letter a might be replaced by the letter b, all occurrences of b would be replaced by z, and so on. Here's a simple example:
tdsjqu dfoufs
decodes to this:
script center
The decoding in this case was done by replacing each letter with the letter of the alphabet that precedes it, so t was replaced by s, d was replaced by c, and so on.
The puzzle is a little more random than that. Decode this script and you'll have a script that opens an instance of Microsoft Excel®, adds a new spreadsheet, assigns four values to the first column in the spreadsheet, and then sorts that column in ascending order.
Have fun!

The Puzzle
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Dr. Scripto's Scripting Perplexer
Answer: Cryptic Script, March 2008
Here's the key to decoding the script:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
And here's the actual decoded script:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

The Microsoft Scripting GuysThe 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: Using SCW on Windows Server 2008
Security Watch
Using SCW on Windows Server 2008
Jesper M. Johansson
This article is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

Back in 2005, Microsoft shipped Windows Server 2003 SP1. That service pack introduced the first roles-based security management tool for Windows: the Security Configuration Wizard (SCW). Microsoft designed SCW to be an attack surface reduction tool first and foremost. Its purpose was to analyze what you were
actually doing with your computer and automatically configure it to support those roles you needed, while disabling roles and services that were not being used.
Windows Server® 2008 retains SCW, which has been updated with new roles and integration with the new Windows® Firewall. However, it remains as advanced an administration tool as it ever was.
Windows Server 2008 also includes the new roles-based Server Manager tool and its kin, the Add Roles and Add Features Wizards. In Windows Server 2008, rather than adding individual components through the old-style Add/Remove Windows Components control panel, you now use the roles management tools to configure your server. Byron Hynes covers these tools in the article "Configuring Roles with Server Manager," also in this issue of TechNet Magazine.
The Add Roles and Add Features Wizards are designed to configure your server with the right components to support the roles you've chosen. These also configure the built-in firewall to ensure these roles function correctly. Given this, you may be wondering whether there is still any need for SCW. Granted, there are many administrators that will no longer have a need for SCW. However, there are two groups of people for whom SCW can be an invaluable tool. The first is the paranoid security folks. These are people that appreciate how SCW takes security to the next level.
You can think of the Add Roles and Add Features Wizards as the tools that take a default server and configure it to securely support the roles and features you want. SCW, on the other hand, is the tool that configures your server to support only the roles and features you want. SCW also has a pedagogical effect in that it helps you understand more about how the server is configured. Therefore, I highly recommend that you run SCW after the server has been configured with its complement of roles and features.
The second group consists of those users who want to understand the relationships between the various components. SCW comes with a set of XML files that document the relationships between roles and features, services, and network ports. If you are interested in understanding what various components need, SCW is a very valuable tool.
In this column, I will describe how SCW works and how you would use it to protect your server. And I will provide a comparison between SCW and the Server Manager tools. Note that this column is adapted from my book, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008).

Security Configuration Wizard Overview
To set the stage, I want to present some statistics about the attack surface on Windows Server 2008. Before you configure a server by adding your personal selection of roles and features, it still has a relatively significant footprint of services. By default, Windows Server 2008 has 105 services—42 of which are set to auto start, 55 are set to manual, and 8 are disabled. Contrast that with a clean installation of Windows Server 2003 R2 SP2, which has 86 services installed by default—34 of these are set to start automatically, 32 are set to demand start, and 20 are disabled.
Even with the roles metaphor and the reduction in default roles supported, Windows Server 2008 still has a larger footprint and requires that you take additional care when hardening your servers. SCW will walk you through creating a custom security configuration for your particular servers.
SCW takes a completely different approach to server hardening than existing tools. It works with a roles metaphor to configure the system to support those roles and little, if anything, else. While SCW helps configure the firewall, as the Add Roles and Add Features Wizards do, SCW also disables unnecessary services and configures some additional security settings. Finally, while the Add Roles and Add Features Wizards are only able to install and configure roles that are built into Windows, SCW is extensible. A developer or an administrator can write a custom role or feature configuration file and use SCW to configure any product.
SCW is designed to be used after you have installed all the roles and features the server is supposed to have. If you also have third-party applications on your server, you should install those, too, before you run SCW.
To demonstrate how this works, I have configured a server with three roles (Application Server, DNS Server, and Web Server) and two features (Microsoft® .NET Framework 3.0 Features and Windows Process Activation Service). This is not a particularly logical set of roles and features, but it serves as a good example for this discussion.
To start SCW, run it from the Administrative Tools menu. You will see the dialog shown in Figure 1.
Figure 1 SCW begins by asking what you want to do
Figure 1 SCW begins by asking what you want to do
The first step is to choose whether you want to create a new security policy, edit or apply an existing policy, or roll back a policy so the system will return to the original settings. The choices are relatively self-explanatory.
When you choose to create a new security policy, SCW creates a new policy using some computer as the template for what the policy must support. It analyzes the computer and determines what features and roles it supports, ensuring that those work but also that many unnecessary features are not enabled.
SCW works on a prototype model. It uses XML files to specify what the roles and features look like in terms of which files are installed, which services are configured, and so on. This is why you need everything installed on the computer that you are developing the policy against. If you have third-party programs that install SCW definitions when they install, those will integrate seamlessly. However, if your third-party programs do not install SCW definitions, you will need to configure them manually.
As you can see, you can create a policy on one system and then apply it to many systems. If you are building out a network with many systems, you should first define host classes that are all configured separately. Then you can create a policy using one of them as a prototype and easily apply the policy to all the others with little to no modifications.
When you click Next (in the dialog shown in Figure 1), the wizard asks which computer you want to use as the baseline, or prototype, for this new policy. You would typically choose the local computer, but you also have the option to use a remote computer as the prototype.
After specifying which system to use, you enter the analysis phase. Here, SCW enumerates which roles and features you have installed and matches those up against the database of roles and features. The database contains information regarding which services are used by each role and feature, what network ports they need, and other important configuration information. After the analysis is complete, you can click View Configuration Database to see what the Security Configuration Wizard has found. Note that this is a read-only view that presents comprehensive information about the configuration of the computer. In fact, if you are truly interested in understanding what is on your computer, you can spend a significant amount of time studying this information.

Configuring Your Server with SCW
When you click Next, you enter the first of four sections in SCW: Role-Based Service Configuration. You might notice that the roles you find in SCW, as shown in Figure 2, are not the same set that you find in the Add Roles Wizard. Most of the roles available in the Add Roles Wizard are also present here, and SCW also offers some that are not included in the Add Roles Wizard. For example, the Application Server role that I selected is not present. This is because SCW uses a slightly different metaphor for roles. I will discuss this in more detail shortly.
Figure 2 Using SCW to select the roles you want your server to support
Figure 2 Using SCW to select the roles you want your server to support
You will often have the right set of roles already selected in this dialog. So just verify that the analysis found what you think it should have found. If something is wrong, check whether the role has been installed, and install it if it is missing before you rerun SCW. If you make a mistake, it is not the end of the world. The rollback feature in SCW will bring you back to where you started by undoing any changes the policy has made.
The answers you give in this section are very important because they determine what you will see later on in the network section. Fortunately, the detection logic is quite good and the correct set of roles is usually selected.
Note also that, by default, you see Installed Roles, which are the roles that the server is capable of supporting with the bits laid down on the disk. The selected roles are the ones that it is currently supporting. You can also elect to see all roles in the database. To do this, just select All Roles from the dropdown list. This is useful primarily when you have to build a policy using a prototype server that does not yet have all the roles it needs installed.
After roles configuration, you select the client features you want to support. The feature set is similar but not identical to that in the Add Features Wizard, and there are fewer features in the set. Again, the metaphors are not exactly the same, and SCW can be extended, so what you will see is different from the Add Features Wizard.
When you click Next on the Client Features page in SCW, you go to the Select Administration and Other Options dialog, as shown in Figure 3. An Option in SCW is something that does not neatly fit into either a role or a feature. It may provide administrative support, or it may just be a single service, such as the Interactive Services Detection. Again, most of the options you need should be selected here. It is worth pointing out the dropdown menu, too. This is populated with options relevant to the roles and features you selected earlier, and it will be different on different computers.
Figure 3 Selecting other services and features in SCW
Figure 3 Selecting other services and features in SCW
Next up is the Additional Services dialog. Although SCW ships with a very large database of services, not everything is described here. Those services that SCW finds on a computer that are not present in the database are shown on the Additional Services page. All built-in services should be described, and you should not see this dialog unless you have some third-party service installed.
The wizard then lets you select what to do with services that you are not configuring. This option is meant for when you plan to take the policy you are creating and apply it to a different computer. If that computer has different services than the one you created the policy on, SCW needs to know what to do with them. One option is to leave them alone, which is the default. The other option is to disable them, which is more secure but may break things. But if you follow the advice of only applying policies to servers that are identical to the one you created them on, your choice on this page will be irrelevant.
Now you are finished with the Roles Configuration portion of SCW, and the wizard recaps what you've done. As you can see in Figure 4, even if you just click right through, you will significantly affect the attack surface of the computer. For instance, because this computer is not a Print Server, and it has no printers installed, you have no reason to run the Print Spooler service. SCW disables all services that are not necessary. On our test server, SCW disables 17 services that were set to automatic start and sets 42 manual start services to disabled. Your results, of course, will vary depending on how your server is configured, but you can see that SCW lets you easily tailor a policy specific to your unique servers, thereby drastically reducing their attack surface.
Figure 4 SCW summarizes the changes you've made
Figure 4 SCW summarizes the changes you've made
You now move on to arguably the most important section of SCW: Networking. After the initial welcome page, you see the Network Security Rules dialog, which is shown in Figure 5. This contains a list of all the firewall rules SCW proposes, which are based on the role support you selected in the previous sections.
Figure 5 SCW lists all the rules it determines you need
Figure 5 SCW lists all the rules it determines you need
If no further configuration is made in the Network section, SCW will build firewall rules that lock down the network interfaces so that only these roles and features are supported but all clients can access them. But to really optimize security on your servers, you should use SCW as an integral part in building a Server Isolation strategy. To learn more about server isolation (and its close sibling, domain isolation), take a look at technet.microsoft.com/network/bb545651.
In Windows Server 2008 Security Resource Kit, there is a chapter on securing the network with server and domain isolation. It also discusses how you can use network threat modeling to analyze your network to help ease deployment of server isolation. SCW is a valuable tool in this process.
You can configure restrictions on the proposed rules by selecting the rule and clicking Edit. This takes you to the dialog shown in Figure 6. This is one of four pages that all let you put further restrictions on the networking rules. For instance, you can require IPsec authentication. If you choose this, you can also tie the port to only certain endpoints. For example, you can configure it so that you permit remote administration only from certain hosts. As you can see, this is a key advantage over the Add Roles and Add Features Wizards.
Figure 6 SCW allows you to build firewall and IPsec rules
Figure 6 SCW allows you to build firewall and IPsec rules
This ability to build connection security rules based on the roles you've selected serves two important purposes. First, it provides a golden learning opportunity to understand what your servers are doing. You don't even need to build out a server. You can just run the wizard, make different selections, and see how they affect the options on later pages. Second, it allows you to tie the very abstract concept of a port to a much more logical concept of a service and configure network restrictions based on exactly what the system is actually doing.
Done right, this permits you to develop a very tight configuration for your servers. The Networking section of SCW is undoubtedly the place where you should be spending the majority of your time when building the security policy for your servers.
The remainder of SCW allows you to configure auditing and a few registry settings. The default settings of these parameters are adequate for most organizations and, unless you have special requirements, you should not need to do much here.
After you create your policy, you can save it and apply it to the computer you are working on. Or you can apply it to other computers. You can also transform your policy to a Group Policy Object (GPO) using the scwcmd.exe /transform command.
However, if you have computer-specific settings in the policy, this may not succeed—or it may give very strange results. For instance, if you create endpoint restrictions that include local adapters in the networking section, the policy is deemed computer-specific and will not successfully transform. This is due to the fact that those adapters must be specified using GUIDs. The GUID for an adapter on one computer is meaningless on another computer.
Therefore, SCW is often better used on a server-by-server basis and as a learning tool. For large server farms, you can use SCW as a way to learn about the computers and develop a basic policy. Then you can take that policy and recreate it to be rolled out using whatever tool you use to configure the servers, such as Group Policy or an Enterprise Management System (such as Microsoft Systems Center).

SCW vs. Server Manager
One thing you've seen so far is that the metaphor used for roles and features differs. A "feature" in SCW is something the computer does to act as a client. A "role," meanwhile, is something it does to act as a server.
This differs from the metaphor used in the Server Manager tools, where a role is a collection of services and features that can be thought of as a unit and a feature is something that supports roles. In essence, Server Manager considers a role to be the thing you bought the server to do. Features are important, but not what you bought the server for. The two metaphors and the two different uses of the same terms are bound to confuse people. You will need to stop and think about this carefully before you switch between the tools.
In addition, the Server Manager tools are not extensible. They are designed to manage only the components that ship with Windows. By contrast, third-party programs that you install can add roles and features to SCW. You can even write your own roles and features. The white paper "Extending the Security Configuration Wizard" (available at go.microsoft.com/fwlink/?LinkId=107397) explains how to do this.
SCW also disables components you do not need. The Server Manager tools, on the other hand, merely deploy components that you ask for—they do not touch anything else on the computer. If you need help determining which components you may not need, SCW is the tool to use.
Moreover, while both the Server Manager tools and SCW will configure your network, SCW is far more powerful in this regard. If you are building out a server isolation strategy, SCW can be a gold mine of information and your best friend for deployment. This is obviously an advanced security administration topic, but SCW is an advanced security tool.
Finally, SCW will also configure some additional security settings that the Server Manager tools do not configure. However, those are largely superseded by more effective controls—or already set by default—on Windows Server 2008.

Jesper M. Johansson is a Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. He holds a PhD in MIS and has more than 20 years of experience in security.


 The Desktop Files: You Can't Be Too Rich or Too Thin
The Desktop Files
You Can't Be Too Rich or Too Thin
Wes Miller

If you've ever been to a Microsoft campus, you've probably seen shared-use kiosk systems in the reception areas of most of the buildings. These systems were built with a Web-based front end connected to Windows Terminal Services so employees running from building to building could catch up on e-mail and have other
connectivity. Originally they were set up using older PCs that were being taken out of service and recycled. The hardware, which was otherwise too slow, lacked memory, and had inadequate hard drives, was perfect for thin client applications. If you have older hardware for whatever the reason, you too can put it to good use as workstations in conference rooms, as training machines, and so forth. Rather than adding to landfills, you can be greener and get more bang for your buck.
If your organization is looking at a Windows Vista® upgrade, you might find that some of your hardware is older than you thought. That may mean no Trusted Platform Module (TPM) or Aero® support, but if all your systems need is a larger hard drive or more RAM, then upgrade the hardware. However, some of your systems will simply not be able to run Windows Vista because the hardware is too underpowered or is lacking key functionality. That's perfect hardware to run as a Windows® thin client. Figure 1 lists the Windows Vista hardware requirements so you'll know which bucket your current hardware falls into.
Figure 1 Windows Vista hardware requirements (Close Figure 1)

Hardware | Requirements
CPU | 1GHz+ recommended. CPU speed can determine usability of Windows Vista. A slow, single core CPU won't cut it, but it can make a great thin client. Note that if you're thinking about x64 at all, a Windows Vista hardware refresh is the best time to take it into account and move to x64 when refreshing your hardware overall.
Memory | 1GB+ recommended. Often memory can be added to a system, but think about whether it's cost effective to install memory on dozens, hundreds, or thousands of systems.
GPU | 128MB+ of graphics memory, DirectX® 9.0-capable with a WDDM driver and Pixel Shader 2.0 support. This may not be a deal breaker since it mostly limits Aero support.
HDD | 40GB+ hard disk. More likely a problem on mobile systems than on desktops.
Driver issues | Are Windows Vista drivers available for all of the hardware in your systems?
TPM | If you want BitLocker support without requiring a USB flash drive, your computer will need TPM 1.2 hardware.

So, What Can You Do with a Thin Client?
Using old hardware and smaller operating systems, you can create common area/reception kiosks so users can catch up on e-mail, just as they do at Microsoft offices. You can set up systems that run Remote Desktop or a carefully managed instance of Internet Explorer®. You can install presentation playback systems in conference rooms by running Microsoft PowerPoint® and Remote Desktop, and little else. You can also use old hardware/thin client combinations for point-of-sale systems or job-search kiosks. So, which thin client should you use?

Windows XP Embedded
I've mentioned in previous columns how Windows XP Embedded was developed as a malleable, componentized version of Windows XP. As Don Jones's column from the April 2007 issue discussed (see technetmagazine.com/issues/2007/04/XPe), there are several tools that you use to create Windows XP Embedded images—the principal one being Target Designer (see Figure 2). Target Designer lets you create your own custom Windows XP Embedded image.
Figure 2 Windows XP Embedded Target Designer image
Figure 2 Windows XP Embedded Target Designer image
Note that Target Designer ships with several design templates to help you get started. Of course, you can do it alone, but using a template will make it considerably easier. In Figure 2 you can see the Kiosk/Gaming Console and Windows-based Terminal templates, which are good places to start. Windows XP Embedded also gives you full device support and native power management, as you would get with the full operating system image (you just have to build the support for them into your image). Of course, the more features you add, the more hardware you'll need, so it's important to choose wisely. There is considerable information about Windows XP Embedded available on the Microsoft Web site: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded for Point of Service
Windows Embedded for Point of Service (WEPOS) provides a completely standardized template for point-of-service (POS) systems built upon Windows XP Embedded. WEPOS provides built-in support for numerous POS-related peripherals and is intended primarily for use in the retail and hospitality markets. Unlike Windows XP Embedded, it provides a very fixed set of functionality designed just for this role and cannot be customized to the degree that Windows XP Embedded can.
The WEPOS platform is designed for a very minimal system, requiring only a 233MHz Pentium II processor or faster, 64MB of RAM, and only 280MB for its core operating system image. Detailed information on WEPOS and links to order a trial are available at microsoft.com/windows/embedded/wepos.

Windows Fundamentals for Legacy PCs
Unlike Windows XP Embedded and WEPOS, which are primarily designed for a device manufacturer to ship built into a device, Windows Fundamentals for Legacy PCs (FLP) is licensed as a component of Software Assurance, designed to be used primarily for this exact scenario. Figure 3 shows the installation screen for Windows FLP, which offers four configuration options for users to choose from: Minimum, Typical, Full, and Custom.
Figure 3 Windows FLP installation
Figure 3 Windows FLP installation
Windows FLP requires 64MB of RAM, 500MB or more of hard drive space, and 800x600 or better display resolution. Actual system requirements for hard drive space may vary depending on the OS components you elect to install.
If you are looking for a relatively flexible, minimal operating system to use on legacy hardware, and you already have Software Assurance, then Windows FLP is a good choice. See microsoft.com/licensing/sa/benefits/fundamentals.mspx for more information on how Windows FLP can provide you with a smooth migration to the latest hardware and operating system.

A Streamlined Windows XP
In addition to these smaller versions, Windows XP itself may be perfect to use as is. If you don't have much RAM, disabling services such as Windows Themes and others may save you enough overhead to make the system perform adequately. Make sure, however, you know what you're disabling and that you aren't compromising security (by disabling Windows Firewall, for example).

What Won't Work
Unfortunately, people often attempt to use a number of other options for Windows for lightweight systems. Here are the most obvious choices and specifics on why each won't work as you might expect.
Windows XP Starter Edition is streamlined for use on constrained systems, but is primarily designed for use in developing technology markets and is only available as a licensed copy of Windows from an OEM included on a new PC in those markets. Therefore, it's usually not an option. If you're curious about it, take a look here: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Likewise, Windows PE is not a viable option. Interestingly, during the development of Windows PE, Microsoft initially thought about its use as a lightweight OS. However, in the end it simply was not designed to be used as a lightweight OS but as a minimal, deployment-focused pre-installation environment. For instance, Windows PE has no shell besides the command prompt (and you can't easily add a very functional one), it has no defined API set, no power management, and no audio support.
A pared-down version of Windows XP is also not a good solution. I've heard it suggested that a viable option is to trim down Windows. I'm not referring to simply turning off services or disabling them, but actually removing applications in order to achieve a lighter-weight Windows installation. I seriously discourage this option. If you remove binaries from Windows in order to trim it down, you run the risk of making it unstable or insecure. If a smaller version of Windows is what you need, use Windows XP Embedded. There is a learning curve, and it takes some time to perfect your image, but it is very powerful and best of all, it's supported by Microsoft.
Similar to a minimized version of Windows XP, using an older version of Windows may sound appealing, but the lack of support, updates, and security should discourage you. Just stick with the solutions Microsoft already supports to help you with lighter-weight computing needs, and get the most out of that old hardware of yours without sacrificing appropriate features or security.

Wes Miller is 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: Preparing for IT 2.0
Field Notes
Preparing for IT 2.0
Romi Mahajan

In The Life of Reason, the great philosopher and essayist George Santayana wrote that "[t]hose who cannot remember the past are condemned to repeat it," indicating the incredible importance of learning deeply from past wrongs in order to actively construct a better future. The application of this thought is clear in the worlds of politics, culture, history, and even science. In fact, the idea of "learning from mistakes" is so common as to be cliché. But how many of us in Information Technology truly think about the past—and learn from it? And if we don't, are we at all prepared for the IT world of the future? And indeed what does this future world look like?
Well, let's guess, using the power of memory. Over the last 30 years, the changes have been profound. IT has evolved from large mainframes to browser-based computing, from device concentration to device proliferation, from immaturity and rarity to super-specialization and commonness, from relative simplicity to extraordinary complexity. Extrapolating, we can therefore expect IT to get more complex, more specialized, and more democratized. IT will also need to support increasing numbers of and kinds of devices as well as increasing numbers of and kinds of platforms. All of this will require more detailed planning than ever before.
Are these notions commonly internalized? Not even close.
Take, for instance, the conversations in a panel I recently lead on the "Consumerization of IT," at a technology conference in November 2007. The premise of the panel was simple: that the lines between business and consumer technologies have blurred, that consumer applications and devices are leading the development of IT, and that IT departments need to gear up for the family of phenomena represented by the Facebooks, iTunes, and BlackBerrys of the world. Simple idea? Obvious? Old Hat?
Well, judging by the reaction of folks in the room, not at all. Of about 100, only 4 mentioned they were "on Facebook." "It's for young people," said one participant. "Well, aren't the employees that your IT department supports young and on Facebook?" asked one of our panelists. Confusion and denial ensued. No more than a handful of the IT managers in the room felt it necessary to build out their organizations by hiring people who understand how to build and support applications and devices on the new platforms that occupy the bulk of people's technology time.
When asked how to build effective IT policies governing the use of and security of cross-over technologies like cellular phones and laptops that are dual home- and business-use devices, the crowd was vociferous but had little by way of substantial opinion. A common feeling was encapsulated by one person who said, in the Draconian fashion typical of IT 1.0, "If someone from my office plugged an MP3 player into a work laptop or accidentally left a work-issued cell phone at a bar, I'd fire him."
Uh huh. Go for it.
Another area in which one can detect this poverty of thought is in the dryness of conferences meant for IT leaders. If I see another conference track devoted to the vague notions of "IT business alignment" or "Common score-carding," I think I'll stop traveling. Why aren't more people asking what IT 2.0 looks like and what we need to do to get ahead of the curve? Why aren't we asking what skills and attitudes the new generation of IT professionals need in order to create a dynamic future? Why aren't we bemoaning the fact that not a single company views its IT department in the same light as innovative companies think of their R&D departments? Instead of debating centralization versus decentralization, why not grapple with the real issues of IT totalitarianism versus IT democratization?
We have to love ourselves a little more by showing we care about our future. We've all heard about Web 2.0. It's time to start thinking of IT 2.0 if we are going to realize anything even closely resembling the potential of technology.

Romi Mahajan is Director of the Technical Audience and Platform Marketing team at Microsoft. Romi has been published extensively in many fields including politics, the environment, technology, and sociology.


 Windows Confidential: How Betas Became RCs
Windows Confidential
How Betas Became RCs
Raymond Chen

Back in the old days of Windows®, prerelease versions of the product followed a fairly standard progression. First up were the alpha releases, which were used internally and possibly shared with software development partners outside of the Windows product team.
After alpha releases, there naturally come beta releases, which are sent to a somewhat broader audience. One major difference between alpha and beta release users is that beta releases include people who aren't software developers, such as end users who like to test prerelease software and corporations who want a head start on evaluating the new OS to determine the compatibility of the new product not only with their critical in-house applications but also with their corporate network, standard hardware configurations, and system management tools.
Finally, you had release candidates. These were, as the name suggests, versions of the code that were candidates for final release. In other words, "If everything goes well, we're shipping this puppy." If some horrific bug was found that invalidated this expectation, then as soon as the bug was fixed, a new release candidate build was spun up and the test cycle restarted. Windows 95 shipped its sixth release candidate.
I'm told that the Windows NT® folks followed the same release naming pattern, but they ran into a problem: corporations didn't bother testing their critical applications against beta releases of Windows NT. The logic generally went something like this: "Why bother? It's just a beta. Betas are for fanboys. It'll all be different in the final version anyway. Any testing we do now would just be a waste of time."
Similarly, software companies paid no attention to issues found during the beta testing of Windows NT. "We don't support beta operating systems," they would respond.
These companies would start testing in earnest once the actual release candidate builds came out, and they'd inevitably find a bunch of problems. Some were problems the companies could address on their own, while other issues were more complex and had to do with Windows NT not being "compatible enough" with the previous version of the operating system. There were minor issues with the way a particular project feature worked, and some of these could sometimes be fixed in a short period of time. But some issues were so serious that the product's release was delayed so the team could resolve the problem.
These release candidate builds also generated a lot of suggestions. We received feedback such as, "We think the UI would look better if you arranged the buttons in this way" and "rephrasing this message would make it less confusing for our employees." Those would have been great suggestions had they only arrived during the beta phase, but by the time the first release candidate is rolled out, it's far too late to start making changes to the interface design. The documentation and help files have already been written, the product has been translated into dozens of languages, and the screenshots for the manual and product box have already been laid out, tuned, color-separated, and printed. All that work isn't going to be thrown out and redone just to move a button.
I recall a meeting during the Windows XP era when one of these last-minute changes was being debated. The proposed change would have required that a 20KB help file be altered so that the instructions corresponded to the new UI. The localization and translation representative informed us that re-translating the modified help file under the extremely tight time constraints would cost hundreds of thousands of dollars.
To counteract the attitude that betas don't count, the Windows NT team resorted to grade inflation. There are still beta releases, but the late beta releases—when there is still time (but not much) to do some fine-tuning—have become known as release candidates, and what used to be release candidates are now escrow builds. The term escrow does a good job of conveying the true state of the build: "It's over, and we're not going to touch it unless there is a real emergency."

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He thinks he can see his house from up here.