 TechNet Magazine November 2006

TechNet Magazine November 2006

Windows Vista: 10 Things You Need to Know about Deploying Windows Vista

From more flexible image handling to a new boot loader, Windows Vista introduces some important changes for desktop deployment. Here’s a look at 10 ways Windows Vista can make your next deployment faster and easier than ever.

Michael Niehaus Windows Vista: Protect Your PC with New Security Features in Windows Vista

Developed according to the Microsoft Security Development Lifecycle guidelines, Windows Vista offers a level of security not built into earlier versions of Windows. Take a look at the new and enhanced features Windows Vista offers to help you detect and prevent security threats.

Justin Harrison Windows Vista: Achieve the Non-Admin Dream with User Account Control

While limiting user privileges is a good way to help protect your systems, non-admin accounts can be inconvenient, introducing problems such as application compatibility issues. Windows Vista offers new features that make it easier for you to manage and support standard user accounts

Alex Heaton Windows Vista: Enterprise Networking with Windows Vista

Since the release of Windows XP, networking has changed drastically—users are more mobile, wireless networking is everywhere, and security threats are more sophisticated. Take a look at the innovations in Windows Vista that make networking simpler, more secure, and easier to manage.

Jason Leznek Windows Vista: Getting Ready for Windows PE 2.0

Along with Windows Vista, a more powerful version of Windows PE will be released. This overview discusses the new features and capabilities found in Windows PE 2.0 and how these changes will affect you

Wes Miller Windows Vista: Inside the New Microsoft Application Compatibility Toolkit

Before you deploy a new OS, it's critical that you determine potential compatibility issues and solutions for the many applications your organization relies on. Here's an in-depth look at how you can access your software portfolio, determine the impact Windows Vista will have on applications, and find solutions for potential issues.

John Melton Windows Vista: New Tools for Event Management in Windows Vista

Windows Vista presents a giant step forward in enterprise management, offering a new and improved infrastructure and tools designed for event logging and tracing. The result is easier, more powerful ways to gather information and quickly perform troubleshooting.

Val Menn Windows Vista: More Powerful Group Policy in Windows Vista

The Group Policy infrastructure has been overhauled, delivering new management features, new policy settings, support for multiple local GPOs, and much more. This article looks under the hood at the many changes Windows Vista brings to Group Policy.

Jeremy Moskowitz From the Editor: Get Ready for Windows Vista

Joshua Trupin Toolbox: New Products For IT Pros

Greg Steen Utility Spotlight: Robocopy GUI

Traditional copy and paste works well enough for simple tasks, but for advanced functionality, you need Robocopy. But what if you're not a fan of the command line? Enter Robocopy GUI.

Joshua Hoffman SQL Q&A: Temp Tables, 64-bit Processing, Mirroring, and More

Your queries answered by Microsoft IT professionals.

Edited By Nancy Michell Hey, Scripting Guy!: Sure, We're Adaptable

You can do a lot of networking through scripts. Two Windows Management Instrumentation classes, Win32_NetworkAdapter and Win32_NetworkAdapaterConfiguration, allow you to work with network adapters on your computers.

The Microsoft Scripting Guys The Future Of Windows: Directory Services in Windows Server "Longhorn"

A number of improvements in Active Directory will come your way with the next version of Windows Server. These new Active Directory features will solve a number of problems you previously had to try to work around or simply live with.

Byron Hynes Security Watch: I Just Got a Security Bulletin. Now What?

The Microsoft monthly security bulletin has helped foster more mature processes for deploying security updates. Since you know security bulletins are released on a predictable day, you can build your own regular processes for handling them.

Christopher Budd Inside Microsoft.com: Management and Delegation of ASP.NET

One of the microsoft.com operations team’s challenges is the proper configuration of ASP.NET. Here are some tips they’ve learned.

Jeff Toews Field Notes: Learn to Ask for Help

Edward Dake Windows Confidential: Handling Compatibility Hacks

What should Windows do when a program is so incompatible with Windows that it cannot run at all or that it runs with severe limitations? The current versions of Windows only display a warning dialog. Here's why.

Raymond Chen


 Windows Vista: 10 Things You Need to Know about Deploying Windows Vista
Windows Vista Michael Niehaus

10 Things You Need to Know about Deploying Windows Vista
At a Glance:
  • New desktop deployment methods
  • Changes in Windows setup
  • Tools to help you get started
Download the code for this article: NeihausDeployment2006_11.exe (152KB)

You've deployed Windows XP in the past, and now you're thinking ahead to Windows Vista. Whether you'll be deploying to 10, 100, or 100,000 computers, just knowing how the process has changed from Windows XP will make the deployment run much more smoothly.
So here are 10 deployment differences between Windows® XP and Windows Vista™ that you'll be glad you discovered when it's time to make the move.

1. Windows Vista Images Are Bigger
With Windows XP and Windows 2000, it was possible to create images that would fit easily on a single CD (less than 700MB). Even organizations that added applications, drivers, and utilities to their image typically ended up with an operating system image in the 1GB to 3GB range.
With Windows Vista, image size begins at about 2GB—compressed. Once this image is deployed, the size is often around 5GB or more, and there's no way to reduce it. If you add additional applications, drivers, or other files, this image obviously grows even larger.
So how will you deploy the image? Does your network have the necessary capacity? (10MB networks or non-switched networks are not sufficient.) If you want to use CDs, how many can you deal with? You'll need three or four. DVDs (with a capacity of 4.7GB each) are now easy to create, so you can deploy using DVD drives if you have them. (If not, consider adding DVD drives when buying the next round of PCs.)
With USB memory keys growing in size (as large as 4GB or more) and shrinking in price, it would be quite easy to use one for deploying Windows Vista, since you can make a bootable key as long as the computer's BIOS supports it.
Finally (though this doesn't relate to image size), take note that there is no longer an I386 directory. Instead, all components, whether installed or not, reside in the Windows directory (although not in the standard SYSTEM32 directory). When installing a new component, the necessary files will be pulled from this location.

2. Security Is Enhanced
A number of Windows Vista security enhancements will impact deployment. For example, configuring Windows Vista to support "low rights" users, where the logged-on user does not have administrator rights, is easier. Some applications failed to work on Windows XP when users did not have administrator access because they assumed they would have full access to the C: drive and all parts of the registry. With Windows Vista, applications that attempt to write to restricted areas will have those writes transparently redirected to other locations in the user's profile.
The second big change here is that non-administrators can load drivers. This lets users attach new devices without needing to call the help desk in tears.
The third difference you'll find is that Internet Explorer® can automatically install ActiveX® controls using elevated rights. A new service can perform these installations on the user's behalf (if, of course, the IT administrator allows this via Group Policy).
Some of you may currently be using Power User rights on Windows XP, but this really does not offer many benefits (in terms of restricting user rights) over simply granting full Administrator privileges. Because of this, the Power Users group in Windows Vista has been removed, although it can be put back if required using a separate security template that can be applied to an installation of Windows Vista.
Sometimes you will need administrator rights, but this doesn't mean you want to run with admin rights all the time. So Windows Vista adds User Access Control (UAC), which causes most user applications—even for Administrators—to run with restricted rights. For applications that require additional rights, UAC will prompt for permission, asking either for permission to run with elevated privileges or for other user credentials that can replace the logged-on users.
There are also enhancements to the firewall built into Windows Vista. The new firewall can now control both inbound and outbound traffic, while still being fully configurable via Group Policy.
Finally, BitLocker™ full-volume encryption, which is included with Windows Vista Enterprise and Ultimate, allows the entire operating system volume to be encrypted. The volume can then be read only from within Windows Vista and only when the right keys are provided, either from the computer's built-in Trusted Platform Module (TPM) 1.2 chip, a USB key, or typed into the keyboard. (Note that only TPM 1.2 or later is supported.)

3. Windows Vista Is Componentized
One of the biggest architectural changes in Windows Vista is that it is now a completely componentized operating system. This affects deployment in the following ways.
Configuring which Windows Vista features should be installed requires configuring the components to be enabled. New tools, like the Windows System Image Manager, shown in Figure 1, assist with this.
Security updates, language packs, and service packs are simply components. Tools such as Package Manager (PKGMGR) can be used to apply these to Windows Vista.
Figure 1 Windows System Image Manager
Figure 1 Windows System Image Manager
In addition, all servicing can be performed offline or online. You can even apply changes to Windows Vista or a Windows Vista image when Windows Vista is not currently running. This is ideal for deployments: the operating system can be patched before it boots onto your network for the first time.
Drivers are also treated as components, so they can be added and removed easily—even offline. This means you can add drivers to existing images, even just-in-time (as the machine boots for the first time) during the deployment process. And this applies to mass-storage drivers as well; no longer do you need to create a new image just to add a new mass storage driver.
Windows Vista exposes more settings, with most components providing configurable options, so it's easier to set installation defaults that can be managed on an ongoing basis using Group Policy. For a rundown of new tools in Windows Vista, see the sidebar "Tools You Need; Tools to Forget."
Tools You Need; Tools to Forget
Here’s a rundown of the tools you’ll be using when you roll out Windows Vista, followed by a list of the tools you can retire for good once Windows Vista arrives.

USE THESE:
  • SYSPREP This is the updated version, modified for Windows Vista.
  • SETUP A new installation tool for Windows Vista, replaces WINNT and WINNT32.
  • IMAGEX The new command-line tool for creating WIM images.
  • Windows System Image Manager A tool for creating and modifying unattend.xml files.
  • PEIMG The tool for customizing Windows PE 2.0 images.
  • Windows Deployment Services The new version of RIS, which adds the ability to deploy Windows Vista and Windows XP images, as well as Windows PE 2.0 boot images.
  • PNPUTIL This is the new tool for adding and removing drivers from the Windows Vista driver store.
  • PKGMGR Also new, this Windows Vista tool is used for servicing the operating system.
  • OCSETUP This replaces SYSOCMGR and is used for installing Windows components.
  • BCDEDIT A new Windows Vista tool for editing boot configuration data.
  • Application Compatibility Toolkit 5.0 This updated tool lets you assess whether your applications are compatible with Windows Vista.
  • User State Migration Tool 3.0 An updated tool for capturing and restoring user state, supports Windows XP and Windows Vista, as well as all versions of Office including 2007.
  • BitLocker The full-volume drive encryption capability included in Windows Vista Enterprise and Ultimate editions.

FORGET THESE:
  • Remote Installation Services RIS has been replaced by Windows Deployment Services (WDS) but still offers legacy support on Windows Server 2003; RIPREP and RISETUP are not possible with Windows Vista.
  • Setup Manager/Notepad Use Windows System Image Manager instead for editing unattended setup configuration files.
  • WINNT.EXE and WINNT32.EXE Use SETUP instead.
  • SYSOCMGR Replaced by OCSETUP, PKGMGR.
  • MS-DOS Boot Floppies Forget them. Use Windows PE!

4. Text-Mode Installation Is Gone
The basic process used to install Windows XP has been unchanged since the earliest days of Windows NT®. This time-consuming procedure involved an initial text-mode installation step in which every operating system file was decompressed and installed, all registry entries were created, and all security was applied. Now with Windows Vista, this text-mode installation phase is completely gone. Instead, a new setup program performs the installation, applying a Windows Vista image to a computer.
Once this image is applied, it needs to be customized for the computer. This customization takes the place of what was called mini-setup in Windows XP and Windows 2000. The purpose is the same: the operating system picks the necessary settings and personality for the specific computer it was deployed to.
The image preparation process has also changed. With Windows XP, you would "Sysprep" a machine to prepare the reference operating system for deployment. With Windows Vista, you'll still run Sysprep.exe (installed by default in C:\Windows\System32\Sysprep), which will "generalize" the machine for duplication.
Windows Vista (any version) is provided on the DVD as an already-installed, generalized (Sysprepped) image, ready to deploy to any machine. Some customers may choose to deploy this image as-is (possibly injecting fixes or drivers using the servicing capabilities described earlier).

5. Boot.ini Is History
That's right, the Boot.ini file is not used in Windows Vista or in the new Windows PE 2.0. Instead, a new boot loader, bootmgr, reads boot configuration data from a special file named BCD. A brand new tool called bcdedit.exe (or a separate Windows Management Instrumentation or WMI provider) is used to maintain the contents of the BCD. A Windows PE 2.0 boot image can be configured in BCD too, making it easy to boot into either Windows Vista or Windows PE without making any other changes to the machine. This flexibility can be useful in recovery or maintenance scenarios.

6. Settings Are Configured in XML
With Windows XP (and previous versions of Windows PE) configuration information was stored in various text files. These text files have been replaced with an XML file.
Unattend.txt, which was used to configure how Windows XP is installed, has been replaced by unattend.xml. Unattend.xml also replaces three other files:
  • Sysprep.inf, which was used to configure how a Windows XP image is customized when deployed to a machine using a mini-setup.
  • Wimbom.ini, which was used to configure Windows PE.
  • Cmdlines.txt, which was used to specify a list of commands to execute during mini-setup.
An example of unattend.xml can be downloaded from TechNet Magazine at microsoft.com/technet/technetmag/code06.aspx.
You may still use separate files if you want, though. You don't need to put all configuration items in a single unattend.xml file. The high-level schema of the new XML configuration file is well defined, with each phase of the deployment process represented. The actual configuration items are specified on the appropriate operating system components and these items are dynamically discovered from the components themselves.
With Windows XP, most IT professionals used Notepad to edit the various configuration files. You can still do that, but the Windows System Image Manager tool I discussed earlier can be used to inspect the Windows Vista image, determine what settings are available, and allow you to configure each one.
Another tool to aid deployment is the User State Migration Tool (USMT) 3.0, which is expected to be released at the same time as Windows Vista. It will also use XML configuration files in place of the .inf files that were used in previous versions. See "Migrating to Windows Vista Through the User State Migration Tool" for more information.

7. No More HAL Complications
With Windows XP, technical restrictions prevented the creation of a single image that could be deployed to all computers. Different hardware abstraction layers (HALs) meant you had to maintain multiple images. (For more on this see the Knowledge Base article "HAL options after Windows XP or Windows Server 2003 Setup") Most organizations needed two or three images per platform (x86 and x64) and some chose to have even more—though each image brings added costs and complexity.
In Windows Vista, those technical restrictions are gone; the operating system is able to detect which HAL is required and automatically install it.

8. Windows PE Rules
Windows PE 2.0, the new version that will be released with Windows Vista, is a key part of the deployment process. Even the standard DVD-based installation of Windows Vista uses Windows PE 2.0, and most organizations will be using it (often customized for the organization's specific needs) as part of their deployment processes.
Compared to MS-DOS®-based deployment, Windows PE 2.0 brings numerous benefits, including less time spent trying to find 16-bit real-mode drivers. (It's not even possible to find these any more for some newer network cards and mass storage adapters.) Better performance from 32-bit and 64-bit networking stacks and tools, as well as large memory support are also advantages. And don't forget support for tools such as Windows Scripting Host, VBScript, and hypertext applications.
Windows PE has been available for a few years (the latest version, Windows PE 2005, was released at the same time as Windows XP SP2 and Windows Server 2003 SP1), but not all organizations could use it; it required that you have Software Assurance on your Windows desktop operating system licenses. With Windows PE 2.0, that's no longer the case. All organizations will be able to download Windows PE 2.0 from microsoft.com and use it freely for the purposes of deploying licensed copies of Windows Vista.
Like Windows Vista itself, Windows PE 2.0 is provided as an image that is componentized and can be serviced both online and off. As with Windows PE 2005, several optional components can be added, although Windows PE 2.0 includes some new ones: MSXML 3.0, Windows Recovery Environment, language packs, font packs, and so on. New tools like peimg.exe are provided for servicing Windows PE 2.0. Peimg.exe can also be used for adding drivers—including mass storage devices, which no longer require any special handling.
For more information on Windows PE 2.0, see Wes Miller's article in this issue of TechNet Magazine.

9. It's All about Images
With Windows XP, some companies used the image creation capabilities of the Systems Management Server (SMS) 2003 OS Deployment Feature Pack or third-party image creation tools. There was no generic image creation tool available from Microsoft. That's changed with Windows Vista: new tools have been created to support the Windows Imaging (WIM) file format. Unlike many other image formats, WIM images are file-based, enabling them to be applied to an existing partition non-destructively. This has great advantages in deployment processes, since user state can be saved locally instead of on a network server, eliminating what is frequently the largest source of network traffic during a deployment.
Because WIM files are file-based images, they (obviously) are not sector-based, so there are no issues around different-sized disks or partitions. A WIM image contains only the contents of a single disk volume or partition, so if you have multiple partitions to capture, you create a separate image for each one. But each of these images can be stored in the same WIM file, since the WIM file format supports multiple images per file.
The WIM file format also supports single-instance storage, so duplicate files (even from different images) are automatically removed. Between this and the advanced compression techniques employed, WIM images are typically smaller than images created by other tools. However, because of the extra processing, they do take longer to create. This size versus performance trade-off is fair enough; since you typically capture the image only once and then deploy it many times, the network traffic savings can be substantial.
The IMAGEX command-line tool interfaces with the lower-level WIMGAPI API (which is fully documented for use in custom tools too), and is used to create and manipulate WIM images. It also provides a mechanism for mounting a WIM image as a file system. Once mounted, the image can be read and modified using standard Windows tools since it looks like a normal removable media drive. This facility opens up whole new servicing opportunities.

10. Deployment Is Language-Neutral
Windows XP supported different languages in two ways. You could either deploy localized versions of Windows XP, requiring a different image for each language, or you could deploy an English Multilanguage User Interface (MUI) version with added language packs. There were advantages and disadvantages to each approach, but in most cases organizations that needed to support multiple languages took the MUI route, dealing with the limitations of running with an operating system that was effectively English at its core. Organizations that worked only with one language typically chose to use only the localized versions.
Now with Windows Vista, the entire operating system is language-neutral. One or more language packs are added to this language-neutral core to create the image that is deployed (although only some versions of Windows Vista support multiple languages).
Servicing of Windows Vista is also language-neutral, so in many cases only one security update is needed for all languages. And configuration is language-neutral, so one unattend.xml can be used for all languages.

Help Is Available
The changes I've described mean that the image creation and deployment processes you've been using for Windows XP will need to be updated. In some cases, these updates might be minor; in others (such as an MS-DOS-based process using cmdlines.txt), significant changes may be required. To help, Microsoft has created new tools, guidance, and step-by-step procedures. These are included in the Solution Accelerator for Business Desktop Deployment (BDD) 2007.
BDD 2007 breaks down the deployment process into more manageable pieces, with different teams managing each component. Guidance, checklists, and tools are provided for each team to help with the tasks they need to perform (see Figure 2).
Figure 2 BDD 2007 Breaks the Deployment Process into More Manageable Tasks
Figure 2 BDD 2007 Breaks the Deployment Process into More Manageable Tasks
BDD 2007 is currently available for download from connect.microsoft.com after you sign up for the open beta program. Contained in the download are all the required Windows Vista deployment tools, including Windows PE 2.0, ImageX, Windows System Image Manager, and USMT 3.0, along with documentation explaining how to use them in an end-to-end process. The final version of BDD 2007 will be released at about the same time as Windows Vista. For a look at BDDWorkbench, see Figure 3.
Figure 3 BDDWorkbench Helps You Manage Multiple Deployment Scenarios
Figure 3 BDDWorkbench Helps You Manage Multiple Deployment Scenarios
The goal of BDD 2007 is simplification. Even if you don't have an existing image creation and deployment process, you should be able to use BDD to set one up quickly. Two deployment methods are provided:
  • Lite Touch, which was completely rewritten, requires user interaction to start deployment. It doesn't require any special infrastructure although it can utilize Windows Deployment Services, the next version of Remote Installation Service (RIS).
  • Zero Touch, which requires no user intervention, is layered on top of the SMS 2003 OS Deployment Feature Pack.
The new features in BDD 2007 include driver repository and injection, full computer backup processing, integration of all the Windows Vista deployment tools, and more. BDD 2007 will include all the source code for all of its automation tools, so you can modify it to meet your specific needs or copy and paste it into your own solutions. The source code is provided without restriction.
For more information on BDD 2007, see the TechNet Desktop Deployment center.

Michael Niehaus Michael Niehaus is a Systems Design Engineer in the Core Infrastructure Solutions group at Microsoft. He is responsible for developing best practices, tools, and scripts for Business Desktop Deployment. Reach him at michael.niehaus@microsoft.com.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Windows Vista: Protect Your PC with New Security Features in Windows Vista
Windows Vista Justin Harrison

Protect Your PC with New Security Features in Windows Vista
At a Glance:
  • Using Windows Security Center
  • Configuring and managing User Account Control settings
  • Scanning for spyware with Windows Defender

Several years ago, Microsoft Chairman (and then Chief Software Architect) Bill Gates called on employees to make trustworthy computing the company's highest priority. Along with this announcement came a series of changes in how Microsoft developed software.
Windows Vista™ is the first operating system fully developed under the guidelines of the Security Development Lifecycle (SDL), a security-focused engineering process meant to move security into the very essence of software design; all widely deployed Microsoft products must follow these guidelines. (For more information about the SDL, check out the book The Security Development Lifecycle by Michael Howard and Steve Lipner, Microsoft Press®, 2006).
Windows Vista also includes new or upgraded built-in security technologies that actively work to detect and prevent security threats. All of these changes mean that Windows Vista is the most secure Windows® release yet. In this article I'll discuss the new security Control Panel applet, Windows Security Center, and the built-in protection including Windows Defender, Windows Firewall, and User Account Control.

The Security Control Panel
When you open the Control Panel in Windows Vista you'll notice that it is arranged into ten areas of functionality, with most of the security-related applets spread between Security, Programs, and Network and Internet. You can use the Security applet to access many of the new security technologies that protect you in Windows Vista, as shown in Figure 1.
Figure 1 Security Technologies in Windows Vista (Close Figure 1)

Function | Description
Security Center | Check for updates; check security status; turn on automatic updating; check firewall status; require a password on wake up.
Windows Firewall | Turn Windows Firewall on or off; allow a program through Windows Firewall.
Windows Update | Turn on automatic updating; check for updates; view installed updates.
Windows Defender | Scan for spyware and other potentially unwanted software.
Internet Options | Change security settings; delete cookies; clear history.
Parental Controls | Set up parental controls for any user; view activity reports.
BitLocker Drive Encryption | Turn on BitLocker Drive Encryption.
You can also check for Windows Updates, turn on BitLocker™ Drive Encryption, delete cookies, clear history, and set a password for your computer to send a prompt for when it wakes up.
The Security applet also makes it easy to access the Security Center, an all-in-one location you can use to manage and check the status of your computer's security settings and built-in protection.

Centralized Security
Until the arrival of the Security Center in Windows XP Service Pack 2 (SP2), dealing with all of the Windows security settings was difficult. Now, Security Center is all you need to manage important Windows security settings in one place, and it's even more useful in Windows Vista.
Windows Security Center runs in the background and actively monitors four categories of functionality, as shown in Figure 2: Firewall, Automatic updating, Malware (viruses and spyware) protection, and Other security settings (Internet and User Account Control settings).
Figure 2 Manage Security Settings in One Place
Figure 2 Manage Security Settings in One Place
With Windows Security Center, you can see which application is acting as your computer's firewall or anti-spyware and antivirus solution. You can also check the status of firewall, automatic update, and user account control settings. Windows Security Center is unique in that it monitors the status of third-party applications in addition to built-in Windows technologies. It checks for the following items:
  • Whether a firewall is installed and whether it is turned on.
  • Whether an antivirus program is installed and if the definitions are up to date and real-time scanning is enabled.
  • Whether an anti-spyware program is installed and if the definitions are up to date and real-time scanning is enabled.
Windows Security Center uses two approaches to detect third-party antivirus and firewall applications. In manual mode, Windows Security Center searches for registry keys and files that let it detect the status of the software. It also queries Windows Management Instrumentation (WMI) providers made available by participating vendors that return the status of features. This means you can use non-Microsoft solutions for antivirus, anti-spyware, or firewall issues and still use Windows Security Center to monitor and protect your computer.
Windows Security Center can be controlled by Group Policy. By default, it is disabled in domain environments. To turn on Windows Security Center, access the Computer Configuration\Administrative Templates\Windows Components\Security Center node. The name of the policy to turn it on is Turn on Security Center (Domain PCs only).
Windows Security Center also monitors the status of User Account Control settings and Internet security settings. User Account Control lets you use your computer as a standard user rather than as an administrator, which is much safer. As a standard user, any changes you make can't affect the entire system and any software you install can only do so much damage.
In Windows Vista, if you are running as a standard user on a computer that is not part of a domain and software needs to perform an action that affects the entire system, the OS prompts for the password of an administrator account. If you are running as an administrator, Windows Vista prompts for permission to execute the system-wide action so that you are aware of (and consent to) the action before it takes place.
User Account Control is managed by Group Policy in a domain environment. If your computer is not part of a domain, it is handled by Local Security Policy. Policy settings are found under Computer Configuration\System Settings\Local Policies\Security Options in the Local Security Policy editor or Group Policy editor. You'll find the Local Security Policy editor in Control Panel under System and Maintenance | Administrative Tools.
As Figure 3 shows, Windows Security Center watches a number of Internet security options.
Figure 3 Internet Security Settings (Close Figure 3)

Windows Security Center monitors these Internet settings:
Download signed ActiveX controls
Download unsigned ActiveX controls
Initialize script and ActiveX controls not marked as safe for scripting
Installation of desktop items
Launching applications and unsafe files
Launching programs and files in an IFRAME
Software channel permissions
If an option changes to a state that is not secure, the Internet Properties dialog indicates "Your security settings put your computer at risk" and Microsoft Internet Explorer® will show an information bar that says "Your current security settings put your computer at risk. Click here to change your security settings..." Windows Security Center also notifies you that "You're not using recommended security settings." If you open Internet Security Settings, the unsecure settings will be highlighted in red (see Figure 4).
Figure 4 An Unsecure Setting Highlighted
Figure 4 An Unsecure Setting Highlighted
Windows Security Center can restore unsecure security settings to a secure state. You do this by clicking Restore my Internet security settings now, as shown in Figure 5.
Figure 5 Eliminating a Risky Setting
Figure 5 Eliminating a Risky Setting

Windows Defender
Rootkits, trojans, spyware, and other malicious software have become a huge problem. They put your information at risk, decrease your computer's performance, and can cause system crashes. Microsoft acquired Giant Software in 2004 to provide anti-spyware technology to protect customers. You can find this new technology built into Windows Vista as Windows Defender (which is also available as a download for Windows XP).
After installing Windows Vista, you don't need to change any of your Windows Defender settings immediately. Since Windows Defender comes configured to provide maximum security with minimal interruption, you can focus on using your computer rather than securing it. Windows Defender provides real-time protection as soon as it is started, and it will automatically check for and download updated spyware definitions every night around 2 A.M., and automatically remove all high-threat risks. You can adjust the settings by selecting Tools | General Settings in Windows Defender.
Real-time protection means that Windows Defender carefully watches for suspicious behavior on your computer at all times. It uses the nine security agents listed in Figure 6 to monitor different parts of your system for application behavior that is characteristic of spyware. Together, the Windows Defender security agents monitor almost all common entry points of spyware.
Figure 6 Windows Defender Security Agents (Close Figure 6)

Agent | Monitors
Internet Explorer configuration | Browser security settings.
Internet Explorer downloads | Applications that work with Internet Explorer, such as ActiveX controls and software installation applications.
Internet Explorer add-ons (browser helper objects) | Applications that automatically run when you start Internet Explorer.
Auto Start | Applications that start when Windows starts, including applications that start via the registry and the Windows start-up folder.
System configuration | Security-related settings in Windows.
Services and drivers | Services and drivers as they interact with Windows and applications.
Windows add-ons | Software utilities that integrate with Windows.
Application execution | Applications when they start, and their execution.
Application registration (API hooks) | Files and tools in the operating system where applications can insert themselves to run.

Threat Response
Windows Defender alerts you when it finds potentially unwanted software or detects suspicious behavior. When innocuous (low threat) changes occur, Windows Defender lets you know by displaying an exclamation point in the system tray. For more severe threats (medium or high), Windows Defender displays a yellow or red dialog depending upon the threat level, as shown in Figure 7. These kinds of threats require an immediate response.
Figure 7 Red Window Indicates High-Level Threat
Figure 7 Red Window Indicates High-Level Threat
All actions Windows Defender performs are logged in the System Event Log with source "Windows Defender". Such actions include definition updates and spyware scans and removals.
Windows Defender threat alerts are intelligent, so you can continue working through them. Multiple threats can be listed and you can choose to respond to all threats ("Remove All") in a threat-alert dialog. You can also configure threat alerts to react differently based upon unclassified threats and known software that is allowed to run. To configure threat alerts, open Windows Defender and click Tools | Options. Scroll down to "Real-time protection options" and choose whether Windows Defender should notify you about software that hasn't yet been classified for risks and about changes made to your computer by software that is allowed to run.
Note that if an application you've created or an application you use is being incorrectly classified by Windows Defender, you can file a vendor dispute at microsoft.com/athome/security/spyware/software/isv/cdform.aspx. If the application is being mistaken for spyware, you can report a false positive at microsoft.com/athome/security/spyware/software/isv/fpform.aspx.

Protection On Demand
Windows Defender watches carefully for potentially unwanted software, but you can also start spyware scans whenever you think it's necessary. Windows Defender offers three types of scans:
  • A Quick Scan rapidly checks places on your computer that spyware is most likely to infect.
  • A Full Scan scans all files on your hard disk, running applications, the registry, and other places.
  • A Custom Scan lets you scan specific files or folders; it automatically runs a Quick Scan when it begins.
To initiate a scan, start Windows Defender and click the down arrow next to the Scan button; then select the type of scan you'd like to start, as shown in Figure 8.
Figure 8 Choose the Type of Scan
Figure 8 Choose the Type of Scan
When Windows Defender detects a threat during a scan, it displays a description of the threat and actions you can take to resolve the threat. By default, it displays the best action to take. If multiple threats are found, you can select responses and apply them all at once by clicking Apply Actions, or you can remove all threats by clicking Remove All. Among the actions you can take are:
  • Remove—Remove the threat from your system completely.
  • Ignore—Ignore the threat. The next time you scan, Windows Defender will detect the threat again.
  • Quarantine—Temporarily disables the threat. You can use this to test whether removing the threat has any ill affects on your system. You can always restore it from inside Windows Defender.
  • Always allow—Stop detecting the threat and add it to the allowed items list. You can remove items from the allowed items list by clicking Tools | Options in Windows Defender.

Preventing Network Intrusion
Windows Firewall in Windows Vista is a bidirectional stateful firewall that contains many advances over the Windows XP version. In Windows Vista, Windows Firewall filters both incoming and outgoing traffic. Rules can also be configured for:
  • Active Directory accounts and groups
  • IP protocol number
  • Specific types of interfaces
  • Services
  • ICMP and ICMPv6 by type and code
  • Source and destination IP addresses
  • All TCP or UDP ports, or specified ports
In Windows Vista, you can also allow a specific program access to the network or deny traffic through the Exceptions list. To access the Exceptions list, click Start | Control Panel | Security, and then Allow a program through Windows Firewall.
By default Windows Firewall blocks all incoming traffic unless it is solicited or matches a rule, and allows all outgoing traffic unless it matches a rule.
Windows Vista comes with a new Microsoft Management Console (MMC) snap-in called Windows Firewall and Advanced Security (see Figure 9), which lets administrators configure Windows Firewall settings on remote computers. To access the new snap-in, click System and Maintenance and then Administrative Tools in Control Panel, then click Windows Firewall with Advanced Security.
Figure 9 Create Advanced Rules to Protect Your Computer from Network Threats
Figure 9 Create Advanced Rules to Protect Your Computer from Network Threats
To add a rule, you can also use the Group Policy editor snap-in to access Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security. You can even configure new Advanced Security settings from the command line using netsh advfirewall.
Each time you connect to a new network, Windows Vista creates a profile just for that network. When you connect to the network again, Windows Vista uses the saved settings from that profile. One of the first things that the OS asks when you connect to a new network is whether it is a public or private network. This determines what profile Windows Firewall loads for configuration and rules. If you want to edit the profiles, click Windows Firewall Properties in the Windows Firewall with Advanced Security snap-in, then click either the Private Profile or Public Profile tab, as shown in Figure 10.
If you like, you can change the profile associated with a network after you connect to it from the Network and Sharing Center. To do so, go to Control Panel | Network and Internet | Network and Sharing Center). To change the network profile, click Customize next to the name of the network to which you are connected.
Figure 10 Customize Protection Based on Network Type
Figure 10 Customize Protection Based on Network Type

Conclusion
Windows Vista is the first complete operating system release since the trustworthy computing initiative announcement several years ago. Developed under the guidelines of the Security Development Lifecycle and with built-in protection such as Windows Defender, Windows Firewall, and User Account Control, Windows Vista offers unparalleled protection both for standalone systems and for those that are part of a domain. Windows Security Center, Windows Firewall and User Account Control all offer Group Policy configuration that enables you to deploy them effectively in your domain environment or configure them very extensively locally on your personal computer.
The SpyNet Community
Security threats are ever changing and sometimes even daily updates are not enough to keep up with all of the security threats your computer might encounter. For even more protection than providing spyware definition updates, Microsoft also brings users together in the SpyNet Community, an online group that shares information about spyware.
The Spynet Community is a voluntary worldwide community of Windows Defender users that report spyware findings to Microsoft. Users who participate in this community play an important role in determining what suspicious applications are eventually classified as spyware, and they also help discover new threats quickly so all Windows Defender users are better protected.
The SpyNet Community is opt-in. You must explicitly decide to participate. You can choose not to become a member, in which case no information about your possible spyware infections is sent to SpyNet. You will not be notified if unclassified, potentially unwanted software is found on your computer. The unclassified, potentially unwanted software may eventually be classified in the regular spyware definition updates.
If you choose to participate, there are two levels of membership:
Advanced membership. Participants send information to Microsoft about unclassified software and actions taken. Advanced participants are alerted of currently unclassified software that may not be safe. Some personal information may be sent, but Microsoft will not use it to contact you.
Advanced Members receive removal statistics showing how other advanced members reacted to the same threat. This information can help you make a decision whether or not currently unclassified potentially unwanted software is dangerous. For example, if a new application is being distributed on the Internet and Windows Defender detects it as being suspicious, some advanced users may report it to SpyNet and remove it. SpyNet will tell you how many Advanced Members reported and removed it, so that you can use the information to make a better decision on what you should do.
Basic membership. Basic information about suspicious software is sent to Microsoft. Personal information may also be sent, but Microsoft will not use it to contact you. Basic participants are not alerted about unclassified software.
To join the Spynet Community, open Windows Defender and select Tools, then click Microsoft SpyNet.

Justin Harrison Justin Harrison (justin@harrison.org) is an expert in Windows security, digital media technology, and digital documents. He has worked for GE Energy and the Digital Documents team and the Casual Games team at Microsoft.


 Windows Vista: Achieve the Non-Admin Dream with User Account Control
Windows Vista Alex Heaton

Achieve the Non-Admin Dream with User Account Control
At a Glance:
  • Why you shouldn't run as administrator
  • Addressing problems trying to run as standard user
  • How User Account Control works

Fewer users running with administrator privileges is a worthy goal in most IT organizations. But while IT administrators generally agree that restricting users to a standard user account is the way to go, about 80 percent deploy their desktops with admin accounts, making those
machines more susceptible to malware and harder to manage. But it's not that easy to avoid the admin account. The potential obstacles you'll face if you try are numerous.
First, there's application compatibility. Because many applications were written and tested using administrator accounts, they may not even run under standard accounts. (This is most often the case because the applications attempt to write to restricted areas such as the Program Files directory or HKLM registry keys.)
Second, earlier versions of Windows® were overly restrictive about which settings users were allowed to configure. Standard users could not change the time zone, power settings, connect to secure wireless networks, or install ActiveX® controls without calling the helpdesk, which has associated costs.
Fortunately Windows Vista™ addresses these concerns. And even if your users don't have admin accounts, User Account Control (UAC) and other management technologies in Windows Vista make it easier to support and manage those desktops, promote higher productivity for standard users, and do it all without the looser security that results when you modify access control lists (ACLs)—the usual method of providing users greater, customized access. Let's look more closely at how Windows Vista alleviates some of your access control issues.

Virtualization Improves Compatibility
Many applications that will not run as a standard user on Windows XP will be able to run without modification on Windows Vista because of the File and Registry Virtualization capabilities. In Windows XP, many applications break when they attempt to write to protected areas of the file system and registry that the standard user is not permitted to access. Windows Vista will improve compatibility by redirecting writes (and subsequent file or registry reads) to a special location within that user's profile. For example, if an application attempts to write to C:\program files\contoso\settings.ini and the user doesn't have permission to write to that directory, the write will be redirected to C:\Users\username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. If an application attempts to write to HKLM\Software\Contoso\ the action would automatically be redirected to HKCU\Software\Classes\VirtualStore\MACHINE\Software\Contoso. Figure 1 outlines the redirection process. In addition, the Certified for Windows Vista Software Logo Program will require that an application will run as standard user without requiring virtualization; if it doesn't, the logo will not be awarded to the application.
Figure 1 File and Registry Virtualization Process
Figure 1 File and Registry Virtualization Process

Standard Users Can Do More
In Windows Vista, standard user accounts have been given additional privileges so users can perform common tasks without helpdesk support and without having the full set of permissions provided by the administrator account. The new privileges include the ability to view the system clock and calendar, to change the time zone, to modify wireless network security settings, to change power management settings, and to download and install critical updates from Windows Update.
Additionally, disk defragmentation is an automatically scheduled process in Windows Vista. Actions that do require administrator privileges are marked with a shield icon, so users can see what configuration changes they can and can't make.

ActiveX Control Installation
ActiveX controls can be particularly tricky to manage centrally because they may update frequently and they need to be repackaged before they can be distributed through a software distribution program like Systems Management Server (SMS) or through Group Policy. Windows Vista includes an optional component called the ActiveX Installer Service that allows IT administrators to use Group Policy to specify Web sites from which standard users will be allowed to install ActiveX controls. To use the ActiveX Installer Service, do the following:
  1. Enable the ActiveX Installer Service on the client computers. You can enable the service through the Windows Features Control Panel applet or when you configure your desktop image.
  2. In Active Directory Group Policy, in Computer Configuration | Administrative Templates | Windows Components, select ActiveX Installer Service. Select Enable. Now after the policy is replicated to the users, they will be able to install controls from the sites you specify.
Since ActiveX controls and other executable code could perform malicious tasks, use this feature judiciously; use it only for vendors you trust and only on intranet sites that are under strict control.
The ActiveX Control Installer Service is also integrated with the Windows Vista Eventing Infrastructure, so you can be notified automatically if there are ActiveX controls your users need to install. When a standard user tries to install a control that has not been approved, the service creates an event in the Application Log. In Windows Vista, tasks can be configured to automatically send an e-mail or execute another program as soon as an event is triggered. Then you know when a user needs a control and you can add the site to Group Policy without the user experiencing significant down time. With Windows Vista you can also subscribe to events from multiple machines across your enterprise and generate a list of all the controls your users are trying to install.

Hardware Device Driver Installation
Concerns that users will be unable to install device drivers they need when traveling is another reason administrator permissions remain popular, particularly for laptop users. The new Driver Store infrastructure in Windows Vista alleviates this hurdle by allowing flexible control over devices that standard users can install. First, you can prepopulate the Driver Store with trusted drivers so users can install permitted devices as they need them. Second, you can use Group Policy to give standard users permissions to install classes of devices, such as printers, or even specific device hardware IDs, such as permitted flash drives.
Since the Windows Vista Driver Store is a trusted cache of in-the-box and third-party drivers on the hard drive of each client machine, users may install them without administrator privileges. To stage drivers in the Driver Store, you can either inject them into offline images or dynamically update drivers to online clients over the network. For offline images, use Package Manager to seamlessly stage drivers in the Driver Store.
For online images, use command-line utilities such as pnputil.exe or DevCon in conjunction with software distribution applications to add, update, or delete drivers in the Driver Store. To further streamline and add flexibility to the process of staging drivers, Windows Vista allows IT departments and third parties the ability to sign driver package integrity.
By default, only users with administrator rights can add new drivers to the Driver Store. But there is a critical need for users, particularly mobile users, to install devices like printers while they're on the go. With new Group Policy settings, Windows Vista enables you to give standard users the flexibility needed to install permitted devices even if drivers aren't already staged in the Driver Store. To delegate device driver staging privileges, open the Group Policy interface and navigate to Computer Configuration | Administrative Templates | System | Driver Installation | Allow non-administrators to install drivers for these devices. You'll need to know the GUID for the device classes you want standard users to stage and install. You can find device classes online at MSDN ® or if the device is installed on your machine, go to the Device Manager | Properties window. Click on the Details tab and select the dropdown labeled Device Class GUID. You also need to make sure the certificates used to sign the drivers are already in the client machine's Trusted Publishers store, which can be managed via Group Policy.
These advances in Windows Vista now provide standard users with the needed flexibility in device installation so you can move more users to a managed desktop environment.

Levels of Desktop Lockdown
Even with these improvements in the Windows Vista OS, not every organization will be able to deploy all of their Windows Vista desktops with standard user permissions. Some organizations may have applications that still require administrator privileges or they may have users, such as developers, who need to install their own software. That's OK. Windows Vista allows multiple levels of desktop control, configurable through user account selection and Group Policy, all of which provide more manageability and security than a full administrator account on Windows XP. Most system settings relevant to UAC settings can be found in the Security Policy Editor (secpol.msc), which is shown in Figure 2.
Figure 2 Security Policy Editor
Figure 2 Security Policy Editor
The first level of control is called Admin Approval Mode. This mode reduces the threat of some types of malware attacks by starting programs with standard user privileges by default and alerting the user if a program is attempting to run with administrator privileges. In this mode you can perform audits through the event log when the user runs a program that requires administrator rights. But keep in mind that while an application may run with standard user privileges, this mode doesn't provide the same security as a true standard user account. The user still has administrator privileges and can change policy settings, install unapproved software, and allow powerful malware such as a rootkit to be installed.
The next level builds upon the first, but uses Group Policy to restrict elevation to programs that are signed with a certificate that is in the Trusted Publishers store. This can help prevent unsigned malware from obtaining administrator privileges and can prevent users from installing arbitrary software. However, when running with administrator accounts, savvy, unscrupulous users, or sophisticated malware could disable the policy, at least temporarily, to perform unauthorized actions. Therefore, these first two levels should be used as interim measures while resolving any issues that prevent you from issuing true standard user accounts.
The next level of security comes from removing users from administrator accounts and making them standard users. One feature of UAC is called the Over the Shoulder Credentials Dialog, which standard users will see by default if they start a program that requires administrator credentials. Standard users are blocked from performing that action, but if they know the username and password of an administrator, they may enter it and continue the action. A typical scenario in which this feature could be used involves a traveling laptop user. If, for example, the user has an urgent need to install a piece of software while he is on the road, he could call the helpdesk who could provide the password for a local administrator account, which the user could enter and allow the program to run (see Figure 3). If you provide the administrator password to the user, I recommend that you have processes and tools in place to reset the administrator password when the user reconnects to the network, and that you log the programs that have been run using the administrator credentials. Also be aware that if the PC has been infected by malware, the administrator may be tricked into giving demonstrators privileges to malware that they did not intend to.
Figure 3 Requiring an Admin Password
Figure 3 Requiring an Admin Password
You also have the option of disabling the credentials dialog using Group Policy. Set the User Account Control: Behavior of the elevation prompt for standard users setting to Automatically deny elevation requests (see Figure 4). This is the way we recommend that most enterprises that deploy standard user desktop should configure UAC. Most organizations would do this to prevent the user from calling helpdesk for a password that the IT department doesn't want them to have.
Figure 4 Application Blocked by Group Policy
Figure 4 Application Blocked by Group Policy
For the strongest level of desktop lockdown you can use UAC and standard user accounts combined with Windows Software Restriction Policies (SRP). With SRP, enterprises can go an extra step and prevent any software from running that they did not specifically allow. SRP is designed to block the execution of software unless it meets specific criteria based on Authenticode® certificate, hash, path, or Internet Zone. SRP is managed through Group Policy, and you can create a very powerful policy to prevent the installation and execution of non-approved programs with little work. A typical policy might disallow all executables except any found in these paths: %WINDIR% and %PROGRAMFILES%, and apply polices to all users except administrators.
With this policy in place, the IT staff can still install whatever software programs it wants into the Program Files directory without having to add each .exe to a whitelist (a list of accepted items). And since the standard user does not have access to these directories, he or she cannot place it somewhere that it will execute.
You may have noticed there was no mention of the Power User group. That's because the Power User group has been removed from Windows Vista. Some organizations used the Power Users group in an attempt to limit administrator privileges. While making someone a power user may prevent him from making unapproved system configurations, he (or malware running with power user credentials) may be able to gain additional rights and permissions and even complete administrative credentials. For that reason, Windows Vista has administrator and Standard user as the two primary account types.

Desktop Management Infrastructure
Using File and Registry Virtualization, the new Driver Store infrastructure, and the other features I discussed will make it much easier for you to deploy Windows Vista desktops with standard user accounts. Even with these techniques, however, you will not be able to support a standard user environment completely unless you have the management infrastructure—tools, processes, and people—to support users who cannot do some things on their own. Some of the issues you need to consider are:
Software Installation If users can't install software on their own, you need to provide another way. One way, which doesn't require any other management software, is to use Group Policy. With Group Policy, you can add a program to the Add/Remove programs list. If a user installs a program using this method it will launch with the elevated permissions needed for the user to complete the installation. For a richer solution you could also use SMS or a similar product. Some solutions even allow you to create self-service Web portals where standard users can pick and choose the software they want to install.
Software Updating You'll need to have a way to install updates on your PCs, other than sending out an e-mail that says, "Please install this update!" To manage and deploy most Microsoft updates you can use Windows Server Update Services, which is a free download for Windows Server. To deploy a broader range of updates, again, you may consider a desktop management product such as SMS.
Support Processes and Staffing When a user calls the helpdesk about something that is causing a performance problem or wants to install something new, in many cases you won't be able just talk them through the process over the phone, since they may not have permissions. Your IT department will need to make greater use of remote assistance and remote administration tools to diagnose issues and change settings. Even Windows Remote Assistance will work differently because logged-in standard users cannot approve the prompts for actions that require administrator privilege, though helpdesk staff could use Remote Desktop to make administrative changes remotely.
It will be critical to have clear, efficient processes for handling policy exceptions. Let's say someone in the marketing department needs to install a trial version of a new graphic design tool she is evaluating for her department. Who gives the approval to install that software—her manager, her director, or the CIO? How will it get installed and how long will she have to wait? We suggest creating a simple approval workflow that is integrated with the helpdesk issue tracking system. A basic workflow could be:
  1. User submits request to install a program and the link to the installation program (on their local hard drive or in their CD tray), and confirms that the software was not obtained illegally and is not being used for malicious purposes.
  2. Request is sent to manager for approval.
  3. Request is routed to application lead in IT department who can check to ensure there are no known compatibility problems, perform a virus scan, and make sure that the company has not already purchased a site license for that program or a similar program from another vendor.
  4. Request is forwarded to a support technician to remotely initiate the installation and notify the user when the software is ready for use.
To create the workflow interface you could either script dynamic Web pages or obtain a commercial helpdesk or issue-tracking package. You will also require different staffing for a managed versus an unmanaged environment. Hopefully, you will need fewer technicians to physically diagnose or reimage unstable or infected PCs. However, you may need to initially allocate additional staff to software packaging and deployment.
Over the long run, you should experience lower support costs as machines remain stable longer, but initially you may experience an increase in helpdesk calls from users asking for help with configuration. The helpdesk calls will taper off after you configure your desktop images and group policies with the settings users need and expect.

Culture
The final hurdle is not technological, but psychological. Some users may have an adverse reaction to the idea of not having administrator privileges. But I believe most users won't notice a difference. And if you deploy Windows Vista at the same time that you enforce standard user accounts, the productivity benefits of the integrated desktop search, the new Aero™ (glass) user interface, and the improvements for mobile users will outweigh any inconveniences that come from not being an administrator. However, if poor processes cause people to wait for weeks to get permission to install a piece of software, then you can expect to have some unhappy employees.
Fundamentally, it's the IT department's responsibility to ensure the security of the PC assets, prevent the use of unlicensed software, and enforce compliance with government regulations and internal policies. Most companies will find that the only way to do this is to enact a new policy of restricting the number of users who have administrator privileges. Luckily, you'll find this much easier to do on Windows Vista.
Additional Resource
For help in reducing administrator privileges:
  • Aaron Margosis’s Non-Admin blog—Running with Least Privilege on the Desktop
  • User Account Control Team Blog
  • User Account Control Overview
  • Understanding and Configuring User Account Control
  • Virtual Lab: User Account Control

Alex Heaton is a Senior Product Manager on the Windows Vista Security Team. Previously he was Lead Site Manager for Microsoft security Web sites, which include microsoft.com/protect. He is also a contributor to the User Account Control Team blog at blogs.msdn.com/uac.


 Windows Vista: Enterprise Networking with Windows Vista
Windows Vista Jason Leznek

Enterprise Networking with Windows Vista
At a Glance:
  • The Next-Generation TCP/IP stack
  • User-focused networking tools
  • Improving network security
  • Simplifying network management

When was the last time you tried working for an entire day without being connected to your corporate network? Think about it—no access to e-mail. No browsing the Internet. You couldn't use
printers or file shares. You couldn't access your essential data in sales databases. You wouldn't be able to do your job at all.
Network connectivity is critical to most people's ability to function at work. Likewise, there are more expectations from users to be mobile, connecting their corporate-owned laptops to virtually any public or home network anywhere. Do you shudder at the security ramifications?
The engineers in the Windows Vista™ networking team know how important connectivity is, and they have been hard at work making the best set of networking innovations since Windows® 95. With Windows Vista, networking becomes simpler to use, more secure, easier to manage, and scalable to the largest of networks.
It's been five years since Windows XP was released. A lot has changed in that time, including a need for more ubiquitous wireless networking capabilities wherever users may be; governmental or industrial regulations like Sarbanes-Oxley and HIPAA; and the need to reduce costs and utilize current investments more efficiently. Users expect network resources to "just be there" and become frustrated with the slightest hint of a connectivity problem. Finally, users are more mobile than ever before, and they may not be connecting to just your corporate network—they could be connecting to virtually any network around town.

Start with the Stack
Windows Vista includes an updated implementation of the TCP/IP stack, which features significant improvements that address several top networking issues, offering greater performance and throughput, a native Wi-Fi architecture, and APIs for network packet inspection.
Maximizing network utilization requires complex tuning of TCP/IP configuration settings. Windows Vista eliminates the need to do this manually by detecting network conditions and automatically optimizing performance. On high-loss networks, such as wireless networks, Windows Vista can better recover from single and multiple packet losses. It can dynamically increase or decrease the TCP receive window to fully utilize the link. Users transferring files across a high-speed/high-latency WAN or downloading files from the Internet should notice much faster transfer times.
Windows Vista also includes a native wireless networking architecture (Native WiFi) as part of its core networking stack. The benefits include flexible deployment across many hardware brands and models, similar user experiences regardless of the hardware, and more reliable third-party wireless NIC drivers. Wireless networking in Windows Vista can be centrally managed, supports the latest security protocols, and provides the user with a more seamless network experience.
The Windows Filtering Platform (WFP) is a new architecture in the Next-Generation TCP/IP stack that provides APIs which third-party software developers can use to participate in the filtering decisions that take place at several layers in the TCP/IP protocol stack without having to write their own kernel-mode applications. The platform also provides support for next-generation firewall features such as authenticated communication and dynamic firewall configuration based on an applications' use of the Windows Sockets API (application-based policy).

Empowering the User
The Network and Sharing Center is a single place for users to check network status—if they are connected, what they're connected to, and whether they are on the local network or the Internet (see Figure 1). They can also view the status of various network services on their computers. Is the computer discoverable on the local network? Are any folders or printers shared? The user can also can create or connect to an existing network, whether it is an ad hoc or infrastructure wireless network, VPN, or home broadband connection.
Figure 1 Network and Sharing Center
Figure 1 Network and Sharing Center
Windows Vista can also diagnose and resolve many connectivity issues without the user needing to call the help desk. The Network Diagnostics Framework provides Windows Vista with the ability to identify the root cause of the connectivity problem from the context of the application's action. For example, if the user can't reach an Internet site, Network Diagnostics will attempt to trace the problem, from whether there's an active wireless connection and a valid IP address, through accessing the DNS server, finding the proxy server, and getting a response from the Web server.
If a problem is found, the user gets a message clearly identifying the problem and how to resolve it (see Figure 2). Sometimes it's as simple as clicking a response. Other times, the user must make a configuration change, and the dialog box will bring the user to the exact location. Sometimes the user simply can't take the appropriate action because of lack of knowledge or administrative privileges; richer information is logged to the Event Viewer so the help desk can work on resolving the problem quickly instead of spending hours troubleshooting.
Figure 2 Troubleshooting a Connectivity Problem
Figure 2 Troubleshooting a Connectivity Problem
Windows Vista has Network Awareness APIs that applications can call to get connectivity status, enabling an application to become aware of changes in connectivity and to identify the type of network—domain, public, or private—the computer is currently connected to. When Windows Vista can access the Domain Controller across the network, it switches into the Domain profile automatically. No other networks can be placed in this category. All other networks are categorized as public unless a user or application identifies the network as private. Networks that represent direct connections to the Internet or are in public places, such as airports and coffee shops, should be left public. Only networks located behind a private gateway device should be identified as private, such as home or small business networks.
With Network Awareness, applications such as Windows Firewall with Advanced Security (discussed later) can have different configurations based on the type of network currently connected to, and switch between configurations automatically when the network type changes. For example, the administrator may have configured the firewall to open up specific ports for desktop management software while the computer is connected to the domain network, but those same ports should be automatically closed when the user is working at a public hotspot.
Group Policy is also network-aware in Windows Vista: it automatically knows when the computer is on the domain network and begins processing any new Group Policy settings without having to wait for the next refresh cycle. This means that Windows Vista will automatically check for new Group Policy settings when it connects to the domain network even if it is coming out of hibernation. This allows administrators to deploy security settings faster when time is of the essence.

Securing the Network
There are many types of threats—users accessing wireless networks that are not as they seem, unhealthy guest PCs connecting to a corporate network, and unmanaged resources attempting to access resources they shouldn't have access to. It's enough to keep a network administrator busy all day and worrying all night. Windows Vista can help with all of these scenarios, with enhanced network security features that are comprehensive yet easy to configure.
The native Wi-Fi architecture in Windows Vista has wide support for the latest security protocols, including Wi-Fi Protected Access (WPA) 2 Enterprise and Personal, PEAP-TLS, and PEAP-MS-CHAP v2 (Protected Extensible Authentication Protocol with Transport Layer Security and with Microsoft Challenge Handshake Authentication Protocol). This broad support ensures interoperability between Windows Vista and almost any wireless infrastructure. The capabilities of the wireless network card are examined by Windows Vista and the most secure protocol is chosen by default when connecting to or creating wireless networks. Using the EAP-HOST framework, Windows Vista is able to support custom authentication mechanisms defined by a hardware vendor or by an organization.
Windows Vista includes many improvements to the behavior of the wireless client to mitigate common wireless attacks. The client will automatically connect only to networks the user has explicitly requested or identified as preferred networks, and will not automatically connect to ad hoc networks. The client also provides a warning if the user is about to initiate a connection to an unsecured network. Additionally, the client will actively probe for fewer preferred networks and only if instructed to do so by the user, making it more difficult for attackers to identify what network the client is trying to connect to and create a rogue network with the same name.
The Windows Vista native wireless client supports a single sign-on (SSO) feature, which executes Layer 2 network authentication at the appropriate time given the network security configuration, while at the same time integrating with the user's Windows logon experience. Once a single sign-on profile is configured, network logon will precede the Windows logon. This feature enables scenarios such as Group Policy updates, logon scripts and wireless bootstraps, which require network connectivity prior to user logon.
Windows Firewall with Advanced Security brings a new level of network security to the Windows platform, providing support for both inbound and outbound filtering as well as Windows Service Hardening. If the firewall detects a Windows service behaving abnormally as defined by the Windows Service Hardening network rules, the firewall will block it. Windows Firewall with Advanced Security also supports Authenticated Bypass, which enables certain computers authenticated with IPsec to bypass firewall rules for such tasks as remote management.
One of the most significant changes in Windows Firewall is its integration with IPsec. In the past, administrators needed to rely on two separate tools—a firewall and an IPsec deployment and management tool—to create a layered set of network security rules. With Windows Vista, administrators can create simple network security rules that may combine both firewall port and IPsec rules to protect the network from unauthorized access. This integration provides a simple way to enforce authenticated, end-to-end network communications, providing scalable, tiered access to trusted network resources and/or protecting the confidentiality and integrity of data.
The administrator can logically isolate the corporate network into zones that can be accessed by any computer (including guests) or by just those computers that have authenticated to the domain (Domain Isolation). The administrator can further isolate specific servers that should only be accessed by a specific set of users or computers, such as an HR application server being restricted to computers in the HR group (Server Isolation) as shown in Figure 3.
Figure 3 Server and Domain Isolation
Figure 3 Server and Domain Isolation
Viruses or worms can enter private networks through a mobile laptop and quickly infected other computers. Windows Vista, when connecting to a network infrastructure based on Windows Server code-named "Longhorn," (the next version of Windows Server) will support Network Access Protection (NAP) to reduce the risks of connecting unhealthy computers to private networks directly or across a VPN connection. If a computer running Windows Vista lacks current security updates, virus signatures, or otherwise fails to meet corporate security requirements, NAP blocks the computer from full access to the network. Instead, it will be connected to a restricted network where it can download and install the updates, antivirus signatures, or configuration settings that are required to comply with current health requirements.

Simplifying Network Management
The networking features in Windows Vista have been designed to support high levels of manageability to help reduce the cost of deploying wireless networks and network security policies, as well as to provide quality of service for applications and users. Windows Vista uses Group Policy or command-line scripting via the Network Shell (NETSH) extensively to manage network features, so you don't need to learn or deploy a new management tool, and you can take advantage of your existing investment in Active Directory® and the Organizational Unit (OU) structure you have already created.
Deployment and management of network security rules—combining firewall and IPsec policies—is made easier within a single wizard-driven Microsoft Management Console (MMC) snap-in called Windows Firewall with Advanced Security (see Figure 4) or command-line scripting via NETSH. The new snap-in provides a simple way to deploy inbound or outbound filtering and connection security rules that limit access by specific users, computers, or applications while providing a granular level of administrative control. IPSec can request or require authentication by user, computer, or health certificate (integrating with Network Access Protection) to provide a scenario-based security policy. The snap-in makes the creation of server or domain isolation rules easy and, since it is Group Policy-based, you can target these rules based on your business structure.
Figure 4 Windows Firewall with Advanced Security
Figure 4 Windows Firewall with Advanced Security
Using Group Policy, you can also define how mobile clients connect to and operate on wireless networks. For example, a company may define a policy that requires all wireless connections to use a certain protocol or that all connections must be limited to a certain wireless network. Because these settings are made via Group Policy, the end user can be prevented from changing these settings.
NETSH enables automation and scripting to assist in troubleshooting wireless network connections. Using the command-line interface, administrators can verify, change, or remove a client's wireless network configuration profiles. These configuration profiles can also be exported to and imported from other computers to expedite provisioning of multiple computers.
Network quality can diminish because high-bandwidth applications tend to consume all available capacity, and applications are not written to give central bandwidth control to IT administrators. Adding more bandwidth may not solve these problems; instead, it only leads to the same applications consuming the newly available capacity. With policy-based quality of service (QoS), administrators can prioritize and/or throttle outbound network traffic without requiring applications to be modified. Policies can either mark outbound traffic with a Differentiated Services Code Point (DSCP) value for routers to prioritize or let Windows Vista throttle the amount of outbound traffic sent, regardless of the router configuration. Combining both techniques provides even greater flexibility. Figure 5 shows the creation of the QoS policy.
Figure 5 Creating a QoS Policy
Figure 5 Creating a QoS Policy

Scaling to the Enterprise and Beyond
Enterprise-level organizations often worry about scalability issues when supporting their network. For example, you may begin running out of available IP addresses, especially when business demands introduce multiple networked devices per user, such as additional laptops and mobile devices like Smartphones. Likewise, while you may be interested in providing additional network services such as IPsec, you may also be concerned about the impact on CPU load. Windows Vista addresses network scalability concerns by supporting IPv6 and hardware offload capabilities.
To solve problems with limited public IPv4 addresses, many governments, ISPs, and other organizations are transitioning to IPv6, the next version of the network protocol that drives the Internet. Windows Vista supports IPv4 and IPv6 together through a dual-layer IP stack architecture. IPv6 is enabled by default, and the dual-layer stack support enables you to migrate gradually using IPv6 transition technologies that can tunnel IPv6 traffic across a private IPv4 network or the Internet. Windows Vista natively supports PPPv6 and Layer 2 Tunneling Protocol (L2TP/IPv6) virtual private networks (VPNs), enabling remote access users to take advantage of the benefits of IPv6 networks.
Windows Vista supports offloading network traffic processing to specialized network adapters. New offload capabilities include IPv6 and TCP Chimney offload. These architectural innovations optimize performance and network throughput to achieve the performance and operational gains made possible by today's high-speed networks. Utilizing compatible network adapter hardware can remove bottlenecks related to network packet processing such as CPU overhead and available memory bandwidth, without requiring changes to existing applications or network management tools.
The network stack also supports Receive-side Scaling, which dynamically balances inbound network connections so the load can be shared across multiple processors or cores, reducing potential bottlenecks in processing network traffic.

Summary
Windows Vista represents the most significant update to Windows networking since Windows 95. Users will find it easier to take advantage of wired and wireless networks as they travel. With the new auto-tuning network stack, file transfers will be faster. Enterprises will appreciate the reduced security risks, including improved protection from threats introduced by mobile and wireless users. Systems administrators will find Windows Vista easier to manage, with the ability to create granular security policies for network traffic as well as QoS for mission-critical apps. These new features let you do more with your network infrastructure while minimizing administration effort and maximizing end-user productivity.
Additional Resources
  • New Networking Features in Windows Server “Longhorn” and Windows Vista
  • Next Generation TCP/IP Stack in Windows Vista and Windows Server “Longhorn”

Jason Leznek is the Senior Product Manager for Windows Vista Networking. He has been with Microsoft for almost ten years and was the Product Manager for Windows Server Update Services and Group Policy prior to joining the Windows Vista team. Prior to that, he spent seven years in the field working with Microsoft enterprise customers.


 Windows Vista: Getting Ready for Windows PE 2.0
Windows Vista Wes Miller

Getting Ready for Windows PE 2.0

At a Glance:
  • Microsoft Windows Imaging technology
  • Driver updates and servicing
  • Unattended setup customization

In the last two issues of TechNet Magazine, I discussed the history of the Windows Preinstallation Environment (or Windows PE), covering various design decisions, and how you can use Windows® PE today. In this article, I am going to focus on Windows PE 2.0, which is the version that will ship simultaneously with Windows Vista™. This is not an in-depth look at how to use the individual features. Instead, this article aims to provide an overview of the new features and capabilities you'll find in Windows PE 2.0. While I'll give you some hands-on information, detailed discussions about how to use Windows PE 2.0 will come in future articles.
As work began on Windows Vista, the Windows setup team (which I was a member of at the time) was focused primarily on building an entirely new setup architecture, creating a new imaging tool to help with deployment, and designing a replacement for Remote Installation Services (RIS). But then our attention shifted to the interim Windows PE and Windows XP Service Pack 2 (SP2) and then to Windows Server® 2003 SP1. This meant holding off on our development efforts for Windows PE in Windows Vista for a bit. But the interim Windows PE update allowed us to deliver some of the functionality we had originally planned to include in the Windows PE 2.0 release, so our efforts had not been completely sidetracked.
The Windows PE team focused pretty intensely on the sustainability and the typical use cases of the Windows PE user when defining the new features we wanted to include (see the "New to Windows PE 2.0" sidebar). Let's drill into the key new features.

Working with Images
There are some basic concepts you must understand regarding Microsoft® Windows Imaging (WIM) technology and Windows Deployment Services. WIM was designed from the ground up to be used for deploying Windows as images (historically referred to as Sysprep images). Rather than being sector-based, as most imaging tools are, WIM is file-based. This means that instead of replicating every single sector of a hard disk, WIM picks up each file and the metadata associated with it (access control lists, short and long file names, and so on) and stores the data in a single file.
One of the key benefits of WIM images is that a single WIM file can store a copy of more than one volume (each is referred to as a volume image). And regardless of how many are captured, each single file is only stored once. This is referred to as Single Instancing. In function, the technique is similar to that used by Remote Installation Services, though the technology used is very different. The tool for creating WIM images is called ImageX. (Note that it had been referred to as XImage at one point, but the name has since changed.)
As we were developing Windows Vista and its new image-based setup engine (which would use Windows PE to deploy the operating system), we saw that we might be able to use some tricks in order to save space on the media. At the time, we were not sure whether Windows Vista would be shipping on CD or DVD and therefore we were driven to minimize the disk space taken up by the setup itself. Since the version of all of the files comprising Windows PE on the CD was identical to the files in the WIM file sitting right next to it, we started to think about including Windows PE in the WIM file itself and booting from it. Thanks to some impressive work done by an architect on the Windows Core operating system team, our idea became a series of prototypes and was integrated into the product before the Developer Preview of "Longhorn" (now Windows Vista) released at the Professional Developers Conference in 2003. Today, Windows PE lives in one WIM file on the media (boot.wim), and the installation media exists in another (install.wim). Though the single instancing between Windows PE and Windows that we had originally envisioned isn't a part of the install media any longer, Windows PE still benefits from the reduced space it gains by being compressed on disc. With the integration of the RAMDisk boot functionality delivered in Windows PE 1.6, the ability to swap media (to remove the initial boot CD/DVD after boot-up is complete) was also added since the early WIM boot work was completed.
Including a Windows PE image in a WIM is as easy as using ImageX to pick up the files (I'll discuss this in detail in an upcoming article) and denoting the image as bootable by providing the /boot flag to ImageX. Think of this as the boot sector. When the Windows Boot Manager loads the WIM file, the marker included with the /boot flag states which image (whether there is one or more than one) in the WIM file is bootable. Note that only Windows PE can boot from a WIM file. You can't boot all of Windows Vista from a WIM. The WIM is also, as in the case of a CD or DVD, read-only. Thus, you can't boot from a WIM image of Windows PE and modify any of the files. To make any changes to Windows PE, you must modify the WIM itself.

Dealing with Drivers
With Windows PE, we've always paid attention to mass storage and networking device support. Yet there were still occasions when Windows PE lacked support for certain devices on new systems. Windows PE 1.5 included some improved support for adding device drivers, but Windows PE 2.0 further streamlines this ability. All types of devices are now supported and they just work on boot—no factory.exe or drvinst.exe magic is necessary. To add a new device driver to Windows PE 2.0, simply run the new peimg.exe tool and it will add the drivers. The syntax, shown here, is simple:
peimg.exe /inf drivername.inf builddirectory\Windows
Just replace drivername with the name of the .inf (wildcards, like net*.inf, are acceptable) and replace builddirectory with the name of the directory where your Windows PE image is being built.

Scratch Space
A problem often faced by applications running under Windows PE is that many Windows applications (and even many components of Windows itself) expect to be run on writable storage. Many react in unpleasant ways when running from read-only media, such as a CD-R. For example, when I first tried getting Microsoft Internet Explorer® to run under Windows PE (and eventually when I tried just the MSHTA, or Microsoft HTML Application, components of Windows), key DLLs would not register because they required writable storage for some of the tasks they needed to complete as part of the registration process.
In Windows PE 2.0, this is not a problem since there is now up to 32MB of scratch space available for file system writes. As a result, components that previously didn't work due to the read-only nature of Windows PE will now work since they can perform the writes to disk that they require. This is different from a RAMDrive for scratch space (as has routinely been utilized by Windows PE users) in that the scratch space is on the same volume as the boot volume—as opposed to being another temporary drive.

Optional Components
As with previous versions of Windows PE, the new version provides optional components that can be used to add more functionality. (Of course, these add size, which is why they are optional.) Support for Windows Script Host (WSH), Windows Management Instrumentation (WMI), and MSHTA is still available. You can now add support for MSXML, the Windows Vista Recovery Environment, additional Windows fonts, and formal Microsoft Data Access Components (MDAC), which replaces the earlier ADO for SQL support that included some, but not all, MDAC support). The most important change here, though, is how easily these components can be added. Instead of being implemented via a rough WSH script, the components can be easily added or removed using peimg.exe—the same tool I discussed earlier used for adding drivers.

Language Packs
One of the original key tenets of Windows Vista was to take the concept of the Multilanguage User Interface (MUI)—a concept that was introduced in Windows 2000 and improved upon in Windows XP—and implement it throughout the operating system. In Windows 2000 and Windows XP, you can specify a language other than English but MUI itself relies on the English version of the operating system to begin with. That is, you can have any other language you want, as long as English is there as well.
That has changed in Windows Vista. While I won't drill into all the specifics, I must note that this change is significant for Windows PE. There was no formal support for MUI under earlier versions of Windows PE. You had to build from the localized language of Windows that you wanted language support for. Now, adding or changing language support works in the same way as with any other optional component—using peimg.exe to add or remove language packs to meet your specific Windows PE needs.

Better Servicing
Earlier versions of Windows PE also lacked support for servicing. To add a service pack, you had to rebuild Windows PE entirely. To add a hotfix, you had to improvise it manually—if you dared to. Given the fact that Windows PE was small, included limited Windows functionality, and didn't run for an extended period of time, we didn't see this as a problem. That is, not until the infamous Blaster vulnerability. Since remote procedure call was included in Windows PE, under the right circumstances the vulnerability could hit and cause Windows PE to continuously reboot.
This is what led us to include the Windows Firewall in Windows PE 1.5. And after that, the team set out to ensure that future versions of Windows PE could be serviced just like a full release of Windows. One key area of focus for Windows Vista was improved serviceability. Windows PE inherits from this. And like with its other optional components and languages, Windows PE uses peimg.exe to perform updates. Updates will be provided via the Windows Download Center.

Unattended File Support
You may be familiar with winbom.ini, which was used in earlier versions of Windows PE to drive a small application called factory.exe. These have been replaced in the new version. There is now a new XML infrastructure that you use to customize Windows PE (this is the same XML mechanism used for unattended setup in Windows Vista) and a new application named wpeinit.exe.
Wpeinit.exe uses the standard unattend.xml format in Windows Vista to specify Windows PE customizations and actions. Figure 1 shows a sample unattend.xml file that could be used to customize Windows PE. The format for the unattend.xml file is documented as a part of the Windows OEM Preinstallation Kit (OPK) and Windows Automated Installation Kit (WAIK), which I will discuss in a moment.
Figure 1 Architecture of an unattend.xml File (Close Figure 1)
XML File Comments
<ComputerName>MyWinPEMachine</ComputerName>
 Sets up the machine name under Windows PE as MyWindowsPEMachine.
<Restart>Shutdown</Restart>
 Shuts down the system upon restart (rather than rebooting, as earlier Windows PE versions do).
<RunSynchronous>

<RunSynchronousCommand>
      <Order>1</Order>
      <Path>notepad.exe</Path>
</RunSynchronousCommand>
Runs notepad.exe.
<RunSynchronousCommand>
    <Order>2</Order>
    <Path>cmd.exe</Path>
</RunSynchronousCommand>
When notepad.exe has finished, cmd.exe runs.
</RunSynchronous>

<EnableFirewall>true</EnableFirewall>
Enables Windows Firewall on boot.
<PageFile>
    <Size>1000</Size>
    <Path>C:\pagefile.sys</Path>
</PageFile>
Sets up a pagefile of 1GB on the C: drive.
<LogPath>C:\mylog.txt</LogPath>
Logs the output of wpeinit.exe and this script to C:\mylog.txt.

Windows Deployment Services
As I mentioned earlier, one of our main goals was improving network-based setup by moving to a unified infrastructure whether setup was started from CD, DVD, or the network. Unfortunately, there is quite a bit of extra work that goes on during setup when performing an RIS-based installation of Windows. We wanted to remove that complexity and redundancy as much as possible and in order to do that, we built Windows Deployment Services.
Like RIS, Windows Deployment Services is a PXE-based installation. But unlike RIS, it starts Windows PE over the network and utilizes the same image-based setup infrastructure as a normal CD or DVD-based setup, while providing the same type of centralized enterprise installation infrastructure that RIS has delivered since Windows 2000. There's a lot to discuss about WIM and Windows Deployment Services and not enough room in this article. But don't worry, I'll look at these in more depth in an upcoming article—so stay tuned!

Using WAIK
At this point, you may be wondering just how you can get started with Windows PE 2.0. The first step is to get the WAIK. Earlier versions of Windows PE shipped as a part of the Windows OPK or as a part of Software Assurance media. Since Windows PE 2.0 is scheduled to be available for all licensed Windows customers, Microsoft has created WAIK for non OEM customers.
WAIK provides all of the Windows PE build tools needed to create your own copy of Windows PE 2.0. You can currently obtain WAIK as a part of the Windows Business Desktop Deployment (BDD) 2007 beta. In addition to WAIK, the BDD provides guidance on how to use WAIK and its tools. Of course, it goes without saying that the best way to really become familiar with Windows PE 2.0 and all of the other new setup and deployment technologies included in Windows Vista is to start experimenting with them as soon as you can.
New to Windows PE 2.0
Windows PE 2.0 includes all the features found in Windows PE 1.6 and adds a number of new capabilities and components, including:
  • Booting from within a Microsoft Windows Imaging (WIM) image
  • Driver injection and real-time Plug and Play Support
  • Writable scratch space (even when booted from CD)
  • Easily added optional components—Microsoft Core Extensible Markup Language Services, Windows Recovery Environment, Microsoft Data Access Components
  • Language Packs
  • Unattended file support
  • Improved tools for building and updating Windows PE

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, Wes worked at Winternals Software in Austin, and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.


 Windows Vista: Inside the New Microsoft Application Compatibility Toolkit
Windows Vista John Melton

Inside the New Microsoft Application Compatibility Toolkit

At a Glance:
  • Changes that affect application compatibility
  • Evaluating the impact to applications
  • Managing mitigation and deployment

Windows Vista is coming and it's time to start preparing to evaluate, deploy, and support a new operating system—including new tools, new features, and new training. Of course, your main task will be to determine how this major Windows release will function in your existing environment.
I can't think of a more important place to start than with your overall application portfolio and determining which applications will work correctly with Windows Vista™.
There are some major changes in Windows Vista that could affect application compatibility. Ensuring application compatibility was an important focus during the development of Windows Vista. By testing thousands of applications with each build and providing immediate feedback to the engineering teams on how their changes affected applications, compatibility issues were reduced during the development cycle.
This process resulted in reducing most of the compatibility concerns to a few areas. In this article I'll discuss these areas and provide tips to help you jump the hurdles they may throw in the way of your deployment.

Changes That Affect Compatibility
Some apps are designed to run on specific OS versions, possibly for good reasons, and this can cause installation or program execution to fail before you begin testing an app.
Fortunately, such problems are easily resolved by using the Program Compatibility Assistant (PCA) in Windows Vista. PCA automatically detects possible compatibility issues during installation, then offers to modify the settings to a Windows® XP compatibility mode that may allow you to install and continue testing.
If everything else is functioning properly with the application, it's simple to modify an application version check, or to apply an application fix to the desktop, which lets the application run as though it's on an earlier operating system.
It's a very different information highway today compared to when Windows XP was released in 2001. Unfortunately, there are now many more potholes around system security concerns. Windows Vista has implemented a number of new security features, and these could play a part in your application compatibility experience.
Microsoft® Windows Resource Protection (WRP) in Windows Vista allows applications to work seamlessly even when trying to write to protected system files and registry locations. WRP automatically creates a temporary work area and redirects writes for the application session. This technology allows applications that may have failed in Windows XP to work in Windows Vista, increasing compatibility over previous versions of the OS. However; this temporary work area is only available for the current application session, so you won't be able to persist any data from session to session.
User Account Control (UAC) is the Windows Vista implementation of administrators and standard users you're familiar with from Windows XP. Many companies have struggled to implement standard user scenarios with Windows 2000 and Windows XP. In Windows Vista, Microsoft has provided a much more robust experience for the standard user, adding appropriate elevation prompts when administrator-level tasks are undertaken by standard users or applications. For applications, you'll need to determine which ones might be subject to restrictions when running as a standard user by using the Microsoft Application Compatibility Toolkit and the UAC Evaluator (more on that later), and making sure that applications are not unnecessarily attempting to execute administrator level commands.
Since Internet Explorer® is a significant window to the Internet for many users, Microsoft has taken steps in Windows Vista to reduce the possibility of attacks through the introduction of Internet Explorer Protected Mode. Internet Explorer in Windows Vista will operate essentially as a standard user, limiting its ability to write to areas of the computer in ways that could introduce malware or viruses to the system. You will also be able to use the Internet Explorer Compatibility Evaluator—available with the Microsoft Application Compatibility Toolkit—to detect which intranet, extranet, or Internet applications might be subject to Protected Mode restrictions.
The best thing about creating a new operating system is being able to innovate—providing new features, new functionality, and taking advantage of new hardware technology. However, this innovation can also create some challenges when it comes to application compatibility.
Security plays a major role in Windows Vista, and one area of note is a new API structure for firewall and antivirus applications that is much more robust. However; the additional functionality means many enterprises will need to upgrade to new versions of their third-party firewall and antivirus software. The WinLogon/GINA (Graphical Identification and Authentication) architecture has also been replaced in Windows Vista, so you'll need to examine applications that work with or pass authentication credentials.
You may also be looking at obtaining new, more powerful 64-bit processors and operating systems. While 32-bit applications should work fine on such systems, you'll need to make sure you have 64-bit drivers. Note that 16-bit applications are not supported on the 64-bit Windows Vista platform.

Evaluating Application Impact
The Application Compatibility Toolkit is designed to assist you in inventory, analysis, rationalization, and prioritization of your existing application portfolio. Figure 1 lists the components of the toolkit. Figure 2 describes the individual Compatibility Evaluators included in the toolkit.
Figure 2 Toolkit Compatibility Evaluators (Close Figure 2)

Evaluator | Description
Inventory | Looks through several system areas, collecting information about the applications on each computer and its associated components.
Internet Explorer | Monitors Internet Explorer 7.0 to discover Web-based applications that could have potential compatibility issues. The Web locations are logged for further processing.
User Account Control | Monitors user interactions with applications and when requests for elevated security are made, application information is logged for further processing.
GINA | Monitors applications for use of credentials based on legacy architectures and logs these applications for needed modification.
Deprecated Components | Looks for legacy technology use that is no longer supported in Windows Vista, such as FrontPage Server Extensions. When such usage is detected in applications, they are logged for further processing.
Session 0 | Detects specific requests for Session 0 and logs applications accordingly. Session 0 is now fully protected in Windows Vista and applications can no longer run in this session.
Figure 1 Application Compatibility Toolkit Components (Close Figure 1)

Component | Description
Compatibility Evaluators | Multiple evaluators that can be run on a computer, used for detecting and logging possible application compatibility issues.
Log Processing | Takes cumulative compatibility information logged on individual computers and sends it to the central log file at predefined intervals.
Inventory Database | Used by the Application Compatibility Manager for reporting and to enable usage of many new fields to help manage the deployment process and status of each application.
Application Compatibility Manager | The central management tool providing capabilities to monitor and change information relating to the deployment process.
Microsoft Compatibility Exchange | A community resource of shared compatibility information. Additional compatibility information can be retrieved from the Microsoft Compatibility Exchange including results from other customers, Microsoft certification information, and vendor information about the application.
There are basically four steps to understanding and identifying the impact Windows Vista might have on your apps.
First, you need to inventory all the applications in your enterprise and their known status with regard to application compatibility. You may have a software management system like Systems Management Server (SMS) to assist with this, or maybe just a trusty old spreadsheet, but neither provides you with the compatibility status. The Compatibility Evaluators included with the Application Compatibility Toolkit can provide this critical information.
The first step is to create a compatibility package that can be deployed to desktop computers to gather an overall application inventory (see Figure 3). You can include the Compatibility Evaluators to identify applications that may be subject to possible compatibility issues. This package can be deployed through your software management system—it's small, and takes few resources when running on the client. In return, you'll receive compatibility information on your computers and applications.
Figure 3a Creating a Compatibility Package
Figure 3a Creating a Compatibility Package
Figure 3b
When you get your first report back from the Compatibility Evaluators, you'll want to get the most current compatibility information available. Your next step is to synchronize with the Microsoft Compatibility Exchange. Click on the Send and Receive Data icon, provide your login information, and you'll be connected with the Microsoft Compatibility Exchange. This is your source of compatibility information to help you analyze, rationalize, and prioritize your application portfolio. The Application Report will contain information provided by other community members, software vendors, and Microsoft about applications in your portfolio, showing you at a glance the compatibility status of those applications. In addition, the known issues and possible solutions are easily accessible and can reduce the overall amount of testing you need to do. If an issue has already been identified, there's no need for you to test and rediscover the issue or to hunt down a solution.
Now that you have your application portfolio, the goal is to reduce the number of applications where you need to focus your efforts. The most efficient process is to organize and categorize your applications.
Start by using the built-in filtering capabilities of the Application Compatibility Manager. The inventory listing will contain many applications you may not be concerned about (see Figure 4). For example, if you will be replacing hardware, there's no need to worry about hardware drivers or special applications delivered by the OEM.
Figure 4 Filtering in Application Compatibility Manager
Figure 4 Filtering in Application Compatibility Manager
The next step is beginning to formulate how you would like to organize these applications to reduce the number that should receive attention. Consider whether applications are global or specific to particular geographies or departments. Where can you rely on vendors to support their applications, and which internal line-of-business applications need attention from your staff? Possibly create a category for developers and a subcategory for each developer to assign programs. Once you've determined your organizational strategy, you can begin to sort your apps.
You can create categories and subcategories using the Application Compatibility Toolkit by selecting the Organize features and creating your own personal entries (see Figure 5). These entries will be available in the reporting options so you can create very specific reports for each subcategory item.
Figure 5 Assigning Categories
Figure 5 Assigning Categories
Your final step in the analysis phase is to assign categories to each of your applications or computers. A good area to focus on is your mobile workforce as Windows Vista provides many new features to improve their experience, so you'll want to create a category or subcategory for those applications. You can assign multiple categories to applications, so create a development team category with team member names as the subcategory, which will allow you to track who has responsibility for which applications.

Managing Modifications and Deployment
After initial categorization of applications, you can further refine the list. It is possible for several hundred applications to show up on a single machine, but you shouldn't be concerned with every possible application. Remember, the goal is to reduce the list of applications significantly in order to focus upon necessary mitigation efforts. Candidates for rationalizing out of the priority list include apps that may be reaching the end of their useful life and are in the process of being updated or rearchitected. You may also find multiple versions of applications exist across the organization that could be consolidated to a single version that is easier to support. Applications may have been identified by their vendors or the Microsoft Compatibility Exchange as compatible and thus need no further attention. And you may discover applications that are not in a geography or department planned for upgrade.
The Custom Reports features in the Application Compatibility Toolkit can assist in rationalizing applications. You can select specific categories so the list of rationalized applications can be reduced to a specific group, geography, or location. This should help you focus on areas where more compatibility work is needed.
After refining the application portfolio down to a manageable set of applications, you can now zero in on a smooth, timely deployment of the new operating system by working on a clear set of application compatibility concerns. Using the Prioritize feature, you can assign a specific priority and category for each application.
There are some additional features in the Application Compatibility Toolkit that can also help you with the process of managing application status and deployment information. Choosing between Testing, Mitigating, and Ready to Deploy will let you track the status of a particular application. In the Reports section, you'll be able to see the overall deployment status of all of the applications.
Here you will also be able to add your own information about the application. You can certify the application, and create or edit a new issue specific to that application (see Figure 6). Sharing this information with the Microsoft Compatibility Exchange will help other admins when they are analyzing their own environments.
Figure 6 Recording Compatibility Status for an Application
Figure 6 Recording Compatibility Status for an Application

Summary
Now you know where to focus your efforts before starting your deployment of Windows Vista. For more information on the Microsoft Application Compatibility Toolkit, visit microsoft.com/technet/prodtechnol/windows/appcompatibility.

John Melton has been in Information Technology for over 20 years and has been with Microsoft for the last 10 years. John is a former Systems Engineer, and is now a Group Product Manager for Windows Vista and Microsoft Application Compatibility.


 Windows Vista: New Tools for Event Management in Windows Vista
Windows Vista Val Menn

New Tools for Event Management in Windows Vista

At a Glance:
  • New event infrastructure
  • Event types
  • Structured event properties
  • Using XPath expressions

Many people say eventing and tracing are boring. Others complain that, more often than not, traces and events are merely by-products of secondary activities (such as debugging and self-monitoring features), and that not enough importance is placed on eventing and tracing capabilities.
Microsoft® Windows Vista™ aims to change these perceptions, offering a giant step forward in enterprise management. Microsoft has overhauled some of the key components and their user interfaces. The Event Log service has been completely rewritten with the enterprise in mind, and tracing has been made much faster and more secure.
Imagine having a better set of tools for discovering and resolving problems with mission-critical systems. Or how about features that let a support technician easily collect tell-tale events and traces from a user's system? Or what if your developers could diagnose and fix bugs in a deployed system using traces sent by users on the fly? Imagine you have easier, more powerful ways to gather information and quickly perform troubleshooting—now that doesn't sound so boring, does it?

What Are Events?
A computer application is like a "black box" that performs a function (or functions). A lot goes on inside this box, but since you can't see into it, it is very difficult to understand its inner workings. However, applications communicate outwardly—with other programs and with users. These communication "events" give you a glimpse into the application.
When it comes to software, an event is typically defined as an occurrence within a software system that is communicated to the outside (the outside being users or other programs). Such an occurrence typically corresponds to a state or configuration change. It may communicate current state or configuration of the software system and the reasons for the change.
More loosely, the term event is also used to refer to the way these occurrences are exposed. There are many examples of such an exposed event:
  • A Win32® object used for interprocess communication (IPC)
  • A WMI event used for transient (non-persistent) notifications
  • An Event Tracing for Windows (ETW) trace event saved into trace files
  • An Event Log event saved into the Event Log live logs and possibly archived into Event Log files
  • An event saved into files using custom infrastructure
The last three examples listed here are of the sort we'll be looking at in this article.

How Events Are Used
A trace or logged event is a record of an occurrence in a program or operating system. These traces and event logs aren't just for developers. They offer indispensable tools for IT and support personnel, providing a glimpse into the state and inner workings of the applications you are running.
You can use such logs to monitor overall system health. Using the Event Log, you can search for any events that indicate problems. For example, you might find error event 6 in the Application log from the CertificateServicesClient source with the following message: "Automatic certificate enrollment for local system failed (0x80070576). There is a time and/or date difference between the client and server." Likewise, you can detect the transition of components from the unhealthy state back to normal operation. For example, after the time and date difference has been corrected, the same CertificateServiceClient source would publish informational event 19 in the Application log indicating: "Certificate enrollment for <user name> successfully received an AutoenrolledWindowsSystemComponentVerification certificate from certification authority <authority name>." Such information is extremely valuable for finding and resolving conflicts and other problems with configuration.
This info is also handy for diagnosing problems. You can locate program and system actions that lead to a problem and find details that can help you determine the root cause. Similarly, you can use this information to evaluate and solve performance issues.
And the Event Logs offer valuable information that you can use to ensure a more secure environment. They can be used to detect intrusion attempts, audit system history, ensure non-repudiation, and find resources configured incorrectly.

Events in Windows Vista
Previous versions of Windows® have had many shortcomings when it comes to eventing and tracing. These include limited scalability of the Event Log (which limited the total size of all logs to the amount of available memory), event publishing performance (which, for example, limited the number of events that could be published on an active Domain Controller), and limited security of the trace events.
Windows Vista addresses many of these issues with a new infrastructure for eventing and tracing, called Windows Eventing 6.0. This extends upon ETW, which has been in use since Windows 2000, and replaces the Event Log service and the Event Viewer. The new Windows Eventing is designed to deal specifically with events that are persisted into log files for future examination. (It is not intended for transient events like IPC and notification mechanisms.)
By providing security and scalability solutions, custom eventing and tracing implementations should be less important. Note that the enhancements are provided while preserving full compatibility with the existing Event Log and ETW APIs, which means that all existing applications will continue to work without change.

New Ways to View Events
The existing Event Viewer is already one of the most popular Windows programs in the IT community. The new Event Viewer has been completely rewritten and since it lives in Microsoft Management Console (MMC) 3.0, its appearance has also changed, but it's still familiar enough that the transition should be fairly easy.
There is still a tree pane and a list of events. You can still access the familiar Application, System, and Security logs under the Windows Logs node. However, some new nodes have been added to the root, and the new ForwardedEvents log, which I will discuss shortly, has been added to the Windows Logs node.
The most obvious new feature is the preview pane, located under the event list. It contains the properties of the focused event. This means you no longer have to double-click an event to see the event properties, and you don't have to juggle windows in order to see both the list and the Event Properties dialog. It is still possible to display properties in the dialog by double-clicking on an event. But the new dialog is not modal, so you can display multiple event property dialogs at the same time.
The new views allow you to display all the events you may be interested in with just a few mouse clicks. Events can be collected for one or more log files and can focus on specific IDs, Levels (Severity), or time frames.
Notice that under the Custom Views node you'll find Administrative Events (shown in Figure 1). This provides a list of all the errors and warnings from various log files that are of interest to administrators.
Figure 1 Administrative Events
Figure 1 Administrative Events
So how exactly did we determine which logs and events are of interest to administrators? We identified five separate event types and the users related to each type. These are detailed in Figure 2. This is a very general though effective division of all the Event Log and trace events that may be of interest to various groups.
Figure 2 Event Types and Their Users (Close Figure 2)

Event Type | Description | Used By
Admin | The Admin type will suffice for the majority of system administrators. These events are very high level and they often provide enough information to identify a problem and determine its solution. At the very least, Admin events should identify when an issue occurs or indicate when an application, a component, or the system as a whole is in or has recovered from an unhealthy state. Most Admin events are errors or warnings, and they are usually actionable. | Administrators, support personnel, and Monitoring and analysis programs
Operational | Like Admin events, Operational events enable problem diagnosis. Operational events consist of more than just errors and warnings. They also inform users about normal operation of an application or OS component. The volume of these events is kept quite low so Operational events can be enabled without affecting system performance. The Operational events—along with the Admin events—are used by support personnel, monitoring utilities, and some sophisticated administrators. | Advanced administrators, support personnel, and monitoring and analysis programs
Audit | Audit events provide a historical record of any resource access or actions taken by the users. These events do not in themselves represent failure or success of the program, but indicate a failure or success of the action. Audit events can be completely disabled or selectively enabled with varying levels of granularity. Security auditing at the OS level is supported (the events can be found in the Security log of the Event Log). | Advanced administrators, security auditors, and Forensics specialists
Analytic | Analytic events, which are not very different from Operational events, are logged during normal operation of applications and components. But the volume and detail of Analytic events is much greater than Operational events and therefore there is a potential of them having a negative effect on system performance. Thus, Analytic events are normally disabled. To make use of Analytic events, enable them before a diagnostic session and then disable them before examining the trace. | Support personnel Monitoring and analysis programs
Debug | Debug events are also high-volume events that are normally disabled. They are used mainly by developers and are seldom viewed by IT professionals. | Developers
Every log in Windows Eventing has a designated type. All events in that log share the type of that log. The view in Figure 1 was defined using this type information—it pulls all error and warning events from the logs of type Admin.

The Windows Eventing Architecture
The Windows Eventing infrastructure consists of software components that allow event objects to be published by programs and delivered to log files. ETW provides the transport used to transfer all types of events from their event publishers to their destinations. ETW has also been overhauled in Windows Vista, and now provides better performance and enhanced security. Publishing of events via ETW is asynchronous and therefore does not affect the performance of the publishing program. When a new event is received by the system, information about the current user context and the publishing process is collected and attached to the event.
After events are published, different types are handled in different ways. Since Analytic and Debug events usually have a high volume, they need to be saved into a file with minimal processing to avoid affecting system performance. Therefore, these events are immediately saved into a trace file.
The Admin and Operational events are infrequent enough to allow additional processing without affecting system performance. These events are delivered to the Event Log service, which saves them into the live event logs and can optionally deliver them to real-time subscribers. Subscribers can pick events to be delivered to them using a query language that I will discuss in a moment.
There are two subscribers, in particular, that are of special interest to the IT community. These are the much enhanced Windows Vista Task Scheduler and the event forwarder that can be used to send events to a remote event collector.

A Look at Structured Events
A common complaint about event logs is that they contain a lot of garbage. That is, they are cluttered with events that have little or no significance, and these tend to hide or obscure the important events. While some events do provide little information, what seems like garbage to one user is often a treasure to another.
Windows Vista offers a way to filter out uninteresting events, allowing you to zero in on the events that matter to you. This relies on a cross-log querying language that is supported by the Event Log service. For this to work, all events must follow a well-defined structure.
Previous versions of the Event Log provided some structure for events, but the structure was not well-defined and it was only visible to the Win32 API. In Windows Vista, events have a well-defined structure. In fact, events are represented externally using XML with a published schema. This makes it possible to create queries that collect the events interesting to you while filtering out extraneous events. Since XML is used, XPath was chosen as the base for the event query language. Of course, the use of structured events opens new doors for automation, as can been seen with the new Task Scheduler integration.
The event preview pane now includes a Details tab. The same tab is available on the Event Properties dialog. Selecting the Details tab on the Event Properties dialog reveals the XML representation of the event. The sample shown in Figure 3 is an Operational event from the Task Scheduler. It contains two parts. The System part consists of the general event information common to every event instance of this event, as well as some system parameters collected when the instance was published. The EventData section, which is extensible, contains structured information from the application.
Figure 3 XML Representation of an Event
Figure 3 XML Representation of an Event
Each event log file is treated as a sequence of such structured event elements. This presents a logical, readable view of the event log and event archive files. Internally the events are saved in a binary format that is designed to provide a balance of compactness, reliability, and search performance.

Event Attributes
The System section of the XML data provides the time at which the event occurred, the process ID, the thread ID, the computer name, and the Security Identifier (SID) of the user. In previous versions of Windows, events had only two attributes—EventID and Category. The XML provides other details, as well, including the EventID, Level, Task, Opcode, and Keywords properties. Let's take a closer look at these.
EventID and Version An event is uniquely identified by the combination of its EventID (which is a two-byte number) and its Version (which is a one-byte number). All events from the same event provider that share EventID and Version share an identical structure.
Level This value represents the severity or verbosity of an event. Predefined values of 1 (Critical), 2 (Error), 3 (Warning), 4 (Info), and 5 (Verbose) are commonly used, but a provider can define its own values up to a maximum value of 255. Higher numbers correspond to more verbose events.
Task The Task property usually identifies a general area of the functionality of the event provider (such as printing, networking, or UI). It can also refer to a sub-component of a program. Security Audit events use these extensively. Each event publisher may define its own set of values for this two-byte number. Note that the meaning of the Task attribute often matches semantically, and is a superset of, the Category attribute in previous versions of Windows. For this reason, Event Viewer displays this value in a column called Task Category.
Opcode This is a one-byte value that is typically used to represent a specific action or a part of an action performed by the software. This value is often used in tracing activity-based processes (such as Web services in which the activity is a specific request received by the Web service). There are a few predefined values, the most common of which are 1 (Start) and 2 (Stop).
Keywords This is a mask with 56 flags that can be set by the program to enable easy grouping of similar events. Each event may have more than one flag set, indicating that the event belongs to multiple groups.

Understanding Publishers and Events
It is difficult to be proactive when you don't know in advance all the types of information that can possibly be found in the event logs and trace files. Therefore, one of our major goals for the new eventing infrastructure was to provide documentation for each event publisher, including information on the set of events and their destinations.
To accomplish this, each publisher must enumerate all the events it will ever publish along with the structure for these events. This information is compiled, encoded, and saved with the publisher's binary (a program or a DLL).
It is now possible to discover all the publishers that are registered with the eventing system, as well as the configuration of every publisher. This includes viewing a complete list of all the potential events a publisher might log, the structures of these events, and their associated messages—all before these events are even thrown. Figure 4 shows how a command-line utility, wevtutil, can be used to display provider configuration. The command being shown displays all of the information known to the system about the event publisher named Microsoft-Windows-Video For Windows.
Figure 4 Using wevtutil to Display Provider Configuration
Figure 4 Using wevtutil to Display Provider Configuration

How the Query Language Works
As mentioned earlier, the structured nature of the events in the new infrastructure has allowed us to include support for a query language, which is based on standard XPath expressions. Generally speaking, given a starting location (an XML element), an XPath expression can refer to any place within the element. (For a complete description of the XPath language, see the official reference at w3.org/TR/xpath). More commonly, an XPath expression refers to another element or attribute contained within the starting element. Since the event log is essentially a sequence of Event elements, you can assume each log looks something like this:
<root>
<Event>... </Event>
...
<Event>... </Event>
</root>
The root element does not have a name—it is simply used as a context for all XPath expressions. Only forward axes are defined, which means an XPath expression can reference Event elements, their sub-elements, and their attributes. And if an XPath expression selects an element that exists, it evaluates to true. Consider a very simple XPath expression based on the event shown in Figure 3:
*/System[Provider/@Name='Microsoft-Windows-TaskScheduler' and Level <= 2]
This expression selects all Event elements ("all" is represented by the asterisk) from the Microsoft-Windows-TaskScheduler event provider with level 2 or smaller (meaning all error and critical events).
While a simple XPath expression can be used to select events from a single log, a simple but powerful XML-based query language allows selection and suppression of events from any log or external event archive. In fact, the query language is pervasive in Windows Vista eventing. Custom Views, for example, are based on queries. And you can use the query language to specify which events from across specific logs should be shown in the Event Viewer's event list pane. You can use the language to subscribe to events, archive selected events, and trigger actions in the new Task Scheduler.
Actual query XML or XPath expressions must be supplied to the Event Log command-line utility. Defining such queries is not for everyone, so the Event Viewer provides a simple UI for creating common queries. The Create Custom View dialog shown in Figure 5, for example, can be used to create a view for all Task Scheduler events. Note that each query creation dialog has a tab titled XML, which displays the text of the query and lets you edit the query directly.
Figure 5 UI for Creating Common Queries
Figure 5 UI for Creating Common Queries

Common Uses for Queries
Queries can be used in numerous ways. But some uses are naturally more common than others. For example, queries are often used to view select events in the Event Viewer or even the Event Log command-line utility.
You can attach a task to a query using the Windows Task Scheduler. Whenever an event is published that matches the query, the Task Scheduler will start the designated task. Note, that this feature uses subscriptions and reacts to any newly arriving events. You can only subscribe to Admin and Operational events; Debug and Analytic events are written directly into the trace files and the system cannot examine them when they occur.
Queries can be used for archiving select events. You can select events from live logs of any type, down-level event archives (EVT files), external trace files, or Windows Vista event archive files. An archive file can be opened in the Event Viewer, backed up to secondary storage, or sent to support personnel for help with diagnosing a problem. All event descriptions and other strings associated with events can be attached to the archive in a language selected during the archive operation. If this is done, the events will be available with full descriptions in the language of choice on any machine.
Finally, queries can be used to forward events to a system that is dedicated to collecting events. This feature uses the new Event Collector service, which allows an administrator to create event subscriptions to remote computers. These subscriptions are persisted on the collector machine and can be retried using a configurable schedule. The event collector uses the industry standard WS-Management protocol to create subscriptions on the remote computers and WS-Eventing protocol to transfer events. (Both protocols are secure and firewall-friendly.) The events received by the Event Collector are saved in the local Event Log.

Conclusion
The changes to Windows Eventing are dramatic and far-reaching—this article only touches upon them. The event forwarding feature alone could fill its own entire article.
The event system boasts improvements in performance, scalability, reliability, and security. But it should not be forgotten that the main goal was to improve the manageability of Windows. The query language, along with the Event Viewer views, lets you more easily discover problems. Tight integration with the Task Scheduler opens the way for simple monitoring, automatic problem resolution, and fast notification problems develop. And event forwarding enables event archiving and agentless monitoring of servers and desktops.
All these features are implemented without sacrificing backward compatibility, meaning existing solutions will continue to work. Ultimately, the improvements to eventing should help organizations manage their systems more efficiently.

Val Menn is with the Management Infrastructure Group at Microsoft where he is Program Manager for the Event Log. He previously worked as a software engineer and system administrator for a number of start-ups.


 Windows Vista: More Powerful Group Policy in Windows Vista
Windows Vista Jeremy Moskowitz

More Powerful Group Policy in Windows Vista
At a Glance:
  • The Group Policy infrastructure
  • Improved network awareness
  • Added Group Policy capabilities

Windows Vista delivers a substantial update to the Group Policy infrastructure. Yet as organizations around the world deploy Windows Vista, many administrators probably won't notice much of a difference in how they work because the numerous changes in Group Policy functions
all take place under the hood. What administrators will find, however, is that Windows Vista™ Group Policy is much more powerful than it was in previous versions.
Prior to Windows Vista, Group Policy processing occurred within a process called winlogon. Winlogon had a lot of responsibility, which included getting people logged on to their desktops, as well as servicing the various Group Policy chores. Group Policy is now its own Windows® service. What's more, it's hardened, which means that it cannot be stopped nor can an administrator take ownership of the permissions upon Group Policy in order to then turn it off. These changes enhance the overall reliability of the Group Policy engine.
This is just for starters. Let's take a more in-depth look at some of the major changes that have been made to the new Group Policy.

Improved Network Awareness
Before Windows Vista, the Group Policy engine would try to figure out if you were coming in over a slow link or a fast link. It would then use this knowledge to help craft which policy settings it would apply. Over a slow link, Group Policy wouldn't send the entirety of policy settings to your system, as this could take quite a bit of time to download. This assistance hasn't been removed from the new Group Policy. However, what has changed is how current network bandwidth is calculated.
This speed determination was done by sending Internet Control Message Protocol (ICMP) ping packets to Domain Controllers. This approach had many problems in real-world use. First, many administrators turn off ICMP on their routers. Second, if the connection was over high-latency links (like satellite), the calculations were unreliable. In these situations, the Group Policy engine had no guaranteed way to determine if the link was truly fast or not.
Additionally, the Group Policy engine had no idea if the machine was being restored from hibernation or standby mode. Nor did the Group Policy engine know if you suddenly dialed in after being off the network for six months. Using a machine that runs Windows XP or Windows 2000, a user could dial in, check e-mail, and disconnect—all without getting a Group Policy refresh. Most administrators would want to perform a Group Policy refresh, if needed, on a system being restored from hibernation or standby or a machine dialing in after a long absence.
The updated Windows Vista Group Policy is smart enough to know about network connectivity in real time. The main change is that the Group Policy engine now uses the Network Location Awareness 2.0 (NLA) handler in Windows Vista. The NLA service simply alerts the Group Policy engine whenever a Domain Controller is available. And, if so, a Group Policy refresh is performed if needed.

Multiple Local GPOs
In the days before Windows Vista, only one Local Group Policy Object (GPO) was supported. If you typed GPEDIT.MSC at a command prompt and made some changes to the settings, you affected every user and administrator who used that machine. This was often a problem if, say, you wanted to remove the Run command from the start menu for typical users, but leave it available for administrators.
The new Multiple Local GPO facility addresses this problem using GPO layers. This capability will probably be used mostly on systems that are not joined into an Active Directory domain. However, corporate users may find this feature useful as well.
The new Multiple Local GPO facility, which is based on layers, can get a bit complicated (see Figure 1). There's still a default local GPO, which applies to the local computer system context and affects all users on the system. This GPO defines both Computer Settings and User Settings.
Figure 1 Users' Total Local Group Policy
Figure 1 Users' Total Local Group Policy
The second layer affects members of either the local system Administrators group or non-Administrators on the local system. By definition, a user account cannot be in both groups. The layer figures out whether the user is a local System Administrator or a regular user and then applies the appropriate GPO (either Administrators or non-Administrators). The third layer affects a specifically named local system user account.
So that's three potential local GPOs that can affect any particular user who sits down at the machine. For example, you can use the three layers to provide settings for everyone on a particular machine, more settings that affect only non-Administrators of the machine, and finally settings that affect just one single user of that machine.
Of course, if the system has been joined into an Active Directory® domain, the Active Directory Group Policy Objects take precedence over local policies. It should also be noted that Domain Administrators can choose to turn off all local GPO processing for Windows Vista.

Error Messages and Troubleshooting
Windows Vista has an entirely new Event Log system. The Group Policy engine leverages this new Windows Eventing 6.0 system (commonly known as the Event Log) and splits events into two particular logs. The familiar System log (which is now seen as an Administrative log) contains Group Policy problems. If an error with the Group Policy engine occurs, it should appear in the System log, listed as coming from the Group Policy Service (not the Userenv process).
A new Applications and Services log (which is an Operational log), is specifically for Group Policy, and stores operational events. This essentially replaces the cumbersome userenv.log troubleshooting file, as each step from the Group Policy engine is listed here for easy reading.

ADM and ADMX
Since the days of Windows NT® 4.o, ADM files have provided the underlying definitions templates for what's possible in Group Policy. Not everything in Group Policy is controlled by ADM files, but they are responsible for all the goodies located under User Configuration | Administrative Templates in addition to Computer Configuration | Administrative Templates.
Functionally, these ADM files have some flaws. In versions of Windows previous to Windows Vista, every time you create a new GPO you copy a slew of these ADM files into every GPO's folder (which lives in SYSVOL) to the tune of about 5MB per GPO. With lots of GPOs, there are lots of duplicated systems template files placed on SYSVOL, and this creates in turn lots of replication from each of these 5MB nuggets.
Additionally, ADM files aren't language-neutral. An ADM file is built in one language and everyone using that file has to make due with that language choice.
Group Policy in Windows Vista addresses these issues with the introduction of a new XML-based format for policy definition files called ADMX. The ADMX files themselves are language-neutral. However, they must be accompanied by a language-specific ADML file. You can easily add more languages by simply adding more ADML files to accompany an ADMX file.
The ADMX format supports a central store. This eliminates all the replication of duplicate information and it makes it easier to update an ADMX file. Suppose an ADMX file is updated, perhaps from a service pack—all you need to do is drop the updated file in the central store and you're done. All Group Policy administrators in the domain who are using Windows Vista workstations will have access to the updated ADMX file. Previously, you needed to ensure each administrator's machine had the correct copy of any updated ADM file, and that was a challenge at best.
A domain administrator needs to create the central store on SYSVOL manually, once for each Active Directory domain. Once the central store is created, all administrators using Windows Vista machines to create and manage GPOs will automatically use the central store. Note that this is a feature specific to Windows Vista and it's the Windows Vista machine joined to an Active Directory domain that checks for the presence of a central store. You don't have to wait for the next version of Windows Server® , code-named "Longhorn," nor do you have to convert you users' machines to Windows Vista. This occurs regardless of whether the domain is based on Windows Server Longhorn, Windows Server 2003, or even Windows 2000. In order to take advantage of the central store, you simply need to create the central store, and then use Windows Vista machines to create or manage GPOs.
As mentioned, ADMX and ADML files are based on XML. The primary benefit of XML is the use of an industry-standard language. It's worth pointing out, though, that there is no ADMX graphical editor (or any plans for Microsoft to release one). Nor is there an ADM to ADMX conversion tool for any custom ADM templates you might already have.
Windows Vista will ship with about 130 ADMX files which replace the 6 to 8 ADM files that shipped with previous versions of Windows. These files live in the \Windows\PolicyDefinitions directory, as shown in Figure 2. Note that the ADML files are stored in language-specific subdirectories, like the en-US directory for United States English.
Figure 2 ADMX Files in the \Windows\PolicyDefinitions Directory

Group Policy Management Console
The Group Policy Management Console, or GPMC, was available as a download for Windows XP and Windows Server 2003. A scriptable Microsoft Management Console, GPMC offered a single administrative tool for managing Group Policy.
GPMC is now built right into Windows Vista. This means that whenever you're ready to create or edit GPOs, you'll have easy access to the best tool for the job. Just type GPMC.MSC at the Windows Vista Start | Search command prompt and you're ready to go.

New Stuff to Control
Windows Vista brings about 800 new policy settings to the table. These exist over multiple categories, many of which you already know and rely on. But Windows Vista also introduces some great new categories—ones that simply hadn't existed or lacked any Group Policy controls.
Enhanced areas in Group Policy include Wired and Wireless networking policy, Windows Firewall and IPsec, Print Management, Desktop Shell, Remote Assistance, and Tablet PC. Note that the updated Wired and Wireless policies may require a forest-wide schema update (for more information on this, see microsoft.com/technet/itsolutions/network/wifi/vista_ad_ext.mspx).
New areas in Windows Vista Group Policy include Removable Storage Device management, Power Management, User Account Control, Windows Error Reporting, Network Access Protection, and Windows Defender.
To control the areas that specifically affect Windows Vista machines, you must use a Windows Vista machine (or a Windows Server "Longhorn" machine) when you create or edit the GPOs. That's because the older operating systems will have no knowledge of these new settings that are specific to Windows Vista.
An exploration of any of these areas could fill an entire article, so there isn't space here to delve into each one. However, the Removable Storage Device management features and Power Management features (seen in Figure 3) are particularly noteworthy. These features, I suspect, will be huge boons for administrators everywhere. In short, these areas give decent granular control over which devices can be attached to Windows Vista and what kind of power settings laptops, desktops, and monitors will use to save companies money.
Figure 3 Enforce Power Management through Group Policy
Figure 3 Enforce Power Management through Group Policy
With the additional Power Management settings in Windows Vista, an administrator can elect to turn off or place an inactive video display monitor into a low-power "sleep" mode. Studies published on the Environmental Protection Agency's Energy Star Web site have shown that controlling monitor power use can result in savings of $10 to $30 USD per monitor annually. That savings can really add up when you've got hundreds or thousands of monitors in your company.
As for Removable Storage Management, consider this scenario: an administrator wants to allow students to use their USB flash drives to access term papers, homework, or other documents on any campus kiosk workstation. However, due to possible misuse, as well as potential security risks, the students should not have write access to the USB drives at the campus kiosk workstation—unless, of course, it is a school-approved USB drive. This type of device management granularity is possible using Windows Vista Group Policy settings.

Wrap Up
As you can see, these improvements to Windows Vista management happen under the hood. Administrators will find that Windows Vista Group Policy provides powerful, flexible configuration management with a significant increase in configurable settings, and new resources to increase system security (and potentially reduce costs).
What's Next for Group Policy
The features described in this article are, more or less, what you’ll see when Windows Vista ships. However, the Group Policy team is already thinking about what’s next on the horizon. Additional Group Policy features will likely be made available in the Windows Server "Longhorn" timeframe. And while these features won’t be available when Windows Vista initially ships, they will likely be made available for Windows Vista through a service pack or some other add-on mechanism. So, while these upcoming features are subject to change, there are three major areas of improvements slated for the future. And just to be clear, none of these features should require Windows Server "Longhorn" to work.
Comments One often-requested feature is the ability to add comments about what each GPO does or what any specific Group Policy setting is meant to do. Right now, the only way to make comments is to keep track of your GPOs and settings in, for example, a spreadsheet and then make comments there. The ability to input comments will be a welcome addition.
Templates Sometimes an administrator wants to give other administrators a starting point for creating their own GPOs. Group Policy Templates will provide this capability. Starting with a template, an administrator will be able to go on to create their own customized GPO. Microsoft will likely add common scenarios to the initial set of templates, offering specific guidance for how to control different types of machines. (For more information on this, check out the Common Scenarios documentation and files.)
Searching and Filters With what feels like a million policy settings, sometimes it’s difficult to find the particular policy setting you need. Fortunately, the upcoming search capabilities will make it easier to search inside the title, explaintext, and comments of policy settings. You’ll also be able to see, at a glance, which policy settings are enabled or disabled within a GPO, making it easier to make quick changes to a misbehaving GPO.
You can submit additional Group Policy feature requests by visiting the Windows Server Feedback Portal at windowsserverfeedback.com.

Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He also runs a two-day Group Policy intensive training course. His latest book is Group Policy, Profiles and IntelliMirror, Third Edition (Sybex, 2005). Contact Jeremy at www.GPanswers.com. Thanks to Mark Lawrence of the Group Policy Team at Microsoft for his assistance with this article.


 From the Editor: Get Ready for Windows Vista
From The Editor
Get Ready for Windows Vista

WINDOWS VISTA IS CURRENTLY at release candidate stage, and it won't be long before the final release is sent to manufacturing. We've put together this special issue of TechNet Magazine to serve as a guide for those of you planning to evaluate and deploy the new operating system.
You've no doubt heard that you'll need to get all new machines to run Windows Vista. This is most likely not true. Windows Vista will be available in a number of different configurations: Business, Enterprise, Home Basic, Home Premium, and Ultimate. Guess which one gives you the ultimate experience!
All versions will provide improved security and reliability, but will be further tailored to provide the features most appropriate for its audience. You'll find info about these editions at Get Ready: The Editions.
The best way to gauge how your machine will run is to use the Windows Vista Upgrade Advisor. This tool scans your machine and reports how it rates for CPU, memory, graphics, and accessories. Windows Vista will install only as much as your machine can handle, so if you're running an older graphics card you won't automatically get the shiny new Aero interface as seen on our cover. However, you'll still get the benefits of improved security, reliability, and more.
The new security features make it much harder to accidentally introduce malware onto a computer and much easier to take away those unnecessary administrator privileges. You may hear some unkind words muttered under the breath of your more "independent" users, but your response is easy-"Security comes first." Just the same, there could be a bit of a learning curve for your people, so download the release candidate and sandbox it for a while. You'll be better prepared for issues that come up down the road.
Speaking of preparation, it doesn't get much better than this magazine, supplemented by the rest of the TechNet program. You'll find many additional resources for IT pros charged with testing and deploying Windows Vista at Windows Vista Resources for IT Professionals. You can even get information right from the Windows Vista team at the Windows Vista Team Blog. The next 18 months are going to bring major changes to the desktop, and it pays to be prepared in advance.
—JOSHUA TRUPIN

Thank you to the following Microsoft technical experts: Derk Benisch, Steve Campbell, Mike Chan, George Holman, Khushru Irani, Kamal Janardhan, Michael Keigley, Mark Lawrence, David Lowe, Mike Lewis, Nathan Muggli, Michael Murgolo, Roger Wolter, and Andy Zeigler.


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

Monitor Your Network
Alchemy Eye
alchemy-lab.com
Short of having an absolutely infallible infrastructure and application stack with no single point of failure, one of the best methods for protecting your interests is to know about problems before anybody else does, and that means having a robust and feature-full network monitoring utility on your hands. If one of your services goes down, you want to be able to react quickly and start fixing the problem before your boss bursts through the door of your office with a fistful of angry e-mails (yes, they still print them out).
Alchemy Labs offers an extensible service monitoring application called Alchemy Eye to help you know before your users know. Adding a new service monitor is a simple process and you can duplicate previously created monitors with a couple of clicks. The application calls each service a server, but to monitor multiple IPs and services on the same machine, you will have to create multiple application &quot;servers.&quot;
Alchemy Eye is a Robust Network Monitoring Utility
Alchemy Eye is a Robust Network Monitoring Utility
Alchemy Eye offers numerous notification mechanisms for each service monitored. You can choose to alert when the service goes down and when it comes back online. You can also send notifications via e-mail, page/SMS, ICQ, or MSN® Messenger. In addition, you can run an executable when a monitored service goes down, make an entry in the Event Log, play sounds, run a SQL query via an ODBC connection, run VBScript or JavaScript, or all of the above. And if those options aren't enough for you, you can purchase additional notification plug-ins. Finally, if the program still doesn't fit your needs as it stands or with any of the plug-ins available for purchase on the Web site, the company will build a custom plug-in for an additional charge.
One feature I particularly like is the ability to add maintenance windows for each service. It will pause monitoring of the server resources during these windows, so you can avoid false alarms due to scheduled down times. You can also attempt to restart a Windows® service when an event is triggered, though this would require a remote RPC call and execution by an account that has privileges to restart the application (which may not be an option for your infrastructure).
If you have a ton of services to monitor, you can organize your service groups into folders to manage the list a bit easier. If you have to turn in those uptime reports to your boss, the application provides a set of HTML reports for you as well. You can generate reports on service availability, event log statistics, error types, and fault counts.
Price: $299 per license.

Map Your Site's Structure
PowerMapper Professional 4.0
www.powermapper.com/pro.htm
Creating site maps and link checking seem to be part of every Internet engineer's task list. Electrum Multimedia Ltd.'s PowerMapper Professional 4.0 gives you a simple way to spider your sites (check for bad links) and produce nice-looking visual reports of your site's structure.
After you have created your map, you can customize it by choosing a map style that fits your needs. The application gives you seven built-in map styles such as a page cloud, a treeview, or a table of contents. The resulting maps are also clickable, so you can walk-through your site map. For larger sites, the multi-page printing functionality gives you the ability to print out a large format view for presentations or information architecture meetings.
PowerMapper Gives You a Simple Way to Spider Your Sites
PowerMapper Gives You a Simple Way to Spider Your Sites
Another nice feature of PowerMapper Professional 4.0 is that it lets you export to third-party formats such as Microsoft® Excel® and Google's sitemap format.
Price: $349.

Book Review
Microsoft Windows Scripting Self-Paced Learning Guide
Process automation is a key element of any successful IT operations environment. Without it, IT pros get too bogged down in repetitive day-to-day operational tasks to get ahead of the curve. And from my experience, a truly proactive IT operations staff leads to happier employees.
In that light, Microsoft Windows Script Host along with VBScript gives you powerful and customizable automation tools, and Microsoft Windows Scripting Self-Paced Learning Guide by Ed Wilson (Microsoft Press®, 2004) shows you how to rid yourself of those mundane repetitive operational tasks.
The book is tailored to the Operations perspective, so if you are not a developer, don't worry. For example, the second chapter, "Getting in the Loop," shows you how to programmatically declare variables, connect to the file system and registry, as well as how to use for and while loops.
Once you have mastered the syntax, the book moves on to systems administration and shows you how to master use of the FileSystemObject for file and directory manipulation— great for automating the archives of your system or Web logs.
Next, the book introduces the power of the Windows Management Interface (WMI) and how to gather and manipu-late data via Windows Script Host and VBScript. You could use VBScript along with the Windows Task Scheduler to perform actions based upon disk thresholds that are tested by querying the WMI.
Part three of the book moves into the Active Directory Service Interfaces (ADSI), showing how to connect to Active Directory and perform tasks such as importing a list of users and changing their passwords or mapping drives based upon a user's OU membership. The book also explains how to work with the registry and create, modify, or delete registry keys.
The last part of the book shows how to manage IIS 6.0 with VBScript, automating repetitive tasks like Web site or virtual directory creation, as well as how to connect and work with Exchange Server 2003 to check queue status.
All in all, this book deserves a spot on the bookshelf of any operations IT pro.
Price: $44.99.

Use a Powerful Text Editor
TextPad
www.textpad.com
A good editor that shows you exactly what is in a file, gives you fast and powerful editing tools, and has support for any type of character set is an absolute necessity for the IT professional. Helios Software Solutions' TextPad offers all the features you need. And unlike other editors that I have tried, TextPad allows you to open and modify huge files without bogging down your machine or the application process. This application is limited only by the amount of virtual memory on the machine you are running it on.
You can have multiple files open at the same time; the UI makes it simple to switch between them, giving you a selectable tab or list view. TextPad has another great view called the Clip Library that gives you a simple and fast method of adding control, MS-DOS®, or ANSI special characters with a double-click. The Clip Library also has your clipboard history, allowing you to easily drop in text from previous cuts in addition to HTML tag and HTML character selections that let you drop HTML into your text file. The undo-redo feature of the application is virtually unlimited as well, allowing you to trace back all the steps you made with a document since you opened it.
One of the best features of TextPad is Document Class, an extensible color-coding syntax file for document types based upon their file extension. This allows you to easily color code your special file formats like HTML and VBScript. You can create syntax files for virtually any file type imaginable and a simple Internet search will usually yield what you are looking for if you don't want to go through the process of creating your own (which is a relatively easy process).
Another helpful feature of TextPad is that it lets you add-in your favorite tools to the editor's menus. For example, there is a tip on the TextPad Web site that demonstrates how to use the tool integration feature to edit and run VBScripts directly from within the application, allowing you to speed up your administration tasks.
TextPad Lets You Open and Modify Huge Files Without Bogging Down Your Machine
TextPad Lets You Open and Modify Huge Files Without Bogging Down Your Machine
TextPad's user interface is localized into seven languages and it comes with a spell-checking dictionary for ten different languages. All the basics are covered as well, giving you easy-to-view line numbers, column locations, and word wrapping.
You can also search, sort, and indent with a click and without adding anything weird to your file. The find/replace functionality offered by TextPad is fantastic, giving you a powerful yet simple way to make document-wide changes. You can find by text or hex values, match whole or partial words, or, saving the best for last, use regular expressions to quickly find and replace what you need. The scope is customizable between selected text, the current document, and all the documents you currently have open.
TextPad also includes macro functionality, so if you find yourself having to do the same keystrokes over and over again, you can easily record a macro to make those steps happen for you.
If all that wasn't enough, TextPad integrates with the Windows Explorer, giving you quick edit access via a right-click context menu on any file.
Price: $29 per single-user license.

Write to Toolbox
If you have a favorite tool or utility you would like to see featured here, please write to the author at tntools@microsoft.com.

The opinions expressed in this column are solely those of the author and do not necessarily reflect the opinions of Microsoft. All prices were confirmed at press time and are subject to change.

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


 Utility Spotlight: Robocopy GUI
Utility Spotlight
Robocopy GUI
Joshua Hoffman
Download the code for this article: UtilitySpotlight2006_11.exe (1052KB)

IT'S FUNDAMENTAL. Try to think of a time when, either as an IT professional or even as just the user of a home computer, you didn't need to copy files. Whether you're building a master image for desktop deployment, publishing new pages to a Web server, or just backing up or reorganizing your own documents and photos, copying files is one of those core operations you are bound to perform in your daily interaction with a PC.
But there's a problem. The traditional "copy and paste" functionality that is built into Microsoft® Windows® has limitations. It works well enough for simple tasks (moving a document from one directory to another, and so on), but it lacks the advanced functionality an IT professional needs in the workplace. For example, the copy and paste operation doesn't include any kind of advanced resiliency that would allow it to recover from a brief network disruption. It's also an all-or-nothing proposition, particularly when copying complete directories. Through the UI, you can't choose to copy only those files which are new or have been updated. You either copy individual files, entire directories, or nothing at all.
Enter Robocopy. This powerful tool, included with the Microsoft Windows Server® 2003 Resource Kit Tools, allows for all of those advanced functions and more. Robocopy enables the more serious file replication tasks that can really simplify your job. The biggest benefit I think you'll find is the ability to create full mirror duplicates of two file structures (including all subdirectories and files, if you choose) without copying any unnecessary files. Only the files that are new or have been updated in the source location will be copied. Robocopy also allows you to preserve all of the associated file information, including date and time stamps, security access control lists (ACLs) and more.
Of course, we all like to work in different ways. Some people prefer the command line and for those people, the Robocopy tool as it ships is great. However, others are more point-and-click oriented, and for that crowd, there's Robocopy GUI. This welcome add-on to Robocopy comes to us from Derk Benisch, a systems engineer with the MSN Search group at Microsoft. Derk's utility allows users to customize their Robocopy scripts using a simple and very familiar-looking graphical interface (see Figure 1).
Figure 1
Robocopy GUI lets you specify your source and target paths, as well as any custom options or filters you'd like to apply, whether or not you'd like to create a drive mapping, where you'd like to store the resulting logs, and so on. These are all features you can certainly execute with traditional Robocopy command line functionality, but for many, having the options consolidated in a graphical interface may really simplify the process.
Robocopy GUI also extends the functionality of the existing Robocopy tool in some very interesting ways. For example, this tool is multithreaded, allowing you to create a Robocopy script, execute it, and begin creating another one while your first script is still running. It also allows you to save your scripts (even if you don't actually execute them) so that you can create a library of common scripts or share them with your colleagues. And most importantly, Robocopy GUI allows you to save your default settings so you don't have to start from scratch every time.
Robocopy GUI includes a help file of its own, as well as an embedded copy of the full Robocopy reference guide. This reference includes a full index of all of the Robocopy commands and syntax to help you determine which settings you'd like to take advantage of.
With all of these useful features, Robocopy GUI makes a great addition to any IT professional's toolbox. You'll find a copy of Robocopy GUI in the downloads section of our Web site.

Joshua Hoffman is the Technical and Acquisitions Editor for TechNet Magazine.


 SQL Q&amp;A: Temp Tables, 64-bit Processing, Mirroring, and More
SQL Q+A
Temp Tables, 64-bit Processing, Mirroring, and More
Edited By Nancy Michell

Temporary Tables
Q I've heard that to avoid contention problems it's not always a good idea to use the temporary database, tempdb. Is that true? I've used it because I need to get data that's spread among many tables and even modify it along the way. I can't do this easily with views.
A It's true that a heavily used tempdb may experience contention. But contention is usually a problem only in rare situations such as when you get hundreds of SPIDs (server process identifiers) creating and deleting large numbers of temp tables all at the same time, as explained in the Knowledge Base article support.microsoft.com/kb/328551.
Using a temporary table (which may or may not be in tempdb, by the way) can actually be quite an acceptable solution. The key is whether the increased performance you gain when pulling data from the temporary table outweighs the overhead in building the table in the first place.
You need to consider the size, lifespan, usage frequency, and especially the number of active instances of the temp table(s) before rejecting the solution. Server dimensioning matters as well, since tempdb contention can be hardware related.
If you need a high number of small, short-lived tables, you can try table variables, which have some advantages over temporary tables. (See the answer to our next question for more detail on the differences between table variables and temp tables, and take a look at "Frequently Asked Questions - SQL Server 2000 - Table Variables" for more information.)
In your case, if all queries to the database must go through temp table creation procedures, it might also be wise to question the original data model rather than trying to just live with it.

Q What are table variables and what is their performance like? Can I really use them instead of temporary tables?
A Temporary tables and table variables provide the same basic functionality; indeed, both are materialized as temporary tables in the tempdb database. However, when only a small number of rows are inserted, table variables can provide superior performance. This is because table variables do not maintain either statistics or indexes, resulting in lower overhead. If the table contents will not exceed a few 8KB-sized database pages that the database engine will keep resident in the data cache, then table variables are preferred.
As per SQL Server™ Books Online:
  • A table variable behaves like a local variable. It has a well-defined scope, which is the function, stored procedure, or batch it is declared in. Within its scope, a table variable can be used like a regular table.
  • Table variables are automatically cleaned up at the end of the function, stored procedure, or batch in which they are defined.
  • Table variables used in stored procedures cause fewer recompilations of the stored procedures than when temporary tables are used.
  • Table variables require fewer locking and logging resources.
  • In some cases, performance may improve, though stats aren't kept.

Mirroring

Q I'm planning to use SQL Server 2005 mirroring to support high availability. The system will be running in a high-availability mode to support automatic failover. But I also want to run some other applications on the mirror to fully utilize the resource. The mirror server will support two databases: Production DB as the mirror to the primary and Staging DB as a standalone database. It will also support two types of clients: one is configured with the mirroring failover to access the Production DB, and the other connects to the Staging DB directly.
In addition, some SQL Server Integration Services (SSIS) packages will be running on the mirror server. They will access both databases, transferring the data from the Staging DB on the local to the Production DB running on the primary server. During the failover, the SSIS packages will transfer the data from the local Staging DB to the local Production DB (failover). Are there any issues with these configurations I need to be aware of?
A In the very general sense, this kind of configuration is not recommended because after failover the new principal could be overpowered.
Functionally, it doesn't seem like there will be issues from the mirroring perspective, but you should test thoroughly if you're going to go ahead with this solution. Testing should be done at peak load, in standard configuration, and post-failover. And your peak load should be an estimated future, not current, peak load; if you don't take future business needs into account, the solution will stop working if the load increases past capacity.
Testing might very well uncover network, disk, and even CPU bottlenecks that would manifest as poor application response times, unacceptable throughput, timeout errors, or extremely high redo queues on the mirror server (which might lead to unexpectedly long failover times depending on the actual redo rate).
In addition, during failover, running packages will lose connectivity with the faulty principal. Once failover completes and the database is available on new principal, the packages should be able to reconnect to the new principal. This assumes, of course, that the packages are built with connectivity retry mechanisms and that they will gracefully handle connectivity errors, such as being able to recover from "broken" connection conditions.

SQL Server and 64-Bit OSs

Q Is it true that if I'm running a 64-bit version of a Windows Server® operating system, I must use SQL Server 2000 Enterprise Edition (64-bit) and I can't use 32-bit SQL Server 2000?
A From the SQL Server 2000 point of view, the only native 64-bit architecture that is supported is Intel's ia64. Thus when SQL Server 2000 talks about 64-bit support, it means ia64. The only version of SQL Server 2000 that is supported on native 64-bit ia64 is Enterprise Edition. There is no Standard Edition SQL Server 2000 that runs on ia64, either natively as a 64-bit application or under ia64 Windows® on Windows (WOW, an OS subsystem that can run 32-bit apps).
For an AMD x64 machine, you have two options with SQL Server 2000. You can either run a 32-bit operating system, in which case you can run any edition of SQL Server 2000 and any service pack (SP). Or you can run a 64-bit operating system and SQL Server 2000 (any edition) SP4 under WOW. In that environment, SQL Server 2000 is not a native 64-bit application. It is running under WOW in 32-bit mode-so it doesn't even know that a 64-bit world is out there.
Just to make things more complicated, ia64 WOW and x64 WOW are two totally different subsystems. On the ia64, WOW has to emulate both a restricted virtual address space and make actual machine instruction emulation. The ia64 machine instructions are totally different from x86-it is a completely different machine. SQL Server does not support any of its components (SQL Server 2000 or SQL Server 2005) running under ia64 WOW.
Under x64 WOW, the story is different. The x86 and x64 machine architectures are very close. The instruction set is the same (or almost the same) so only the 32-bit virtual address space has to be emulated-and there is hardware assistance for that. Thus, there are many SQL Server components that support x64 WOW, such as SQL Server 2000 SP4 and any edition of SQL Server 2005.

Upgrade to SQL Server 2005

Q I want to upgrade from SQL Server 2000 to SQL Server 2005. Besides the SQL code remediation, what application changes do I have to make? For example, if I'm connecting SQL Server 2005 using a Microsoft® .NET Framework client, do I have to upgrade my desktop clients to Windows XP SP2?
I am running Windows XP SP1 and Visual Basic® 6.0, as well as some apps that use .NET. Are SQL Server Native Client, the .NET Framework 2.0, and Windows XP SP2 required? In other words, what are the overall minimum client requirements for an upgrade? And if I decide to adopt SQL Server 2005 mirroring, do the client requirements change?
A To take full advantage of mirroring, you need to use SQL Native Client (for OleDb or ODBC) or the ADO.NET 2.0 SqlClient. And the connection string should be changed to reference both the principal and the mirror.
But, you only need SQL Native Client or the .NET Framework 2.0 to make the client mirror-aware. Older clients can connect, but won't automatically try the mirror if the principal is down.
Without touching the clients, you can add a BIG-IP switch between the clients and server to move them from the one box to the other manually on failover. Or you can change code in the application to attempt a connection to the mirror server on connection failure to the principal.
The system requirements include the following: Windows Installer 3.0, Microsoft Windows XP SP1 or later, Microsoft Windows 2000 SP4 or later, or Microsoft Windows Server 2003. For more information on requirements, see "Using ADO with SQL Native Client"; "Updating an Application to SQL Native Client from MDAC" and "System Requirements for SQL Native Client"

SQL Server 2000 Out of Memory
Q I am experiencing strange out-of-memory exceptions on my production SQL Server 2000 Enterprise Edition SP4 on Windows Server 2003 SP1. Figure 1 shows the error I get from the logs.
Figure 1 Out-of-Memory Error (Close Figure 1)
2006-06-23 14:41:40.72 spid77    WARNING:  Failed to reserve contiguous memory of Size= 24641536.
2006-06-23 14:41:40.85 spid77    Buffer Distribution:  Stolen=4800 Free=1744 Procedures=39391
                                Inram=0 Dirty=90621 Kept=0
                                I/O=0, Latched=99, Other=3063345
2006-06-23 14:41:40.85 spid77    Buffer Counts:  Commited=3200000 Target=3200000 Hashed=3154065
                                InternalReservation=587 ExternalReservation=0 Min Free=1024 Visible= 173320
2006-06-23 14:41:40.85 spid77    Procedure Cache:  TotalProcs=9555 TotalPages=39391 InUsePages=1031
2006-06-23 14:41:40.85 spid77    Dynamic Memory Manager:  Stolen=44191 OS Reserved=7648
                                OS Committed=7619
                                OS In Use=7603
                                Query Plan=39088 Optimizer=0
                                General=4183
                                Utilities=140 Connection=7651
2006-06-23 14:41:40.85 spid77    Global Memory Objects:  Resource=1617 Locks=313
                                SQLCache=1836 Replication=204
                                LockBytes=2 ServerGlobal=42
                                Xact=63
2006-06-23 14:41:40.85 spid77    Query Memory Manager:  Grants=0 Waiting=0 Maximum=94533 Available=94533
2006-06-23 14:41:40.88 spid77    Error: 17803, Severity: 20, State: 12
2006-06-23 14:41:40.88 spid77    Insufficient memory available..
My server has plenty of RAM (32GB). Strangely, this problem seems to occur randomly; the stored procedure that causes this error does so perhaps once or twice out of 20 executions.
The server's performance counters indicate plenty of available memory. Is the lazy writer not paging to disk fast enough? Why does the process request such a large amount of memory when executing my stored proc? Is it the number of select statements or use of temp tables?
A The amount of physical memory on the machine is not relevant here. Depending on how your boot.ini is set up, applications will have between 2 and 3GB of virtual address space. Virtual address space is a precious commodity on 32-bit systems. By default, the buffer pool will consume all but 384MB of the virtual address space. That 384MB is set aside for thread stacks and allocations from components that are either too large to be serviced by the buffer pool, or are unaware of how to allocate from the buffer pool (third-party xprocs, linked servers, COM components).
The warning indicates that an allocation of approximately 23MB failed. Whether or not allocations of this size succeed will depend on the number and placement of other allocations within the 384MB block.
You might consider removing some of the third-party xprocs that are loaded on the system, determining if there is any use of COM components via sp_oacreate or linked servers.
It's quite possible that the process is requesting such a large amount of memory when executing your SQL stored procedure due to the use of the FOR XML clause in your sproc (which we did not reprint here). However, if you want more information, Process\sqlservr\Virtual Bytes will give you an indication of how much virtual address space is still available. And there is a tool called VMStat (included on the CD for the book Programming Applications for Microsoft Windows by Jeffrey Richter) that will determine the largest virtual address block size. The lazy writer is not involved in this allocation; the area of memory being used for the allocation is not in bpool.?

Thank you to the following Microsoft IT Pros for Their Technical Expertise: Ramon Arjona, Stephen Borg, Sandu Chirica, Robert Djabarov, Guillaume Fourrat, Osamu Hirayama, Alejandro Mihanovich, Maxwell Myrick, Uttam Parui, Shashi Ramaka, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson, Madhusudhanan Vadlamaani, Jian Wang, and Dave Wickert.


 Hey, Scripting Guy!: Sure, We're Adaptable
Hey, Scripting Guy!
Sure, We're Adaptable
The Microsoft Scripting Guys
This column is based on a prerelease version of Windows Vista. Some information herein is subject to change.
Download the code for this article: ScriptingGuys2006_11.exe (151KB)

YOU'VE PROBABLY heard that one of the best ways to advance your career is to network-you know, make connections with other people in the industry so you can learn from them, share information with them, and possibly get a new job from them. The Scripting Guys never really got the hang of that whole career networking thing (which should be obvious), but we do know a thing or two about computer networking. That's because you can do a lot with networking through scripts.
Windows® Management Instrumentation (WMI) provides a number of classes you can use in order to both control and monitor your network environment. Two of those classes, Win32_NetworkAdapter and Win32_NetworkAdapaterConfiguration, allow you to work with-what else?-network adapters on your computers.
A question we hear frequently is "How do I enable and disable my network adapters through a script?" Well, we won't hold you in suspense. We'll tell you right now that you can't. At least not until you're running Windows Vista™. In Windows Vista two new methods have been added to the Win32_NetworkAdapter class: Enable and Disable. We'll take a look at these methods in a minute. But first, before you get too dejected, we'll show you some of the things you can do with pre-Windows Vista operating systems. Just for starters, you can find out what network adapters are actually available on the machine (see Figure 1). That's good stuff, right?
Figure 1 Finding Network Adapters (Close Figure 1)
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapter")

For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "Description: " & objItem.Description
    Wscript.Echo
Next
In Figure 1, we start by connecting to the WMI service on the local computer. Sure, it's easy enough to find the network adapters on your local computer through the GUI, but try using the GUI to get information about the network adapters on a remote computer. That's one of the beauties of this script, and of WMI scripting in general: you can run this same script against a remote computer simply by changing the value of strComputer to the name of the remote computer.
After we've connected to the WMI service we then query for the Win32_NetworkAdapter class. This query returns a collection of all the network adapters on the computer. From there all we have to do is set up a For Each loop to walk through the collection of adapters and echo back the Name and Description of each one. Your output will look something like this:
Name: Broadcom NetXtreme 57xx Gigabit Controller
Description: Broadcom NetXtreme 57xx Gigabit Controller

Name: RAS Async Adapter
Description: RAS Async Adapter

Name: WAN Miniport (L2TP)
Description: WAN Miniport (L2TP)

Name: WAN Miniport (PPTP)
Description: WAN Miniport (PPTP)
There's a lot more information you can retrieve about your network adapters just by echoing back different properties of Win32_NetworkAdapter, such as DeviceID, Manufacturer, and TimeOfLastReset. For more information, see the magnum opus "Automating TCP/IP Networking on Clients", found-where else?—in the Script Center.

Adapting to Change
With the Win32_NetworkAdapter class all you can do is retrieve information about network adapters. If you want to actually change any of the adapter settings you need to use the Win32_NetworkAdapterConfiguration class. Not only does this class provide additional information about your adapters (thanks to properties not found in Win32_NetworkAdapter), but it also offers several methods that allow you to configure your network adapters to your liking.
For example, maybe you can't enable and disable the adapters, but you can enable and disable dynamic host configuration protocol (DHCP) on each TCP/IP-enabled adapter. Figure 2 shows a script that looks for all TCP/IP-enabled adapters, checks to see whether DHCP is enabled on each adapter and, if it isn't, enables it.
Figure 2 Enabling DHCP (Close Figure 2)
strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapterConfiguration Where IPEnabled = 'True'")

For Each objItem in colItems
    If objItem.DHCPEnabled = False Then
        Wscript.Echo objItem.Caption
        intReturn = objItem.EnableDHCP
        Select Case intReturn
            Case 0
                Wscript.Echo "DHCP enabled"
            Case 1
                Wscript.Echo "You must reboot before DHCP will be enabled"
            Case Else
                Wscript.Echo "Error occurred"
        End Select
        Wscript.Echo
    End If
Next
Just like the script in Figure 1, the script in Figure 2 connects to the WMI service on the local computer. It then queries for the Win32_NetworkAdapterConfiguration class. Note that because we're concerned only with those adapters that are TCP/IP-enabled we included a Where clause in our query:
Where IPEnabled = 'True'
This clause specifies that we want only the instances of the Win32_NetworkAdapterConfiguration class where the IPEnabled property is True, meaning the adapter associated with that instance is TCP/IP-enabled.
Next, we use a For Each loop to iterate through the collection of adapters returned from our query. Within the loop we first check the DHCPEnabled property of each adapter. If the property is set to False it means that DHCP is not enabled, so we want to enable it. We do that by calling the EnableDHCP method on the adapter object. That's really all there is to it.
Just to make it easier to see what's happening in the script, we echoed back the Caption property so we know which adapters we're working with. We also included a Select Case statement and created descriptors of each possible result for the end user. The EnableDHCP method returns an integer value when it's finished. A value of 0 means the method ran successfully and DHCP is enabled. A value of 1 means the method ran successfully but the computer needs to be restarted for the change to take effect. Any other value means something went wrong and DHCP was not enabled. We use the Select Case statement to check these integer values and return an appropriate message.
You can also disable DHCP; this is done by setting a static IP address and a subnet mask on the adapter (see Figure 3).
Figure 3 Setting an IP Address (Close Figure 3)
arrIPAddress = Array("192.168.0.12")
arrSubnetMask = Array("255.255.255.0")

strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapterConfiguration Where IPEnabled = 'True'")

For Each objItem in colItems
    If objItem.DHCPEnabled = True Then
        Wscript.Echo objItem.Caption
        intReturn = objItem.EnableStatic(arrIPAddress, arrSubnetMask)
        Select Case intReturn
            Case 0
                Wscript.Echo "Static address assigned"
            Case 1
                Wscript.Echo "You must reboot before the static address will take effect"
            Case Else
                Wscript.Echo "Error occurred"
        End Select
        Wscript.Echo
    End If
Next
The script in Figure 3 is almost identical to the script in Figure 2, with just a few key differences. At the beginning of the script we declare two arrays, arrIPAddress and arrSubnetMask, and assign a value to each. Then in our For Each loop, rather than checking to see if DHCPEnabled is False, we check to see if it's True, meaning DHCP is enabled (in turn, meaning that we want to disable it). We then call the EnableStatic method on the adapter object. You'll notice that, unlike the EnableDHCP method, EnableStatic takes parameters. These parameters are the arrays we declared earlier that contain the new static IP address and the subnet mask.

Windows Vista Additions
As promised (because Scripting Guys never-or at least rarely-break their promises), we'll now show you what you can do in Windows Vista. As we said earlier, in Windows Vista the WMI class Win32_NetworkAdapter has two new methods, Enable and Disable, that allow you to enable and disable your network adapters. There's also a new property, NetEnabled, that returns True if the adapter is enabled and False if it isn't. Figure 4 shows a script that finds all the network adapters on the computer that are disabled, and then enables them.
Figure 4 Enabling Network Adapters (Close Figure 4)
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapter Where NetEnabled = 'False'")

For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "Description: " & objItem.Description
    objItem.Enable
    Wscript.Echo
Next
This is almost identical to the script we showed you in Figure 1. (In case you hadn't noticed, we're strong advocates of reuse.) We connect to the WMI service on the local computer and query for all instances of Win32_NetworkAdapter. Because we're interested in only the adapters that are disabled, we added a Where clause:
Where NetEnabled = 'False'
This clause uses the new NetEnabled property to specify that only adapters in which NetEnabled is set to False—in other words, where the network adapter is disabled—should be returned from the query. We then, once again, set up a For Each loop to loop through the collection of network adapter objects returned from the query. After echoing back the Name and Description of the adapter, we call the Enable method to enable the adapter.
It's all pretty simple, right? Now if only we could get the hang of this other type of networking.

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.


 The Future Of Windows: Directory Services in Windows Server &quot;Longhorn&quot;
The Future Of Windows
Directory Services in Windows Server "Longhorn"
Byron Hynes
This column is based on a prerelease version of Windows Server, code-named "Longhorn." All information herein is subject to change.

A number of improvements in Active Directory will come your way with the next version of Windows Server, code-named "Longhorn." Some of the changes are significant and open up exciting new avenues toward better manageability and efficiency. One of the most obvious changes in Active Directory is the naming of features and functions. Everything that relates to identity management is now grouped under the Active Directory® banner. What you and I have thought of as Active Directory in Microsoft® Windows Server® 2003 is now Active Directory Domain Services (ADDS), and there are a number of other additional services, including Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, formerly Active Directory/Application Mode, or ADAM), Active Directory Certificate Services (ADCS), and Active Directory Rights Management Services (ADRMS).
Each of these services represents a server role—a new concept in Windows Server "Longhorn." You can choose to have a computer dedicated to one server role or to several, and you can administer server roles using Server Manager, shown in Figure 1. From there you can add roles, find help, and perform other necessary administrative tasks.
Figure 1 Server Manager
Figure 1 Server Manager
As you can see, the new approach organizes day-to-day functions and features into logical groups that are accessible in Server Manager.

Functional Levels
Windows Server "Longhorn" introduces a new functional level for forests and domains. The Windows Server "Longhorn" forest functional level (which will be renamed on release) doesn't add any new functionality on its own, but it ensures that all domains in the forest are at the Windows Server "Longhorn" domain functional level, which enables two new enhancements. The first is the use of the newest distributed file system (DFS) replication engine for the SYSVOL share, which is more robust, granular, and efficient. The second is added support for 256-bit Advanced Encryption Services (AES) encryption for the Kerberos authentication protocol. Using the latest functional level will give the best performance, but you can continue to operate at lower functional levels as you migrate to Windows Server "Longhorn."
A number of schema extensions to support various features have also been introduced, all of which are fully compatible with the existing schemas in use today. Domain controllers running Windows Server "Longhorn" can happily co-exist and interoperate with those running Windows Server 2003.

Support for Server Core
Active Directory Domain Services is one of the server roles that will work in a Server Core installation of Windows Server "Longhorn." Server Core, which is not covered in detail in this article, is a minimal installation option where only core server functionality is retained. Server Core does not install the Windows shell and does not use a graphical user interface, saving quite a bit of overhead.

Read-Only Domain Controller
For some environments, the most significant feature for ADDS in Windows Server "Longhorn" is a Read-Only Domain Controller (RODC), which allows you to easily deploy a domain controller that hosts a read-only replica of the domain database. This is well suited for locations where physical security of the domain controller can't be guaranteed or where other applications must run on the domain controller and be maintained by a server administrator (who, ideally, is not a member of the Domain Admins Group). Both of these scenarios are common in branch office deployments.
A read-only domain controller is installed by simply enabling one checkbox in the Installation Wizard, as shown in Figure 2.
Figure 2 Installing the Read-Only Domain Controller
Figure 2 Installing the Read-Only Domain Controller
Before the release of Windows Server "Longhorn," if users had to authenticate with a domain controller in a different location, the traffic would have to cross a wide-area network (WAN) link. WAN links are often slower and more expensive than local area network (LAN) connections, and sometimes are more susceptible to service disruption. One possible solution was to deploy a DC into the remote site or branch office. However, this introduced other problems, including replication traffic, and the need to maintain physical security over the DC in the branch office—something that is all too often lacking in small and remote branch sites. In other cases, branch offices have poor network bandwidth connected to a hub site, increasing the amount of time required to log on.
With the exception of account passwords (unless specifically configured otherwise), an RODC holds all the Active Directory Domain Services objects and attributes that a writable domain controller holds. However, locally originating changes cannot be made to the replica stored on the RODC. Instead, changes are made on a writable domain controller and replicated back to the RODC. This prevents changes made at branch locations from potentially polluting or corrupting the forest via replication, thus eliminating one avenue of attack.
Local applications that request read access to the domain directory information can obtain access directly from the RODC, while Lightweight Directory Access Protocol (LDAP) applications that request write access receive an LDAP referral response. This referral response directs them to a writable domain controller, normally in a hub site.
Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This reduces the workload of bridgehead servers in the hub and the effort required to monitor replication. RODC unidirectional replication applies to both ADDS and Distributed File System (DFS) Replication. The RODC performs normal inbound replication for ADDS and DFS Replication changes.
In the domain database, each security principal has a set of approximately 10 passwords or secrets, called credentials. An RODC does not store user or computer credentials, except for its own computer account and a special "krbtgt" account (the account that is used for Kerberos authentication) for each RODC. The RODC is advertised as the Key Distribution Center (KDC) for its site (usually the branch office). When the RODC signs or encrypts a ticket-granting ticket (TGT) request, it uses a different krbtgt account and password than the KDC on a writable domain controller.
The first time an account attempts to authenticate to an RODC, the RODC sends the request to a writable domain controller at the hub site. If the authentication is successful, the RODC also requests a copy of the appropriate credentials. The writable domain controller recognizes that the request is coming from an RODC and consults the Password Replication Policy that's in effect for that RODC.
The Password Replication Policy determines if the credentials are allowed to be replicated and stored on the RODC. If so, a writable domain controller sends the credentials to the RODC, and the RODC caches them, as shown in the sidebar "How a Read-Only Domain Controller Works."
After the credentials are cached on the RODC, the next time that user attempts to log on, the request can be directly serviced by the RODC until the credentials change. When a TGT is signed with the RODC's own krbtgt account, krbtgt, the RODC recognizes that it has a cached copy of the credentials. If another DC has signed the TGT, the RODC will forward requests to a writable domain controller.
By limiting credential caching only to users who have authenticated to the RODC, the potential exposure of credentials by a compromise of the RODC is also limited.
By default, no user passwords will be cached on an RODC, but that's not necessarily the most efficient scenario. Normally, only a few domain users need to have credentials cached on any given RODC, compared with the total number of users in a domain. You can use the Password Replication Policy to specify which groups of users can even be considered for caching. For example, by limiting RODC caching to only users who are frequently at that branch office, or by preventing the caching of high-value credentials, such as administrators, you can reduce the potential exposure.
Thus, in the event that the RODC is stolen or otherwise compromised, only those credentials that have been cached need to be reset, and, as I'll discuss, you'll know exactly which accounts those are, as Figure 3 shows.
Figure 3 Cached Account Info
Figure 3 Cached Account Info

Administrator Role Separation
In many branch offices, a domain controller is given additional server roles or tasks to perform, such as acting as a file or print server. In other cases, a line-of business application is installed on a domain controller out of necessity. This creates a problem: in order to administer those applications and servers, an employee at the branch office needs to have administrative credentials. And anyone who can administer one Windows Server 2003 domain controller can administer the entire domain.
In Windows Server "Longhorn," an administrator can be given permission to manage only a particular RODC, without having the access that would let him manage other domain controllers and without having to be made a member of the Domain Admins security group unnecessarily.

User Interface and Tool Improvements
To support the functions of an RODC and to make it easy to monitor password replication, a new Password Replication Policy tab appears on the properties page of a domain controller in Active Directory Users and Computers, as shown in Figure 4.
Figure 4 The Password Replication Policy Tab
Figure 4 The Password Replication Policy Tab
By clicking the Advanced button on this tab, you can see which passwords have been sent to the RODC, which ones are stored there, and which accounts have authenticated against that RODC, as shown in Figure 5. Since the list includes accounts that have authenticated, even if they are outside the groups that are allowed to have their passwords replicated, you can use that information to decide which groups should be included in the Password Replication Policy.
Figure 5 Advanced Password Replication Policy
Figure 5 Advanced Password Replication Policy
A number of changes have been made to the venerable dcpromo utility, more formally known as the Active Directory Domain Services Installation Wizard. This wizard can be launched as a full graphical application by choosing the Add Roles command in the Initial Configuration Tasks (ICT) page that runs immediately after the installation of the operating system. Choose Add Roles and then ADDS in Server Manager or invoke dcpromo from a command line or the Run box.
As soon as you use the wizard in graphical mode, you'll notice better organization of elements and choices, as related items are grouped together. There are also more options. You can access the advanced mode from the UI without using the /adv switch to perform tasks such as creating a new domain tree, installing from media (to reduce initial replication over a WAN), or selecting the source domain controller for initial replication.
Some improvements have been made to make your job easier and reduce frustrating errors. For example, if you are using the wizard to create a new domain controller in an existing domain or forest, you can browse for existing domains instead of having to type the NetBIOS name.
New pages have been added to specify additional options, to let you configure the DC as a global catalog server, as a DNS server, and as an RODC. In the wizard you can also configure site selection, set functional levels, create a password replication policy for RODCs, and configure DNS delegation.
As a command-line tool, dcpromo can be run in a completely unattended way. Unlike the same tool in Windows Server 2003, an unattended installation does not require a response to any user interface prompt, such as needing to restart the computer. This makes it easier to use ADDS on Server Core installations of Windows Server "Longhorn."

ADDS Auditing
Microsoft adds a lot more functionality to auditing for directory services in Windows Server "Longhorn." In Windows Server 2003, you could turn auditing on or off for directory access, but even if you had full success auditing enabled, the audit trail did not include what information had been changed. Now, it can.
In Windows Server "Longhorn," the auditing policy for ADDS has the following four subcategories:
  • Directory Service Access
  • Directory Service Changes
  • Directory Service Replication
  • Detailed Directory Service Replication
For most IT pros, there are two key facts to remember about these changes. First, the Directory Service Access auditing gives essentially the same information as it did under Windows Server 2003, but the Event ID is changed from 566 to 4662. Make note of this change if you use tools to parse the security event log. Second, the new category Directory Services Changes records both the previous value and the current value of the changed attribute.
To implement auditing in ADDS, you use the Global Audit Policy, System Access Control Lists (SACLs), and the ADDS schema. The components work together in order to give you both a flexible and comprehensive auditing framework.
The Global Audit Policy controls whether or not any auditing is done on ADDS. If auditing is enabled, the Global Policy controls which of the four subcategories of access (listed earlier) are audited. The Global Audit Policy is usually applied in the Default Domain Controllers Group Policy object, so it applies to the entire directory on the domain controller.
Although the Group Policy tools can turn the Global Audit Policy on or off, you must use the Auditpol.exe command-line tool to view or configure the subcategories. They are not exposed in the graphical user interface.
A SACL is a part of an object's security descriptor. By specifying entries in the SACL, you tell the system two things: which actions and which users (or security principals) you care about. In other words, you specify which users attempting to perform which actions should be recorded in the event log. So if you want to record changes to User objects made by Domain Admins but not by the users themselves, you can control this with SACLs. A SACL applies to an object (and can be defined for new objects, and inherited from container objects).
You can also configure the ADDS schema to limit change auditing to particular attributes. Since SACLs are applied to the object by default, access or changes to any attribute are recorded. This could generate a lot of logging activity, and perhaps not all attributes matter to you. So, at the attribute level, you can set a flag to prevent changes to that attribute from being logged.
SearchFlags is an attribute defined in the class that defines attributes, so it's an attribute of an attribute. It is also a bitmask, where each bit of a one-byte value represents a different on/off setting. You might find it easier to get your head around it by thinking of it as a property of an attribute. In Windows Server 2003, seven of these values are used to control various settings, including the indexing and GC replication of the attribute. In Windows Server "Longhorn," the eighth bit (with a value of 128) is used to control whether or not changes are logged. If this bit is set, ADDS will not log change events when modifications are made to that attribute. This applies to all objects that contain the attribute. In Beta 2, you cannot use the graphical user interface to set the eighth bit.
By default, in Windows Server "Longhorn," the Global Audit Policy is turned on and the Directory Service Changes is set to log successful changes.

Restartable ADDS
In Windows Server "Longhorn," ADDS is a restartable service. This simply means that the ADDS Services can be stopped and started without rebooting the domain controller. This allows administrators to perform functions that can't be done while the service is running (such as an offline defragmentation of the database) more easily and without entering Directory Services Restore Mode.
There are three possible states for a domain controller running Windows Server "Longhorn": ADDS Started, ADDS Stopped, and Directory Services Restore Mode. Let's examine each of these states.
ADDS Started The domain controller is operating normally.
ADDS Stopped The server has characteristics of both a domain controller in Directory Services Restore Mode and a domain-joined member server.
As with Directory Services Restore Mode, the ADDS database (Ntds.dit) is offline. The Directory Services Restore Mode password can be used to log on locally if another domain controller can't be contacted for logon.
As with a member server, the server is joined to the domain. Users can log on interactively or over the network by using another domain controller for domain logon. However, a domain controller should not remain in this state for an extended period because it can't service logon requests or replicate with other domain controllers.
Directory Services Restore Mode This mode (or state) is unchanged from Windows Server 2003.
The flowchart in Figure 6 shows you how a domain controller that is running Windows Server "Longhorn" can transition between these three possible states.
Figure 6 A Domain Controller on Windows Server 'Longhorn' Can Transition between Three States
Figure 6 A Domain Controller on Windows Server 'Longhorn' Can Transition between Three States

Looking for More?
It is impossible in one short article to explain the depth of the new ADDS features in Windows Server "Longhorn." But as you saw, new Active Directory features will solve a number of problems you previously had to try to work around or simply live with. As the release of the final version of the product draws near and you want to learn more, rest assured that additional documentation will be made available publicly. For now, the best place to look for updates during the beta phase is the Windows Server "Longhorn" Web site.

Byron Hynes works in the Windows Server User Assistance group at Microsoft. In the past, he worked as a consultant and trainer, and has a range of experience including running a regional Internet backbone, troubleshooting client-server and Web-enabled applications, and designing databases schemas, network infrastructure, and security models. You can reach him at bhynes@microsoft.com.


 Security Watch: I Just Got a Security Bulletin. Now What?
Security Watch
I Just Got a Security Bulletin. Now What?
Christopher Budd

The Microsoft monthly security bulletin release process, established in October 2003, was a response to customer requests. One of the chief requests was for predictability in the release schedule of security bulletins. We've been able to use that regularity and predictability to hone and improve our processes.
The Microsoft Security Bulletin site is where you can find the most recent security bulletin and search past bulletins, as shown in Figure 1. An example bulletin, in this case for August 2006, is shown in Figure 2.
Figure 1 Microsoft Security Bulletin Site
Figure 1 Microsoft Security Bulletin Site
For many customers, the Microsoft monthly security bulletin has helped foster more mature processes for deploying Microsoft security updates. With security bulletins being released on a predictable day, customers have used this opportunity to build their own regular processes for handling them. These customers have created timelines and steps in their own security update evaluation and deployment processes that integrate the predictable timelines around the Microsoft monthly security bulletin release. Customers use that process to analyze, test, and deploy updates in a systematic fashion that helps to increase their overall security posture and decrease downtime and disruption.
Figure 2 August 2006 Security Bulletin
Figure 2 August 2006 Security Bulletin
However, some customers proceed through security update evaluation and deployment without a set procedure. While it is possible to deploy updates in an unsystematic fashion and not experience any problems, it fundamentally runs counter to what we consider to be best practices for managing security updates.
We've provided useful information about how and when we release bulletins, but we have not provided much guidance on what you should be doing with the bulletins and how you can integrate them into your own processes. Some customers may not be aware of the processes that may benefit them, or the best way to build them.
Therefore, in this column I will outline the steps and processes that we recommend for your evaluation and deployment of security updates. Organizations of any size can follow these steps. For some larger organizations, it will be appropriate to divide the steps among different groups, based on the internal structure. For smaller organizations, all these steps can be carried out by one group or even by one person. Regardless of the allocation of responsibilities, all these steps should be explicitly accounted for in your evaluation and deployment processes. Figure 3 provides an overview of the process.
Figure 3 Security Bulletin Assessment and Deployment Process
Figure 3 Security Bulletin Assessment and Deployment Process

1. Receive Advanced Notification
The first step in your monthly security bulletin process should be to ensure that you receive the Advanced Notification of coming security updates. Microsoft posts information on its Web site at approximately 10 A.M. Pacific Time (GST -8) three business days before the standard monthly release, which is the second Tuesday of each month; therefore, the Advanced Notification information is posted on the prior Thursday.
The goal of the Advanced Notification is to provide information that will help deployment planning ahead of the actual release. The level of detail included is balanced against a need to protect customers until the release of the security updates by not disclosing any information that could facilitate attacks. The Advanced Notification aggregates information about the upcoming updates by product name without information about specific versions (for example, Microsoft® Windows® or Microsoft Office). Each of these entries details how many bulletins for that product will be released, the highest maximum severity of those bulletins, whether any of the updates will require a restart, and which of our detection tools will apply to those bulletins.
To ensure that there are no surprises and to minimize possible confusion, the Advanced Notification also provides information about other updates not associated with security bulletins that will be released on the same day. Specifically, it details how many High Priority Non-Security Updates will be released through Microsoft Update (MU) and Windows Update (WU), as well as any updates to the Microsoft Windows Malicious Software Removal Tool.
Finally, we will provide information about any issues that might cause delays in your deployment, as we did for the "Send as" permission change in MS06-019.
Each month the new Advanced Notification is posted, at which time a notification is sent out through the Security Notification Service Comprehensive Edition (SNSCE). You can register for the SNSCE.

2. Assess the Potential Impact
Once you receive the Advanced Notification, your first step should be to assess the relevance of upcoming releases in your environment. Even though the Advanced Notification contains limited details about the products affected, it presents enough information that you should be able to gauge whether upcoming bulletins will be relevant for your environment.
For example, suppose that Advance Notification notes two Microsoft Exchange bulletins that have a highest maximum severity rating of critical and that require a restart. If you don't run that program, you'll know right away that those bulletins won't be applicable to your environment. Conversely, if you run Exchange Server 2003, you will know that on Tuesday you might have up to two bulletins rated as critical requiring restarts.
For planning purposes, think of the Advanced Notification as a tool to help you determine the maximum possible impact on your organization in terms of numbers of bulletins, their severity, and their impact at deployment regarding restarts. Once you've assessed the relevance and maximum possible impact of the updates, you can create a schedule which should include the following action items:
  • Personnel for risk assessment, testing, and deployment
  • Test plans and test lab time
  • Deployment plans and scheduled restarts (where appropriate)
All scheduling at this point should be tentative since information in the Advanced Notification is subject to change. Also, because of the limited nature of the information in the Advanced Notification, you may make changes once you have the full details.
Finally, if there is any additional information, such as functionality changes, you should use the time between the Advanced Notification and the actual security bulletin release to research the issue and evaluate its possible impact to your environment. You might need to revise your tentative schedule based on your research.

3. Receive New Microsoft Security Bulletins
On the second Tuesday of the month Microsoft releases its security bulletins. 10 A.M. Pacific Time is the target for release, but as the release is part of a large, complex, interconnected process, it might be delayed for a variety of reasons. In this release, security bulletins, security updates, updates to detection and deployment tools such as the Microsoft Baseline Security Analyzer (MBSA) and Windows Server® Update Services (WSUS), and new detection tools such as a new version of the Enterprise Scan Tool (EST) are all posted on Microsoft Web sites.
The Microsoft security bulletin page is enabled to support RSS feeds. When security bulletins include updates, our RSS feed is also updated which in turn will update RSS aggregators and viewers. In addition, notification is sent out using both the Security Notification Service (SNS) and the SNSCE. Notifications are sent out through both e-mail and MSN® Alerts.
To learn about the availability of new security bulletins, you should register for all of the notification mechanisms offered. You can subscribe to the RSS feed and for both SNS and SNSCE.

4. Assess the Relevance of Security Bulletins
It is important that you clearly assign the responsibility for reviewing the new security bulletins and assessing their relevance for your environment. As part of this assessment, you can take the full specific information from the security bulletins to make revisions and adjustments to your tentative scheduling as appropriate. Going back to the example, if you notified your Exchange administration team of a possible critical security update, but you then find that Exchange Server isn't affected, you can adjust your scheduling of those resources.
Once you have assessed the relevance of the security bulletins for your organization, you can then move ahead with those that are relevant in your processes.

5. Perform Risk Assessment and Rate Bulletins
At this point you need to perform a risk assessment of the relevant bulletins. In organizations with divided responsibilities, this step is often performed by the security group. While each Microsoft security bulletin contains a maximum severity rating, that rating reflects the highest severity of all vulnerabilities in all affected products. The Microsoft severity rating that applies to your organization may be different from the maximum severity rating listed, depending on the severity of the issue on the versions in your environment. It's important to look at the full Severity Ratings and Vulnerability Identifiers table under the Executive Summary section of the security bulletin and obtain the specific vulnerability information for your particular versions.
After that, you should review additional technical information such as Mitigating Factors and technical details from the FAQ for each vulnerability and make adjustments to your risk assessment based on your environment and policies. Your policies may also dictate that your assessment account for nontechnical, environmental factors such as the threat environment or the criticality of certain applications to your organization.
At the end of this process, you should have a risk rating for each of the bulletins and the updates associated with them. Continuing with our example, the Exchange administration group may rate a security update as "moderate risk" based on the changes detailed in the security bulletin. Based on your policies, you should make updates and changes to your schedule as appropriate. For example, your policies may dictate that moderate risk updates require one or two more days of testing than low risk updates.
In some cases, your policies may dictate that for bulletins with a certain risk rating you also need to consider implementing workarounds. For example, your organization's policy may state that for all security updates you rate as critical, you should review and deploy workarounds as soon as possible. In that case, you would perform an additional risk assessment on the workarounds to determine what to implement and when.
At the end of this process, you should have a list of updates to be deployed in your environment with associated risk ratings for each. In addition, you should have a list of workarounds to be implemented which should be used to update your testing and deployment schedule. The changes to your schedule should reflect the timelines specified by your policies. For example, you may have a policy that dictates that for all critical security updates, workarounds must be deployed within 24 hours and updates deployed within seven calendar days.

6. Determine the Possible Impact of Security Updates and/or Workarounds on the Organization
Understanding the impact of security updates or workarounds on your environment is a critical step in the evaluation process. In organizations with divided responsibilities, this step will often be performed by the group that manages the systems directly affected by the security updates or workarounds.
Understanding the possible impact helps you to understand and determine the risk posed by the security updates or workarounds themselves. Information can be found in the security bulletin in the "Frequently Asked Questions (FAQ) Related to This Security Update" section. Information about how the security update addresses the vulnerability is located within the Vulnerability FAQ under "Vulnerability Details."
The goal of this step is to determine a risk rating for the updates and workarounds. Continuing with the previous example, the Exchange administration group may rate a security update as "moderate risk" based on the changes detailed in the security bulletin. Based on your policies, you should revise your schedule as appropriate. For example, your policies may dictate that "moderate risk" updates require one more day of additional testing than "low risk" updates.
You may also need to revisit the decisions around deploying workarounds based on the impact of your risk rating on your schedule. For example, you may find that you need to extend testing by two days and this leaves your systems unprotected for longer than your policies allow. In that case, you would then revisit the deployment of workarounds to be in compliance with your policies.
Finally, you will use the information that comes from this step when you move on to developing a test plan for the updates.

7. Define a Test Plan
To be effective, testing must be systematic and must be built with a meaningful plan. Your test should target areas that would be most likely to exhibit problems in your environment. Since each environment is different, we can't offer a standard template for an effective test plan.
For organizations with divided responsibilities, the test plan will often be designed by more than one group. The group that manages the technologies or systems directly affected by the security updates or workarounds can provide its particular expertise. The testing group can offer expertise on building test cases, options for test tools, and an understanding of practical timelines.
During this phase you should note how the test plan impacts your risk rating of the security updates or workarounds and make changes to your testing and deployment schedule accordingly. For example, if you determine that you cannot develop a test plan to test an update as fully as you would like, you may increase its risk rating, choose to delay the deployment, and implement workarounds in the interim.

8. Develop a Deployment Plan
Deployment is the process that actually implements the protection that the security updates or workarounds provide. Because deployment is really the ultimate goal of the process, understanding the deployment methods available and factoring them into your assessments is as important as a security risk assessment. In organizations with divided responsibilities, determining possible deployment methods for security updates is often performed by the groups that are responsible for managing the software update infrastructure, such as the group that maintains Systems Management Server (SMS). Groups that have oversight of configuration management technologies such as Active Directory may be involved in determining possible deployment methods for workarounds.
In this step, your goal is to understand the possible deployment methods and to build from that a plan that you will use to deploy the security updates or workarounds. An important thing to understand in this step is how the possible deployment methods may impact your schedule and make any necessary changes. For example, if a security update is not supported by WSUS and that is your primary deployment method, you may determine that it will take you two days longer to deploy the update than originally planned. You may, in turn, decide to implement workarounds to provide necessary protections during this deployment window.
Information regarding deployment methods is contained in the security bulletin in the "FAQ Related to This Security Update" section. Information about ways to implement workarounds is listed with each workaround; individual workarounds are associated with each vulnerability.
This concludes the planning stages. At this point, you should have a schedule that reflects all elements of your assessments and planning regarding security risk, risk rating of the security updates and workarounds, testing, and deployment. As you can see throughout these stages, they are intricately interrelated and not necessarily linear. In some organizations, these stages occur simultaneously, whereas in others they are sequential. You should decide on the implementation of these steps based on the policies, needs, and resources of your organization. The most important thing for these steps isn't the specific structure and order, but rather that you ensure that these different stages are able to inform and respond to one another. The key for any implementation is to remain flexible and adaptable.

9. Test Updates and Workarounds
In the testing stage, you'll put the security updates and workarounds through the test plan defined earlier in your testing environment. The goal in your testing environment is to replicate the critical elements in your production environment. In testing the security updates or workarounds, you are striving to find any issues that might occur before you deploy to your production environment.
As problems are identified in testing, you should determine the severity of the issue and the steps needed to resolve them. You may discover minor issues that have an acceptable level of impact, whereas others will require resolution prior to deployment of the updates. If you choose to accept the issue, document it for your support staff.
To resolve the issue, you can open a case with Microsoft Product Support Services (PSS), which offers no-charge support for issues related to security updates. You can find information on how to contact PSS at support.microsoft.com/security. Because resolving issues can add time to testing and thus delay deployment, before you choose to resolve an issue you should consider the potential impact to your schedule.
When the testing is complete with all issues either resolved or documented, you can then certify the security updates or workarounds for deployment in your production environment.

10. Deploy Updates and Workarounds
After security updates or workarounds have been certified by testing, you can proceed with the deployment process. During deployment, use the plan to guide you as you actually apply security updates or configuration changes to systems. The groups that were involved in developing the plan are usually responsible for the actual deployments.
If you encounter problems in the deployment-for example, a security update fails to install properly through your update management infrastructure-you'll need to examine the problem carefully. If the problem introduces delays, you may want to re-examine options and/or consider workarounds in order to protect your systems.
Ideally, your testing process will identify all issues that might occur in production before deployment. However, if you do encounter issues after deploying into your production environment, you should follow the same steps you would if you encounter an issue in testing. Evaluate the issue and decide whether to accept or resolve it.
If security updates are successfully applied, then the protections are in place and the ultimate goal of these processes has been met. However, if they are not successfully applied, your systems are still vulnerable.
Because some systems may not have updated successfully, the final step in the deployment process is very important-auditing systems to verify the success of the deployment. In some organizations, auditing will be performed by a separate auditing group, often connected with security teams. Microsoft tools such as WSUS, MBSA, and SMS can be used to audit for the successful application of security updates. In addition, there is information in the security bulletin in the Security Update Information section on how to verify the successful application of the security update.

Conclusion
With the Microsoft monthly security bulletin release, it's possible for you to implement more regular planning and processes for the management of security updates. Building regular procedures and processes helps you better protect your systems while at the same time minimizing disruption and possible downtime.
While every organization should build its own unique processes for managing security updates, your organization's processes should include the steps recommended in this column. You don't need to have separate security and update teams, but you should perform both a security risk assessment and develop a deployment plan.
The key concept here is the importance of planning. With good planning, the steps that involve actual activity, such as the testing and deployment stages, will go much more smoothly, which, in turn, will result in a successful security update process.

Christopher Budd is a security program manager in the Microsoft Security Response Center (MSRC). He specializes in technical communication with IT and security professionals and other software users.


 Inside Microsoft.com: Management and Delegation of ASP.NET
Inside Microsoft.com
Management and Delegation of ASP.NET
Jeff Toews

The microsoft.com Web infrastructure runs almost entirely on the .NET Framework 2.0. One of the microsoft.com operations team’s key Web administration challenges is the proper configuration of ASP.NET, and we’ve learned a lot while trying to tweak our settings to perfection. Getting
configuration settings right requires a good working knowledge of the various configuration sections in web.config and machine.config files and an understanding of what those settings mean. A good way for you to get a handle on the settings and their significance is to look at examples. In this column I’ll present some configuration tips derived from configuring the servers running microsoft.com so that you have the benefit of learning from our experience.

1. Set the Compilation Switch Appropriately
When deploying ASP.NET-based applications in a production environment, it is critical to make sure that nobody accidentally (or deliberately) leaves the compilation debug attribute set to true in any application web.config files, as it is here:
<compilation debug="true" />
In busy environments with many Web applications to manage, you will want to use the ASP.NET configuration control mechanisms to block this from occurring. (I’ll give more details on this in a bit.)
It is also important to ensure that the page-specific debugging attribute is not set to true in individual .aspx as it looks like here:
<%@ Page debug="true" %>
Again, in busy environments with high volumes of publishing, it’s often not realistic to expect you’ll be able to ensure that this setting is removed from all .aspx pages prior to their being published. You’ll need a global means to prevent this from occurring.
Compiling your Web application with this setting will result in debug binaries rather than retail binaries. Plus your code will not be optimized, resulting in slower performance. In addition, your ASP.NET requests will not time out because the debug settings prevent timeouts. Using a debug version in production environment is like opening a door and inviting hackers!
Fortunately, the Microsoft® .NET Framework 2.0 has a new deployment setting for machine.config that tells ASP.NET to disable the following: debug capabilities, trace output, and display of ASP.NET error messages (both on localhost and remotely) regardless of the instructions in your web.config file or specific page attributes. It looks like this:
<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>
Note that these last two benefits (disabling trace output and the disabling of detailed ASP.NET error messages remotely) are security best practices you really should adopt. If you don’t, you’re exposing the internal workings of your application for all the world to exploit.
While I’m on the subject, here’s another important fact: locking the <system.web><compilation> debug attribute in the root web.config file inside <location allowOverride="false"> or using the lockItems attribute will prevent web.config files lower in the application configuration hierarchy from turning on debug settings. But this will not prevent individual .aspx pages from enabling debug mode in their page attributes. The deployment retail switch is the only way to fully disable ASP.NET debug capabilities at all levels.
Setting the deployment retail switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leaks. As I said, this switch is brand new in ASP.NET 2.0; it was the direct result of feedback to the ASP.NET team.
Conversely, for internal-facing preproduction environments where devel-opers need to debug their Web applications, do not use the deployment retail setting. Simply set <compilation debug="false"> in the preproduction root web.config file and allow this value to be overridden by individual applications’ web.config files or .aspx page attributes.

2. Use Medium Trust in ASP.NET 2.0
If, as was the case for many sites on microsoft.com, you were still using a Full or High trust level even after migrating your site or applications to ASP.NET 2.0, take another look at what is now possible under Medium trust. For example, restricted WebPermission constrains an application’s communications to only one address or range of addresses that you define in the <trust> element. This lets you control and maintain a list of approved external sites and address ranges that can be called remotely. This is a big security boon.
FileIOPermission is also restricted. This means an application’s code can only access files in its virtual directory hierarchy. By default under Medium trust, each application is granted Read, Write, Append, and PathDiscovery permissions for its virtual directory hierarchy only. This puts an end to random file I/O access—quite important in a shared Web environment in which many applications are hosted.
Another advantage is that unmanaged code privileges are removed. What this means is that you can prevent use of legacy components, the easiest way we’ve yet found to disable use of the Aspcompat page attribute. (Setting Aspcompat to true can cause a page’s performance to degrade.)
Medium trust under ASP.NET 2.0 is quite flexible in terms of the ability it gives the administrator to create custom exceptions to each of the previous default restrictions. This flexibility was lacking in ASP.NET 1.1. Another reason running at Medium trust with ASP.NET 2.0 is easier than with ASP.NET 1.1 is that you have access to Microsoft SQL Server™ databases.
Thus, if you host multiple applications on the same server, you can use code access security and the Medium trust level to provide application isolation. By setting and locking the trust level (using <location allowOverride="false"> tags) in the root web.config file, you can establish security policies for all Web applications on the server. By setting allowOverride="false", as you see in Figure 1, an individual developer is unable to override the Medium trust policy setting in his application’s web.config file.
Figure 1 Trust Settings (Close Figure 1)
<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>
More information regarding the use of Medium trust in ASP.NET 2.0 can be found in the following article: "How To: Use Medium Trust in ASP.NET 2.0".

3. Restrict Download of Specified File Types
There are file types on your server that you undoubtedly do not want to fall into the wrong hands. Fortunately, by default, ASP.NET is configured to intercept and stop requests for several different file types that are used in ASP.NET applications. They include .config files and .cs files that store the source code of the application. ASP.NET ensures the privacy of these files by associating both file types with System.Web.HttpForbiddenHandler. This handler, when invoked, returns an error to the user who requests the file. In fact, you can use this method to restrict any file type.
For example, on the microsoft.com site, the file type .asmx is disallowed by adding the following entry to the <system.web><httpHandlers> section of the root web.config file:
<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />
As you can see, you can use <add> sub tags in the <httpHandlers> element to specify additional file types that you want blocked. Set the verb attribute equal to "*". When you do this, you specify that all types of HTTP requests are blocked for that file type. Define the path attribute as a wildcard character that matches the types of files you want to block. For example, you may specify "*.mdb". Finally, set the type attribute to "System.Web.HttpForbiddenHandler".

4. Be Careful When Adding Assembly References
Each Web server that runs the .NET Framework has a machine-wide code cache called the Global Assembly Cache (GAC). The GAC stores assemblies specifically designated to be shared by multiple applications on the computer. It makes sense to add assemblies to the GAC if several different applications need to reference them, even if the majority of the sites on the Web server don’t access them. This does not result in a significant performance/resource penalty but gives the benefit of maintaining centralized version control rather than having shared assemblies scattered across the server in individual application’s /bin folders.
The criteria for when an assembly reference should be added to the root web.config, however, needs to be much stricter than the criteria dictating when an assembly is placed in the GAC. Having individual applications add assembly references in their applications’ web.config file for components that aren’t truly global yields much better performance than declaring these assembly references in the root web.config file. This reduces page load time significantly for all applications on a Web server that don’t use these assemblies as the compiler doesn’t need to spend time loading unnecessary assemblies. The ASP.NET compiler won’t load an assembly for an application simply because the assembly resides in the GAC; it only loads it if an assembly reference exists in its appdomain or in a higher app scope. As a result, at microsoft.com we allow application developers to override the <configuration><system.web><compilation><assemblies> element in their applications’ web.config file for all Microsoft.com environments.
Specifically, in the microsoft.com production and staging environments’ root web.config files, all attributes of the <system.web><compilation> node are locked (including debug, explicit, defaultLanguage) as well as all its elements (buildProviders, expressionBuilders, and such), except for the <assemblies> element:
<compilation debug="false"
    explicit="true" defaultLanguage="vb"
    numRecompilesBeforeAppRestart="500"
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >
In the internal-facing preproduction environment, the <system.web><compilation> section is locked in the root web.config file, but we allow application publishers to specifically override the <assemblies> element and also to override debug="false" (to enable troubleshooting/debugging):
<compilation debug="false" explicit="true"
    defaultLanguage="vb"
    numRecompilesBeforeAppRestart="500"
    lockAllAttributesExcept="debug"
    lockAllElementsExcept="assemblies" >
Note the use here of lock attributes, which are new in ASP.NET 2.0. Again, detailed information on these attributes and examples of their use can be found at "General Attributes Inherited by Section Elements".

5. Remove Manually Set MaxConnection Values
Nearly all microsoft.com Web sites have ASP.NET applications that make calls to remote Web service clusters. The maximum number of concurrent remote Web service calls that can be made from a single Web server is determined by the maxConnection attribute of the <connectionManagement> element in the machine.config file. In ASP.NET 1.1, by default the maxConnection value was set to 2. This old default maxConnection value was much too low for sites like microsoft.com that have hundreds of different applications that make remote Web service calls. The result was that ASP.NET requests would queue while waiting for the remote Web service calls to complete. (You can view the number of queued ASP.NET requests via the perfmon counter ASP.NET\Requests Queued.) To enable more calls to execute concurrently to a remote Web service (and thereby improve the performance of applications on the site), we increased the maxConnection value to 40 for our quad processor Web servers. (The general recommended value for maxConnection is 12 times the number of CPUs, but tune this to suit your specific situation.)
In ASP.NET 2.0, however, you no longer need to configure maxConnection manually as it is now automatically scaled and set. This is a result of the new configuration section for the processModel tag in machine.config (for more information about the processModel element, see "processModel Element (ASP.NET Settings Schema))".
<system.web>
    <processModel autoConfig="true" />
</system.web>
With autoConfig enabled in machine.config (this is the default setting), ASP.NET sets the value of the maxConnection parameter to 12n (where n is the number of CPUs). Enabling autoConfig also causes the following: the maxWorkerThreads parameter and the maxIoThreads parameter are set to 100, the minFreeThreads parameter is set to 88n, the minLocalRequestFreeThreads parameter is set to 76n, and the minWorkerThreads is set to 50.
Prior to making use of autoConfig in ASP.NET 2.0 to automatically scale and set values for maxConnection and the other attributes in the list, be sure to remove any manually set values for these parameters as these values would be used instead of the autoConfig values. This is something to keep in mind when migrating from ASP.NET 1.1 (where maxConnection needed to be explicitly set) to ASP.NET 2.0, where there are defaults.
Again, the autoConfig values for maxConnection and the other attributes listed previously are somewhat arbitrary and may not work for absolutely every instance, but I have found that these limits work well for nearly all microsoft.com applications.
If you decide that you need to tune the maxConnection value manually, be cautious when increasing its value as this can lead to an increase in CPU utilization. This increase is caused by the fact that more incoming requests can be processed by ASP.NET instead of having them wait for their turn to call the Web service. Of course, you should remember that the maxConnection attribute does not affect local Web service calls, only remote calls.

6. Beware of Unhandled Exceptions
When porting ASP.NET 1.1 Web sites or applications to ASP.NET 2.0, it is extremely useful to be aware of a major change in the default policy for unhandled exceptions. In the .NET Framework 1.1 and 1.0, unhandled exceptions on managed threads were ignored and, because the applications continued to run, these exceptions often remained hidden. Unless you attached a debugger to catch the exception, you would not have realized anything was wrong. Under ASP.NET 2.0, however, when an unhandled exception is thrown, the ASP.NET-based application will quit unexpectedly. This can seriously impact your site or application’s availability if there are a lot of unhandled exceptions that were previously covered up by the old default exception handling policy.
The best way to address this is to do thorough testing and eliminate the unhandled exceptions (which should really not be present in your application). However, for migrations of very large applications in which it may be difficult to determine where the exception is occurring or if you need to migrate a lot of legacy applications for which thorough, individual testing isn’t feasible, you have a couple of options. When migrating the microsoft.com Web site to ASP.NET 2.0, we changed the unhandled exception policy back to the default behavior that occurs in ASP.NET 1.1 and ASP.NET 1.0.
To enable this legacy default exception handling behavior, add the following code to the aspnet.config file:
<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy
            enabled="true" />
    </runtime>
</configuration>
The code is located in these two folders:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (on x86 or SYSWOW64 systems) and %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (on x64 systems).
This change will essentially revert the .NET Framework to the old 1.1 and 1.0 behavior. Consider this a short-term fix because ultimately it is masking issues with your application that are really bugs. However, it is a very handy way to avoid availability issues due to unexpectedly terminating worker processes. For more information about this behavior change, see "Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0".

7. Ensure Proper Proxy Server Configuration
A Web server administrator can specify the proxy server to use for HTTP requests to the Internet by configuring the <configuration><system.net><defaultProxy> element in the machine.config file.
In the microsoft.com production environment, we configure the <defaultProxy> value to use the system default proxy (as the firewall client is not installed) and we use <location allowOverride="false"> tags to prevent the <defaultProxy> element from being overridden by application devel- opers (who might accidentally publish a web.config file with an internal proxy server):
<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>
In the microsoft.com internal preproduction and staging environments, we set the usesystemdefault attribute to false, bypassonlocal to true, and add a proxy bypasslist (see Figure 2). The bypasslist lists regular expressions that describe addresses that do not use the specified proxy. Again, this section is contained within <location allowOverride="false"> tags to prevent developers from specifying their own proxy server in their web.config files. (These proxy servers are often internal and calls to them break when pages are published to production.) Any attempts to specify a proxy server in preproduction or staging will result in an ASP.NET error at run time, which will force developers to remove this configuration prior to publishing to production.
Figure 2 Setting Bypasslist (Close Figure 2)
<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. Do Not Display Custom Errors to Everyone
As I mentioned, it is critical to not allow detailed ASP.NET error messages to be returned remotely by Web servers in the production environment.
In the microsoft.com production and staging environment’s root web.config files, the <configuration><system.web><customErrors> mode attribute is set to RemoteOnly so that custom errors are displayed to remote clients and ASP.NET errors are displayed to localhost (to allow troubleshooting by the Web server administrators). Note that the <customErrors> element is contained within a <location> tag with allowOverride="false" (see Figure 3). This is to prevent individual application owners from accidentally (or deliberately) setting mode="Off" and spilling detailed ASP.NET error messages into the Internet.
Figure 3 Preventing the Display of Error Messages (Close Figure 3)
&lt;configuration&gt;
    &lt;location allowOverride=&quot;false&quot;&gt;
        &lt;system.web&gt;
            &lt;customErrors mode=&quot;RemoteOnly&quot; defaultRedirect=
                   &quot;/errorpages/generic_customerror.aspx&quot;&gt;
                &lt;error statusCode=&quot;404&quot; redirect=&quot;/errorpages/filenotfound_customerror.aspx&quot; /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;
Also remember, as I mentioned earlier, that the use of the <deployment retail="true"/> switch in the machine.config file turns off the ability to show detailed ASP.NET error messages both to remote clients and locally. This deployment retail switch should still be your primary method of turning off these error messages if you are running ASP.NET 2.0. (To get detailed information regarding ASP.NET exceptions, use the Application Event Log.)
In the microsoft.com internal-facing preproduction environment root web.config file, the <customErrors> mode attribute is set to off so that ASP.NET errors are always displayed to both localhost and remote clients. This is to enable debugging and troubleshooting. In addition, no custom error pages are configured:
<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. Know When to Enable Tracing
ASP.NET traces are generated during the execution of an ASP.NET page, and capture interesting details about the Web request, page control tree, and execution of various stages of the page lifecycle and controls. As well, custom messages that can be written to the trace by the page developer may be displayed. The trace can be appended to the response output of the page being traced or examined as part of the list of traced requests in the application trace viewer. This feature is primarily intended for development-time debugging scenarios in internal preproduction environments and should not be used for production deployments.
In the microsoft.com production and staging environments root web.config files, the <configuration><system.web><trace> enabled attribute is set to "false" so that the ability to output trace information in a Web page is disabled. Note that the <trace> element is contained within a <location> tag with allowOverride="false". This is to prevent individual application owners from accidentally (or deliberately) setting enabled="true" and outputting detailed ASP.NET tracing information onto the Internet:
<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>
As mentioned earlier, use of the <deployment retail="true"/> switch in the machine.config file also turns off the ability to output ASP.NET trace output in a Web page. This switch should still be your primary method of turning off tracing output if you are running the .NET Framework 2.0.
To be completely certain that tracing cannot accidentally become enabled in external-facing production environments, at microsoft.com we remove the actual trace.axd handler from the root web.config file or comment it out, like so:
<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. Disable Session State Web Farms
Because all Web sites on microsoft.com are currently clustered using Network Load Balancing (NLB) with no affinity (to allow even distribution of requests across all servers in the cluster), there is no guarantee that the same server will handle all requests for a given application. As a result, the ASP.NET Session State module is disabled to prevent use of the Session property by application developers. The guideline we give to application developers who need to maintain state is to use View State (which maintains the state in a structure within the page code and, as a result, uses no server resources).
To disable Session State on a Web server, you should simply remove the following child node from the <httpModules> node:
<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>
I’ve assumed here that you’ve already seen and even used ASP.NET configuration files (machine.config, root web.config, and individual application web.config files), but if you haven’t, the following ASP.NET Quickstart Tutorial will help: asp.net/QuickStart/aspnet/doc/management/fileformat.aspx.
The article mentions that the ASP.NET 2.0 configuration system now also includes a number of very helpful features that allow administrators to lock individual elements and attributes of configuration, using the lockItems and lockCollections attributes. These attributes and their use are documented in the following article "General Attributes Inherited by Section Elements".

Jeff Toews is a Systems Engineering Manager who has been a member of the Microsoft.com Operations Team, based in Redmond, WA, for six years. You can reach him with any technical questions or comments at mscomblg@microsoft.com.


 Field Notes: Learn to Ask for Help
Field Notes
Learn to Ask for Help
Edward Dake

TOO MANY DESKTOP administrators think they never need help. We should all be islands unto ourselves and know everything there is to know. Computers do what we want them to do and only what we tell them to do, and software simply behaves as designed. Why would we ever need to seek help or collaborate with our peers?
Who cares how many administrators toil in your organization? Everyone has his assigned job and we all know what that is, so we never step on one another with settings or infrastructure changes. Is there a server you can't reach in the enterprise? Clearly, it's not down for routine maintenance; it's off-line permanently. Just delete it! Don't check with anyone to find out the real story, don't e-mail or reference any change-management documentation recommended by Information Technology Infrastructure Library (ITIL) or Microsoft® Operations Framework (MOF). Need to try some new product or procedure? Who needs virtual machines when we have real ones to work on?
Do all of these examples sound horrifying to you? As far-fetched as these situations may appear, I've encountered them all in my career as a support engineer, and many could have been avoided with some planning and cross-team communication.
The truth is that to be really effective, administrators need to rely on a whole team of personnel, both inside and outside the IT group. There's no way I can know everything there is to know about administering today's heterogeneous enterprise environments. We all need to build great relationships so we have experts to call on when necessary. My instant messenger list is full of people I respect and trust from other groups.
I've found that building a network (not the wired or wireless type) of peers to collaborate with is extremely helpful when it comes to solving problems I haven't seen before or dealing with complicated issues that involve multiple technologies. Say you're troubleshooting Active Directory® replication, for instance. Is the problem a replication issue or a DNS issue? The term "forestprep" now applies to Exchange Server and Active Directory. Which forestprep is being attempted? Do I need to collaborate with my peers in Exchange or Active Directory?
I use my contacts in Microsoft Office Communicator and Windows Live™ Messenger (newly released) sorted by groups, and I can't tell you how many times I have solved complex issues with assistance from fellow engineers. Get to know your peers and ask them for help if you run into something that falls outside of your specific support boundaries. Most people are very willing to help and it could mean resolving your current issue in a more timely manner or even stopping an issue before it becomes a big problem.
Other tools in my collaboration toolbox include Microsoft Technical Communities, Support Webcasts, and Product Solution Centers. All of these are available as menu options on the Microsoft Help and Support page under Self Support Options. I have found the Newsgroups (in the Technical Communities section) very handy for supplying information and advice from people who have experienced the same issues or who have environments that match my own.
Adding yourself to newsletter distribution lists for specific technologies is also helpful. Such bulletins contain tips and tricks, best practices, news about upcoming releases, and other information that has helped me resolve issues and kept me aware of features that are on the way.
Testing in a virtual environment is a safe way to try out schema updates, group policies, environment changes, and many other products and processes. You can use Microsoft Virtual Server 2005 R2 (free download after registration) to build a lab to test many updates before rolling them out into production. In this way, you can find and resolve potential problems in a non-production environment and avoid unexpected issues during your enterprise-wide rollout. I've found the following resources in the Windows Server System™ Reference Architecture (WSSRA) very useful when planning and designing a virtual test environment. In particular, see the documentation entitled "WSSRA Virtual Environments for Development and Test". The chapter on Planning, Testing, and Piloting Deployment Projects is especially useful.
I also highly recommend TechNet Virtual Labs for demos and test drives of products. The labs are updated regularly and they're a great place to get a first look at a product or technology without the time and effort of building an environment yourself.
I have also found the Help and Support feature in current releases of many products to be very useful. It has improved over time and is now an invaluable tool to use to research help for current technologies and updated content. Don't forget about online documentation and even e-books for quick searches and assistance. Being a great administrator doesn't mean you need to know everything. Perhaps most important is knowing where to go for help. You'll be an even better administrator by collaborating with peers and with those in other groups to help resolve issues that cross boundaries or are new to you. The beauty of our industry is that we are a community and we should work to build relationships with each other. I often rely on the help of others to drive issues to completion. The end result is a satisfactory resolution and my administrative skills are enhanced by working in collaboration with others.

Edward Dake has worked for Microsoft Corporation since 1997 as both a Technical Account Manager and a Support Engineer. His current role is Technical Lead for the Directory Services team in the Customer Service and Support organization.


 Windows Confidential: Handling Compatibility Hacks
Windows Confidential
Handling Compatibility Hacks
Raymond Chen

THERE WAS A PROGRAM written for Windows® 3.1 that opened the Printers Control Panel by looking for the Control Panel window, accessing the File menu, and searching for an item called Printer. In Windows 95, the Control Panel didn't have a Printer option under File. As a result, when run on Windows 95, this program would post a garbage command message to the Control Panel. To address this problem, Windows 95 created a decoy Control Panel window for the program to find. When the program posted the message to the decoy, the Printers folder opened.
Some people argue that Windows 3.1 should have detected that the program was making bad assumptions about the Control Panel and displayed a warning. That way, the author of the program would have seen the warning and fixed the problem before releasing the product. But detecting the intent of a chunk of code requires a degree of analysis that ventures into the realm of artificial intelligence. Essentially, Windows 3.1 would have had to detect that the program was doing a strcmp for Printers, analyze the particular strcmp, and decide if it were bad. But that only catches the Printers case. How many compatibility checks do you want the system to perform? And what about false positives?
Another argument is that Windows 95 should have responded to this bad assumption with a warning dialog that said "Program XYZ is doing something bad." But for Control Panel to know what posted the garbage message, the detection would have to be put into the window manager. This creates a fragile coupling between two components-Control Panel and the window manager. And, again, this only addresses one case. Do you want the window manager to be brittlely coupled to all the other components in the system?
Providing a generic message, without naming the specific application would be easier. But that's not a good solution, either. A vague error message is no better than no error message at all. What's more, this dialog would in all likelihood be ignored by the user-especially since it wouldn't recommend a specific course of action. Users would perceive the dialog box as an annoyance. This is a very important point. It is essential that any error message be actionable. If the user knows how to react to the warning, the dialog becomes useful.
Another problem is that a dialog box creates a point of reentrancy due to the dialog loop. This is a technical problem. Unexpected reentrancy is a major source of bugs in UI programming. What's more, the Control Panel itself may be in a modal state and displaying a dialog box causes the modal structure to fall apart.
A dialog box also creates a new localization burden. If a dialog box is written for every compatibility hack, there will be hundreds of them scattered throughout the system. Each would have to be translated into the 33 languages for which Windows provides full translations.
Finally, consider the reaction from competitors when their product results in one of these dialog boxes. They'd say things like "Microsoft is blaming other people for its own buggy operating system" and "Microsoft is intentionally making our program look bad." I'm not exaggerating. There have been companies who complained to Congress that Microsoft was maliciously targeting and disabling their software. Upon further inspection, it was found that there were bugs in their programs. Frankly, it's better just to fix their bug for them than endure a lengthy Congressional investigation.
As a result, the current versions of Windows only display a warning dialog when a program is so incompatible with Windows that it cannot run at all or that it runs with severe limitations. And even in that case, Microsoft tries to work with the vendor to ensure that no customer is left stranded. After all, people want to run programs on the operating systems they buy. If a program doesn't work, you don't care whose fault it is-you just want to get your work done.

Raymond Chen's Web site, The Old New Thing, deals with Windows history and Win32 programming. He is working on a book, coincidentally also titled The Old New Thing (Addison-Wesley, 2007).