 TechNet Magazine September 2007

TechNet Magazine September 2007

Windows Vista: Deploying Windows Vista with BDD 2007

Your organization is ready to migrate from Windows 2000 or Windows XP to Windows Vista, and the project is your responsibility. Don’t fret. Here’s a step-by-step guide to how you can use the Business Desktop Deployment 2007 Solution Accelerator to simplify your Windows Vista deployment.

Michael Niehaus Windows Vista: A Guide to Windows Vista Backup Technologies

Backup is something many people ignore until it’s too late. But there’s no excuse for this, especially now that the new Windows Vista Backup and Restore Center offers a variety of features that make it easy to protect your data against most forms of data loss. Find out how you can plan a complete recovery strategy with Windows Vista.

Christine Fok Windows Server: 11 Essential Tools for Managing Active Directory

In a large organization, even the most common Active Directory tasks, such as adding and modifying objects, can be tedious and time-consuming. These 11 tools can make Active Directory management a lot easier.

Laura E. Hunter Windows Server: Reanimating Active Directory Tombstone Objects

There are a few essential tricks and tools that should be included in every Active Directory disaster-recovery plan. Tombstone reanimation is one of these techniques, offering the only way to recover deleted objects without taking a domain controller off line. Here’s a guide to finding and recovering tombstones in Active Directory.

Gil Kirkpatrick Communications: Connecting Users with Office Communications Server 2007

Unified communication is here. Take a tour of the Microsoft Office Communications Server 2007 and find out how integrated messaging, voice, video, and conferencing features can help to improve productivity and enhance long-distance collaboration in your organization.

Alan Maddison From the Editor: Pathways to Learning

Joshua Trupin Letters: Answers to Your Questions

Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: CPU Bottlenecks, Restoring and Moving Databases, and More

Edited by Nancy Michell Utility Spotlight: PageDefrag

The typical Windows defrag tool can optimize most of the files on your hard drive. But certain items, such the Windows page file and Registry hives, are beyond the powers of most defragging tools. This utility, created by Mark Russinovich for Sysinternals, saves the day by defragging the files that are left untouched by other tools.

Lance Whitney The Cable Guy: Strong and Weak Host Models

A multihomed host provides enhanced connectivity by simultaneously connecting to multiple networks. However, services running on multihomed hosts have an increased vulnerability to being attacked. To help you prevent attack, here’s a look at the various host models of multihomed hosts and how they are supported in Windows.

Joseph Davies Windows PowerShell: Securing the Shell

When designing Windows PowerShell, Microsoft gave security a leading role. And it shows. Take a look at some of the key security features and settings, such as credential handling and execution policies, that ensure Windows PowerShell won’t fall game to the same problems that VBScript enabled.

Don Jones Hey, Scripting Guy!: Can This Relationship Be Saved?

Relational databases are designed to handle one-to-many relationships. This can make writing scripts that query these databases a bit tricky. But don’t worry—the Scripting Guys are here to show you everything you need to know.

The Microsoft Scripting Guys Exchange Queue & A: Setup, Message Journaling, Storage Options, and More

Learn how you can use message journaling to monitor e-mail in your company, find out if Office 2003 users can use Unified Messaging, examine storage options for your Exchange 2007 implementation, get answers about connecting to Exchange 2007 with older versions of Outlook, and more.

KC Lemson and Nino Billic Security Watch: The Long-Term Impact of User Account Control

For as much coverage as it gets, there are still a lot of questions and misconceptions about User Account Control. Here’s a frank discussion about what UAC is, what it is not, and how it should affect the way you manage systems.

Jesper M. Johansson The Desktop Files: PC Recovery with Windows PE

Windows Vista offers some valuable tools that make system recovery quite easy. But for large, diversified organizations, out-of-the box solutions don’t usually work. If you’re in a large company that needs to build customized self-recovery solutions, don’t miss this discussion about building your own recovery solution with Windows PE.

Wes Miller Field Notes: Free Food and Training Tips

Good user education is critical to keeping issues to a minimum. So don’t forget the importance of providing casual training sessions and roaming the halls to see if anyone has questions they wouldn’t bring up otherwise.

Michael Dragone Windows Confidential: The Known DLLs Balancing Act

The Known DLLs feature was included in Windows as a way to improve performance. Find out how it works, and take a close look at how this feature has changed over time.

Raymond Chen


 Windows Vista: Deploying Windows Vista with BDD 2007
Windows Vista Michael Niehaus

Deploying Windows Vista with BDD 2007
At a Glance:
  • BDD 2007 Solution Accelerator
  • Preparing the image
  • Drivers and application packages

You've been putting it off, but it's finally time to take the plunge. Your organization has hundreds, maybe even thousands, of machines that need to be migrated from Windows 2000 or Windows XP to Windows Vista. And it's your team's job to make it happen.
So where do I start?
If you have been installing Windows® operating systems for years, you've probably noticed that relatively few things have changed from Windows NT® 3.5 through Windows XP. The installation and configuration process has been fairly consistent, the tools have been the same, and the process overall wasn't altered. But with Windows Vista®, the whole process has been redesigned and there are many new tools. For a good overview of the changes and how they'll impact you, see the "10 Things You Need to Know about Deploying Windows Vista" article from the November 2006 TechNet Magazine, also available online at technetmagazine.com/issues/2006/11/Deployment.

How do I learn the new process and tools?
There are two choices:
  1. Learn each new tool. Study all of the available documentation. Identify how to insert each of these into your existing processes. Make the necessary adjustments. Then validate the results.
  2. Take advantage of something that has already done all of those things for you.
Sure, you could choose the first option, but then this would be a book instead of a magazine article. I suggest going with door number 2: the "something" that you'll use is the Business Desktop Deployment (BDD) 2007 Solution Accelerator, which is available for download through the Microsoft® Desktop Deployment Center at microsoft.com/desktopdeployment.
The BDD 2007 Solution Accelerator is a set of tools, guidance, and step-by-step procedures to simplify the Windows operating system deployment process, tying together all the new deployment processes and tools introduced with Windows Vista.
To get started with BDD 2007, identify a Windows XP or Windows Server® 2003 computer on which you want to install BDD 2007. Before installing, you first need to install the Microsoft .NET Framework 2.0 and Microsoft Management Console (MMC) 3.0. Then, you can install BDD 2007 itself. Once installed, review the Release Notes document available through the BDD 2007 folder on the Start menu. Then launch the MMC snap-in using the Deployment Workbench shortcut (see Figure 1).
Figure 1 Starting the BDD 2007 Deployment Workbench
Figure 1 Starting the BDD 2007 Deployment Workbench
At this point, it would probably be a good idea to review the information available in the Information Center, especially the Getting Started checklist and the documentation. Be sure to download the latest news and component listing by right-clicking on the Components node and choosing Check for updates.
There is one more prerequisite needed: the Windows Automated Installation Kit (AIK). BDD 2007 needs the tools included in the Windows AIK for many of the functions it performs. You can get the Windows AIK in two different ways: download it from the Microsoft Download Center (go.microsoft.com/fwlink/?LinkId=85377) or use the "Components" node in the Deployment Workbench to do it for you. Either way, it is a fairly large download so be prepared for it to take a little while.
After Windows AIK is installed, you can move on to the next phase: gathering all the files that you need to perform the Windows Vista deployment.

What files do I need?
At this point, you'll need to gather together the Windows Vista installation files, the applications that you want to install, any drivers that are needed for your hardware, and any Windows Vista updates or language packs that you may want. All will get copied to the distribution share directory structure created when installing BDD 2007.
Creating Your Own Custom Image
The steps discussed in this article describe how to deploy the standard Windows Vista image directly from the Microsoft product DVD. But you might want to deploy a customized image containing additional applications (such as the 2007 Microsoft Office system) needed on all of your computers. This is the classic debate: should you stick with a minimal "thin" image and install everything else at deploy time, or should you create a larger "thick" image with everything preinstalled? Often the answer depends on factors such as time available to do the deployment, administrative effort to create and maintain the image, network capacity, and so on. In most situations thinner is better, but it's your call.
Regardless of what you decide to include in your image, make sure that the process of creating the custom image is completely automated. With automation, making updates to the image is as simple as adding another step into the process, then re-running the entire process, capturing a new image at the end.
So how would you do that with BDD 2007? It's really fairly simple:
  1. Create a build for creating your custom image.
  2. Modify the task sequence for this build to include all of your custom steps.
  3. Perform a "bare metal" deployment from the lab deployment point (booting from the Windows PE ISO), selecting that build.
  4. Specify that you want to join a workgroup.
When performing those steps, the deployment wizard will present another pane.
By choosing to capture an image of the reference computer, BDD 2007 will automatically execute Sysprep to prepare the operating system for capturing, then reboot to Windows PE and execute ImageX.exe to capture a new WIM image. Then you can import that image into the Deployment Workbench and use it for your next deployment.
Capturing a reference image with BDD 2007
Capturing a reference image with BDD 2007

First, let's copy the OS installation files. Insert your Windows Vista DVD (preferably volume license media, since that won't require a separate product key for each installation), then launch the New OS Wizard by right-clicking on the Operating Systems node in Deployment Workbench and choosing the New command. Select Full Set of Source Files and specify the path to your DVD drive (or the appropriate path if you have already copied these files to another location). Complete the wizard, accepting the remaining defaults. Now you should see one or more OS images (depending on the media that you used) in the list shown when clicking on the Operating Systems node.
Applications are next. You don't have to add any applications at this point, but if you do, you'll be able to select them from a list when deploying Windows Vista. Ideally, you would want to specify a command line for installing the application without user interaction, as you don't want anyone to have to wait around for that application installation to begin. Just to see what this looks like, try adding a single application now by choosing the New command on the Applications node in Deployment Workbench, then complete the New Application Wizard (see Figure 2).
Figure 2 Adding an application to the workbench
Figure 2 Adding an application to the workbench
Next up are OS packages. There are three types of packages that you are likely to be interested in: language packs, security updates, and Windows Vista components.
Language packs enable Windows Vista to operate in many different languages. For details on the supported languages, see microsoft.com/globaldev/vista/Vista_Language_Support.mspx. The language packs, which are packaged as CAB files, can be downloaded from licensing.microsoft.com for all Software Assurance customers, and are available from Windows Update if you are running Windows Vista Ultimate. (Note that only Windows Vista Enterprise and Windows Vista Ultimate support multiple language packs installed on a computer.)
Windows Vista security updates are typically released monthly and are available for download through microsoft.com/technet/security/bulletinsandadvisories as individual MSU files.
You can also include new Windows Vista components, such as Windows PowerShell™. These components are available for download from the Microsoft Download Center (microsoft.com/downloads), and are also packaged as MSU files.
Behind the scenes, all of these are actual- ly components—also called packages, hence the OS Packages node. These components can all be injected into Windows Vista either online (while the OS is running) or offline (when it isn't). In the case of BDD 2007, you always inject them offline, after the Windows Vista image has been expanded and placed on the disk, but before it boots for the first time.
There is one additional challenge: the MSU files are designed to be installed online, while Windows Vista is running, using the WUSA.EXE update installer. In this example, however, you'll want to install these updates offline. For that, you need the CAB files containing the actual components. Well, these MSU files are actually CAB files themselves, with the real component CAB file inside. You can extract these CAB files from the MSU files yourself using a command such as:
EXTRACT.EXE file.msu -F:*.CAB C:\
That would then give you the CAB file that you need to import. Note that Microsoft has released a patch for BDD 2007 that automatically does this extraction. Once installed, this manual step is no longer necessary; you can point BDD 2007 at the MSU files and it will take care of the rest. For more details on this patch, see support.microsoft.com/kb/937191.
To add these components into Deployment Workbench, right-click on the OS Packages node and choose New to start the New Package Wizard. Specify the path to a folder containing the packages that you want to add.
Lastly, you may need drivers for the computer hardware on which you would like to run Windows Vista. Find the drivers you need from the vendors' Web sites or from Microsoft Update, download them, and then extract them from whatever they were packaged as. That last step can be a little tricky, but the end result should be the raw driver files: the .inf, .sys, .dll, and related files needed for the driver itself.
When you have the driver files extracted, run the New Driver Wizard by right-clicking on the Drivers node and choosing New Deployment. Workbench will scan the directory structure looking for all .inf files, so don't worry about cleaning up the extracted directory structures.
As the drivers are imported, Deployment Workbench creates a catalog of all the driver details, including the platforms supported, manufacturer and version, and list of Plug and Play (PnP) IDs supported by the driver.

What is done with these drivers? Do I inject them into the operating system image I imported earlier?
BDD 2007 doesn't make any modifications to the imported OS image. Instead, the drivers are injected during the deployment process. The basic process goes like this:
  1. You run a utility (Microsoft.BDD.PnpEnum.exe) on the computer being deployed, identifying all the PnP IDs present on the computer.
  2. Look up each of those PnP IDs in the driver catalog. For each match found, copy the driver files needed to the computer.
  3. Instruct Windows Vista setup to inject the drivers into the OS after the image has been applied to the disk, but before Windows Vista starts for the first time. This order is essential since some of these drivers, such as mass storage drivers, may be needed for the operating system to start.

Am I ready to deploy yet?
There are just a few more steps before you can deploy. First, you need to define a build that associates an operating system in the distribution share with the settings that should be used and the sequence of tasks that need to be executed to perform the OS installation and configuration.
To create this build, right-click on the Builds node and choose New to start the New Build Wizard. Specify a build ID (a simple value of your choice with no spaces or special characters) along with a build name and description, both of which will be seen when performing the operating system deployment (see Figure 3). Then select the operating system you want to install, and specify some basic settings to use.
Figure 3 Specifying basic build information
Figure 3 Specifying basic build information

OK, now are we ready to deploy?
One more thing is needed: a deployment point. Simply put, this is a network share containing all the files that you've gathered so far, all the build details, and the Windows PE images that are used for the deployment process. Creating a deployment point works just like the other steps you've seen so far: right-click on the Deployment Points node and choose New. Select Lab or single-server deployment (see Figure 4) and accept the rest of the defaults.
Figure 4 Choosing the type of deployment point
Figure 4 Choosing the type of deployment point
After finishing the wizard, right-click on the new deployment point in the list pane and choose Update to generate the share and Windows PE images.
Remember the drivers that you added earlier? Those same drivers, at least the network and mass storage ones, are also needed by Windows PE, so this update process will automatically add the drivers to the Windows PE image.

Are we ready to deploy yet?
Yes! First, let's try a deployment to a new computer. Take the LiteTouchPE_x86.iso file from the \distribution\boot folder and burn it to CD-R using your favorite CD writer software, or use the cdburn.exe tool that you can download from Microsoft (go.microsoft.com/fwlink/?LinkID=77796). Boot a computer from the CD, which will start Windows PE and show the initial welcome wizard shown in Figure 5.
Figure 5 Ready to start a deployment
Figure 5 Ready to start a deployment
Choose Run the Deployment Wizard and click Next to start it. From there, you can choose the build that you defined, any applications that you added, and any language packs that were imported. You can also choose to join a domain, specify the name of the computer, and configure various other settings. You can even specify that you want to automatically capture a new custom image (using Sysprep, Windows PE, and ImageX to create a new image file).
The deployment may take a while (depending on the speed and type of computer), but will not require any user interaction. When the deployment wizard is completed, a summary screen will be displayed to let you know about any warnings or errors logged during the process. This enables you to quickly verify that the deployment was successful—a yellow or red summary screen means more attention is needed, while white indicates everything was OK.
Now try a machine that is already running Windows XP. From a command prompt, map a drive to the Distribution$ share you created on your BDD 2007 server, then run LiteTouch.vbs to begin deployment:
NET USE M: \\MyServer\Distribution$
cscript.exe M:\Scripts\LiteTouch.vbs
This will start the same deployment wizard that you saw before, except now there will be some new choices (see Figure 6).
Figure 6 Choices for a computer running Windows XP
Figure 6 Choices for a computer running Windows XP
If you choose Refresh this computer, the existing OS will be removed (after optionally capturing the user data and settings using the User State Migration Tool, which would need to be downloaded using the Components node as was done earlier with Windows AIK), and a fresh installation of Windows Vista would be performed. You could also choose Upgrade this computer, which lets Windows Vista setup take care of upgrading the existing OS, preserving the existing apps, data, and settings on the computer. The option you choose depends on a variety of factors, although most will choose to perform a refresh in order to start with a clean, known state.

So that's everything I need to know?
What about Windows XP?
What if you are still deploying Windows XP? Don't worry, you can still use BDD 2007 to help with that process. The same steps apply; just use Windows XP installation files to create the initial build, capture a new Windows XP Windows Imaging (WIM) image—deploying a Windows XP image is much faster than performing an unattended install—then use that WIM file for your subsequent deployments.
Keep in mind that, compared to Windows Vista deployments, there are a few extra complications when deploying Windows XP:
Windows XP mass storage drivers require extra configuration, such as TEXTMODE folders, unattend.txt settings, and sysprep.inf settings. Of course, because mass storage drivers can't be injected into existing Windows XP images, you need to capture a new image each time you need to add an additional mass storage driver. Also, Windows XP images are not HAL-independent, so you may need to have two or three separate images. Finally, language packs and security updates can't be injected off-line into Windows XP, so they need to be installed after Windows XP is up and running.
If you use BDD 2007 for your Windows XP deployment, you'll already be fully prepared for Windows Vista once you decide the time is right.

No, that's just scratching the surface. But seeing the process working end-to-end lets you view how all the new tools work together without requiring that you learn each one. Now you can dig into the BDD 2007 scripts and logs to see what was performed. You can build your own custom images and add them into BDD 2007 to deploy instead of the standard Windows Vista image. You can create DVD media or USB flash drives with your image loaded on them. You can integrate SMS 2003 and its OS Deployment Feature Pack into the process.

Where can I find more information?
Review all of those documents that I skipped over earlier—there are well over a thousand pages available, divided up between the different teams typically involved in a deployment project. Also check out the microsoft.com/desktopdeployment site mentioned previously. Use the microsoft.public.deployment.desktop newsgroup where IT pros like yourself ask all sorts of Windows deployment questions. Check out third-party Web sites like deployvista.com and myitforum.com, where there is a wealth of information about BDD 2007 and Windows Vista deployment. Check out the new Windows Vista Resource Kit book (microsoft.com/mspress/books/9536.aspx) available from Microsoft Press. Read my blog at blogs.technet.com/mniehaus for discussions on various parts of BDD 2007. Talk to your local Microsoft representatives about BDD 2007 and Windows Vista training seminars that are available in your area. Finally, see the "Deployment Resources" sidebar for additional information.
And if you have Software Assurance for the Microsoft Office System, be sure to take advantage of the Desktop Deployment Planning Services (microsoft.com/licensing/sa/benefits/deployment.mspx) to have Microsoft or a Microsoft partner spend a few days working with you to come up with a plan, and even to work on a proof-of-concept lab at your own site.
Deployment Resources
  • Microsoft Desktop Deployment Center microsoft.com/desktopdeployment
  • 10 Things You Need to Know about Deploying Windows Vista technetmagazine.com/issues/2006/11/Deployment
  • Microsoft .NET Framework 2.0 go.microsoft.com/fwlink/?LinkId=94601
  • Microsoft Management Console (MMC) 3.0 for Windows Server 2003 x86 go.microsoft.com/fwlink/?LinkId=94602
  • Security Bulletins and Advisories microsoft.com/technet/security/bulletinsandadvisories

Michael Niehaus is a Systems Design Engineer in the Solution Accelerators team 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: A Guide to Windows Vista Backup Technologies
Windows Vista Christine Fok

A Guide to Windows Vista Backup Technologies
At a Glance:
  • File Backup and Restore
  • Windows Complete PC Backup and Restore
  • System Restore
  • Shadow Copy

Too many people don't think about backing up their data until it's too late and the data has already been lost. This shouldn't ever be the case, but, unfortunately, it is. Windows Vista aims to make backing up easier, with a full range of features to seamlessly protect your data. The familiar
System Restore has been redesigned to be more robust and to support more system repair scenarios. File Backup has been improved to make data protection simpler and more thorough, and two new features, Windows® Complete PC Backup and Restore and Shadow Copy, have been added.
All of these features rely on Volume Shadow Copy Service in one way or another. This is a service that creates point-in-time copies (referred to as "shadow copies") of a volume and keeps track of changes made between shadow copies.
While these four features, all of which are available from the new Backup and Restore Center (see Figure 1), all allow you to back up and restore data, each is very different. But together they provide broad protection against various forms of data loss throughout the lifetime of your computer.
Figure 1 Backup and Restore Center in Windows Vista
Figure 1 Backup and Restore Center in Windows Vista

File Backup
Scheduling Complete PC Backup
Scheduling a regular Complete PC Backup is one way to ensure you have recent images of your entire computer. Complete PC Backup is not schedulable through the control panel, but you can work around this by creating a new task in the Task Scheduler. If you choose to schedule Complete PC Backups, I advise periodic monitoring to verify that backups completed successfully. Why is this necessary? Because this method doesn't notify you via a pop-up if the backups fail due to disk space issues or other transient problems. This should not be considered a replacement for using File Backup on a regular basis. That said, here's how you can use Task Scheduler to schedule Complete PC Backup:
  1. Go to Task Scheduler (which you'll find in the Accessories\System Tools folder in the All Programs portion of your Start menu).
  2. Click Create Task.
  3. Go to the General tab.
  4. Type a descriptive name, such as Scheduled Complete PC Backup.
  5. If you want the task to run regardless of whether you're logged on, click Run whether user is logged on or not.
  6. Click Run with highest privileges.
  7. Go to the Triggers page.
  8. Click New and then specify when and how often the scheduled backup will take place.
  9. Go to the Actions page.
  10. Click New.
  11. Under Program/Script, type wbadmin.
  12. In Add arguments (optional), type the following command, adjusting the target drive letter as necessary:
    Start backup –allcritical –backupTarget:D: -quiet
    If you want to include additional volumes that are not the system, boot, or Windows Recovery Environment volumes, use the following statement instead, substituting the appropriate drive letters (separated by commas) for E and F:
    Start backup –allcritical –backupTarget:D: -include:E:,F: -quiet
    Note that the command should always include the allcritical flag. Not having this flag risks excluding important system volumes from the backup, which would lead to failure during restore.
  13. Configure any other task-related settings.
  14. Click OK.

Suppose I buy a new laptop. After copying various files—photos, Microsoft® Word documents, and so on—to my system, installing applications, and downloading the latest Windows updates, I decide to do a file backup. So I connect an external hard drive to the laptop and go to the Backup and Restore Center. When I click the Back up files button, I am presented with a wizard that guides me through the setup. It asks me for the backup target (in this case, the external hard drive), categories of files to back up (such as Pictures), and when to perform the backup.
File Backup uses a category-based approach for specifying what files to back up. While the source must be NTFS, the target hard drive can be either NTFS or FAT formatted. The determination of whether a file is associated with a particular category is based on three factors: MIME type, application association, and file extension.
If you want to back up files that do not fit into any other categories, choose the Additional files category. This includes files with extensions that are not recognized by Windows. It does not, however, support executable and system files. Such files are not backed up by this feature because they rarely represent user data. If you really do want to back up system and executable files using this mechanism, you can place them into a .zip file and select the Compressed files category in the wizard.
As this is my first time using the backup features on my new laptop, a full backup—which is a complete backup of all the files from the selected categories—is performed right away. Thereafter, only incremental backups are performed. The term incremental in the context of File Backup refers to keeping track of new or updated files only. For example, if you have an old Word document and then make some changes to it, the File Backup tool would keep complete copies of both the old and updated document. (The collection of a single full backup and the sequence of incremental backups created thereafter are referred to as a backup set.)
Rather than performing incremental backups indefinitely, you should occasionally perform full backups. Prompts to do so are based on factors such as how long since your last full backup, how many files you are backing up, how many CDs or DVDs you have backed up to, and so on. This is to ensure that a full, baseline backup is always available.
Data being backed up is stored as .zip files (with a maximum size of 200MB each). This makes the data more universally accessible. For example, you can restore the data to a machine that is not running Windows Vista by browsing directly through the backup media. The backup data is stored in separate files and can span multiple discs. If one disc was to fail, backup data on the other media is still accessible.
In File Backup, Volume Shadow Copy Service is used to create consistent copies of files that are open or in use by applications. During the backup process, the backup app reads from these consistent copies. This is handy, for example, when backing up a .pst file that is constantly opened by Microsoft Outlook®. Volume Shadow Copy Service ensures the backed-up .pst file is in a consistent state so that it can be accessed upon restore.
File backups aren't deleted automatically. However, you can delete file backups manually if you're low on space. A word of advice: you should always delete an entire backup set as opposed to deleting individual incremental backups.
As an aside, I should point out that you should avoid copying a file backup to a different location. If you must do so, keep in mind that this will only work if you move a single original backup media to another single destination media. For example, you can copy backup data from one CD to one DVD, but you cannot copy backup data from multiple CDs to one DVD. When you move a backup, you must copy the backup folder with your computer's name and the mediaid.bin file, both of which are located in the root of the backup media. Note that if you want to restore a file that has been moved, you must select Advanced restore | Restore files from a backup made on a different computer from the backup control panel to reach those files, since the backup catalog on the computer will not know of this new backup location.

Complete PC Backup
With my new laptop all set up and configured, I want to do a complete backup, protecting everything including the OS, the apps I've installed, configuration settings, and updates. I use the Complete PC Backup feature, which can then be used to recover my machine in case of a hard drive failure or other disaster. I wouldn't have to reinstall all the apps individually and redo all of my configuration settings. On first run, this feature performs a full backup of all blocks across the volumes I've selected, minus any blocks that do not have information stored. Subsequent backups are differential at the block level (more details about this in a moment).
After performing the backups, the control panel of the Backup and Restore Center is updated (see Figure 2). It now provides such information as when the backup was performed and where it was stored.
Figure 2 Backup and Restore Center provides details about previous backups
Figure 2 Backup and Restore Center provides details about previous backups
While both perform backups, Complete PC Backup works totally differently from File Backup. Complete PC Backup creates a block level image backup of the entire computer in a virtual hard drive (.vhd) format. During the first full backup, the engine scans the source disk and copies blocks that contain data into a .vhd file stored on the destination disk. Although the backed-up data is not compressed, it is compact.
The next time a Complete PC Backup is performed, only new and changed data is written to the .vhd file, and old data on the same block is moved to the shadow copy storage area. Volume Shadow Copy Service is used to compute the differences between snapshots taken as well as to handle the process of moving the old data out to the shadow copy area on the destination disk (see Figure 3). This approach makes the backup fast (since only changed blocks are backed up) and efficient (since data is stored in a compact manner). Note that the backup application defines the maximum amount of shadow copy storage space available on the destination disk. For a step-by-step procedure on using the Complete PC Backup system regularly or automatically, see the sidebar "Scheduling Complete PC Backup."
Figure 3 How data moves in a Complete PC Backup and Restore
Figure 3 How data moves in a Complete PC Backup and Restore
When restoring data, blocks are restored to their original location. If you want to restore from an older backup, the engine reads from the shadow copy area and restores the appropriate blocks.
Note that Complete PC Backup can only back up NTFS-formatted disks. If the backup destination is a hard drive, it too needs to be NTFS-formatted.

System Restore
System Restore is enabled by default. I access the System Restore wizard by choosing Repair Windows using System Restore, available on the upper-left part of the Backup and Restore Center (it can also be accessed in the Accessories\System Tools folder in the All Programs portion of your Start menu). If I select "choose a different restore point" and click Next, I can see that restore points have already been created at various points while I was setting up my laptop, installing applications, and performing backups.
Restore points are turned on by default only on the boot volume, even on a system where the hard disk has multiple volumes. Restore points are automatically created during application and driver installations and daily across the selected volumes (if a restore point has not already been taken on that day). Restore points can also be created manually by choosing the System Protection option in the System control panel applet. Shadow copies created during File Backup and Complete PC Backup can also be used as restore points.
In Windows XP, System Restore uses a file system filter to keep track of system file changes. In Windows Vista, System Restore uses Volume Shadow Copy Service to keep track of block-level changes over the selected volumes. This makes System Restore more robust and allows it to support a broader range of repair scenarios.
Also new, System Restore can now run while your regular Windows installation is offline. This is done using Windows Recovery Environment, allowing you to repair your system even if Windows is unbootable.

Shadow Copy
Shadow Copy is nearly invisible. It is enabled by default and requires no input on the user's part. If a user ever needs to restore a file, that's when she is likely to first take notice of this feature. It essentially exposes the point-in-time copies of files that are created by Volume Shadow Copy Service.

Shadow Copy Space Management
There are storage spaces set aside for shadow copies both on the live volumes and on the backup disk for Complete PC Backup. You can check the used, allocated, and maximum shadow copy storage space values by running the following command from an elevated command prompt:
VSSAdmin list ShadowStorage
Used indicates how much space is currently taken up by shadow copies; allocated indicates the amount of space reserved for shadow copies (and so cannot be used for other purposes); maximum is the size limit that shadow copies are guaranteed to stay under.
Space allocation for shadow copies is automatic, meaning it cannot be set by the user. New space is allocated in fixed increments whenever the space previously allocated is used up. This is why the value shown for used space is always less than the value you see for allocated space.
For the live volume, the maximum shadow storage space allowed is determined when the first shadow copy is created—typically when System Restore is first enabled and a restore point is created during setup. The value is set to 30 percent of free space or 15 percent of the overall size of the volume—whichever is less. This maximum size is static. It will not change when more or less free space is available, nor will it change after the size of the volume has been adjusted.
However, you actually can manually adjust the size of this storage area by using the VSSAdmin tool from an elevated command prompt. For example, the command to increase the maximum storage size to 15GB on C:\ would be:
VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB
This tool originated on Windows Server®, where shadow copies for a particular volume could be maintained on another volume. In Windows Vista, shadow copies for a volume are kept on the same volume. Hence, the "for" and "on" volume has to be the same.
The backup destination disk for Complete PC Backup, on the other hand, has a fixed maximum shadow copy storage size of 30 percent of the disk space. This value is controlled by Complete PC Backup and cannot be changed manually. This shadow copy storage space is used for storing incrementals for Complete PC Backup.
Up to 64 shadow copies can be kept on a volume at any one time, provided there is enough space in the shadow copies storage area. Once the maximum space limit is reached, older shadow copies are deleted to make room for the new ones. Therefore, old restore points for System Restore are deleted when the shadow storage limit on the live volume is reached and old Complete PC Backups are deleted when the limit is reached on the backup disk. In addition, storing and editing other data on the backup disk may interfere with the normal process of aging old backups, causing old backups to be deleted at an accelerated rate.

Restore a File with Shadow Copy
Now, imagine I've had my laptop for a while and I've been using it to create some presentations. I've finished the presentations and passed them along to my clients. A month has passed, I'm onto new projects, and I've since deleted these files. Then my manager asks me for a copy of the old presentations. This is where Shadow Copy really comes in handy.
There are two ways to look for copies of deleted files. First, if I know where the file had been stored, I can simply right-click the folder that contained the deleted file and select "Restore previous versions." From there, I choose a date that contains the desired version of the deleted file (see Figure 4), click open, and then copy the target file to another location on the live volume. This copy operation is as fast as a regular file copy.
Figure 4 Restoring a file that was deleted
Figure 4 Restoring a file that was deleted
If I have forgotten where the file was stored, I can open up the previous version of the closest parent folder in the file tree and do a search from there. For example, if I have forgotten the specific folder but do know it was in some subfolder located within Documents, I can search the previous version of Documents by typing the file name (full or partial) in the search box located at the top right-hand corner of the Windows Explorer window, as shown in Figure 5. Note that the search functionality for shadow copies does not work at the root folder. And since shadow copies are not indexed, the search time can be longer than searching on a live volume.
Figure 5 Searching for the previous version of a document by typing a partial file name
Figure 5 Searching for the previous version of a document by typing a partial file name

Restore a File from a File Backup
Shadow copies are not available forever since they get pruned from time to time to manage the available space. If I need a file that is no longer available using this method, I can resort to my scheduled file backups. I simply select Restore files from the Backup and Restore Center, and choose a backup date that contains the deleted presentation. When I click the Add files button, I get an open file dialog that lets me navigate through the backup. After I select the file I'm looking for, I am given the option to restore the file to the same or a different location.
It's worth noting that the Restore files option only shows backups contained in the latest backup set. To view backups from an older backup set, select Advanced restore and then the Files from an older backup made on this computer option. On the rare occasion that you can't find an old backup set using that option, select Advanced restore and then the Restore files from a backup made on a different computer option. This can happen because the computer backup catalog is trimmed when it gets too big.

Restore a File from Complete PC Backup
I should mention, for thoroughness, that a Complete PC Backup can be used to restore individual files. While intended for restoration at the volume level, Complete PC Backup stores data in a .vhd format, and this means you can use the offline VHD mounting tool to access and restore individual files. (At the time of writing this article, the VHD mounting tool is only available as part of Microsoft Virtual Server 2005 R2 SP1, which you can download from microsoft.com/technet/prodtechnol/eval/virtualserver.) To mount the backup, open a command prompt with elevated privileges and navigate to Microsoft Virtual Server\Vhdmount. The command is:
vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]
When doing this for the first time, the system may not pick up the required driver since it is unsigned. This will cause an error message that says the device driver could not be loaded. To solve this problem, after plugging in the .vhd file using the command above, go to the Device Manager, right-click on the new device that shows up, and select Properties. From there, go to the Driver tab, select Update Driver, click Browse my computer for driver software, and select Let me pick from a list of device drivers on my computer. The correct driver file will be located at Microsoft Virtual Server\Vhdmount\vhdstor.inf. After installation, the new drive will appear and you'll be able to browse the latest Complete PC Backup and copy the files you want to an alternate location.

Complete PC Restore
Now imagine that one sunny afternoon, I decide to use my laptop while sitting by the pool. I slip on some wet tiles and my laptop dives into the pool. It's beyond repair and I have no choice but to buy a new one. Since I used the Complete PC Backup tool, I can restore my system to the new laptop—I don't have to spend a lot of time manually reinstalling each application and reconfiguring them with my personal settings. Performing a Complete PC Restore is straightforward. At startup, I use the Windows Vista installation disk to boot into the Windows Recovery Environment. Here, I am prompted to attach the device that contains the system image. I choose the appropriate image, and then the restore process begins.
After the restore is finished, I perform a file restore from my latest file backup. This is because I do file backups more frequently so the data contained in my file backup is more current. Since the computer is reverted to a time prior to the chosen file backup, it does not contain a record of this backup in the catalog. Therefore, I select Advanced restore | Restore files from a backup made on a different computer | Restore everything from this backup. I also start a new full backup to protect my newly restored data.
Windows Recovery Environment is often installed by the OEM on the hard drive as a hidden partition. This can be used for restoring a Complete PC Backup image to the same hardware. But if you need to restore an image created from one computer to another, you need to run Windows Recovery Environment from external media, such as your Windows installation disk.
There are some caveats worth considering. Complete PC Restore works simply when restoring to the same hardware the backup was taken from. (Provided, of course, that hardware failure wasn't part of your problem.)
Since Complete PC Backup includes an image of the entire computer, some restrictions apply when restoring to different hardware. First, the backup image contains drivers that are used to boot to the machine after the restore completes. In rare cases, the drivers needed to boot on the new machine might not be present. This might happen when restoring an image backup taken on one type of disk controller (IDE, SATA, or SCSI) to another type of disk controller. Even in this case, there is still a good chance you can complete the restore successfully, because the common Windows drivers included in the image backup would likely be compatible.
Second, the restore can only be performed if the new computer has at least the same number of hard drives and each hard drive is at least as big as the original it replaced. Keep these restrictions in mind if you intend to use Complete PC Backup for migrating to new hardware.
Since backup and restore are performed at the block level for entire volumes, Complete PC Restore requires a volume to be either fully restored or skipped. Therefore, you might want to create multiple volumes for backup (for instance, partitioning the system files from the data files). Then when restoring, you can choose whether to restore only the system volume (identified as critical) or all volumes.

Putting These Features into Practice
Windows Vista has made significant improvements over Windows XP in protecting your data and system by introducing new backup technologies and improving existing options. The four main backup features—File Backup and Restore, Windows Complete PC Backup and Restore, System Restore, and Shadow Copy—deliver different yet complementary capabilities, casting a broad net of data protection. It's important to understand how these features work together, to make sure your system is configured to utilize all four methods, and to apply the appropriate protection and remedy according to the situation.
As a rule of thumb, always try Shadow Copy restore first in a data loss situation since this method is likely to have the most up-to-date copy of your data. For system instability and repair, use System Restore. Complete PC Restore should generally be used as a last resort for a full system repair, and it should be used with caution. Nonetheless, Complete PC Repair can be a real lifesaver. Most importantly, take action before it is too late: backup now!
I would like to thank Eduardo Laureano, Ivan Pashov, Jill Zoeller, and all the members of the backup and restore product team for their assistance with this article.

Christine Fok is a Program Manager in the Storage Solution Division of Microsoft. She focuses on backup and restore experiences in the Windows client platform.


 Windows Server: 11 Essential Tools for Managing Active Directory
Windows Server Laura E. Hunter

11 Essential Tools for Managing Active Directory
At a Glance:
  • Creating objects at the command line
  • Performing bulk operations within Active Directory
  • Active Directory updates and maintenance

If you've ever been handed an Excel spreadsheet listing 200 new employees starting next week, or if your user accounts are configured incorrectly because help desk staff clicked something
they shouldn't have, or if you just want an easier way to manage Active Directory® besides opening Users and Computers every time, there are a number of free administration tools that can help. Some are built right into the Windows® OS, some come in a Resource Kit or the Windows Support Tools, and some are free third-party tools. What are these handy tools and where can you get them? Let's find out.
I'll start with the built-in command-line tools in Windows Server® 2003 that allow you to create, delete, modify, and search for objects in Active Directory.

CSVDE
The Comma-Separated Values Data Exchange tool, known as CSVDE, allows you to import new objects into Active Directory using a CSV source file; it also provides you with the ability to export existing objects to a CSV file. CSVDE can't be used to modify existing objects; when you are using this tool in import mode you can only create brand-new objects.
Exporting a list of existing objects with CSVDE is fairly simple. Here's how you'd export your Active Directory objects to a file called ad.csv:
csvde –f ad.csv
The –f switch indicates that the name of the output file follows. But you must be aware of the fact that, depending on your environment, this basic syntax could result in a huge and unwieldy output file. To restrict the tool to export objects only within a particular organizational unit (OU), you could modify the statement as follows:
csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com
Let's further say that you're only interested in exporting user objects into your CSV file. In that case, you can add the –r switch, which allows you to specify a Lightweight Directory Access Protocol (LDAP) filter for the search, and the –l switch, which restricts the number of attributes that are exported (note that the following is all on one line):
csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
    "(&(objectcategory=person)(objectclass=user))" –l
    DN,objectClass,description
The –i switch allows you to import objects into Active Directory from a source CSV file. However, creating user objects with CSVDE has one critical limitation: you can't set user passwords with it. Because of this, I'd avoid using CSVDE to create user objects.

LDIFDE
Active Directory provides a second built-in tool for bulk user operations, called LDIFDE, and it is more powerful and flexible than CSVDE. In addition to creating new objects, LDIFDE can also modify and delete existing objects and even extend the Active Directory schema. The trade-off for LDIFDE's flexibility is that the necessary input file, which is referred to as an LDIF file with the extension .ldf, uses a more complex format than the simple CSV file. (With a little work you can also configure user passwords, but I'll get to that in a moment.)
Let's start with a simple example, exporting users in an OU to an LDF file (note that the following is all on one line):
ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
       –r "(&(objectcategory=person)(objectclass=user))"
As with most command-line tools, you can find a full explanation of the LDIFDE switches by running the LDIFDE /? command. Figure 1 describes the ones I've used here. (Note that the switches are actually the same for both the CSVDE and LDIFDE commands.)
Figure 1 LDIFDE switches (Close Figure 1)

Switch | Description
-d | Specifies LDAP path that LDIFDE should connect to for the operation.
-f | Indicates the name of the file to be used, in this case to output the results of the export.
-r | Specifies the LDAP filter to use for an export.
-s | Specifies the domain controller (DC) to connect to that will perform the operation; if you leave this out, LDIFDE will connect to the local DC (or the DC that authenticated you if you are running the tool from a workstation).
The real power of LDIFDE is in creating and manipulating objects. Before doing this, however, you first need to create an input file. The following creates two new user accounts called afuller and rking; to create the input file, enter the text in Notepad (or your favorite plain-text editor) and save it as NewUsers.ldf:
dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking
Once you've finished creating the file, run the following command:
ldifde –i –f NewUsers.ldf –s DC1.contoso.com
The only new switch here is -i, which, you can probably guess for yourself, denotes that this is an import operation instead of an export.
When modifying or deleting existing objects, the syntax for the LDIFDE command doesn't change; instead, you modify the contents of the LDF file. To change the description field of the user accounts, create a text file called ModifyUsers.ldf, such as the one shown in Figure 2.
Figure 2 The ModifyUsers LDF file
Figure 2 The ModifyUsers LDF file
You import the changes by running the same LDIFDE command syntax as before, specifying the new LDF file name after the -f switch. The LDF format for deleting objects is even simpler; to delete the users you've been working with, create a file called DeleteUsers.ldf and enter the following:
dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete
Note that unlike CSVDE, LDIFDE is capable of configuring user passwords. Before you can configure the unicodePWD attribute for a user account, however, you must configure secure sockets layer/transport layer security (SSL/TLS) encryption on your domain controllers.
Moreover, LDIFDE can create and modify any type of Active Directory object, not just user accounts. The following LDF file, for example, will create a custom schema extension called EmployeeID-example in the schema of the contoso.com forest:
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example
Because LDIFDE files use the industry-standard LDAP file format, third-party applications that need to modify the Active Directory schema will often supply LDF files you can use to examine and approve the changes before applying them to your production environment.
In addition to tools for bulk import and export operations, Windows Server 2003 also includes a built-in toolset that lets you create, delete, and modify various Active Directory objects as well as perform queries for objects that meet certain criteria. (Note that these tools, dsadd, dsrm, dsget, and dsquery, are not supported under Windows 2000 Active Directory.)

Dsadd
Dsadd is used to create an instance of an Active Directory object class on a particular directory partition. These classes include users, computers, contacts, groups, organizational units, and quotas. Dsadd has a generic syntax that consists of the following:
dsadd <ObjectType> <ObjectDistinguishedName> attributes
Note that each object type you create takes a specific set of switches corresponding to the attributes available for that type. This command creates a single user object with various attributes populated (note that the following is all on one line):
dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
The –memberOf switch requires the full distinguished name (DN) of each group the user should be added to; if you want to add the user to multiple groups you can add multiple DNs separated by spaces.
If any element contains a space, such as the DN of the Help Desk group, it needs to be enclosed in double quotes. If an element contains a backslash, like an OU called IT\EMEA, the backslash must be entered twice: IT\\EMEA. (These requirements apply to all of the ds* tools.)
When you use the -pwd * switch, you'll be prompted to enter a password for the user at the command line. You can specify the password within the command itself (-pwd P@ssword1), but this will display the password in plain text on the screen or in any text or script file that you've embedded the command into.
Similarly, you can create a group object and an OU using the following two commands:
dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod
Dsmod is used to modify an existing object, and you work with it much as with dsadd, using different submenus and syntax depending on the type of object you're modifying. The following dsmod statement changes a user's password and modifies his account so he will be prompted to change to a new password on next logon:
dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
To see how similar these switches are, look at the dsadd syntax you would use to create this user with the same attributes configured:
dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
As you can clearly see, if you know the switches to create objects in dsadd, you can use those same switches to modify users with dsmod.

Dsrm
The converse of dsadd is dsrm; as you might imagine, this tool lets you delete an object from the command line. The basic dsrm syntax is pretty straightforward: simply enter dsrm followed by the distinguished name of the object you want to delete, like so:
dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com
By default, dsrm will prompt "Are you sure you want to delete this object?" Type Y, then press Enter. You can suppress this prompt using the –noprompt switch, but, obviously, you then get no chance to confirm that you've selected the correct object before deleting it. Two additional switches can be helpful if you are deleting a container object, that is, an organizational unit that could potentially contain other objects within it. The following command deletes the TrainingOU organizational unit and all objects contained within it:
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
This one deletes all child objects contained within TrainingOU but leaves the organizational unit object itself in place:
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
    –exclude

Dsmove
To move or rename an object in Active Directory, you use the dsmove tool, but note that you should use it to move an object only within a single domain. To migrate objects between domains or forests, use the Active Directory Migration Tool (ADMT), a free download from the Microsoft Web site. Dsmove relies on two switches that can be used separately or in combination. This command gives Steve Conn's account a new last name:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
    –newname "Steve Conn"
This command moves Steve's account from the IT OU to the Training OU:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
    ou=Training,dc=contoso,dc=com
You can combine a rename and a move into a single operation by specifying both switches at once, like this:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
    "Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget and Dsquery
The ds* command-line toolset also includes two tools used to query Active Directory for information rather than for creating or modifying objects.
Dsget takes an object's DN as input and provides you with the value of the attribute or attributes you specify. Dsget uses the same submenus as dsadd and dsmod—user, computer, contact, group, ou, and quota.
To obtain the SAM Account Name and Security Identifier (SID) of a user account, enter the following command (note that the following is all on one line):
dsget user cn=afuller,ou=IT,dc=contoso,dc=com
    –samAccountName –sid
You'll get output such as that in Figure 3.
Figure 3 Running dsget
Figure 3 Running dsget
Dsquery returns a list of Active Directory objects that meet criteria you specify. You can specify the following parameters no matter which submenu you're using:
dsquery <ObjectType> <StartNode> -s <Search Scope> -o <OutputFormat>
For ObjectType, dsquery can use the following submenus, each of which has its own syntax: computer, contact, subnet, group, ou, site, server (note that the server submenu retrieves information about domain controllers, not any member servers in your environment), user, quota, and partition. And if one of these query types doesn't fit the bill, you can use the * submenu, which lets you enter a free-form LDAP query.
StartNode specifies the location in the Active Directory tree where the search will start. You can use a specific DN such as ou=IT,dc=contoso,dc=com, or one of the following shortcut specifiers: domainroot, which begins at the root of a particular domain, or forestroot, which begins at the root of the forest root domain using a Global Catalog server to perform the search.
Finally, the Search Scope option specifies how dsquery should search the Active Directory tree. Subtree (the default) queries the specified StartNode and all of its child objects, onelevel queries only the immediate children of the StartNode, and base queries the StartNode object only.
To better understand search scopes, consider an OU that contains both user objects and a child OU that itself contains additional objects. Using the subtree scope will query the OU, all of the user objects contained within it, and the child OU and its contents. The onelevel scope will query only the users contained within the OU and will not query the child OU or its contents. A base query will search only the OU itself without querying any of the objects contained within it.
Finally, you can use Output Format to control how the results of dsquery are formatted. By default, dsquery returns the distinguished names of any objects that match the query, like this:
"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com"
To query for all user objects contained within the IT OU and any child OUs, use the following:
dsquery user ou=IT,dc=contoso,dc=com
You can further refine this query by adding additional switches such as -disabled, which returns only disabled user accounts; -inactive x, which returns only users who haven't logged on in the past x weeks or more; or -stalepwd x, which will return only users who have not changed their passwords in x days or more.
Depending on the number of objects in your directory, you may need to specify the -limit x switch when running your query. By default, dsquery will return up to 100 objects that match the specifics of your query; you can specify a larger number such as -limit 500, or use -limit 0 to instruct dsquery to return all matching objects.
You can use the other submenus to perform useful queries for other object types as well. Consider the following query, which returns every subnet defined in Active Directory Sites and Services that's in the 10.1.x.x address space:
dsquery subnet –name 10.1.*
Or use the following to return every subnet located in the Corp site:
dsquery subnet –site Corp
With another submenu, you can quickly determine how many domain controllers in your forest are configured as Global Catalog servers:
dsquery server –forest –isgc
You can also use this syntax to help you determine which domain controller in your domain hosts the Primary Domain Controller (PDC) Emulator Flexible Single Master Operations (FSMO) role:
dsquery server –hasfsmo pdc
As with the other ds* commands that include submenus, you can view all of the switches available within a particular dsquery submenu by going to the command prompt and typing dsquery user /?, dsquery computer /?, dsquery subnet /?, and so forth.
An additional slick trick is to pipe the output of dsquery into another tool such as dsmod using the | character (shift-backslash on U.S. keyboards). For example, let's say your company has renamed a department from Training to Internal Development and now you have to update the description field of each relevant user from the old department name to the new. On a single command line, you can query for user objects that have a description field of Training and then modify that description field in bulk, as follows:
dsquery user –description "Training" | dsmod
    -description "Internal Development"

Some Third-Party Gems
Because Active Directory is based on LDAP standards, you can query and modify it using any tool that can speak LDAP. Many third-party vendors have released fee-based tools to assist you in administering Active Directory, but sometimes you find a treasure that has been made available to the community at no charge. Such is the case with a collection created by Directory Services MVP Joe Richards, available for download from joeware.net/freetools. There you'll find numerous tools to serve many different functions. Three that I turn to again and again are adfind, admod, and oldcmp.

Adfind and Admod
Adfind and admod are similar to dsquery and dsmod; adfind is a command-line query tool for Active Directory, and admod can create, delete, or modify one or more Active Directory objects.
Unlike the ds* tools that have multiple submenus and different switches depending on the type of object, adfind and admod have a consistent syntax regardless of the type of query or modification you're trying to perform. The basic syntax for adfind is:
adfind –b <Search Base> -s <Search Scope> -f <Search Filter>
    attributesDesired
So a query for the DN and description of all computer objects within your domain would be:
adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
    description
A query for all user objects would look like this:
adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
    (objectclass=user))" dn description
Notice that except for the contents of the LDAP query, the syntax has not changed.
As you work with adfind, you'll find a number of shortcut operators that can save you a lot of typing. For example, the -default switch can replace -b dc=contoso,dc=com in the previous example and search your entire domain; -gc searches against a global catalog (GC) and returns all users in your Active Directory forest. You can also use the -rb switch to set a relative base for your search; if you want to search the Training OU in the phl.east.us.contoso.com domain, you can save yourself quite a bit of effort by simply specifying –default –rb ou=Training rather than –b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com.
Adfind can also perform a number of advanced search functions that can't be easily managed at the command line otherwise, including those shown in Figure 4.
Figure 4 Adfind switches (Close Figure 4)

Switch | Description
-showdel | Queries the Deleted Objects container for tombstone objects.
-bit | Queries against bitwise operators such as the userAccountControl attribute.
-asq | Performs an attribute-scoped query. This function (which can't be replicated in dsquery) can retrieve an attribute of a particular object and then perform a query against it.
-dsq | Pipes the output of an adfind query into dsmod or one of the other ds* tools.
An example using the –asq switch would be "Show me the group memberships of the members of the HelpDesk," like this:
adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf
Admod, as its name suggests, is used to modify objects within Active Directory. As with adfind, there are no specialized submenus with particular syntaxes to remember; admod uses the same syntax regardless of the type of object you're working with. You can also use admod to add, move, rename, delete, and even undelete objects simply by adding the appropriate switch, such as -add, -rm, -move, -undel. And just as with dsquery and dsmod, you can also use the | character to pipe the results of an adfind query into admod.
Note that performing an undelete with admod simply performs a tombstone reanimation operation, in which most of the objects attributes have been removed. To fully restore an object and all of its attributes, you'll still need to perform an authoritative restore of the object.

Oldcmp
There's one additional joeware tool I consider an indispensable part of my automation toolkit: oldcmp, which scans your Active Directory database for computer accounts that have not been used in a specified number of weeks and can do the following:
  • Create a report of accounts without taking any action against them
  • Disable the unused computer accounts
  • Move the computer accounts to a different OU that you designate
  • Delete the computer accounts outright
Note that because oldcmp has the potential to wreak serious havoc on your directory, it has a number of built-in safety features. It will not delete any account that has not already been disabled (and without manually specifying a "No really, I mean it!" command-line switch). It will not modify more than 10 objects at a time without a similar "No really, I mean it!" switch, and it absolutely will not do anything to the computer account for a domain controller.
Despite the now-misleading name of the tool, Joe has updated oldcmp so that it will perform similar functions for user accounts that have not been used for a certain amount of time as well.
For a small Active Directory environment or one where you're only working with one or two additions or changes at a time, the GUI tools such as Active Directory Users and Computers might be sufficient for day-to-day administration. But if you're adding and modifying large numbers of objects on a daily basis or simply want a more streamlined solution for your administrative tasks, moving to the command line can greatly speed up the process of creating, modifying, and deleting objects within Active Directory. As you've seen, there are a number of flexible and powerful tools available free of charge, both built right into Windows and downloadable from members of the Active Directory community. Any of these tools has the ability to greatly enhance your productivity as an Active Directory administrator, and together they become even more essential to your daily work life.

Laura E. Hunter is a four-time recipient of the Microsoft MVP award in the area of Windows Server Networking. She is the author of the Active Directory Cookbook, Second Edition (O'Reilly, 2006). A 10-year veteran of the IT industry, Laura currently works as the Active Directory architect for a global engineering firm. She holds multiple industry certifications and is a frequent speaker at user group meetings and industry conferences.


 Windows Server: Reanimating Active Directory Tombstone Objects
Windows Server Gil Kirkpatrick

Reanimating Active Directory Tombstone Objects
At a Glance:
  • How deleted objects are stored in Active Directory
  • Using LDP and ADRESTORE to find and restore tombstones
  • Object attributes and systemFlags

While it may not be your favorite topic to think about, accidental data loss is a fact of life and, as an IT professional, you have to be prepared for all sorts of recovery scenarios. In the April 2007 issue of TechNet Magazine, I discussed the importance of having a plan in
place for recovering Active Directory® users and groups. In that article, available at technetmagazine.com/issues/2007/04/ADRecovery, I covered the mechanics of object linking, replication, deletion, and authoritative restores. Unfortunately, the authoritative restore function requires that you start a domain controller (DC) in Directory Service Restore Mode (DSRM). Doing this renders the DC unavailable for the duration of the restore operation.
There is another approach you should be aware of. Tombstone reanimation (which has nothing to do with zombies) provides the only way to recover deleted objects without taking a DC offline, and it's the only way to recover a deleted object's identity information, such as its objectGUID and objectSid attributes. It neatly solves the problem of recreating a deleted user or group and having to fix up all the old access control list (ACL) references, which contain the objectSid of the deleted object. Just keep in mind that tombstone reanimation does have its own limitations, which I will discuss, so you'll still want to keep authoritative restores in your box of tricks.
Tombstone reanimation was introduced in Windows Server® 2003 Active Directory to simplify certain data recovery scenarios. This feature takes advantage of the fact that Active Directory keeps deleted objects in the database for a period of time before physically removing them. In this article I'll give you a detailed description of how Active Directory deletes and reanimates objects, and I'll show how you can recover deleted objects using standard Microsoft tools.

What Is a Tombstone?
When Active Directory deletes an object from the directory, it does not physically remove the object from the database. Instead, Active Directory marks the object as deleted by setting the object's isDeleted attribute to TRUE, stripping most of the attributes from the object, renaming the object, and then moving the object to a special container in the object's naming context (NC) named CN=Deleted Objects. The object, now called a tombstone, is invisible to normal directory operations. It does not show up in any Microsoft® Management Console (MMC) snap-ins, and most Lightweight Directory Access Protocol (LDAP) utilities are blissfully unaware of the tombstone's existence. The tombstone is, for all intents and purposes, gone. The data, however, is still there—it's just invisible. So why does Active Directory keep tombstones, otherwise deleted objects, in the database?
While invisible to other processes, a tombstone is visible to the Active Directory replication process. In order to make sure the deletion is performed on all the DCs that host the object being deleted, Active Directory replicates the tombstone to the other DCs. Thus the tombstone is used to replicate the deletion throughout the Active Directory environment.

The Lifetime of a Tombstone
Active Directory typically deletes an object from the directory in response to an LDAP delete protocol operation or a Security Accounts Manager (SAM) delete operation. This operation is called the originating delete and is distinct from the delete operations performed by the Active Directory replication process. Note that this discussion does not concern dynamic objects, which have a different delete mechanism and are directly deleted by Active Directory when their time to live (TTL) expires.
When Active Directory receives the delete operation, it first runs through a checklist to make sure the object is allowed to be deleted. This process is surprisingly involved as it makes sure the following criteria are all true:
  • The isDeleted attribute of the object is not already set to TRUE. (You can't delete an already deleted object!)
  • The "private object" resource-specific security descriptor control flag is not set in the object's security descriptor. (This appears to be an undocumented "feature." The private object flag is bit 1 of the Sbz1 byte of the security descriptor structure.)
  • The "disallow delete" bit (0x80000000) is not set in the systemFlags attribute of the object.
  • The isCriticalSystemObject attribute of the object is not set to TRUE.
  • The object's security descriptor grants the appropriate access rights to the user to delete the object. (More specifically, the user is allowed to delete the object itself and is allowed to delete a child from the parent object.)
  • The object is not a cross-reference object (objectClass = crossRef) for an existing naming context.
  • The object does not have any subordinate objects. (If the LDAP delete operation includes the LDAP "tree delete" control object id, Active Directory will automatically delete subordinate objects as well, unless they have the isCriticalSystemObject attribute set to TRUE. This prevents critical system objects from being deleted inadvertently as part of a tree deletion operation. You can of course delete these objects individually.)
  • The object is not a critical internal object (for instance, it isn't the nTDSDSA object for the DC or placeholder objects for ancestors of the NC heads).
In addition to these criteria being true, Active Directory must also be in an appropriate state to process the delete operation. For example, if Active Directory is in the process of renaming a domain, it will not delete a domain trust account or a crossRef object.
If it is determined that the object can in fact be deleted, Active Directory proceeds to turn the object into a tombstone. Active Directory first strips unnecessary attributes from the object, leaving those specified in Figure 1 and those defined in the schema to be retained in the tombstone. (See the section "Recovering Object Attributes" for more information on this.) It then changes the relative distinguished name (RDN) of the object to CN=<old RDN>\0ADEL:<objectGUID>, where \0A indicates the ASCII linefeed character and <objectGUID> is the objectGUID expressed as a string. The lastKnownParent attribute is then set to the distinguished name (DN) of the parent container of the object and the isDeleted attribute is set to TRUE. Active Directory then removes all forward and backward link attributes from the object. Finally, if the systemFlag attribute of the object does not have the "disallow move on delete" bit set, Active Directory moves the object to the CN=Deleted Objects container for the NC. (See the "systemFlags Attribute and Object Behavior" sidebar for more information on this topic.)
Figure 1 Attributes saved in a tombstone (Close Figure 1)

Hard-Coded to Be Saved
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
Saved Due to searchFlags Setting
msDS-AdditionalSamAccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid
You should note that the CN=Deleted Objects folder is flat and has no object hierarchy. You might think this would cause name conflicts if you deleted two different objects with the same CN. This isn't the case, though. Since the objectGUID is incorporated into each tombstone's RDN, each tombstone's RDN is unique within the CN=Deleted Objects container.
Obviously, objects don't remain in the CN=Deleted Objects container forever. The default tombstone lifetime is 60 days for forests initially built using Windows® 2000 and Windows Server 2003, and 180 days for forests that were initially built with Windows Server 2003 SP1. You can change the tombstone lifetime by setting the tombstoneLifetime attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain> object.
Every 12 hours, each domain controller starts a garbage collection process. (This can be changed by setting a new value for the garbageCollPeriod attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<root domain> object.) This garbage collection scans all of the tombstones on the DC and physically deletes any that are older than the tombstone lifetime.

Using LDP to Find Tombstones
LDP is a Windows Explorer-like utility for working with Active Directory. LDP was originally designed by the Active Directory development team to test its LDAP code while Active Directory was under development. Now part of the Windows Server 2003 Support tools, LDP has evolved into a robust tool for working with Active Directory.
Even though tombstones are invisible to normal directory operations, you can find tombstone objects in Active Directory using LDAP search operations and special LDAP extensions called controls. Controls are a mechanism, defined in the LDAP standard, used to extend the LDAP protocol to provide additional functionality beyond what is defined in the LDAP standard while remaining compatible with other LDAP-compliant software. Active Directory supports 22 controls, including the Return Deleted Objects control. When used to extend an LDAP search operation, this control retrieves deleted objects that would otherwise be invisible.
To demonstrate how this works, I log into the foo.local domain with Enterprise Administrator credentials and then use the Active Directory Users and Computers (ADUC) MMC snap-in to create a user object (CN=John Smith,CN=Users,DC=foo, DC=local), as shown in Figure 2. I then delete the user object, again using ADUC.
Figure 2 Using ADUC to create a user
Figure 2 Using ADUC to create a user
Now I can run the LDP program and use it to display the tombstone for the deleted user. The first step is to connect LDP to a specific DC and authenticate using the appropriate credentials. To connect to the DC, I simply select the Connect option from the Connection menu. Since I am running LDP on the DC, I just press OK to connect to the local DC. If you are running LDP remotely, you must specify the name of the DC you want to connect to. After I successfully connect, LDP displays the attributes of rootDSE—this contains attributes describing the state and configuration of the DC itself (see Figure 3).
Figure 3 LDP connected to a DC
Figure 3 LDP connected to a DC
Now, to authenticate to the DC using domain or enterprise administrator credentials, I select Bind from the Connection menu. Because I'm already logged in as an Enterprise Administrator for the forest (Domain Administrators and Enterprise Administrators by default have the rights to list and reanimate objects in the CN=Deleted Objects container), I simply leave the Username and Password in the Bind dialog empty and press OK. Otherwise, I could enter the appropriate credentials into the Bind dialog.
Next I want to list the contents of the CN=Deleted Objects,DC=foo=DC,local con- tainer. You will normally never see the CN=Deleted Objects container because the container itself is marked as deleted. The only way you can search the CN=Deleted Objects container is to use the Return Deleted Objects LDAP control.
To use this control with LDP, go to the Browse menu and select Search. The search dialog shown in Figure 4 will appear. The Base Dn field lets you specify where in the directory tree to start searching. I enter the DN of the Deleted Objects container for the domain–in this example, the DN is CN=Deleted Objects,DC=foo,DC=local.
Figure 4 LDP Search dialog
Figure 4 LDP Search dialog
In the Filter field, I specify the search criteria LDP will use. The default value is (objectClass=*), which instructs the search to return all objects that have a value for the objectClass attribute. Because even deleted objects in Active Directory have a value for objectClass, the default filter will return every object within the search scope. In this example, I change the filter to (objectClass=user), limiting the search to user objects. This will make it easier to find the deleted John Smith user among the possibly thousands of tombstones in the CN=Deleted Objects container.
You may find that there are more objects in the CN=Deleted Objects container than Active Directory will return in a single search operation. To address this problem, you would typically use a paged LDAP search, which returns the results a group at a time. However, LDP does not let you specify both a paged and extended search. So you'll have to refine your LDAP filter to locate the object you want.
The Scope radio buttons let you specify how much of the directory tree to search. A base search will only return the object specified by the Base Dn field. A one-level search will return objects that are immediately subordinate to the Base Dn object. And a subtree search will return all objects subordinate to the Base Dn object. Because the CN=Deleted Objects folder is flat, I use a one-level search to retrieve all tombstones.
So far, I have merely outlined a conventional LDAP search. If I were to run it now, LDP would display an error indicating that CN=Deleted Objects,DC=foo,DC=com does not exist since it's marked deleted. I still have to include the Return Deleted Objects LDAP control with the search operation. To do so, I click the Options button on the Search dialog and select Extended for the Search Call Type, as shown in Figure 5. This option allows me to specify controls for the search operation. Here, I also change the Attributes list to *. This causes LDP to display all of the normal attributes for each object it retrieves, instead of LDP's default set of attributes.
Figure 5 LDP Search Options dialog
Figure 5 LDP Search Options dialog
Now I press the Controls button to display the Controls dialog. LDP's Controls dialog is a little awkward, so when you do this, be sure you carefully follow these steps for adding the Return Deleted Objects control.
Open the Load Predefined dropdown list, select Return deleted objects, and press the Check in button. This adds the object identifier (OID) for the Return Deleted Objects control (1.2.840.113556.1.4.417) to the Active Controls list, as shown in Figure 6. LDP then adds the control to all subsequent extended search operations. Press OK to save the control settings and press OK again to close the Search Options dialog.
Figure 6 Adding the Return Deleted Objects control
Figure 6 Adding the Return Deleted Objects control
The Controls dialog has some peculiar behavior. Specifically, even though an OID appears in the Active Controls list, this doesn't necessarily mean that the control is actually in effect. Sometimes you have to check out a control and then check it back in to ensure that the control will be used in the next LDAP operation.
Now I'm ready to run my search. I press the OK button on the LDP Search dialog and LDP retrieves all the user objects from the CN=Deleted Objects container for the domain. Figure 7 shows my results.
Figure 7 Results from the CN=Deleted Objects container
Figure 7 Results from the CN=Deleted Objects container

Examining the LDP Results
My search returned two tombstone objects. First, you can see the DN of the first tombstone: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. The objectGUID of the deleted object is represented as a string (41800281-6bc4-42c3-a99b-b283022b3af8). Beneath the DN is a list of attributes showing the values for objectClass, cn, distinguishedName, and so on. You can see that the value of the isDeleted attribute is TRUE, meaning the object has in fact been deleted. You'll also see that the objectSid has been preserved in the tombstone—this is important for recovering user and group tombstones, as I'll discuss later. The lastKnownParent attribute, which represents the DN of the object that contained the deleted object before it became a tombstone, is also extremely important when recovering tombstones.
In my sample, LDP displayed two tombstone objects, both of which were user objects named CN=John Smith that originally came from the CN=Users,dc=foo,dc=local container. How can two separate objects with the same RDN come from the same container? The explanation is pretty simple. Before running LDP to search for tombstones, I created the CN=John Smith user object in the CN=Users,DC=foo,DC=local container and deleted it. Then I created another user object with all the same attributes and deleted that one as well. Because I had already deleted the first CN=John Smith user object, it was perfectly reasonable to create the second one, even though it had the same name. But these are separate, unique objects, distinguished by their objectGUIDs. Because Active Directory incorporates the objectGUID into the tombstone's DN, they appear as separate objects in the CN=Deleted Objects container.

How a Tombstone Is Reanimated
Active Directory provides a mechanism for restoring a tombstone back into a normal object. This is effectively an undelete function for deleted objects. The function is a specially formed LDAP modify operation that must include two specific attribute modifications: it must remove the isDeleted attribute (not just set it to FALSE) and it must move the object to another container by changing the object's distinguishedName. The new distinguishedName typically (but not necessarily) uses the lastKnownParent attribute as the container and keeps the same RDN minus the \0ADEL:<objectGUID> component that Active Directory added when it created the tombstone.
Before reanimating the tombstone, Active Directory checks to ensure certain necessary conditions are all true. The user must have the reanimate tombstone extended access right defined on the NC head of the NC containing the tombstone. The user cannot be reanimating his own object. The isDeleted attribute of the tombstone must be set to TRUE. And the owner Security Identifier (SID) of the object, as defined in the security descriptor, must have a SID from one of the domains in the forest or a trusted domain.
If the object in question is in the Configuration or Schema NCs, the FLAG_CONFIG_ALLOW_RENAME and FLAG_ CONFIG_ALLOW_MOVE bits must be set in the tombstone's systemFlags attribute. If the object is in the Configuration or Schema NCs and the FLAG_CONFIG_ALLOW_LIMITED_MOVE flag is set, the object is only able to be moved to a container that has the same grandparent—in other words, the object must retain its great-grandparent after the move. And if the object is in a domain NC or an application partition, then the FLAG_DOMAIN_DISALLOW_RENAME and FLAG_DOMAIN_DISALLOW_MOVE bits must not be set in the tombstone's systemFlags attribute.
The user must have the rights, as defined in the security descriptor, to modify the RDN (usually CN, but not always) and to add the object to the new parent container. And the new parent container must be a possible superior for the tombstone's objectClass, as defined by the schema.
Reanimating a schema object is never allowed. This, however, is not really an issue since you can't legitimately delete an object from the Schema NC.
If all of the checks are successful and the necessary requirements are met, Active Directory performs the following steps on the tombstone to reanimate the object:
  • The isDeleted attribute is removed.
  • If not otherwise prescribed in the modify operation, the objectCategory is set to the most specific objectClass indicated in the tombstone.
  • The RDN is changed and the object is written to the new parent container.
After reanimation, the object has the same objectGUID and objectSid attributes it originally had. This means that external references to the object, for instance in ACLs, don't have to be reset as they do if you recreate a deleted object. The reanimated object looks and acts just as it did before it was deleted. There is one important difference, though: the restored object is missing any attributes that were not saved in the tombstone.

Using LDP to Reanimate Tombstones
systemFlags Attribute and Object Behavior
The systemFlags attribute is an optional attribute defined for the class top, which makes systemFlags an optional attribute for every Active Directory class. It is a 32-bit integer bit mask that controls the behavior of object moves and deletes. Here's a rundown of important flags.

FLAG_DISALLOW_DELETE (0x80000000)

If this flag is set, the system will not allow the object to be deleted or moved to another domain.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Objects in the Configuration and Schema NCs cannot be renamed unless this flag is set in the systemFlags attribute.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Objects in the Configuration and Schema NCs cannot be moved unless this flag is set in the systemFlags attribute.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Objects in the Configuration and Schema NCs cannot be moved unless this flag is set in the systemFlags attribute. This flag imposes a further restriction on the target container of the move operation‑the target container must have the same grandparent as the current container.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

By default, objects in a domain NC or application NC can be renamed. However, if this flag is set in the systemFlags attribute of the object, the system will not allow the object to be renamed.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

By default, objects in a domain NC or application NC can be moved to another container. However, if this flag is set in the systemFlags attribute of the object, the system will not allow the object to be moved.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

If this flag is set, the system will not move the object to the CN=Deleted Objects container of its naming context. It will simply set the isDeleted attribute, rename the object, and strip the attributes not designated in the schema to be saved. This means that not all deleted objects appear in the CN=Deleted Objects container for the naming context; some remain in the original parent container.

Now that I've shown you how the nuts and bolts of tombstone reanimation work, I want to demonstrate how I can use LDP to restore the CN=John Smith user I deleted. First I connect to a DC and authenticate. Now I can perform a modify operation using LDP. In the modify operation parameters, I can remove the isDeleted attribute and specify a new DN at the same time.
Because I am operating on a tombstone, I have to specify the Return Deleted Objects LDAP control. To set this control for the modify operation in LDP, select Controls from the options menu, select Return deleted objects from the Load Predefined dropdown list, press the Check in button, and press OK to save the control settings.
Now I select Modify from the Browse menu to open the Modify dialog and enter the DN of the tombstone object I want to restore. The easiest way to do this is to copy and paste the DN from the results of the search operation I performed earlier.
Next, I have to enter a list of attribute operations to perform. Reanimating a tombstone requires two attribute operations—delete the isDeleted attribute and replace the distinguishedName attribute with the desired DN of the reanimated tombstone. So I type isDeleted into the Attribute field and select the Delete radio button. When I press the Enter button, the attribute operation is added to the Entry List, as shown in Figure 8.
Figure 8 Specifying attribute operations to be performed
Figure 8 Specifying attribute operations to be performed
Then I enter distinguishedName into the Attribute field, select the Replace radio button, and enter the new DN of the object in the Values field. In this case, I use the original distuiguishedName of the user, CN=John Smith,CN=Users,DC=foo,DC=local. When I press the Enter button, the modify operation is added to the Entry List.
Because I have to include the Return Deleted objects LDAP control with the modify operation, I have to use an extended LDAP modify. To do this, I check the Extended checkbox. Once everything is set, as shown in Figure 9, I press the Run button to make the changes. LDP displays the results in a large text window.
Figure 9 Change the distinguishedName
Figure 9 Change the distinguishedName
When I go back to the Active Directory Users and Computers MMC snap-in and look in the CN=Users container, I'll find the once-deleted user object back where it came from. But the object will have some important differences from its original state, which I'll look at in a moment.

Using ADRESTORE to Reanimate Tombstones
Once you figure out how to use LDP, reanimating a tombstone is not terribly difficult. But it's not very convenient, either. Fortunately, the good folks at Sysinternals (a company that is now part of Microsoft) developed a command-line tool to simplify the reanimation process. This tool, called ADRESTORE, is available from the Microsoft Web site at microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. Installation is simple. Just copy the executable to an appropriate directory on your machine, for instance the C:\WINDOWS\SYSTEM32 directory.
ADRESTORE runs in two modes. If you run it with no parameters, it will list all the tombstones in the CN=Deleted Objects container of the default domain. You can add a search string to the command line to select the objects to display, for instance:
C:\> adrestore John
This will display all the tombstone objects in the CN=Deleted Objects container that contain the string "John" in their CN or OU attribute—it uses the LDAP search filters cn=*John* and ou=*John*. This isn't exactly the most flexible way to search tombstone objects, but it is workable for most situations. Figure 10 shows the output my search returned in ADRESTORE.
Figure 10 Attributes saved in a tombstone
Figure 10 Attributes saved in a tombstone
If you want to reanimate a tombstone, not just find it, then you need to specify the –r switch, along with an optional string, such as the following:
C:\> adrestore –r John
This command will prompt you to reanimate each matching tombstone object. ADRESTORE always reanimates the object into the container given by the tombstone's lastKnownParent attribute—there is no way to specify a different container.
ADRESTORE provides a convenient command-line interface for using the Active Directory reanimation functionality. Though not very flexible, it is quite a bit easier to use than LDP. Still, ADRESTORE doesn't avoid two significant problems with reanimating tombstones: recovering the attributes stripped from the object when it was first deleted, and recovering objects deleted from the Configuration NC.

Recovering Object Attributes
In terms of data recovery, tombstone reanimation has a great advantage over performing an authoritative restore: tombstone reanimation doesn't require the DC to be taken offline. And reanimating tombstones is much better than simply recreating a new version of a deleted object. If you recreate an object, it will always get new objectGUID and objectSid (if it's a security principal such as a user) attributes. As a result, any external references to the object, such as ACLs, will have to be updated to reflect the new object's identity. This can be a major headache.
Some attributes are stripped when an object is deleted, and these attributes aren't recovered with tombstone reanimation. But Active Directory saves some key attributes in the tombstone, the most important of which are identity-related attributes such as objectGUID and objectSid. It saves many other attributes by default as well (see Figure 1). Most of the attributes that are hardcoded to be saved aren't very interesting, particularly in a discussion about recovering deleted user objects. But you can specify additional attributes to be saved in the tombstone by setting bit 3 (0x00000008) of the searchFlags attribute of the corresponding attributeSchema object in the Active Directory schema. Some attributes already have this bit set in the schema in Windows Server 2003 R2 (these are also shown in Figure 1).
Installing certain applications may change bit 3 of the searchFlags of existing attributes or even add new attributes that have bit 3 set. Exchange Server, for example, configures several additional attributes to be saved in the tombstone.
Active Directory will not save forward-linked or backward-linked attributes in the tombstone, even if you specify to do so in the searchFlags attribute of the schema object. In particular, Active Directory doesn't save things such as the member attribute of a group or the memberOf attribute of a user. Thus tombstone reanimation doesn't provide a solution for recovering group memberships in Active Directory for this, see my "Disaster Recovery: Active Directory Users and Groups" article at technetmagazine.com/issues/2007/04/ADRecovery. So you will still have to provide an alternate mechanism for recovering this information when reanimating tombstones.
If you want to use tombstone reanimation as part of your data recovery strategy, either you'll need to make sure that the important attributes are saved in the tombstone or you'll need to provide another way to save and recover important attributes, such as using LDIFDE or another backup and restore scheme. Other options include third-party Active Directory data recovery products that provide an automated mechanism for backing up and restoring attributes that aren't saved in and recovered from the tombstone.

Reanimating Objects from the Configuration Naming Context
One other substantial limitation that tombstone reanimation suffers is that, generally speaking, you cannot reanimate objects that were deleted from the Configuration NC. Those objects are subject to special rules with respect to moving and renaming, as defined by the object's systemFlags attribute. Unless otherwise specified by the systemFlags attribute, objects in the Configuration NC cannot be moved or renamed, which means their tombstones cannot be reanimated. Active Directory enforces certain values for the systemFlags attribute when it creates objects of specific classes, as defined in Figure 11. Note that Active Directory applies the bit-wise logical OR operation to these values in combination with any systemFlags value specified in the add operation. This way even if the application specifies a different value for the systemFlags attribute, the necessary bits will be properly set.
Figure 11 Default systemFlags settings (Close Figure 11)

Class | Default Setting
server | FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site | FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer | FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA | FLAG_DISALLOW_MOVE_ON_DELETE
siteLink | FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge | FLAG_CONFIG_ALLOW_RENAME
nTDSConnection | FLAG_CONFIG_ALLOW_RENAME
The only objects from the Configuration NC that you can reanimate under normal circumstances are server objects. Interestingly, when Active Directory deletes a server object, the tombstone is not moved to the CN=Deleted Objects container for the Configuration NC; the tombstone simply remains where the object is. This allows the Knowledge Consistency Checker (KCC), which is the process responsible for calculating the Active Directory replication topology, to automatically recover from certain scenarios where deleted server objects might inhibit proper replication. So if you find yourself trying to reanimate a server object, remember that you won't find it in the CN=Deleted Objects container.

Reanimation in Your Recovery Plan
Tombstone reanimation should be a key part of your data recovery toolkit. This mechanism is the only way to recover deleted objects without taking a DC offline and, equally important, it's the only way to recover a deleted object's identity information. This neatly solves the problem of recreating a deleted user or group and having to fix up all the old ACL references.
But tombstone reanimation is an incomplete solution. You have to provide your own mechanism for recovering the attributes that Active Directory doesn't retain in tombstone objects, and your ability to recover deleted objects from the Configuration NC is limited. Remember that if you do elect to reanimate a deleted user or group, you will still have to recover the group memberships and any other linked attributes of which you might be in need.

Gil Kirkpatrick is the CTO at NetPro and has been developing software for Active Directory since 1996. Along with Guido Grillenmeier from HP, he delivers the popular Active Directory Disaster Recovery workshops. Gil is also the founder of the Directory Experts Conference (www.dec2007.com).


 Communications: Connecting Users with Office Communications Server 2007
Communications Alan Maddison

Connecting Users with Office Communications Server 2007
At a Glance:
  • Office Communications Server architecture
  • Conferencing features
  • Enterprise Voice
  • Enhanced Presence

Unified communication is here. The impending launch of Office Communications Server 2007 will provide a complete overhaul of the experience available though Live Communications Server 2005. In addition to architectural and administration improvements, Office
Communications Server 2007 includes a new client, Office Communicator. It also features new and enhanced capabilities such as Enterprise Voice, on-premise Web conferencing, enhanced presence and instant messaging, and federation. Combined, these features provide the platform for the Microsoft® Unified Communication strategy, and promise to improve productivity and enhance long-distance collaboration.
This update also includes a streamlined Microsoft Management Console (MMC) snap-in interface. Figure 1 shows one of the new administrative enhancements for performance counters.
Figure 1 The new MMC snap-in includes performance counters
Figure 1 The new MMC snap-in includes performance counters
The new Office Communications Server 2007 comes in two editions: Standard and Enterprise. Office Communications Server 2007 Standard is ideal for deployments involving fewer than 10,000 users. In a Standard edition deployment, a single front-end server would host all of the services.
For larger deployments, the Enterprise edition is available and can be deployed in either a consolidated or expanded configuration. In a consolidated topology all of the hardware is arranged in a single pool of front-end servers. For maximum scalability, you can use the expanded configuration, which allows you to use dedicated Web servers running Internet Information Services (IIS), Web conferencing, and audio/visual (A/V) conferencing servers outside of the enterprise pool of front-end servers. Figure 2 shows an expanded configuration topology.
Figure 2 Expanded configuration topology
Figure 2 Expanded configuration topology

Architecture
The Office Communications Server 2007 architecture is built upon a foundation of core servers: front-end servers, edge servers, and application servers. Front-end servers provide user authentication, address book maintenance, presence management, conference management, and application hosting, as well as signal handling among servers and clients, media management (including file sharing), and routing of instant messaging (IM) and conferencing traffic.
The core conferencing functionality of Office Communications Server 2007 is provided through a series of integrated servers also known as multipoint control units (MCUs). Figure 3 provides a summary of these servers and their roles.
Figure 3 Conferencing servers and their functions (Close Figure 3)

Conferencing Server (MCU) | Supported Functionality
Instant Messaging | Enables group IM by routing IM traffic among participants. Integrated into the front-end server and cannot be installed on a separate server.
Telephony | Enables support for inbound and outbound dial tone. Integrated into the front-end server and cannot be installed on a separate server.
Web | Responsible for collaboration functionality such as whiteboarding, application sharing, and Q & A. This server also provides support for Office document sharing and PowerPoint presentations. Can be installed on the front-end server or in the expanded pool configuration on a separate server.
A/V | Used for multiparty IP audio/video mixing and relaying. Can be installed on the front-end server or in the expanded pool configuration on a separate server.
Another important function of the front-end server is as host to the address book server. Those of you familiar with Live Communications Server 2005 SP1 will recognize this service. In Office Communications Server 2007, it plays a central role and is now no longer an optional component. The address book server consists of two components: the address book service and the address book file store. This server is responsible for providing contact information from both internal and external sources. The Global Address List and distribution lists from Active Directory® and Exchange Server are typical examples of internal sources. External sources include users from federated partners or public IM contacts.
Office Communications Server 2007 enhances the external user connectivity introduced in Live Communications Server 2005 and allows external users to participate in on-premise conferences. This additional functionality requires two new edge servers: Web conferencing edge server and A/V edge server. In another change, what was formerly the access proxy server is now known as the access edge server. The Office Communications Server edge servers are designed to be placed in your network perimeter (screened subnet) and provide critical external user connectivity. Figure 4 provides a summary of the edge server roles and what they are used for.
Figure 4 Edge server roles (Close Figure 4)

Server | Supported Functionality
Access edge server | Federation; remote user connectivity; Public IM Connectivity (PIC).
Web conferencing edge server | External Web conferencing.
A/V edge server | A/V conferences and point-to-point A/V calls with external users.
Reverse proxy server | Group expansion, address book file download, Web conferencing access to meeting content. Not strictly an Office Communications Server role, but provides critical functionality. ISA Server 2006 can also provide reverse-proxy functionality.
In addition to the integrated servers described previously Office Communications Server takes advantage of various application servers to perform essential functions such as authentication, storing conference metadata, and providing distribution list functionality. The application servers commonly used with Office Communications Server include IIS, certificate servers, global catalog servers from your Active Directory environment, SQL Server® 2005, Exchange Server 2007, and file servers.
IIS is used to provide access to meeting content, address book updates, expansion of Active Directory distribution groups for IM, expansion of Outlook® distribution lists for external users, and to facilitate the underlying communication between Office Communications Server components.
Certificate servers play a crucial role within Office Communications Server in terms of securing both client/server communication and server/server communication. If you use an internal enterprise certificate server, all internal clients and servers must trust the issuing certificate authority (CA). As such, each CA certificate chain must be installed in the Trusted Root store on each computer. If you use Office Communications Server federation services, then your partner organization must do the same.
Conference participant authentication is supported by the global catalog servers in your Active Directory environment. For internal and federated users your global catalog servers will use Kerberos for authentication. Remote users employed by your company will use their Active Directory credentials over NTLM and anonymous users will be authenticated using Digest Authentication.
SQL Server 2005 is used to maintain state data about conferences, user registration and presence information. In the event of a failure, you can quickly restore a meeting by using the data stored in SQL Server, thus providing a quick and reliable method of recovery without loss of content.
Exchange Server 2007 and its unified messaging features provide an important adjunct to Office Communication Server 2007 via the inclusion of voice messaging and auto attendant capabilities.
File servers are used for storing data that needs to be accessed by clients. For example, the physical files required by clients when downloading the address book are stored on a file server. Likewise, additional meeting content is also stored on a file server.
The underlying protocol architecture of Office Communications Server 2007 is based on a mix of standard Internet protocols and Microsoft protocols. For instance, Session Initiation Protocol (SIP) is used extensively for functionality such as IM, conferencing, and presence subscriptions. The protocols used by the various components of Office Communications Server provide the maximum amount of power and flexibility. Figure 5 provides a summary of the core protocols and their use.
Figure 5 Protocols and their usage (Close Figure 5)

Protocol | Supported Functionality
Hypertext Transfer Protocol (HTTP) | Client access, downloading meeting content, and address book data. Also used for communication between the conferencing servers and Focus, a component of Office Communications Server.
Session Initiation Protocol (SIP) | Session creation and management by the various components of Office Communications Server, including Enterprise Voice, IM, conferencing servers, and enhanced presence.
Centralize Conference Control Protocol (CCCP) | A custom protocol used for establishing and controlling of conferences and conference clients.
Persistent Shared Object Model (PSOM) | A custom protocol used in the transport of Web conferencing content, including security keys and user roles and rights.
Real-Time Transport Protocol (RTP) | Delivery of real-time data. Within Office Communications Server 2007, it provides the transport mechanism for Enterprise Voice and A/V conferencing.
Secure Real-Time Transport Protocol (SRTP) | Security services such as encryption, message authentication, and integrity for RTP data. Within Office Communications Server 2007 it is used for the secure transport of audio and video content to media devices such as microphones and speakers.
Real-Time Transport Control Protocol (RTCP) | Used together with SRTP to convey information about the signal quality of A/V conferencing sessions among media devices.

Enterprise Voice
Enterprise Voice is the Microsoft implementation of Voice over Internet Protocol (VoIP) telephony and is the single most significant addition to the product. Based on an implementation that uses Session Initiation Protocol (SIP) for signaling and Real Time Protocol (RTP) for voice traffic, Enterprise Voice allows you to make and receive calls from PC to PC as well to any other phone. In addition, Enterprise Voice provides functionality such as call control and routing and number normalization. There is support for the Public Switched Telephone Network (PSTN) and interoperability with Private Branch Exchanges (PBXs) that support either SIP, Computer-Supported Telecommunications Applications (CSTA) or that interface directly with the Office Communications Server 2007 API.
Office Communications Server 2007 can be deployed without significant alterations to your existing voice infrastructure while still allowing you to achieve significant benefits. As such, Enterprise Voice supports three deployment configurations: SIP–PBX, SIP–IP–PBX, and IP-PSTN.
In the SIP–PBX setup, all remote calls are controlled by the PBX and you maintain your existing telephones. This integration is made possible by the Remote Call Control (RCC) gateway and CSTA.
The SIP–IP–PBX configuration takes advantage of the IP-PSTN gateway, which eliminates the need for CSTA and allows the Office Communicator client to dial numbers and control the IP-PBX phone. If you do not have existing handsets you can configure Office Communicator as a "softphone."
Deploying Office Communications Server 2007 with the IP-PSTN component allows you to route call controls to the front-end servers. Office Communicator can interface with VoIP or Microsoft-certified third-party SIP endpoints (in many organizations this endpoint is typically a handset) to make and receive calls over the Internet.
Media gateways are third-party gateways that provide signaling and media conversion between VoIP and the PSTN. Office Communications Server 2007 supports three types of media gateways, which can be categorized as basic, advanced and basic hybrid. In order to support gateways other than advanced, Office Communications Server 2007 offers the Mediation Server role, providing critical protocol and media translation functionality. Remote office integration is also possible using the components available with Office Communications Server.
As with other components of Office Communications Server 2007, Enterprise Voice relies on edge servers to provide external user connectivity. Specifically, the access edge server is required (for its role in SIP signaling) for users outside the corporate perimeter, while the A/V edge server allows external users accessing voice or video services to connect through perimeter network services such as your firewall and Network Address Translation (NAT) implementation.
Although Enterprise Voice will ultimately support a large number of clients, the currently recommended client for Enterprise Voice is the latest version of Office Communicator. In addition, Microsoft and its partners have announced plans for new VoIP phone hardware that will integrate with Office Communications Server.
Enterprise Voice also integrates with the Unified Messaging role of Exchange Server 2007, offering a single interface for voice mail, e-mail, calendars, contacts, and receipt of faxes that is accessible from either a telephone using Outlook Voice Access or from a computer. In addition, Unified Messaging provides auto-attendant services, which gives you the means to implement an automated phone menu system.

Enhanced Presence
The concept of presence that you may be familiar with from Live Communications Server 2005 has been extended and enhanced in Office Communications Server 2007. In general, presence is associated with the status and availability of users. In Office Communications Server, the supporting infrastructure has created a richer experience with improved granularity for configuring presence-related information.
Users now have the option of selecting from six different status modes: status can be set to Online, Busy, Do Not Disturb, Be Right Back, Away, or Appear Offline. Users also have the ability to customize this status with additional information. For example, if a user's status is set to Do Not Disturb, the user can provide additional information as to why they should not be disturbed.
Enhanced presence also permits users to filter the information that is displayed to other users through the use of five optional presence levels: these presence levels are Personal, Team Members, Workplace, Public, and Block. These levels provide a hierarchical approach to presence management. For example, the Personal presence level allows contacts the greatest amount of flexibility by permitting such actions as contact through IM even when the user's status is set to Busy. Presence levels also control the amount of information that is displayed to contacts.
Furthermore, when using the Office Communicator, a user is able to set their location status, which can be a custom location or one of the default choices of home or office. Location information is available to contacts classified as Personal or Team.
While the enhancements to presence are welcome and will prove themselves in terms of streamlining communications, it is the underlying infrastructure of Office Communications Server and the presence engine that will have the biggest impact on organizations. For example, Office Communications Server 2007 comes with the Member Web Part, an Office SharePoint Server 2007 Web Part, that allows users to view the presence of other users associated with a SharePoint Web site or portal. This Web Part can be easily added to your SharePoint sites to facilitate presence information across your critical collaboration infrastructure.
Presence information is integrated into the entire Microsoft® Office 2007 application suite through the use of document workspaces and smart tag action buttons. For example, smart tag action buttons can display the status, contact, and calendar information of users. Users can employ the smart tag actions to share work, schedule meetings or start an IM conversation.

On-Premise Conferencing
Another significant improvement in Office Communications Server 2007 is the on-premise conferencing capability. The ability to host real-time conferences with internal or external users (anonymous or federated) should be a valuable tool for many organizations. These conferences can be scheduled or ad hoc and can include IM conferences, A/V conferences, and Web conferences as well as other collaborative tools such as file sharing, whiteboarding, slide annotation, participant polling, and participant Q&A sessions. Office Communications Server also supports transitioning from one type of conference to another. For example, a user can choose to add collaboration to an existing IM session and create an ad hoc conference.
While Office Communicator is the recommended client for conferencing, Office Communications Server 2007 also supports Office Live Meeting 2007 and Office Live Meeting Add-In for Outlook 2007. Office Communicator 2007 supports IM, A/V session participation, application sharing, whiteboarding, and file transfer. Office Live Meeting 2007 includes support for conference participation as well as schedule sessions, record sessions, participant polling, and Q&A.
Office Live Meeting 2007 Add-In for Outlook 2007 includes support for conferencing tasks using Outlook 2007 as well as the ability to designate individual participants as attendees or presenters and to send separate invitations to the different roles. In addition to users holding the role of Organizer, Presenter or Attendee, they are also categorized as belonging to an internal or external user groups based on their location and credentials. Internal users have an Active Directory logon and are on the corporate LAN. External users are subdivided into three categories: Remote, Federated, and Anonymous.
Remote users denote anyone with an Active Directory account within an organization. This could include remote workers or contractors. All remote users can host, join, and present conferences.
Federated users have credentials defined by the establishment of a federation within Office Communications Server. Federated users can attend meetings and act as presenters, but they cannot organize a meeting.
Anonymous users are the most restricted group; they can only attend meetings to which they have been invited.
To provide an additional layer of security for any given meeting, it is possible to specify different types of entry control settings. Office Communications Server 2007 provides the following: open authenticated, closed authenticated, and anonymous.
An open authenticated meeting allows any remote or internal user with an Active Directory login to join. Any federated user can also join. A closed authenticated meeting restricts the meeting to those users invited by the meeting organizer. Federated users cannot participate in the meeting.
An anonymous meeting is open to anyone who receives an invitation. To join, a user must present a conference key and pass Digest authentication in order to have his credentials verified. Unless promoted to presenter after joining, an anonymous user can only be an attendee. Some of the available settings are shown in Figure 6.
Figure 6 Meeting settings
Figure 6 Meeting settings

Dialing In
By streamlining communications, integrating different communication mediums, and putting control in the hands of the user, Office Communications Server 2007 has the potential to revolutionize the way your company works. The concept of contextual communications, where both presence information and a means to communicate are embedded within the application, will be the basis for this revolution. If Office Communications Server 2007 is not in your lab, it should be.
For more information about Office Communications Server 2007 and to try the beta, take a look at the TechNet Office System TechCenter at technet.microsoft.com/en-us/office/bb267356.aspx. Also, be sure to check out the Unified Communications Group Team Blog at blogs.technet.com/uc.

Alan Maddison is a Senior Consultant at MTI Technology Corporation. His primary focus is on Active Directory, Exchange Server, and virtualization.


 From the Editor: Pathways to Learning
From The Editor
Pathways to Learning
Joshua Trupin

For as long as we've been creating magazines, we've created our September issue with sort of a "back to school" motif. Of course, we realize that this timeframe isn't always exact. For instance, much of the United States goes back to school in late August. And some people seem to never stop going to school.
However, for most of us, September is close enough. And TechNet Magazine is the higher education institution that grants the IT pro degree. OK, so we just made that up. But we don't make up the education you get with our magazine. We've developed a full syllabus of instruction this month.
Like all good institutions of higher learning, we offer a variety of educational experiences, from introductory courses on SQL for the scripting fan (in "Hey, Scripting Guy!") to a survey of Active Directory management tools.
Our intermediate-level studies include a degree track in Windows Vista. First you learn how to deploy Windows using Business Desktop Deployment (BDD 2007). Then, once you have Windows Vista deployed in your enterprise, you also receive guidance on how to implement regular backups on your systems, with a look at some of the key technologies available to you today.
Now you're getting close to your IT pro diploma, and you can take advantage of our advanced coursework in Active Directory studies. If you've ever wondered about tombstone reanimation but didn't want to wait until our special Halloween issue, you can dig right in this month.
TechNet Magazine, of course, is just one pathway to learning. The Microsoft TechNet site offers more distance-learning courses for you. TechNet features hundreds of webcasts on key technologies for IT pros, including demonstrations of how Microsoft IT uses technology internally. The webcast offerings are broken down by audience type (IT pros, executives, and so forth) and technologies, and they're rated by level of difficulty, just like in a real college catalogue.
To give just one example, TechNet Magazine offers several in-depth pieces about Active Directory this month. But maybe you're a step away from really being able to put them to their best use. Just go to TechNet webcasts and watch the Level 200 presentation called "Active Directory Fundamentals" (msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295120).
Today's educational opportunities come in many forms. From the magazine to the Internet, we're here to give you the information you need. After you've read some of our articles, why not come visit the TechNet Magazine blog (blogs.technet.com/tnmag) for a little post-class chat over coffee?
—Joshua Trupin

Thank you to the following Microsoft technical experts: Paul Bowden, Justin Hall, Anand Lakshminarayanan, Eduardo Laureano, Mike Lewis, Tim Mintner, Michael Murgolo, Mark Russinovich, and Jim Truher.


 Letters: Answers to Your Questions
Letters
Answers to Your Questions

PsTools
In the March 2007 Desktop Files column, Wes Miller talks about the PsTools utilities ("A PsTools Primer," see technetmagazine.com/issues/2007/03/DesktopFiles). I'm having a little trouble trying to get these awesome utilities to run. I am especially interested in PsLoggedOn. Could you please explain exactly how to put these great utilities in a folder on my path? An example would really help.
—Tim

The best way to get started is to download the full PsTools package (download.sysinternals.com/Files/PsTools.zip) to a working directory (for example, c:\toolbox). Once you've extracted the ZIP file into that directory, the tools are ready to use. If you'd like to add that directory to your PATH so that the tools can be executed from anywhere, simply run the following command from a command prompt, substituting your working directory for c:\toolbox:
SET PATH=%PATH%;c:\toolbox

Robocopy Praise
Until reading your November 2006 article on Robocopy GUI (technetmagazine.com/issues/2006/11/UtilitySpotlight), our help desk was stumped and could find no way to preserve timestamps of files being moved from network folders to SharePoint® stores. Robocopy is one great tool!
—Cristino

Checking Registry Subkeys
For the past couple of weeks, I have been trying to figure out how to test whether the value for the EnableLUA registry subkey is on or off. When it is off, User Account Control is disabled. That's what we want so we can install programs automatically in our test lab without having to log in with an administrative account for confirmation. We want to put this test at the beginning of all of our installation scripts and then run a script that changes the value of EnableLUA from 1 (on) to 0 (off) before the script is run. However, I have been drawing a blank on how to make this test work. I would really appreciate any help you might be able to offer.
—Derek

Here's a basic script to read a registry key, check the value, and change the value if necessary. This example reads the key HKLM\Software\Microsoft\Test\TestKey, checks to see if the value is 1, and if it is, change the value to 0; if the value is not 1, the script quits:
On Error Resume Next
Set WSHShell =  Wscript.CreateObject _
    ("Wscript.Shell")
RegLoc = _
    "HKLM\Software\Microsoft\Test\TestKey"
KeyValue = WSHShell.RegRead(RegLoc)
If (KeyValue = "1") then
  WSHShell.RegWrite RegLoc,"0"
end If
Wscript.Quit
As always, be sure to use scripts that modify the registry with great care—especially in a case like this.

ReadyBoost
Could you explain ReadyBoost to me a bit more clearly? As I understand it, ReadyBoost acts like a buffer between a machine's RAM and hard drive, but the data will be written simultaneously. Doesn't this mean that performance will decrease as the system double-copies data? How do I test the performance of the system with and without ReadyBoost?
—Alex

The idea of ReadyBoost is to allow flash memory (USB sticks and so forth) to act as a temporary cache, augmenting the amount of (often more expensive) traditional RAM. ReadyBoost does not necessarily write the same data to flash memory and the hard disk simultaneously. Rather, it acts as an intermediate caching layer between RAM and disk. Mark Russinovich explains this a bit more in his March 2007 article "Inside the Windows Vista Kernel: Part 2" where he says:
"After the ReadyBoost service initializes caching, the Ecache.sys device driver intercepts all reads and writes to local hard disk volumes (C:\, for example), and copies any data being written into the caching file that the service created...
...When ReadyBoost sees random reads that can be satisfied from the cache, it services them from there, but because hard disks have better sequential read access than flash memory, it lets reads that are part of sequential access patterns go directly to the disk even if the data is in the cache."
You can read the rest of Mark's article online at technetmagazine.com/issues/2007/03/VistaKernel.

Windows PE Download
There seems to be some inconstancy in your Letters column in the May 2007 issue. The first question, "Making an Image," says, "You can build and customize Windows® PE 2.0 images with tools found in the WAIK..." This implies that Windows PE is included in the tools and is downloadable.
In the last question, "Getting Windows PE," however, you answered, "Windows PE is (only) available as a benefit of Software Assurance..." I think your first answer is right and the second answer is out of date.
—Xihui

Windows PE 2.0 is available as a download in the Windows Automated Installation Kit (WAIK). It has different licensing rules than Windows PE 1.6 (the preceding version, which was discussed last year in "Getting Started with Windows PE." You can read this article at technetmagazine.com/issues/2006/09/WindowsPE). Windows PE 1.6 was available only as part of software assurance.

Windows PowerShell Security
There has been a lot of talk about Windows PowerShell™. I have seen many articles that tout its UNIX-like syntax, the ease of formatting command output, and more, but I haven't heard anything about security concerns when rolling out Windows PowerShell into the datacenter.
What are the security issues that come into play when deploying or running such a powerful shell as Windows PowerShell on production servers?
—Carlos

We completely agree with you that security around Windows PowerShell is an important topic. As a matter of fact, our Windows PowerShell columnist, Don Jones, delves into this topic in this issue of TechNet Magazine. In addition to this coverage, you may want to take a look at two important books that were released recently: Windows PowerShell in Action by Bruce Payette (Manning Publications, 2007) and Windows PowerShell: TFM by Don Jones and Jeffrey Hicks (SAPIEN Press, 2007). Both of these books cover Windows PowerShell in considerable depth, and both have full chapters dedicated to security.

SQL Best Practices
I have to strongly disagree with the recommendations of your answer regarding Best Practices Analyzer (BPA) and schema-qualifying objects (see technetmagazine.com/issues/2007/05/SQLQA). SQL Server™ 2005 must still resolve schemas (as opposed to only owners in SQL Server 2000, which the author erroneously calls "schemas"). The order of resolution for SQL Server 2005 is well documented in Books Online (BOL).
Thus, qualifying objects is still a best practice to avoid ambiguity errors and to save the optimizer CPU cycles resolving object names. The recommendation in the column seems in opposition to the Microsoft whitepaper, "Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005."
—Mike

We went right to the source for an answer—David Browne, a contributor to our SQL Q&A column and a Technology Architect for the Microsoft Technology Center in Dallas, Texas. He said the following:
Best practices are matters that people can and will disagree about. Especially with regard to performance, people have differing perceptions about what constitutes a significant performance difference and what a worthwhile optimization might be.
For instance, writing queries in a certain manner to save the optimizer CPU cycles in compilation is not something I have ever considered doing, and I doubt it would make a measurable difference to a realistic workload.
On the other hand, reducing the frequency of compilations by promoting query plan reuse is a commonly accepted performance optimization.

WinPE
We are using the Systems Management Server (SMS) Operating System Deployment Feature Pack (OSDFP) for OS installation. Now that Windows Vista® has been released, we want to install it through OSDFP and we upgraded to the latest version. Which version of Windows PE is provided with the newest OSDFP?
We used to create an image installation .iso file and copy it in Remote Installation Services (RIS). We then used the network boot option to boot a new machine. But we've upgraded RIS to Windows Deployment Services (WDS), which only supports a Windows Imaging (WIM) file as a boot image. How can we create a WIM image through an installation option from OSD?
—Vasishta

The version of Windows PE was not updated with the latest release of the OSDFP—it still includes version 1.5 (also known as Windows PE 2004). Even though Windows PE wasn't updated, Windows Vista deployment is now fully supported in the latest release of OSDFP.
The best process to use for creating a deployable desktop image is the one outlined in the BDD (Business Desktop Deployment) Solution Accelerator. You can find all of the necessary components and documentation online at microsoft.com/technet/desktopdeployment/bdd/2007. Also check out Michael Niehaus's article "Deploying Windows Vista with BDD 2007" in this issue of TechNet Magazine.

Windows 2003 Server Posters
I just received my July 2007 TechNet Magazine and was delighted to find two Windows Server® 2008 posters! A colleague of mine received a Windows 2003 Server poster in a previous issue. Do you know how I could get the Windows 2003 Server editions of these posters, either printed or in PDF?
—Jason

We're so glad you liked the Windows Server 2008 posters! A PDF version of the Windows Server 2003 poster is available online at go.microsoft.com/fwlink/?LinkID=80428. We only did one version of the Windows Server 2003 poster.


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

Move SQL Server Databases
xSQL Bundle Professional Edition
www.xsqlsoftware.com
It doesn't matter if you're dedicated to operational support, application development, quality assurance testing, or configuration management. If you're an IT professional (and I'm guessing you are since you're reading TechNet Magazine), moving SQL Server™ databases around is probably a part of your life. And when moving data and data schemas around, you need to be careful about inconsistencies. To help you avoid such inconsistencies, you need a good toolset to perform schema and data comparison and synchronization.
One tool I've used recently is xSQL Bundle from xSQL Software. The bundle is made up of four different applications: xSQL Object, xSQL Data Compare, and their associated commmand-line utilities.
xSQL Object lets you compare and synchronize database schemas. It provides a number of comparison options for the types and instances of objects you want to compare between databases. The application also allows you to create schema snapshots, which are handy for maintaining version history. This feature also gives you an easy way to rollback to a previous schema state. You can even generate schema scripts with xSQL Object, allow-
ing you to transport or package your database schema.
xSQL Data Compare can equate and synchronize the data contained in two SQL Server databases. It lets you choose to compare either the entire contents of two databases or select a set of tables to compare. In case your tables don't exactly match, you can define a custom table mapping to make sure that the data within those tables is the same. When synchronizing large amounts of data, the application switches to bulk insert mode, saving time on the synchronization process.
Both xSQL Data Compare and xSQL Object let you save your workspace so you don't have to constantly recreate your comparison environment. Synchronization for both applications is transactional, so you can be sure that either all operations are committed successfully or rolled-back as a whole. And all the applications in the bundle also support both SQL Server 2000 and SQL Server 2005 database instances and you can compare and synchronize relevant data and objects between versions.
Perhaps one of the more powerful features of the xSQL Bundle are the two commmand-line utilities that, in effect, let you run your comparison and synchronization tasks via any build, process, monitoring, or automated task scheduler you may have. (In my book, automation of redundant tasks always makes work-life easier and more productive.) The commmand-line utilities slurp in an XML configuration file that you can create via a configuration wizard from the main application UI, and each utility has a number of text-file logging options so you have the ability to track what's happening during your automated execution.

Price: xSQL Bundle Professional Edition starts at $499 for a single user license.
xSQL Data Compare can synchronize the data in two SQL Server databases
xSQL Data Compare can synchronize the data in two SQL Server databases

Enable More Secure Communication
WinSSHD
www.bitvise.com
If you're looking at ways to improve security in your organization, you may be considering Secure Shell Handling 2 (SSH2) and Secure FTP (SFTP). Simply put, SSH2 tunneling lets you securely connect to services on remote machines. It can also help you limit exposure to potential hackers by reducing the number of available listening, direct-to-application ports open on your firewall. SFTP is an alternative to your standard FTP server and uses SSH2 to secure your data and commands.
If these protocols sound like something you'd be interested in, you should definitely take a look at WinSSHD from Bitvise. WinSSHD is an SSH2 server designed specifically for Windows.
Installation is straightforward. The app provides an intuitive control panel for managing the WinSSHD service. The control panel is where you find everything from basic start/stop functionality to a customized view of the Windows®Event Log (where you can filter for WinSSHD events). This is also where you go to launch the settings panel, which lets you configure the nitty-gritty details of your setup. You can set interface and port bindings, tweak the logging configuration, specify SSH session encryption methods that you want to enable, configure session timeouts, choose authentication methods, specify proxy configurations, and control who has access to the instance. You can also import and export configurations.
Access control settings give you the ability to restrict access via IP rules (with masking support for subnet control) and by DNS name rules (which are processed after your IP rules).
WinSSHD supports virtualization, which is fantastic for SFTP implementations. This means you can assign thousands of virtual users to one Windows account, simplifying account and security details. The application also supports Windows groups for authentication and access control, so you don't have to define a policy on a per-user basis.
With support for Kerberos 5 and NTLM authentication, WinSSHD can be integrated into a single sign-on environment. Accomplishing this task requires a GSSAPI-enabled SSH client such as Tunnelier, which is a nice companion product that is also available from Bitvise. Tunnelier is, as you might expect, completely compatible with the WinSSHD server. It can also be used to configure your WinSSHD server remotely.
If your SFTP or SSH2 server environment is mission-critical, you can cluster WinSSHD for high availability. This is a fairly straightforward task, but if you find you need some assistance, the company's Web site provides information and configuration guides on setting up clustering, port-forwarding, tunneling Remote Desktop, and so on.

Price: $99.95.
WinSSHD lets you specify SSH session encryption methods
WinSSHD lets you specify SSH session encryption methods

Monitor USB Activity
USB Monitor Professional
www.hhdsoftware.com
Here's a product for all types of users. Maybe you're a DIY software junkie who likes to create and modify drivers for your USB devices. Or you might be a hardware engineer who actually creates USB devices. Or perhaps you have simply found yourself staring at the activity light on some USB device wondering what exactly was causing so much activity. If any of these scenarios ring true, USB Monitor Professional from HHD Software can help out. This utility allows you to record, display, and analyze the data being transferred between a USB device and a Windows-based system via the USB host controller.
The UI is a tad convoluted, but once you get used to it you can gather vast amounts of information about the data passing to and from the USB device being monitored. By default, the application records most of the commands and command sets passed to a USB device. With some devices, notably mass storage, this can be quite verbose. Fortunately, you can customize what data you want the app to record for mass storage devices.
Once you record a session, you can then analyze the data in a number of ways. For mass storage devices, you get the Mass Storage View. There are also options for a linear graph of statistics and device throughput, a raw packet and control request view, a data packet decoder view, an HID-specific view, and a Still Image View (which will decode the USB Still Image protocol for applicable devices).
Due to the amount of data recorded by the application, you wouldn't want to leave a USB recording session running for too long. Still, you can restrict the maximum amount of disk space allowed for active recording sessions and compress the recorded data to reduce the space needed.

Price: Starts at $175.99 for a regular license.
USB Monitor Professional records the commands passed to a USB device
USB Monitor Professional records the commands passed to a USB device

Manage Virtual Media
Virtual CloneDrive
www.elby.ch/fun/software
Dealing with physical media can be a real drag. Since switching to Windows Vista and losing direct compatibility with the Microsoft Virtual CD-ROM Control Panel, I have been looking for a replacement to mount CD and DVD images. (By the way, for those of you who are interested, you can find the Microsoft®Virtual CD-ROM Control Panel for Windows XP at go.microsoft.com/fwlink/?LinkId=94801.)
Sure, it is possible to run the Virtual CD-ROM Control Panel in Windows Vista. The problem is that you always have to run as Administrator and you can only see the mounted drive under the Administrator context, which means via a Run as Administrator command prompt—but not within your user's Windows Explorer context. As a result of this, not only does the tool not work as I need it to work, but it also requires me to run the app in a less secure environment.
One tool I've found that does work within your Windows Vista user context
is Virtual CloneDrive from Elaborate
Bytes. The application installs itself as a GUI management application and a storage controller you can see from the
Device Manager. Once installed, the application has three basic settings. First,
you can specify the number of virtual drives you would like to use, with a maximum of 8 drives in parallel. Second, and perhaps my favorite option, you can choose to set the Virtual Sheep setting which replaces the standard CD/DVD drive icon with an angry sheep, so you know what drives are ISO drives versus real physical drives on your system. Finally, you can choose to automount the last image that you had assigned to that virtual drive on startup.
In addition to ISO files, Virtual CloneDrive can also mount and read .ccd, .dvd, .img, .udf, and .bin files. Also, it integrates into Windows Explorer, giving you quick access to mounting and unmounting images. And one of the best things about Virtual CloneDrive is that it's free. If you've moved to Windows Vista®and have been looking for a new solution to manage ISO files, definitely check out this tool.

Price: Free.
The angry sheep of Virtual CloneDrive
The angry sheep of Virtual CloneDrive

Book Review
SharePoint Products and Technologies Administrator's Pocket Consultant
microsoft.com/MSPress/books/10623.aspx
Today's office may not be paperless, but there certainly are more and more electronic documents to deal with. Managing these documents and how they are shared is a growing issue and many companies are considering Microsoft SharePoint®Services and SharePoint Server as solutions. Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant, by Ben Curry can help. Whether you are just considering SharePoint, you're knee-deep in the planning stages, or you already have a SharePoint infrastructure in place, this administrative-feature and daily-task reference is a great companion.
For those of you familiar with the Administrator's Pocket Consultant series, this guide will feel very familiar. It is on par with the others in terms of its level of content and structure. This particular book covers Windows SharePoint Services 3.0, SharePoint Server 2007 Standard, and SharePoint Server 2007 Enterprise Edition. It's split into four sections.
The first section, "SharePoint Products and Technologies Fundamentals," provides an overview of the components, versions, requirements, and installation of the SharePoint Server products. This section explains what differentiates Windows SharePoint Services 3.0 and the Standard and Enterprise versions of SharePoint Server. Then the section guides you through the installation of each of the three products. It also details what SQL Server databases and IIS Web sites are created during the installation process.
The next section, "SharePoint Core Administration," covers the Central Administration UI and offers references on how to create new Site Collections and sites, how to import, use, and edit Web Parts, and how to configure Group and email settings for the installation. Here, too, you can see how to manage the different Workflow features and monitor those Workflows.
The third part of the book, "Working with SharePoint Server 2007," delves into the features and functionality specific to SharePoint Server Standard and Enterprise versions. It covers such topics as how to configure Enterprise Content Management, how to create and configure SharePoint Portals, how to set up Search and Indexing, and how to configure the Excel®Calculation Services. The Excel Calculation Services section also provides guidance on how to configure services in a multi-server environment to increase performance and availability.
The fourth section expands on the operational aspects of a SharePoint Server implementation, showing you how to scale out SharePoint Server 2007 to a server farm and the different possible configurations for that implementation. Finally, the book shows you the basics of the Backup and Restore operations, how to analyze performance, and how to use the logging features of SharePoint Server to help maintain and improve your site.
While the book labels itself as a daily reference for administrators, I think those of you in the planning stages as well as those just curious about SharePoint will find this a quick way to better understand SharePoint. The structure of the book—beginning with a very basic discussion that details the different SharePoint technologies and what they can do and moving up through increasingly complex topics such as configuring Excel Calculation Services and scaling out to a server farm—ensures that it will be a useful reference for someone just getting to know SharePoint technologies and that it will continue to be a useful reference as that person's knowledge grows.

Price: $29.99.

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.


 SQL Q&amp;A: CPU Bottlenecks, Restoring and Moving Databases, and More
SQL Q&A
CPU Bottlenecks, Restoring and Moving Databases, and More
Edited by Nancy Michell

Q My SQL Server™ CPU usage started spiking excessively all of a sudden—but nothing has changed. No new users were added, no hardware went down, no new tables were created. So what's going on?

Tip: Access during Index Creation
There are times when you want to create indexes on large tables (which can take a huge amount of time), but you want to have the data available during this process. How can you achieve both objectives?
Whenever a clustered index is created, dropped, or rebuilt, SQL Server puts a Schema modification (SCH-M) lock on the table, which prevents all user access to the underlying data for the duration of the operation. This is the case when you create a clustered index on a table. In contrast, when you create a non-clustered index on a column, SQL Server puts a Shared (S) lock on the table and this, while also preventing data updates to the underlying table, at least allows you to perform SELECT statements so you can read the data.
If read availability on the table is important during the creation of the clustered index, you can create an index on a table and make it an online operation. Here's the command:
CREATE UNIQUE CLUSTERED INDEX CLUST_IDX_SQLTIPS
ON SQLTips (tip) with (ONLINE=ON) Go;
When using online index operations on tables, SQL Server will still put an SCH-M lock for a clustered index or Shared (S) lock for a non-clustered index on the underlying table, but only for a very short period of time—during the start and end phase of the index operation. Therefore, this option provides better access for querying and updating of the underlying table during the index creation process. Just note that online index creation/operations are available with SQL Server 2005 Enterprise edition only.

A A CPU bottleneck that happens suddenly and unexpectedly without any changes or additional load on the server may have several reasons at its core, but some of the common ones include a non-optimal query plan, a poor SQL Server configuration, improper application/database design, and insufficient hardware resources.
The first thing to do in a situation like this is to identify whether your server is CPU-bound and if it is, identify the statements that are the largest consumers of CPU on your local SQL Server system. You can use Performance Monitor to determine if the server is CPU-bound by looking at the PROCESSOR:% PROCESSOR TIME counter. If you find the value for time used per CPU to be equal to or greater than 75 percent, you have a CPU bottleneck.
You should also monitor SQL Server schedulers by querying the system Dynamic Management View (DMV) called SYS.DM_OS_SCHEDULERS to see the value of runnable tasks. A nonzero value indicates that tasks have to wait for their time slice to run; high values for this counter are also a symptom of a CPU bottleneck.
You can use the following query to list all the schedulers and look at the number of runnable tasks:
SELECT
 Scheduler_ID,
 Current_Tasks_Count,
 Runnable_Tasks_Count
FROM
 SYS.DM_OS_SCHEDULERS
WHERE
 Scheduler_ID < 255
To get the top 50 CPU-intensive SQL statements, use the query in Figure 1.
Figure 1 Top 50 CPU hogs (Close Figure 1)
SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
 Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
 Total_Physical_Reads,
 SUBSTRING(b.text,a.statement_start_offset/2,
 (case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
 else
 a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
 dbname=Upper(db_name(b.dbid)),
 b.objectid AS 'Object_ID'
 FROM sys.dm_exec_query_stats a
 CROSS APPLY
 sys.dm_exec_sql_text(a.sql_handle) AS b
 ORDER BY
 [Avg_CPU_Time] DESC

Q I had to recover a SQL Server 2005 database from tape. After the restore, most of the permissions users had to the database were lost. Can you tell me what I did wrong during the restore? The data was fine, but the permissions were a mess.

A Most likely you didn't restore the master database to the same point in time and the login IDs in the user database don't match the current master database. You need to sync them up. The sidebar "Where to Get Help When Moving a Database" lists the most useful resources for getting to the bottom of the problems you experience when restoring or moving a database.

Q I developed an application in which I use a stored procedure that shreds XML data into relational tables using OpenXML in SQL Server 2005 SP1. The XML document is at most 5KB (the average is 2.5KB). The stored procedure is called many times in parallel (up to 50 times).
I'm facing serious lock contention problems and I think they might be due to OpenXML. What do you think?

A While OpenXML may be faster for shredding or converting data on a single thread than the nodes method, the nodes method normally scales better, especially if used in parallel. However, if you're going to use OpenXML at all, you should use the following guidelines to improve your overall OpenXML performance.
Instead of calling OpenXML five times with the same row pattern (as you noted you were doing in your solution), you should extract all the data with the same row pattern into a temp table and then perform your selects from the temp table. Try to release the memory with sp_xml_removedocument as early as possible. Also, it is a good idea to avoid using wildcards such as * and //, whenever possible; providing the explicit path will result in a better performing query.

Q DBCC SHRINKFILE is running really slowly on my server. Would I get better performance on a multi-processor machine? What can I do to improve the situation?

A DBCC SHRINKFILE is a single-threaded operation, which means it does not take advantage of multiple CPUs. It moves pages from the back end of the file to the front end of the file, one page at a time. And shrink, as it is often called, does not perform defragmentation; as a matter of fact, in a lot of situations, shrink increases logical fragmentation.
Some ways to improve shrink performance include moving pages in clustered indexes. If you have heaps and those heaps have many non-clustered indexes, the speed would be noticeably slow (compared to a clustered index situation).
Note also that moving pages for large object blob (LOB) data is slow, because in-row data has to be read to find the root of LOB data.
If most content of an index/table resides at the end of the file, you can rebuild the indexes to move them to the front end of the file. Rebuilding the indexes takes advantage of multiple CPUs and could use less log space in bulk_logged mode. Then when you run shrink, it will run faster.
For more information on shrinking operations, start with the entries at blogs.msdn.com/sqlserverstorageengine/archive/2007/03/29/how-does-your-schema-affect-your-shrink-run-time.aspxand blogs.msdn.com/sql-serverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx.
Where to Get Help When Moving a Database
  • How to Move Databases between Computers That Are Running SQL Server
  • How to Move SQL Server Databases to a New Location by Using Detach and Attach Functions in SQL Server
  • INF: Using the WITH MOVE Option with the RESTORE Statement
  • How to Resolve Permission Issues When You Move a Database between Servers That Are Running SQL Server
  • INF: How to Transfer Logins and Passwords between Instances of SQL Server
  • INF: Understanding and Troubleshooting the Copy Database Wizard in SQL Server 2000
  • User Logons and Permissions on a Database May Be Incorrect after the Database Is Restored
  • You Cannot Restore System Database Backups to a Different Build of SQL Server
  • How to Retrieve a Specific Table or Rows from Database Backups or Transaction Log Backups in SQL Server

Tip: Changing Ports
Anyone familiar with SQL Server knows that the default port number SQL Server listens on is 1433. While named instances of SQL Server are configured to use Dynamic Ports (meaning they can select any available port whenever a SQL Server instance starts), the default SQL Server instance always listens on port 1433. So if your server is listening on the default port and it's not tightly secured, it is at risk. But you can thwart attacks by changing the default port. Here's how.
Open SQL Server Configuration Manager and expand SQL Server 2005 Network Configuration, then Protocols. Next, double-click TCP/IP. The list of TCP/IP properties and their functions is shown in the chart below, so set accordingly.
Note that the SQL Server Database Engine can listen on multiple ports on the same IP address, so list the ports you want to use separated by a comma in the format 1433,1500,1501. If you want to configure a single IP address to listen on multiple ports, you must also set the Listen All parameter to no on the Protocols tab of the TCP/IP Properties dialog box.
Now, right-click each address and click Properties to identify the IP address you want to configure. If the TCP Dynamic Ports dialog box contains 0, indicating that the database engine is listening on dynamic ports, delete the 0. Within the IP Properties area, in the TCP Port box, type the port number you want this IP address to listen on, and then click OK. In the console pane, click SQL Server 2005 Services, and in the details pane, right-click SQL Server (<instance name>) and then click restart to stop and restart SQL Server.
After you have configured SQL Server to listen on a specific port, there are three ways for a client to connect to the port. You can run the SQL Server Browser service on the server to connect to the Database Engine instance by name; you can create an alias on the client, specifying the port number; or you can program the client to connect using a custom connection string.

Property | Description
Active | Indicates SQL Server is listening on the designated port. Not available for IPAll.
Enabled | Enable or disable this connection. Not available for IPAll.
IP Address | View or change the IP address used by this connection. Lists the IP address used by the computer, and the IP loopback address, 127.0.0.1. Not available for IPAll.
TCP Dynamic Ports | Blank, if dynamic ports are not enabled. To use dynamic ports, set to 0.
TCP Port | View or change the port on which SQL Server listens. By default, the default instance listens on port 1433. This field is limited to 2047 characters.

Thanks to the following Microsoft IT pros for answering this month's questions: Chad Boyd, Cindy Gross, John Hadden, Saleem Hakani, Stephen Jiang, Mahesh Nayak, Paul Randal, and Wayne Yu.


 Utility Spotlight: PageDefrag
Utility Spotlight
PageDefrag
Lance Whitney
Download the code for this article: PageDefrag (70KB)

Your average Windows® defragmenter can optimize most files on your hard drive, but some items are beyond the powers of most defragging tools. Files that are open and locked for exclusive use, such as the Windows page file and Registry hives, aren't normally processed by the built-in Windows defragmenter or by third-party utilities. The standard Windows APIs don't support defragmentation of these files while they're in use. Luckily, the PageDefrag utility, created by Mark Russinovich for Sysinternals, saves the day by defragging items untouched by other tools.
PageDefrag can defragment the Windows page file, Registry hives, event logs, and the hibernation file (the area on disk where memory is saved when a notebook jumps into hibernation mode). The program optimizes these files during the PC's bootup sequence before they're in use.
To run PageDefrag, just double-click the pagedfrg.exe file. The program displays the name of each file it can process for defragmentation (see Figure 1). The page file is pagefile.sys. The Registry hives appear as individual files for each hive—DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM. The event logs also display as their individual files; for example, AppEvent.evt is the Application log, SecEvent.evt is the Security log, and SysEvent.evt is the System log. Finally, the hibernation file is Hiberfil.sys.
Figure 1 PageDefrag displays the names of each file it can process
Figure 1 PageDefrag displays the names of each file it can process
Next to each file name is a Clusters column, which shows you how many clusters on the disk are allocated to the file, and a Fragments column, which indicates how many fragmented, or noncontiguous, pieces of the file are scattered around the disk. Based on this data, you can determine whether or not the files need defragmentation.
You have two options: you can defrag the files at the next bootup or at every bootup. Unless the files are heavily used or the PC is a server or other box that's rarely rebooted, you should be fine just defragmenting them at the next bootup. You can also enable a countdown so you have time to cancel the defragmentation as soon as the PC starts up.
The next time you reboot the computer, the normal chkdsk command runs, and then PageDefrag goes into action. Files already organized into contiguous clusters are bypassed. Those broken into fragments are optimized one by one. The program displays the name of each item being defragmented, tells you if the defrag is successful, and lists the number of clusters allocated to the file, both before and after defragmentation.
PageDefrag may not be able to optimize a file if the PC has too little available disk space or if the free space itself is too fragmented. In these cases, you'll need to clear up more space and run a defragmenter within Windows to optimize the free space and then try PageDefrag again.
PageDefrag usually runs quickly as it's tackling only a small number of files. However, if the files are heavily fragmented, it may take some time to complete, at least the first time. After PageDefrag finishes its work, Windows loads normally. You can then open the program again to confirm that each file is now a single fragment.
You can run PageDefrag non-interactively via the command line or through a script by using the options -e Defrag boot, -o Defrag once, -n Never Defrag, and -t Set countdown to specified number of seconds with the pagedfrg.exe file.
To learn more and download a copy, visit microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx.

Lance Whitney is an IT consultant, trainer, and technical writer. He has spent countless hours tweaking Windows workstations and servers. Originally a journalist, he took a blind leap into the IT world 15 years ago.


 The Cable Guy: Strong and Weak Host Models
The Cable Guy
Strong and Weak Host Models
Joseph Davies

An increasingly common configuration for network hosts is to be multihomed with multiple network interfaces. A multihomed host provides enhanced connectivity because it can be simultaneously connected to multiple networks, such as an intranet or the Internet. Because they can be connected to both an intranet and the
Internet, however, services running on multihomed hosts can be vulnerable to attack. In order to help prevent attack, and to get an idea of how IP traffic is processed for a multihomed host, I'm going to take a look at the weak and strong host models of multihomed hosts and then describe how these models are supported in Windows®.
RFC 1122 is the specification that describes the two models for a multihomed host that is not acting as a router and is only sending and receiving unicast IP traffic. These models, known as strong host and weak host, specify whether unicast traffic sent or received must be associated with the network interface on which the traffic travels. These models determine how a host sends and receives packets and impacts the vulnerability of the services running on the host.
Although RFC 1122 defines these models for IPv4, they also apply to IPv6. An example of a multihomed host for IPv6 is a computer using both IPv4 and IPv6 that has a network adapter that is connected to an intranet and an IPv6 tunneling interface.

Weak Host Model
In the weak host model, an IP host (either IPv4 or IPv6) can send packets on an interface that is not assigned the source IP address of the packet being sent. This is known as weak host send behavior. An IP host can also receive packets on an interface that is not assigned the destination IP address of the packet being received. This is known as weak host receive behavior.
When you have a multihomed IP host with multiple interfaces, enabling weak host receive behavior on interfaces can sometimes make the host vulnerable to multihome attacks. For example, Figure 1 shows Host A connected to both the Internet and an intranet. Host A has the public IPv4 address 131.107.89.211 assigned to its Internet interface and the private IPv4 address 192.168.17.48 assigned to its intranet interface.
Figure 1 Example of a multihomed computer
Figure 1 Example of a multihomed computer
With weak host send behavior enabled on both its Internet and intranet interfaces, Host A can send packets from 131.107.89.211 on its Internet interface, packets from 192.168.17.48 on its Internet interface, packets from 131.107.89.211 on its intranet interface, and packets from 192.168.17.48 on its intranet interface.
With weak host receive behavior enabled, Host A can receive the following types of packets (assuming that the host firewall rules permit the incoming traffic): packets to 131.107.89.211 on its Internet interface, packets to 192.168.17.48 on its Internet interface, packets to 131.107.89.211 on its intranet interface, packets to 192.168.17.48 on its intranet interface.
When you have weak host receive behavior enabled, a malicious user on the Internet can send packets to Host A's Internet interface to attack services running on Host A that are only available to hosts on the intranet. This type of attack can occur if the Internet infrastructure supports the forwarding of packets destined for 192.168.17.48 to Host A's Internet interface. You can prevent this type of attack by setting the appropriate firewall rules on Host A's Internet interface. Even if you do, however, the services running on Host A that are available to intranet clients can be at risk.

Strong Host Model
In the strong host model, the send and receive behaviors are different. With strong host sends, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. With strong host receives, the host can only receive packets on an interface if the interface is assigned the destination IP address of the packet being received.
With strong host send behavior enabled on its Internet and intranet interfaces, Host A in Figure 1 can only send packets from 131.107.89.211 on its Internet interface, and packets from 192.168.17.48 on its intranet interface.
With strong host receive behavior enabled, Host A can only receive packets to 131.107.89.211 on its Internet interface and packets to 192.168.17.48 on its intranet interface.
In Figure 1, the strong host model for Host A drops all incoming packets on the Internet interface that are addressed to 192.168.17.48 without the need for you to configure firewall rules, effectively isolating the intranet interface of Host A from the Internet.
When you choose the strong host model, remember that it might impact some types of connectivity that are designed for weak host behavior. For example, some load balancing implementations might use weak host receive behavior to receive packets on any interface and then route them to the appropriate interface internally. A host that uses weak host sends to send traffic from any source address on an interface corresponding to a fast connection can also be impacted.

Strong Host Sending and Receiving
Now let's see how the sending and receiving process works on a generic host for either IPv4 or IPv6 when you allow strong host sends and receives to be enabled or disabled on a per-interface basis.
For packets being sent, IP first checks whether a source address has already been specified. If it hasn't, IP performs an unconstrained lookup of the destination address of the packet in the routing table. In an unconstrained lookup, all of the routes in the routing table are considered. Based on the selected route for the destination, IP determines the next-hop interface (the interface used for placing the packet on the link layer) and the next-hop address. Based on the next-hop interface, IP uses the address selection process defined in RFC 3484 as needed to determine the best source address. At this point, IP has everything it needs to send the packet: the source and destination addresses, the next-hop interface, and the next-hop address.
If the source address has been specified, the source interface is known. The source interface is assigned the source address. IP then determines whether strong host sends are enabled on the source interface.
If they are disabled, IP performs an unconstrained lookup of the packet's destination address in the routing table. Based on the best matching route for the destination, IP determines the next-hop interface and the next-hop address. IP has the source and destination addresses, the next-hop interface, and the next-hop address. Note that with strong host send behavior disabled on the source interface, the next-hop interface might not be the same as the source interface.
If strong host sends are enabled on the source interface, IP performs a constrained lookup of the destination address of the packet in the routing table. In a constrained lookup, only those routes with a next-hop interface of the source interface are considered. Based on the selected route for the destination, IP determines the next-hop address. IP has the source and destination addresses, the next-hop interface, and the next-hop address. Note that with strong host send behavior enabled on the source interface, the next-hop interface is always the same as the source interface. Figure 2 shows the generic IP sending host process.
Figure 2 Generic IP sending host process
Figure 2 Generic IP sending host process
When the source address has been specified, the constrained route lookup can select a route with a higher metric among multiple routes in the routing table that are the closest match to the destination. For example, Host A in Figure 1 has two default routes; one points to the Internet with a metric of 10 and another points to the intranet with a metric of 20. Strong host behavior is enabled on both LAN interfaces.
If the sending application on Host A does not specify a source address, the result of the route lookup is the default route with the lowest metric; Host A always sends the traffic out of the Internet interface with a source address of 131.107.89.211. However, if the sending application on Host A specifies a source address of 131.107.89.211, the result of the lookup is the default route for the Internet interface; Host A sends the traffic out of the Internet interface. If the sending application on Host A specifies a source address of 192.168.17.48, the lookup selects the default route for the intranet interface; Host A sends the traffic out of the intranet interface. With the constrained route lookup, IP sends traffic with a source address of 192.168.17.48 using the default route with the higher metric.
For received traffic, IP first determines whether the traffic is destined for the host. If not, IP silently discards the packet because the host is not acting as a router. IP then determines whether strong host receives are enabled on the incoming interface (the interface on which the packet was received). If disabled, IP processes the packet. If enabled, IP determines whether the destination address in the packet is assigned to the incoming interface. If so, IP processes the packet. If not, IP silently discards the packet. Figure 3 shows the generic receiving host process.
Figure 3 Receiving host process
Figure 3 Receiving host process

Weak and Strong Host Behavior in Windows
Windows XP and Windows Server® 2003 use the weak host model for sends and receives for all IPv4 interfaces and the strong host model for sends and receives for all IPv6 interfaces. You cannot configure this behavior. The Next Generation TCP/IP stack in Windows Vista and Windows Server 2008 supports strong host sends and receives for both IPv4 and IPv6 by default on all interfaces except the Teredo tunneling interface for a Teredo host-specific relay. Figure 4 lists the commands that you can use to configure send and receive behavior for both IPv4 and IPv6 on a per-interface basis. Note that InterfaceNameOrIndex is either the name of the interface from the Network Connections folder or its interface index. You can obtain the interface index of an interface from the display of the command:
Figure 4 Commands to configure strong and weak send and receive behavior (Close Figure 4)

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
netsh interface ipv6 show interface
Weak and Strong Host Behavior and RFC 3484
To provide a standardized method to choose source and destination IPv6 and IPv4 addresses with which to attempt connections, RFC 3484 defines two algorithms. The first is a source address selection algorithm to choose the best source address to use with a destination address. The other is a destination address selection algorithm to sort the list of possible destination addresses in order of preference.
Strong and weak host behavior is in effect when determining the list of candidate source addresses for a given destination address, and this also affects the final sorted list of destination addresses. For strong host send behavior, the list of candidate source addresses consists of the unicast addresses assigned to the sending interface for the destination. For weak host send behavior, the list of candidates can include addresses assigned to any interface that has weak host sends enabled. For more information about source and destination address selection, please go to microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

By default, both weak host sends and weak host receives are disabled for both IPv4 and IPv6 for all interfaces except the Teredo tunneling interface for a Teredo host-specific relay.
For more information about RFC 3483, see the sidebar "Weak and Strong Host Behavior and RFC 3484."

Disabling Default Routes for Remote Access VPN Connections
A remote access virtual private network (VPN) client is another example of a multihomed host. Even though it might have a single LAN interface that is connected to the Internet, when a remote access VPN client completes a VPN connection, it is multihomed. It has two interfaces: its LAN interface and an interface based on Point-to-Point Protocol (PPP) for the VPN connection. It also has two IPv4 addresses: an Internet Service Provider-assigned IPv4 address for the LAN interface and a VPN server-assigned IPv4 address for the PPP-based interface.
To ensure that the VPN client sends default route traffic across the VPN connection to the intranet, Windows XP and Windows Server 2003 modify the IPv4 routing table by raising the metric of the existing default route and adding a new default route with a lower metric that uses the PPP interface. This default behavior makes the locations on the intranet reachable and almost all of the locations on the Internet unreachable for the duration of the VPN connection. It is possible to configure a VPN client for split tunneling to have simultaneous access to both Internet and intranet locations by not adding the default route for the VPN connection and adding specific routes for intranet destinations. However, there is a risk that split tunneling VPN clients can route packets between the Internet and the intranet. For more information, see microsoft.com/technet/community/columns/cableguy/cg1003.mspx.
The default VPN client behavior in Windows XP and Windows Server 2003 was designed for weak host send behavior. The route lookup always uses the default route for the VPN connection because it has the lowest metric. However, when you use strong host send behavior, the default route used for sent traffic depends on the source IP address in the packet. The route lookup for traffic from the IPv4 address assigned by the ISP will use the default route that uses the LAN interface, making all Internet locations reachable. The route lookup for traffic from the IPv4 address assigned by the VPN server will use the default route that uses the PPP interface, making all intranet locations reachable. Therefore, when you use strong host send behavior, the VPN client has a split tunneling configuration and simultaneous access to both the Internet and intranet, even for applications that do not have administrator-level privileges to directly modify the IPv4 routing table.
To prevent strong host send behavior from creating a split tunneling configuration by default, the VPN client in Windows Vista® and Windows Server 2008 automatically disables the default routes of LAN interfaces when the VPN connection completes. This behavior ensures that there is only a single active default route in the routing table that uses the PPP interface. This behavior also ensures that applications without administrator-level privileges cannot perform split tunneling.
Because of the fact that traffic from the VPN client computer must originate from the IPv4 address assigned by the VPN server, this behavior provides better isolation of the intranet from the Internet. When the VPN connection is terminated, the disabled default routes are enabled.
You can control this behavior with the command:
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written five books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.


 Windows PowerShell: Securing the Shell
Windows PowerShell
Securing the Shell
Don Jones

When the Windows PowerShell team sat down to create a new shell and the word "scripting" floated across the table, the groans of dismay were probably audible throughout Redmond. After all, previous Microsoft efforts with administrative scripting—I'm speaking of VBScript here—were not exactly problem-free. An
overly permissive execution model, combined with the penchant of most users to log on as full administrators, opened the door for disaster.
"Surely," folks in that first Windows PowerShell™ meeting must have prayed, "we're not going to go through that again." And they haven't. Microsoft has vastly improved its security reputation, in large part because it began thinking about security first rather than later in a product's development cycle. This philosophy is very much evident in Windows PowerShell.

Why Won't My Scripts Run?
Install Windows PowerShell on a fresh computer and double-click a .ps1 file: up pops Notepad, not Windows PowerShell. This is because the .ps1 file name extension—the extension used for Windows PowerShell scripts—has no association with the shell itself. In other words, you can't run a script by simply double-clicking it. The only way to run a script is to open Windows PowerShell, type the script name, and then press Enter.
Actually, just typing the script name isn't sufficient, either. You can see in Figure 1 that the file Demo1.ps1 exists in the current folder, yet typing demo1 and pressing Enter results in an error: "The term 'demo1' is not recognized as a cmdlet, function, operable program, or script file." Why is this? After all, the file is sitting right there.
Figure 1 To avoid command hijacking, Windows PowerShell requires a path to your script
Figure 1 To avoid command hijacking, Windows PowerShell requires a path to your script
This is another aspect of the Windows PowerShell security model. One trick malicious users commonly attempt in other shells is creating a script with the same file name as a built-in command. So, for example, if you wanted a user to run your script, you might name it Dir.ps1 and drop it into a folder. If you convinced the user to type Dir and press Enter, your script could run, not the Dir command the user was expecting. This technique is called command hijacking. In Windows PowerShell, you must always provide a path to such a script, making Windows PowerShell pretty well protected against command hijacking.
Running demo1 doesn't work, since there's no path, but running ./demo1 does work. This is because I've now specified a path—the current folder. That command line is less likely to be confused with a built-in command since you'd never type any kind of path if you were referring to a built-in command. Thus, requiring a path helps Windows PowerShell avoid command hijacking and confusion over what might happen when you press Enter.

A Policy for Script Execution
So you've got a freshly installed copy of Windows PowerShell, you're using the proper syntax, and you attempt to run a script. To your surprise, you're greeted with yet another error message, informing you that Windows PowerShell isn't allowed to run scripts. What??? Welcome to the shell's Execution Policy.
You can see what the current Execution Policy is by running Get-ExecutionPolicy in the shell. By default, it's set to Restricted, which quite simply means that scripts won't run. Ever. For anybody. By default, Windows PowerShell can only be used interactively, rather than to run scripts. You can use the Set-ExecutionPolicy cmdlet to choose one of four possible Execution Policy settings:
  • Restricted, the default setting, doesn't allow any scripts to run.
  • AllSigned only runs trusted scripts (more on this in a moment).
  • RemoteSigned runs local scripts without requiring them to be trusted; scripts downloaded from the Internet, however, must be trusted before they can run.
  • Unrestricted allows all scripts to run, even untrusted ones.
Frankly, AllSigned is the lowest setting any production computer should be set to. I find RemoteSigned helpful in development and test environments, but it isn't necessary for the typical user. And I see no need for Unrestricted whatsoever, and wouldn't mind if some future version of Windows PowerShell omitted this overly permissive setting.

It's a Question of Trust
Your computer is preconfigured to trust certain root Certification Authorities (CAs)—that is, servers that issue digital certificates. Figure 2 shows the Internet Options control panel application, which lists trusted root CAs. In Windows Vista®, this list is pretty short and includes only a few major commercial root CAs. By contrast, the default list in Windows® XP is large and includes many root CAs I've never heard of. When a root CA is on this list, you're essentially saying that you trust the company that operates the root CA to do a good job of verifying someone's identity before issuing a digital certificate to them.
When you obtain a Class III digital certificate—commonly called a code-signing certificate—the CA (which may be a commercial CA or a private CA that exists within your organization) must verify your identity. That digital certificate is like an electronic passport or identification card. Before giving me an ID that says I'm Don Jones, for example, the CA needs to take some steps to ensure I really am Don Jones. When you use your certificate to digitally sign a Windows PowerShell script, which you can do using the Set-AuthenticodeSignature cmdlet, you're signing your name to the script. Of course, if you're able to obtain a false certificate containing someone else's name, you can sign his name to the script, which is why it's so important that only trustworthy CAs show up on the list in Figure 2.
Figure 2 Default trusted root CAs in Windows Vista
Figure 2 Default trusted root CAs in Windows Vista
When Windows PowerShell checks to see if a script is trusted—which it does under the AllSigned and RemoteSigned Execution Policy settings—it asks three questions:
  • Is this script signed? If not, the script is untrusted.
  • Is the signature intact? In other words, has the script changed since it was signed? If the signature is not intact, the script is untrusted.
  • Was the signature created using a digital certificate that was issued by a trusted root CA? If not, the script is untrusted.
CMDLET of the Month: Set-AuthenticodeSignature
Set-AuthenticodeSignature is the key to digitally signing your Windows PowerShell scripts, allowing you to use the shell's safest execution policy, AllSigned. To use this cmdlet, you start with another—Get-ChildItem—that fetches an installed code-signing certificate:
$cert = Get-ChildItem –Path cert:\CurrentUser\my –codeSigningCert
You need to replace that file path with one that points to an installed certificate—any installed certificate will be accessible via the cert: drive. Once the certificate is loaded, run this to sign a script:
Set-AuthenticodeSignature MyScript.ps1
–cert $cert
Of course, provide the complete path to your .ps1 script file. The shell will add a signature block to the file.

How does trust improve security? Sure, a hacker could potentially write a malicious script, sign it, and convince someone in your environment to execute it. Since the script was signed, it will run. But because it was signed, you can use the signature to find the identity of the author and take appropriate action (such as calling law enforcement authorities). A person would have to be extremely stupid, though, to create a malicious script and then put his real name on it!
Of course, if a malicious user were able to get a certificate for someone else's identity—say, from a CA that didn't have a good identity-checking process—you wouldn't be able to use the signature to identify the actual culprit. This is why the root CAs you trust should have an identity-verification process you've found satisfactory.
If you use the AllSigned Execution Policy setting, you even have to digitally sign every script you produce yourself before it will run. The Set-AuthenticodeSignature cmdlet is pretty easy to use, but this can still be quite a hassle. That's where third-party software may come in handy. I recommend you select a script editor or visual development environment that will automatically sign your scripts using the certificate you specify. That way, using signatures is transparent and requires no extra effort. If you'd like suggestions for editors and development environments that support this, visit some of the online scripting forums (such as my site at ScriptingAnswers.com) and post a message asking what other Windows PowerShell fans are using.
Once you have a certificate, you can also run the following one-liner to sign all the scripts in a particular location:
Get-Childitem *.ps1 | %{Set-AuthenticodeSignature $_.fullname $cert}

Centrally Secured
The Windows PowerShell Execution Policy can, obviously, be configured on a computer-by-computer basis. But that's not a good solution for enterprise environments. Instead, you can use Group Policy. (You can download the Windows PowerShell Administrative Templates from go.microsoft.com/fwlink/?LinkId=93675.) Simply drop the file into a Group Policy Object (GPO) that affects your entire domain and set it to Restricted. That way, no matter where Windows PowerShell is installed, you can be sure that scripts won't run. Then you can apply a more permissive setting (say, AllSigned) on just those computers that should be running scripts (such as your own workstation).

Alternate Credentials
Unlike any previous administrative scripting language for Windows, Windows PowerShell even comes prepared to deal with alternate credentials in a secure fashion. For example, the Get-WMIObject cmdlet has a –credential parameter, which allows you to specify an alternate credential for remote WMI connections. The parameter will accept a user name but not a password, thus preventing you from hard-coding sensitive passwords into a clear text script. Instead, when you provide the user name, Windows PowerShell prompts you for the password using a dialog box. If you plan to use an alternate credential again, you can store the authentication information by using the Get-Credential cmdlet:
$cred = Get-Credential DOMAIN\USER
You'll be prompted immediately for the password and the final credential will be stored in the variable $cred. The $cred variable can then be passed to the –credential parameter as often as needed. You can even use the ConvertTo-SecureString and ConvertFrom-SecureString cmdlets to convert the credential into an encrypted string or to convert a previously encrypted string back into a credential.
The problem with this is that your encryption key winds up being stored in a plain text script, which completely defeats the security. So instead of doing this, you can add a call to Get-Credential to your Windows PowerShell profile. Then, when Windows PowerShell runs, you're immediately prompted for a user name and password, which are then stored in a variable named $cred. This way, you always have a $cred variable available in the shell representing a domain administrator account. And you never have to bother storing that credential anywhere—since the credential is recreated each time you open the shell, there's no need to store it.

Secure by Default
By default, Windows PowerShell is installed and configured with the most secure settings you could probably come up with for an administrative shell that supports scripting. Unless you change any of those settings, Windows PowerShell will stay as secure as it can be. In other words, anything that reduces security in Windows PowerShell is a result of your decision and your action. So before you change any of the defaults—reconfiguring file extension associations, changing the Execution Policy, and so forth—make sure you fully understand the consequences of your actions and be prepared to take responsibility for your changes.

Don Jones is the Lead Scripting Guru for SAPIEN Technologies and an instructor for ScriptingTraining.com. You can reach Don through his Web site, scriptingAnswers.com.


 Hey, Scripting Guy!: Can This Relationship Be Saved?
Hey, Scripting Guy!
Can This Relationship Be Saved?
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2007_09.exe (150KB)

Relationships do matter. But how would the Scripting Guys, of all people, know that relationships matter? Well, for one thing, we watch a lot of TV, and on TV they're always telling us that relationships matter.
And that's not just on soap operas or TV movies of the week. For example, there's a payday loan company commercial that encourages people to patronize their business. Is that because they're willing to loan money to people who probably shouldn't be getting a loan in the first place? No. Is that because they'll charge you as much as 900 percent annual interest on that loan? Of course not. It's because this payday loan company forms a personal relationship with you. As their commercial states, "Relationships matter."
Note: sure, we're crying—we're not ashamed of that. After all, you'd have to be pretty cold and callous not to tear up a little just thinking about the deep, enduring ties that bind a person and their payday loan company.
Of course, we know what you're thinking: "Gosh, if relationships matter to payday loan companies, then relationships must really matter to people who write scripts that interact with databases." And the fact of that matter is that relationships should matter to people who write scripts that interact with databases. Unfortunately, though, these script writers don't always realize that relationships matter. But that's OK; in this month's column we'll set everyone straight.
We know that a lot of system administrators use databases, often as a way to track their hardware inventory. The problem is that many of these databases are set up in somewhat less-than-optimal fashion. For example, suppose you need a database that keeps track of the disk drives attached to all your computers. If you don't have a background in database design, there's a good chance you'll create a one-table database like the one in Figure 1.
Figure 1 A one-table database
Figure 1 A one-table database
As you can see, that's a very simple design: there's a field for the computer name, and a couple of Yes/No fields used to indicate whether a computer has a C: drive and a D: drive. And that's about it. Crisp, clean, and to-the-point.
So what's wrong with this database? Well, to tell you the truth, pretty much everything. If you can be sure none of your computers have more than two disk drives, this design will work (sort of). However, what happens if you have a computer that has three disk drives? In that case, you're going to have to add another field, one that keeps track of drive E. OK, but what happens if you have a computer that has eleven disk drives? And what if you want to keep track of the properties for each of those drives? For example, suppose you'd like to keep track of the total size of each drive. In that case, you're going to need a Drive_C_Size field. And a Drive_D_Size field. And a Drive_E_Size field, and—well, you get the idea. (And heaven forbid you'd also like to keep track of available disk space, disk connector type, whether disk quotas have been enabled on the drive, and so forth.)
Here's a rule of thumb to keep in mind: any time an entity can have more than one of something (for example, a computer can have more than one disk drive), this "flat-file" (one-table) design isn't very good. True, in the case of disk drives you might think you can get away with it; after all, you're only going to have a finite number of drives connected to a computer. But suppose you want to query your database and get back a list of all the disk drives that are 100 gigabytes or larger. How would you go about doing something like that? Well, you'd have to first look for 100-gigabyte drives in the Drive_C_Size field, then look for the same thing in the Drive_D_Size field, then the Drive_E_Size field, then.... All in all, not a very efficient or effective approach. But what's the alternative? If you can't use a flat-file database, what can you use?
That's easy: a relational database. Relational databases are designed, among other things, to handle one-to-many relationships (for example, one computer that can have many disk drives). And before you ask, no, you don't have to go out and buy anything new in order to use a relational database; if you have a database of any kind (Microsoft® Access™, SQL Server™, Oracle, whatever), the odds are that you already have a relational database. You don't need to buy anything; you just need to know two things: 1) how to set up a relationship between two tables in that database; and 2) how to write a script that can take advantage of that relationship.
Note: according to TV you should never try to take advantage of a relationship. But this is different.
Because this column isn't called Hey, Database Design Guy!, we won't spend a lot of time discussing database design. Instead, we'll just show you a very simple relational database design that will enable us to talk about writing relational queries. In this database we have two tables. The first is named Computers and consists of a pair of fields: ComputerName and SerialNumber. The ComputerName field is where we'll store the computer name, and the SerialNumber field is where we'll store—oh, you guessed it. That's right, the serial number.
Then where in the world do we put our disk drive information? That goes in our second table, which is named DiskDrives. This table contains three self-explanatory fields: SerialNumber, DriveLetter, and DriveSize.
The key field here is SerialNumber. If that field name sounds familiar, well, it should: we have the exact same field in the Computers table. And that's not an accident or a coincidence; we did it on purpose. In order to establish a relationship between these two tables we need to have one field that appears in each table; that's how we can tell which disk drives belong to which computers.
Why did we link the two tables using serial number rather than, say, computer name? There's actually a good reason for that: computer names can (and often do) change. Serial numbers typically don't.
But enough talk. Let's take a look at Figure 2, a script that can search these two tables and retrieve a list of the disk drives that belong to each computer. Figure 3 shows the kind of data this script returns.
Figure 3 Search results (Close Figure 3)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-01
E:

atl-ws-02
C:

atl-ws-02
D:
Figure 2 Searching the tables (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
 "Provider = Microsoft.Jet.OLEDB.4.0; " & _
 "Data Source = c:\scripts\test.mdb"

objRecordSet.Open "SELECT Computers.*, DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber " & _
 "ORDER BY Computers.ComputerName, DiskDrives.Drive", objConnection, adOpenStatic, _
  adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
 Wscript.Echo objRecordset.Fields.Item("ComputerName")
 Wscript.Echo objRecordset.Fields.Item("Drive")
 Wscript.Echo
 objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
We're not going to discuss the fundamentals of connecting to and working with databases in this month's column; if you're new to database scripting you might want to take a look at the Scripting Guys webcast "Database Scripting for System Administrators" (go.microsoft.com/fwlink/?LinkId=22089). All we will say is that we are connecting to an Access database (C:\Scripts\Test.mdb) and working with relational tables named Computers and DiskDrives. That much should be pretty clear from the script.
OK, one more thing we will say is that you need to make one small change to get this to work with Access 2007: it's important that the Provider needs to be changed from Microsoft.Jet.OLEDB.4.0 to Microsoft.ACE.OLEDB.12.0, like this:
objConnection.Open _
 "Provider = Microsoft.ACE.OLEDB.12.0; " & _
 "Data Source = c:\scripts\test.accdb"
That's it. What we're going to do, instead, is focus on the SQL query that retrieves data from our two tables:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
Complicated? Maybe a little. So let's see if we can break this down a bit and make it easier to digest.
The first part of our query is actually pretty easy. We want to select all the fields in both tables: Computers and DiskDrives. Hence this bit of SQL:
SELECT Computers.*, DiskDrives.*
That's not too bad; the asterisk, needless to say, is simply a wildcard character that means "everything."
If you've written SQL queries before (or if you've written Windows® Management Instrumentation, or WMI, queries, which use a subset of the SQL query language), you know the routine: after specifying the items you want to select, you next specify where you want to select these items from. Thus the next piece of our query puzzle:
FROM Computers INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber
Don't let this throw you. True, it's more complicated than a typical FROM statement, but for good reason. After all, in a typical SQL query we only select data from one table; this time we're selecting data from two tables at once.
Let's take a closer look at the syntax and see how it works. As you can see, we're asking the script to select data from the Computers table and from the DiskDrives table. Notice, however, that we don't use the word "and"; instead, we use the term INNER JOIN. This term defines the type of relationship and, in turn, describes how we're going to join information from two separate tables into a single recordset. (And yes, there are other types of joins; we'll discuss those in a few minutes.)
As we've implied, it's up to us to specify the type of relationship that exists between our tables; it's also up to us to specify exactly how those tables are related. That's what this bit of code does for us:
ON Computers.SerialNumber = DiskDrives.SerialNumber
What we're doing here is defining how we're going to join our tables. Records will be grouped together any time the SerialNumber field in the Computers table matches the SerialNumber field in the DiskDrives table. What if we had used a different field (say, ComputerName) as our joining field? Well, then our code would look like this:
ON Computers.ComputerName = DiskDrives.ComputerName
In case you're wondering, no, the two fields do not have to have the same name; they just need to contain the same data. Using the same name makes it easier to identify the relational field. There's just one minor catch to keep in mind: because we have two fields with the same name, we need to always use the syntax Table.Name.Field.Name when referring to one of these fields. That means using code like this: Wscript.Echo obj- Recordset.Fields.Item("Computers.SerialNumber").
That's really all we need; the rest of the query merely sorts the data, first by computer name and then by drive:
ORDER BY ComputerName, Drive
See, that wasn't so bad, was it? We need to pause for a few seconds now and talk about joins. Why did we use an inner join in our query? That's easy. An inner join returns only records that have matching values in each table. In other words, suppose we have serial number 121989. If that serial number appears in both the Computers and DiskDrives tables, the corresponding records will be returned. (Of course, the serial number can't just show up anywhere; it must be in the SerialNumber field.) Does this make sense? Good.
Now, suppose we have a computer that has the serial number 121989; however, there are no disk drives with that serial number. In that case, no data for the computer with serial number 121989 will be returned. That's because an inner join only returns information if a record has matching values in each of the joined tables.
In other words, an inner join query returns all the computers that have hard disks; what it won't return are any computers that don't have hard disks, or any hard disks that aren't installed in a computer. That's good; that's often what we want. But what if you do want a list of computers that don't have hard disks or hard disks that don't have computers? What then?
That's what the outer join is for. (Oh, so that's what the outer join is for!) For the time being, we're going to say that there are just two different types of outer joins: Left and Right. In our database we have two tables: Computers (which is considered the "left" table because it's the master table) and DiskDrives (which is considered the "right" table because it's, well, not the master table). Suppose we want our returned recordset to include all computers, even those that don't have any disk drives installed. In that case, we use the syntax LEFT OUTER JOIN, and a query that looks like this:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "LEFT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
As you probably figured out, a left outer join returns all records in the left table, even if there are no corresponding records in the right table. So, we get back all computers, but only records from the right table (disk drives) that are associated with a computer.
Alternatively, maybe we want a list of all the disk drives, including those that aren't installed in a computer. Because the DiskDrives table is the right table in the relationship we use the syntax RIGHT OUTER JOIN, like so:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "RIGHT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
Now that we think about it, if DiskDrives is the right table in the relationship, then by all rights Computers should be known as the husband table in the relationship instead of the left table. As some of the Scripting Guys know through painful experience, the husband is never the right entity in a relationship.
With the right outer join we'll get back all the records in the right table (all the disk drives), but only computers (records in the left table) that are associated with a disk drive.
This might not make a lot of sense at the moment, but if you play around with it a bit you'll see how it works. If you need a database to play around with, we've posted a sample one at microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx.
It is important to mention that any time you use an outer join you should also, at the very least, make On Error Resume Next the first line in your script. Why? Well, suppose we do a left outer join; in that case it's possible we'll get back some computers that don't have any hard disks installed. That's fine (after all, that's what we want to get back), at least until we encounter this line of code, which echoes back the drive letter:
Wscript.Echo objRecordset.Fields.Item("Drive")
Because no Drive field exists for this particular computer, the script will come to a crashing halt:
C:\Scripts\database.vbs(22, 9) Microsoft VBScript runtime error: Type mismatch
If we implement On Error Resume Next, however, the script can ignore the fact that a computer has no disk drives and it can continue on its merry way. Alternatively, you could use code such as this to check the value of the Drive field and then take the appropriate action:
If IsNull(objRecordset.Fields.Item("Drive")) _Then
    Wscript.Echo "No disk drives installed."
Else
    Wscript.Echo _
      objRecordset.Fields.Item("Drive")
End If
With this code we check to see if we get back a Null value as opposed to an actual drive letter. If so, then we echo the message "No disk drives installed." If we don't get back a Null value, then we simply echo back the value of the Drive field. The net result is output, as shown in Figure 4.
Figure 4 Display appropriate results (Close Figure 4)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-02
C:

atl-ws-02
D:

alt-ws-03
No disk drives installed.
Without going into much explanation, let's look at a couple more queries. For example, here's an inner join query that returns a list of computers and their installed disk drives, provided those disk drives are larger than 50 gigabytes (we're assuming that drive sizes are stored in gigabytes):
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "WHERE DriveSize > 50 " & _
 "ORDER BY Computers.ComputerName, " & _
 "DiskDrives.Drive", objConnection, _
 adOpenStatic, adLockOptimistic
As you can clearly see, all we did was add a standard WHERE clause to the original query:
WHERE DriveSize > 50
What if we only wanted information about Drive E on computers? No problem—just add the appropriate Where clause:
WHERE Drive = 'E:'
And here's a slightly more complicated query, one that returns a collection of computers that have no disk drives installed:
objRecordSet.Open _
 "SELECT Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "FROM Computers LEFT JOIN DiskDrives " & _
 "ON Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "GROUP BY Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "HAVING (DiskDrives.Drive) Is Null " & _
 "ORDER BY Computers.ComputerName", _
 objConnection, adOpenStatic, adLockOptimistic
Like we said, this one's a little more complicated, and since we're running out of space we won't explain how it works. But it does work, which is the most important thing.
Well, maybe the second most important; as we've pointed out several times, it's relationships that truly matter. Which doesn't mean that relationships can't go awry. As Woody Allen said at the end of "Annie Hall," "A relationship...is like a shark; it has to constantly move forward or it dies. And I think what we got on our hands is a dead shark." Oh, if only Woody had known about inner joins and outer joins. With these query techniques, you'll always have successful relationships!

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


 Exchange Queue &amp; A: Setup, Message Journaling, Storage Options, and More
Exchange Queue & A
Setup, Message Journaling, Storage Options, and More
KC Lemson and Nino Bilic

Q I'm running Exchange Server 2007 setup and I need to know if I can bypass the prerequisite check. I don't want to fix all the issues that prerequisite check told me to; I just want to run setup and be done with it!

A The short answer is no, you cannot. You really must fix any issues that the prerequisite check flags if these issues block setup from continuing, or your long-term Exchange experience will suffer.
Some admins have tried to edit the ExBPA.PreReqs.xml file (which is the file that contains the list of Exchange 2007 setup prerequisites) and remove the checks that are causing the setup block. This does not work, however, as the XML file is digitally signed, and any modification of its contents will make the signature invalid.
This is all to prevent you from creating an installation that will not work properly. We have tested Exchange 2007 in different environments and learned that some configurations and settings work better than others, and some can present real problems. Prerequisites are there to make sure that your setup has the best possible chance of succeeding, based on our experiences and testing.
If you find a genuine problem with Exchange 2007 prerequisite check, and it is blocking setup in your environment, you should open a case with Exchange support.

Q Where do I find the setup log? I can't find it in the root of the C: drive.

A All setup logs are now stored in the %SYSTEMDRIVE%\ExchangeSetupLogs directory, which in most installations means c:\ExchangeSetupLogs. You'll find multiple files in there, two of which are of primary interest:
ExchangeSetup.log This is the log that contains information about tasks and parameters that were used when setup was run. When server roles are being configured, the information about tasks that were run to configure the server is also recorded into this log. This is also the place where you will want to check for the majority of information pertaining to your server setup. Service pack setup will also append to the same file.
ExchangeSetup.msilog This file contains information about the unpacking phase of setup. When the Microsoft® Installer is copying files to their destinations from a temporary location, it logs into this file. So, if you have an issue that could be related to the ability to copy files or to accessing files during setup, this is the log that might be helpful.

Q I know that the prerequisite check is powered by the Exchange Server Best Practices Analyzer (BPA), so where can I find the report for the prerequisites?
A If you want to find a report that BPA created during the prerequisite check, look at the following folder:
%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs
The file names have a standard format:
ExBPA.<dateandtime>.data.xml
If you are trying to figure out what a specific prerequisite check was looking for, find the XML file that contains the error message you saw and, just above the message, you will see the rule definition that was being tested.
Q How do I read setup logs? What options do I have?
A There are generally two ways to go about reading setup logs. You can run Get-SetupLog from the Exchange Management Shell, or you can just open the setup log file in Notepad or your favorite text editor.
If you use Get-SetupLog, here is an example of how you would pull up any warnings or errors:
Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error
If you want to make it pretty, you should get the Out-HTML.ps1 and Out-IE.ps1 scripts, which are available in the Exchange 2007 PowerShell Scriptacular demo pack. (Read more on our blog at msexchangeteam.com/archive/2006/12/27/431998.aspx.)
Once you get those scripts, place them into the Exchange scripts folder (by default c:\program files\microsoft\exchange server\scripts) and then run the following:
Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE
This will open an easy-to-navigate browser window with an HTML view of errors that might have happened during setup (see Figure 1).
Figure 1 Out-HTML and Out-IE make the view of your setup logs easier to read
Figure 1 Out-HTML and Out-IE make the view of your setup logs easier to read
If, on the other hand, you opt to view the exchangesetup.log using Notepad, here are a few tips:
  • To find a start of the setup run, search for: [0] Starting Microsoft Exchange 2007 Setup.
  • To find an end of a setup run, search for: [0] End of Setup.
  • Major setup tasks are separated by: [0] **************.
  • To look for an account that ran setup, search for: [0] Logged on user.
  • If you want to see which domain controller was used during setup, search for: [0] Setup will use the domain controller.
Generally speaking, when reviewing setup logs using Notepad, you should start at the end of the file and go back in time to see what the problem was. Errors are usually some of the very last pieces of information that are logged into the setup log.

Q Can I use Exchange 2007 Unified Messaging with my PBX?

A You probably can. Check out microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx for a list of the supported VoIP gateways and PBXes. Any changes to the list of supported products will be added to this page.
Q I have a client running Small Business Server 2003 with Exchange, and the company policy requires that all mail be monitored. To perform the monitoring, I want to send a copy of all incoming and outgoing mail to the administrator's account. How can I make this happen?
A What you need is message journaling, which allows you to keep a copy of all messages sent to or from a specific mailbox database in a separate journaling mailbox. There are a variety of options that let you configure how detailed the journaled copies should be (for example, do you want to capture BCC recipients?), and an additional tool you can download to get some advanced features, at go.microsoft.com/fwlink/?LinkId=93725. Journaling in Exchange 2003 is enabled on a per- database level, so every user in that database gets journaled. After you create the mailbox to hold the journaled messages, go to the properties of the mailbox store in Exchange System Manager and check the box to archive messages sent to or received by mailboxes on that store. Depending on your business policies, you may also want to enable the mailbox manager to automatically clean out old journal copies from the journal mailbox.
Exchange 2003 has another feature similar to journaling, called the archive sink. Unlike journaling, which saves copies of the messages to another mailbox in Exchange, the archive saves messages into a specified folder on the server hard drive. Why choose one method over the other? Journaling is generally intended for regulatory compliance scenarios, but the archive sink can be useful if you want to capture all messages coming in from or going out to the Internet, for example.
Exchange 2007 simplifies these scenarios significantly, and you can easily journal on a per-user or per-distribution-list (DL) basis. If you don't want users to know that their mail is being journaled, you can hide that DL from the Global Address List (note that this is not the same as hidden membership of a DL) or set up a custom attribute on the users and then create a Query-Based Distribution Group (also called Dynamic Distribution Lists or DDLs around here) to key off all users with that custom attribute. If you want to journal all mail in the entire organization to the same location, leave the recipient field blank when creating the journaling rule. Also note that if you want to use any journaling other than per- database in Exchange 2007, you'll need the Enterprise Client Access License (CAL) for those users. You'll find more information at microsoft.com/exchange/howtobuy/licensingFAQ.mspx. If you don't want that CAL or any of the other features, you can continue to use the per-database journaling feature from Exchange 2003. Finally, have a look at David Strome's article from the December 2006 issue of TechNet Magazine entitled "More Powerful Journaling in Exchange 2007," at technetmagazine.com/issues/2006/12/journaling.

Q All of my users run Microsoft Office 2003, and we have no plans to move to the 2007 Office system until a hardware refresh in 2008. From what I've read, though, I'm afraid they'll miss out on some features because of this. Will they be able to use Unified Messaging?

A Absolutely. In Office 2003, Unified Messaging-enabled users can receive voicemail messages and faxes in their mailboxes, as well as call in to access their mailbox via any phone. If you don't upgrade to Outlook 2007, the Unified Messaging feature you'll miss is the ability to configure voicemail settings through the Options tab in Outlook, as well as the special custom form that shows up on a voicemail message in Outlook and lets you play the message inline without having to launch a separate media player. In addition the feature that lets you write audio notes and save them with the voicemail message will not be available. But even without Outlook 2007, your Unified Messaging-enabled users can still use OWA 2007 to access the Unified Messaging settings (on the OWA options page) as well as use the custom form for voicemail in OWA.

Q My company already has a Storage Area Network (SAN) and I want to hook up Exchange 2007 to it. But I've heard a lot about direct attached storage (DAS) that makes me wonder whether I should choose that option. What do you think?

A There isn't a right or wrong answer to this question; it really depends on your company's policies and scenarios (especially if you already have a SAN). If you're thinking of buying a new SAN, adding another one, or otherwise considering an upgrade, we highly recommend you consider DAS. Here's some information to take into account: as of June 2007, Microsoft IT has deployed 17 Exchange 2007 mailbox servers for 40,000 mailboxes (with quotas ranging from 500MB to 10GB), all using Cluster Continuous Replication (CCR) with DAS. By September we plan to have 35 Exchange 2007 mailbox servers with 152,500 mailboxes all on DAS. So if you're wondering if DAS is appropriate and workable on an enterprise scale, it absolutely is. DAS has been key in allowing Microsoft IT to increase user quotas while decreasing overall storage costs. More information on this topology and deployment and the savings involved is at microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx.
Although it may initially seem like a huge savings in storage to have all of your servers hooked up to the same SAN, it is not without risk. For example, one problem that commonly occurs is related to the different usage scenarios for the software hooked up to the SAN. If you have an HR application on the SAN that runs a batch process every evening at 5:00 PM, for example, that I/O spike could seriously affect your Exchange users. Lack of deterministic I/O is a common problem with shared SAN deployments.
An advantage we've also realized with DAS is that it's simpler to manage because it doesn't require dedicated storage administrators or special equipment. It's incremental and easy to buy and expand later. And it's generally inexpensive enough that if you want to have spares lying around, it won't break the bank.

Q I have installed my first Exchange 2007 server. Now, when I try to connect to it using Outlook 2003, I get an error stating that the administrator has blocked my Outlook version. ("Your Exchange Server administrator has blocked the version of Outlook that you are using. Contact your administrator for assistance.") But I am the administrator and I never blocked it. What is going on?

A This behavior is not unexpected. When Exchange 2007 is being installed, the Setup wizard asks whether you are running any Outlook 2003 or earlier or Entourage clients in your organization (see Figure 2). If you answered no to this question, you may encounter this problem.
Figure 2 The Exchange 2007 Setup legacy client question
Figure 2 The Exchange 2007 Setup legacy client question
To resolve this issue after the fact (after setup has completed), you can simply create a public folder store using the Exchange Management Console or the Exchange Management Shell and restart the Information Store service. Restarting the Information Store service is mandatory in this case, and legacy clients (Outlook 2003 and earlier) will not be able to connect to the server until the service is restarted.
Additionally, if you are running the unattended setup of Exchange 2007, you can use the /EnableLegacyOutlook switch to specify how you want to answer the question about legacy clients.

Q Why would Exchange 2007 care if I connect to the server using older versions of Outlook? Why does creating the public folder store and restarting the Information Store service fix this problem?

A The answers to these questions revolve around the presence of the public folder store. If you recall, the public folder store in previous versions of Exchange is used to store the users' Free/Busy data, among other things. When a legacy Outlook user is connected to his Exchange server using MAPI or RPC over HTTP and publishes something to his calendar, the information about his Free/Busy status is also published to the server into a special public folder called the Schedule+ folder. This is the only way that legacy Outlook clients know of publishing users' Free/Busy data to the server and actually the only way a legacy Outlook knows how to read other users' Free/Busy information.
Exchange 2007 knows this. That's why if there is no public folder store, Exchange 2007 blocks earlier versions of clients. If Exchange 2007 allowed the legacy client connection, the client would encounter frequent errors as Outlook could not connect to the public folder store to publish Free/Busy data, and the client functionality would be limited as Free/Busy lookups that a user wants to do (when trying to schedule a meeting with someone else, for example) simply would not work. This is also why creating the public folder store resolves the issue, as Exchange 2007 server then knows that legacy clients can use the Free/Busy publishing functionality, so the mailbox logon is allowed.
From all this, there is one more thing you could have concluded: that Outlook 2007 clients do not require the public folder store to publish their Free/Busy information. This is true, but with a twist.
Without going into too much depth, let us just say that if a public folder store is present on an Exchange 2007 server, even an Outlook 2007 client will publish users Free/Busy data to it. The reason that this is done is so other clients, some of which are presumably legacy Outlook clients, can look up the Free/Busy information for an Outlook 2007 user; if the information is not in the public folder store, legacy clients would see no information for the Outlook 2007 user as nothing would ever populate the information into the public folder store. If the public folder store is not present, however, an Outlook 2007 client will not try to publish Free/Busy data. When there are no public stores and all clients are at least Outlook 2007, another mechanism of Free/Busy information lookup is used in which the calendar data is read directly out of the users' mailboxes, without creating a copy of this information anywhere else. If you want to read more about that, please look up information on the Availability Service in your server's help file or online Exchange documentation located at go.microsoft.com/fwlink/?LinkId=69434.

Q I just read Knowledge Base article 288894, which talks about blocking MAPI clients using a registry key (see support.microsoft.com/kb/288894). I checked my server's registry but this key was not set. How does the store execute this legacy client version block?

A A very good question! Indeed, Exchange 2007 Information Store does not use the "Disable MAPI Clients" registry value that is mentioned in that Knowledge Base article to block legacy clients. The reason for this is because there is a possibility that no public folder store exists and, therefore, no modification of that registry key can unblock those clients if no public folder store is present.
The behavior to block clients older than Outlook 2007 is simply hardcoded into Exchange 2007 Information Store. At service startup, the store checks for the presence of the public folder store, then decides whether only Outlook 2007 will be allowed to connect or if older versions will be able to connect to their mailboxes too. This check happens only at service startup. That's why you have to restart the Information Store service for the change to take effect after you create the public folder store.

KC Lemson is the User Experience Manager for Exchange Server. She is currently working toward a doctorate at a prestigious non-accredited university.
Nino Bilic is a Supportability Program Manager for Exchange Server. He is considering becoming a professional race car driver in Forza Motorsports 2.


 Security Watch: The Long-Term Impact of User Account Control
Security Watch
The Long-Term Impact of User Account Control
Dr. Jesper M. Johansson

The problem with running as an administrator is obvious: any malware that attacks users, or the applications they run, will have full control over 90 percent of the computers it infects. The User Account Control (UAC) feature in Windows Vista is the Microsoft solution to a pervasive security challenge—the fact that over
90 percent of users currently on the Windows platform run with administrative privileges. While it is possible to run as a standard user on Windows® XP—and I have—it can be extremely painful. For instance, if you travel frequently while using Windows XP, you'll find that as a standard user, you're unable to modify the time zone on your system.
UAC is the feature that is supposed to change all that. Actually, that's the first misconception. UAC is not just a feature; it is a collection of features, most of which are not particularly obvious. I won't give you an in-depth analysis of all the implementation details of UAC. For that, I highly recommend Mark Russinovich's article in the June 2007 issue of TechNet Magazine, which you can find online at technetmagazine.com/issues/2007/06/UAC.
Rather, in this piece I hope to give you an unbiased view of what UAC is, what it is not, and how that affects the way you should manage your systems that are running Windows Vista®.

What UAC Appears to Be
The most visible feature of UAC is the elevation dialog, shown in Figure 1. In fact, if you were to ask a representative sampling of Windows Vista users what UAC is, the majority would likely say something about the annoying elevation dialog.
Figure 1 UAC approval dialog for administrator in admin-approval mode
Figure 1 UAC approval dialog for administrator in admin-approval mode
In spite of the visibility and all the opinions about UAC, I do not believe that most of the discussion about UAC has very much to do with what UAC really is. In fact, there seems to be some real confusion out there. Pundits write blog posts, newsgroup entries, and articles with titles like "Vista's Most Annoying Feature," and they pontificate on how many people will turn it off and why it is so annoying.
Given that so few have bothered to understand the rationale behind UAC, why don't I start this column with a look at what UAC is?

What UAC Is
UAC is an attempt to enable more people to run as standard users. In a sense, it is version 2.0 of that effort. Version 1.0 shipped first in Windows NT® 3.1 and enabled a user to run as a non-administrator. This was a radical departure from the 16-bit Windows 3.1 and its successors, Windows 3.11, Windows 95, Windows 98, and Windows Me, none of which had any concept of low-privileged users. Whether a non-administrator could actually do anything useful depended on a lot of factors, but up through Windows XP and Windows Server® 2003, least user privilege often ranged from painful to useless. Windows Vista brings the first set of technologies aimed at making it easier to do the right thing when it comes to interactive user privileges.
While it is correct to claim that a goal of UAC was to provide some level of protection for apps running as an admin from those that were not, that was not by any means the primary purpose of UAC. The primary purpose was to start us on a path where more users run as standard user, which in turn would force developers to write more programs that work as a standard user, reducing the number of situations where users need to elevate. As developers write more UAC-compliant apps, the number of prompts the user gets goes down and the user experience gets better. In the process, ideally we end up in a situation where most people do not run as administrators and, hopefully, they start questioning some of the elevation prompts they do get. The fewer the prompts, the more likely users are to consider them carefully before allowing them.
Or so the theory goes. By extension, yes, there may be less malware, but that will depend on whether users keep UAC enabled, which depends on whether developers write software that works with it and that users stop viewing prompts as fast-clicking exercises and actually consider whether an elevation request is legitimate.
To meet the major goal of increasing the number of users who can run as a non-administrator most of the time, UAC is designed to meet a number of constituent goals:
  1. Decrease the number of scenarios that require elevation to an administrative account.
  2. Make elevation considerably easier—automatic if possible—than the previous kludges such as using runas.exe or logging out of one account and into another. In other words, bridge the gap until ISVs fix their applications.
  3. Provide some isolation for those applications running as an administrator to protect them from those that are not.
  4. Enable certain exposed applications to run with even lower privileges whenever possible.
Two of those goals aim to make the user experience of running as a non-admin as palatable as possible. Two have to do with protecting applications that are particularly exposed.
What is interesting is that only two of them are related to the feature that is popularly seen as UAC, and only one deals with the actual elevation task. Yet the elevation, when an application asks for additional privileges, is what people complain about because it is the only really visible manifestation of the collection of technologies that comprise UAC. The first overarching goal has nothing to do with elevation at all. The idea was simply to enable more people to run as non-admins most of the time. In fact, you could argue that the intention is to reduce the number of elevation events.
The goals related to the elevation task itself are goals 2 and 3. Goal number 2 is about making elevation easier than it was in Windows XP, and goal number 3 is about providing some level of protection for applications that are running elevated. The remaining goals have to do with entirely different issues. Each of these goals required changes to the operating system, however. Mark Russinovich's aforementioned article details these changes for those that are interested.
As I mentioned, there are many, many recommendations out there to disable UAC. It is likely that a number of users will do so without even trying it, and many more will get their computers from some big-box store, complete with a Windows Vista build that has UAC disabled already. I think it's shameful that retailers are disabling important security features in the operating system as part of their default deployment image.
Unfortunately, much of the advice to turn off UAC is based on the initial experience. While setting up your computer, you get a fair number of prompts as you install software and make any necessary changes. You should expect that you will have a very different administrative experience while you are configuring your computer than you will once the computer is in a steady state. The first few weeks will be quite different from the following few weeks. If you try UAC on a computer that is in relative steady-state, I think you'll find that it is really not particularly intrusive at all.

What UAC Is Not
UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.
In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."
UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.
UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.
UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.

The Buzz
Microsoft itself contributed to both the buzz about UAC and to the misunderstandings about what it does. In the Windows Vista Security Guide, for example, the "Defend Against Malware" chapter presents UAC as the primary technology that does so (microsoft.com /technet/windowsvista/security/guide.mspx). It recommends running with UAC turned on—for the most part—and it lists a number of points to consider when using UAC to combat malware. One point, however, is glaringly missing: UAC does not, nor is it intended to, stop malware.
Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."
This, however, means a significant change in the nature of common attacks against Windows. As I mentioned earlier in this column, local privilege escalation vulnerabilities, where a user can escalate from a local standard user to a local administrator, have never been particularly interesting on the Windows platform.
With Windows Vista, the idea is that users will run as standard user instead, and suddenly local privilege escalation issues become very interesting. Unfortunately, this is also where we run into some of the limitations of UAC. Remember, there is no effective isolation; there is no security boundary that isolates processes on the same desktop. The OS does include some protective measures to keep the obvious and unnecessary avenues of communication blocked, but it would be impossible and undesirable to block them all. Therefore, Microsoft does not consider breaches of that nonexistent security boundary to be security breaches. Mark Russinovich pointed out as much in a blog post at blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx.
Mark is totally correct. Microsoft is well aware of the fact that there is no security boundary between a low process and an elevated one on the same desktop. As there was never intended to be any isolation between processes on the same desktop, it really can't be called a security vulnerability when it is discovered that there is no isolation between processes on the same desktop. Obviously, that diminishes the value of UAC as a first-order mechanism for fighting malware, but it was not designed to be that anyway, despite what you might read in various places, including some from Microsoft.
Does this fact diminish the value of UAC with regard to its primary goal—enabling more people to run as standard user more of the time? No. The existence or lack of an impervious security boundary between a malicious low-privileged app and an elevated application does not change the fact that more users can effectively use UAC and run their Windows Vista computers as a standard user. In fact, contrary to what some in the industry would have you believe, I wrote this article (and my entire book on Windows Vista Security for that matter) as a standard user on Windows Vista, and not once did I get a UAC prompt asking me to accept anything that I wrote!
The fact that UAC does not mitigate all security problems, or that it does not possess a property that many of us, myself included, would dearly like to have—first-order protection against malware—does not mean it is not a security technology. The ability to identify users through separate user accounts does not, by itself, stop malware from infecting your system, but nobody would stretch that fact into meaning that user accounts, therefore, are not a security technology. That UAC does not solve all the problems we would like it to solve for us does not mean that the problems it does solve are not valuable.
UAC leaves it up to technologies such as the vastly improved Windows Firewall, Windows Defender, and other anti-malware programs to keep malicious code off your box and to keep it from executing if it gets there anyway (whether due to wily programming or flying pigs). None of those security technologies is likely to be 100 percent successful at their missions either, yet they are all valuable security technologies and all have their place. But, as I have said many times before, even if all avenues of attack are shut down, it all comes down to the user. If the person at the keyboard chooses to allow malicious code to run, no technical mitigation in the world will help.

Best Practices
How should you use UAC? Should you run as an administrator in admin approval mode? As noted several times, UAC does not prevent code injection from a lower privileged application into a more privileged application on the same desktop. This means that neither running in admin approval mode nor as a standard user and elevating within session (over-the-shoulder elevation) provides effective isolation. However, either solution is far better than running as an administrator under Windows XP or with UAC turned off in Windows Vista. Eventually, however, malware will probably be written to take advantage of elevated applications on the interactive desktop.
How you decide to run, then, depends on your risk management philosophy. When you run as a standard user and use over-the-shoulder elevation to elevate an application, the elevated application has a different user environment than the regular ones. This lessens the risk of a poisoning attack, where a malicious non-elevated application poisons the user environment for an elevated one, but it does not necessarily remove the ability of a non-elevated application to control an elevated one. While a malicious application that ran weeks ago cannot easily poison an elevated application you run today, a malicious application running now may be able to control an elevated application. You need to consider the risk tradeoff of using admin approval mode or over-the-shoulder elevation in context of the ease of use it provides.
This leads to a set of best practices for UAC, summed up in Figure 2. The best option by far, in my opinion, is also the most complicated. However, for the truly paranoid or exposed, the best option is to run as a standard user and never elevate. In a sense, running as an administrator under Windows XP, once you ran malicious code it was game over. Under Windows Vista, if you run malicious code and then elevate within that session, it is likely game over. You are free to pick whichever approach works best for you and provides a level of protection you are comfortable with.
Figure 2 Account elevation best practices (Close Figure 2)

Protection Level | Elevation Method
Worse | Turn off UAC.
Bad | Automatically elevate administrators.
Good | Run in admin-approval mode.
Better | Run as standard user and elevate to a separate admin account.
Best | Run as standard user and switch user to a separate admin account instead of using UAC to elevate.
In addition, the truly paranoid do not trust the vendor when it says its app must run as an administrator! One of the most visible examples of where this claim is made but is not true is Visual Studio® 2005 Service Pack 1. When you launch Visual Studio, you are told you should run it as an administrator. However, this is only true for developers who need to perform certain tasks. More information is available at msdn2.microsoft.com/en-us/vstudio/aa972193.aspx.

Empower the User
Users should be empowered to make more and better decisions. There is a contingent of security professionals who believes security decisions should be hidden from the user. Their unspoken rationale is that users are not only uninterested in security, they are not intelligent enough to learn how to do it properly. Only by relying on Insert-YourFavoriteAntiTechnologyHere will they be properly protected.
I fail to see how technology can ultimately protect people from attacks targeting people. The majority of attacks today, including virtually all phishing attacks, are targeted primarily at people and how they run their computers, not at the technology inside those computers. The most effective of these attacks may blend attacks on people with attacks on technology, but they still often require user interaction to run. Technology simply cannot be expected to protect against attacks that are not targeting technology. I wrote a lot about that a while ago: technetmagazine.com/issues/2006/07/SecurityWatch.
UAC is already forcing users to make security decisions, and there are already promises from technology vendors for solutions that prevent users from making those decisions. It is true that users prefer not to be bothered by security. However, it is also true that no software can discern intent in other software. No intrusion prevention system can tell whether a Web site is asking for your credit card number so it can ship you a copy of Windows Vista Security or so that it can send it off to a shadowy criminal organization. Only the end user can do that and only if proper information is given. As software engineers we need to accustom users to the fact that they need to make intelligent security decisions, teach them how, and give them the information they need to do it.
If we persist on our current path—of attempting to prevent users from making security decisions—we will only find that we are unable to protect them. Users will eventually tire of getting hacked and having their privacy, bank accounts, identity, dignity, and self-respect violated. When that happens, they will stop using the products we need them to buy to sustain the industry. There are those in the high-tech industry who believe that if we withhold the fact that there are security issues with computers and e-everything, users will blindly use whatever we throw at them. Nothing could be further from the truth. When users finally realize that we have not been open and honest with them, they will lose faith and trust entirely and turn away from our products, causing a collapse of the very industry we are trying to protect by withholding the facts.
UAC is an exciting step in the direction of empowering users to take responsibility for the security of their systems. It is by no means a complete security solution but, as a first attempt at helping users run with least privilege, it is definitely a significant step in the right direction.

Dr. Jesper M. Johansson is a Principal Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. Jesper holds a Ph.D in MIS and he has more than 20 years of experience in computer security.


 The Desktop Files: PC Recovery with Windows PE
The Desktop Files
PC Recovery with Windows PE
Wes Miller

In previous columns, I've mentioned that our initial vision for Windows PE was for it to be a deployment environment. As with all good products, Windows PE evolved beyond being just that. Customers (OEMs, initially) were eager to build one solution for manufacturing and user self-recovery, and several companies produced
Windows® PE solutions that worked for both.
Most recovery tools that exist today are based on the premise of returning a system to a known good state by mirroring the deployment process. Windows Vista® makes recovery quite a bit easier than Windows XP and provides in-box imaging support (see the article on Windows Vista backup technologies by Christine Fok in this issue of TechNet Magazine).
In this month's column, I will discuss building your own recovery solution based upon Windows PE. Windows PE 2.0 is available for free as a component of the Windows Automated Installation Kit (AIK) to all Windows licensees. This license not only applies to deployment, but also to the use of Windows PE for recovery and troubleshooting purposes.
Obviously you'll have to take into account your own customizations and tweaks, but here I will cover the general points you need to remember, whether you're deploying Windows XP or Windows Vista. If you're familiar with imaging, you'll already know much of this.
The key components of any Windows PE recovery solution are:
  • Windows PE
  • An imaging utility
  • Scripting glue (or a formal application) to hold it together
Optionally, you may want to include SQL support and Active Directory® Service Interfaces (ADSI) support. With SQL connectivity you can indirectly build a solution that allows your systems to have a "bill of materials" of sorts that defines what they need in order to install. Similarly, connecting to Active Directory is convenient for handling per-machine account object (MAO) properties.
Note that the inclusion of ADSI in Windows PE isn't supported by Microsoft, but there are quite a few articles online that explain how to do this—and when done correctly, it works quite well. If you don't feel like hacking it, you can add in the SQL support and build in the workflow for your Windows PE recovery tool there. If you need any ADSI properties, you can have a server system with a Scheduled Task to query that same SQL Server™ and then query Active Directory via ADSI—in essence, working as a pass-through.
It's not a perfect solution, and it will require some scripting or other automation, but this design will allow you to interact with Active Directory from Windows PE.
Note that you can also use the LDIFDE utility to read Active Direc-tory information from within Windows PE (see the Knowledge Base article on this topic at support.microsoft.com/kb/237677 for more information). For example, you can use the following command:
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
Entering this command will retrieve an attribute from the specified computer object to x:\output.ldf, where the output can then be parsed.

SKUs, Bits, and Languages
You need to consider the versions, architectures, and languages of Windows that you need to deploy. In a small, locale-specific organization, you are likely to be deploying just one OS—Windows XP or Windows Vista—or using whatever comes already installed on your new PCs. You probably aren't deploying many, if any, x64 Windows systems just yet. And odds are you need to support just one language. However, the larger, more global your organization, the more architectures, versions, and configurations you are likely to be dealing with.
I mentioned in an earlier column that you can store x64 and x86 volume images in the same Windows Imaging Format (WIM) file—but you will not save space. If you're building a recovery solution and need to account for both architectures, you should store each in a separate WIM. Similarly, if you are deploying and supporting both Windows XP and Windows Vista, you won't realize savings by storing both operating systems in the same image. The only savings you will see are if you are including many instances of the same applications (for instance, the 2007 Microsoft® Office system) in both deployments. Then the application files don't have to be stored multiple times, but this is still unlikely to lead to significant space savings.
Windows PE Boot Methods
Windows PE 1.6
PXE boot from Remote Installation
Service (RIS) (no RAMDisk)
Hard Disk Drive
USB Flash Drive
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB Flash Drive
RAMDisk Hard Disk Drive

Windows PE 2.0
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB Flash Drive
RAMDisk Hard Disk Drive

PXE Boot from RIS is optimal if you need PXE, but it's worth noting that this method takes longer to boot and consumes more network resources than a PXE RAMDisk.
Hard Disk Drive uses minimal memory but locks the drive. This method is ideal if you are using a dual-partition flip-flop recovery scenario.
USB Flash Drive makes booting convenient; however, UFD (for both RAMDisk and non-RAMDisk scenarios) is haphazard if booting systems have not been verified by the OEM as UFD bootable and don't have a Windows Vista Capable logo (which ensures UFD boot support as a logo requirement). UFD boot requires a high-performance flash drive (for both read and write) as well as Hi-Speed USB support from the USB controller and the BIOS.
RAMDisk Boot (in all its flavors) requires more memory, but delivers optimal performance and gets Windows PE out of the way by putting it into a RAMDisk in memory. RAMDisk boot of Windows PE 1.6 should generally only be used on systems with at least 256MB of RAM. Windows PE 2.0 (which is always a RAMDisk WIM boot) should in general only be performed with systems that have at least 384MB of RAM.

Note, though, that there are significant space savings when you store multiple SKUs of a particular version of Windows in the same WIM. For instance, suppose you combine Windows XP Professional with Windows XP Tablet PC Edition or Windows Vista Business Edition with Windows Vista Ultimate Edition—these combinations make efficient use of space since two SKUs from the same release and service pack level share much of the same code and files.
Finally, language comes into play. The larger an organization, the more languages it will need to take into account. With Windows XP, you can choose to use localized builds or Multilingual User Interface (MUI). With fully localized builds of Windows XP, almost every little string has been localized into the destination language. With MUI, on the other hand, the base language is English while MUI language packs (and later, Language Interface Packs) have changed as many language strings as possible. (MUI had fair results in Windows 2000 and much better results in Windows XP and Windows Server 2003.)
If your organization uses MUI, you get quite a good return when combining various language versions in the same WIM. This is because they all use English binaries at the core. This is not the case, however, for localized versions that came prior to Windows Vista. Since the binaries themselves are localized, the same binary won't match across languages, meaning you have to store almost the entire operating system (and any localized applications) for each language.
With Windows Vista, you can think of localized versions (localized as a part of a single binary with resources inside it) as deprecated. Windows Vista uses .mui resource files for each language—including English. Essentially, Windows Vista is language-free while almost all language information lives in MUI files. Thus storing more than one language version of Windows Vista in the same WIM will result in significant space savings. Storing two, four, or more languages as one WIM means that you do not need the image to grow dramatically—and you can switch or add languages later as your requirements change.
In short, when building your solution, you should take into account which versions of Windows, as well as which versions of other applications, share identical binaries, allowing for single instance storage of files. This will help you to determine how many WIM files you need across your entire organization.

User Scenarios
Generally, the larger an organization becomes, the more complicated it becomes. This is not simply due to sheer size, but because of all the variables that are introduced—you have more users and more business units, with more specific needs.
I recall a specific multinational organization—it had tens of thousands of users and had a deployment process that was all managed from one location, geographically and organizationally. The person who ran this organization always presented some very challenging questions. For instance, he was concerned about some of his remote users in certain parts of Africa who often didn't have a good network connection—in fact, many of them were hundreds of miles from a telephone line. He needed to know how these users could recover their own systems without being down for days and without having to travel great distances.
When you develop a product—and in this sense, you should think of your recovery solution as a product—you need to think about your users. Think about specific business needs, but also think about the various complexities associated with the different categories of users. You should incorporate use cases, using short descriptions, to describe each type of end user you need to support. These can help you recognize any users accidentally left out of your recovery solution and ensure that you take the needs of each type of user into account.

The Right Version of Windows PE
Another important decision is determining which version of Windows PE is right for your needs. Previous installments of this column may help, but I'll try to make the decision a bit clearer here. If any of the following are true, you should use Windows PE 1.6:
  • You are only recovering Windows XP (or Windows Server 2003)
  • You are recovering any systems that are not Advanced Configuration and Power Interface (ACPI) compliant
  • You are recovering any systems that do not have at least 512MB of RAM
  • You are recovering any systems that need to Pre-Boot eXecution (PXE) boot with less than 256MB of RAM
If any of the following are true, you should use Windows PE 2.0:
  • You are only recovering Windows Vista (or Windows Server 2008)
  • You are recovering Windows Vista as well as Windows XP
  • You are utilizing BitLocker™
Note that ImageX (see the section "Create, Update, and Store") and most third-party imaging solutions will work fine with either version of Windows PE.

Booting Windows PE
The next thing you should take into account is how Windows PE will boot. User scenarios play a key role here. Is it realistic for your users to tote around CDs or DVDs for recovery? Will they be able to throw them onto a laptop while traveling? And how will you keep this recovery media up to date? Recovery images on removable media can get stale very quickly.
Far and away the most common scenario I've seen is the secondary hard disk partition. Another option is PXE booting. Or you could look at using external USB drives or even USB Flash Drives (UFDs)—but beware that the hardware in question must explicitly support booting from a UFD device.
The "Windows PE Boot Methods" sidebar outlines the supported methods for booting each version of Windows PE and provides some important considerations about each method.
Your goal for booting Windows PE should be getting the recovery process started while meeting certain criteria:
  • With minimal user interaction
  • With minimal moving parts (removable media or removable devices)
  • While the PC may not have network connectivity
  • While the PC may not be able to boot locally (Windows is failing to boot)
Admins often consider putting Windows PE (flat or in a RAMDisk) on the hard disk as a non-viable option due to concerns about drive failure. But the reality is that this is viable given the reliability of disks today and the fact that if the physical drive actually fails, the user will not be able to recover their system themselves anyway.
My preference is to create a secondary partition and store the recovery image there. I'm not a big believer in making the partition hidden—that just mystifies users. Using an access control list (ACL) on it isn't viable, either—unless your users are not local admins.
By shrinking the partition used for Windows (see the sidebar "Making a Recovery Partition"), you may be able to create enough space to store Windows PE and your recovery image. To place Windows PE on the secondary partition, you simply create the appropriate boot sector on the recovery partition and place Windows PE on that partition (the documents included in the Windows AIK and earlier versions of Windows PE explain this process, so I won't drill into it here). The key thing to remember is that the partition used to boot is determined by which partition is marked active. Diskpart features an active flag and an equally important inactive flag. To boot the recovery partition from within Windows (or from within a copy of Windows PE), use diskpart to switch active partitions (see Figure 1). The following is an example of a diskpart script (use diskpart /s nameofscript.txt) used to switch a single disk, dual partition system:
SEL DIS 0
SEL PAR 1
INACTIVE
SEL PAR 2
ACTIVE
EXIT
Figure 1 Diskpart changing the active partition
Figure 1 Diskpart changing the active partition
This is the process that many consumer recovery tools use to flip-flop partitions—something that can only be done from within Windows PE for certain partition types, such as hidden OEM partitions. Sometimes these tools will also unhide a hidden OEM partition type.

Create, Update, and Store
Making a Recovery Partition
The process of making a recovery partition while leaving Windows intact is not difficult, once you know the steps involved. Here's a quick run-through of what you need to do. Note that this process requires Windows PE 2.0. While you may not be using Windows PE 2.0 for deployment or recovery, you must use version 2.0 for this task. This process can also be used when deploying Windows Vista and to create a boot partition to be used for the BitLocker boot files, as BitLocker requires at least two partitions (one for boot files and one for the remainder of the Windows system).
  1. Defragment your disk (this can help speed up the shrink process, which takes a considerable amount of time)
  2. Boot to Windows PE 2.0
  3. Run diskpart (if you want, you can create a script for steps 4 through 9 and pass diskpart the following argument: /s name_of_your_script
  4. SEL VOL 1 (or the volume you want to shrink)
  5. SHRINK DESIRED=N MIN=N (specified in megabytes, DESIRED is the goal and MIN is the absolute minimum you need)
  6. When shrink has completed, run SEL DIS 0
  7. CRE PAR PRI (you can specify SIZE=N if you want to specify a size other than the disk remainder)
  8. ASSIGN LETTER=N: (this letter is just for use under Windows PE)
  9. Exit diskpart
  10. FORMAT N: /Q /Y /FS:NTFS (NTFS formats the new partition)
  11. Run bootsect N: /nt60 for 2.0, /nt52 for 1.x)
  12. Copy your desired Windows PE files to the recovery partition
  13. Shut down system

While ImageX is a freely available solution, you may already have an imaging tool you've been using for a while. You can use whichever tool you are most comfortable with. If you are considering ImageX, there are a few things worth noting about it that I like (besides the great price). In particular, ImageX is aggressive about compression. Also nice, an image can be appended to and edited relatively easily.
I also like that ImageX allows you to non-destructively image one or more volumes, letting you preserve user data by simply moving it out of the way. In other words, when recovering Windows, you don't have to obliterate the entire volume.
Then, of course, you need to decide where to store the image. Assuming your solution uses a recovery partition, you can store a WIM or other imaging file there. You may even consider using Windows Deployment Services (WDS), creating a standard OS image and storing it up on the network. This allows for a common recovery solution that is available across your entire infrastructure. Of course, if you have users in the field (such as the workers mentioned earlier in remote parts of the world), you'll need to ensure they have their own solution available when they can't get to the network.
I mentioned before that you can use media, such as DVDs, but there are a number of reasons I personally don't like this option for general use. For instance, the size of an image can quickly grow beyond the size of a DVD, and disks like this can't be easily updated. That isn't to say optical media doesn't have a place; you just need to consider which scenario is best for which types of users. My preference, if you haven't figured out by now, is to store the image either on a recovery partition, on a USB hard disk or flash drive, or, when viable, on the network using WDS.
One aspect that makes WDS an attractive choice is that a centralized image can easily be updated. You should all know by now that Windows Updates come out every month and the updates are usually critical. Engineer your solution in such a manner that the recovery image is as up-to-date as possible. With WDS, you can update the image on each server and it is complete.

Concerns about User Data and Settings
There are a few issues you should bear in mind when engineering a recovery solution. A key aspect of planning any recovery solution is ensuring that your user data is also safe. You don't want a user in the field performing a recovery just to discover that she lost all her important data in the process. Ideally, you'll want user data stored somewhere other than on the C: partition, unless you are careful about how the system recovery is handled.
I mentioned earlier that ImageX lets you non-destructively restore a disk. For example, it will move the existing Documents and Settings (or Users) directory tree to another directory so a user or a script can manually recover files after the recovery is complete. Users who store all of their files under their profile or who use Roaming Profiles should, in most cases, be able to recover a system without losing user data. But it is important to remember that unless you very carefully craft your recovery solution or you have a perfect backup solution, you may still lose some amount of user data.
Remember that despite all your planning, some users will store information in locations other than their profile. You should ensure that your solution takes into account that it may blow away user data by accident and warn users before doing so.
If you use Encrypting File System (EFS), make sure you have your key recovery plan executed—you don't want to lose data due to unrecoverable encryption. Similarly with BitLocker, be sure you are prepared to recover volumes encrypted with it. This means using Windows PE 2.0 (1.x cannot interact with BitLocker). For more information on BitLocker recovery, see blogs.msdn.com/si_team.
Finally, be prepared for the fact that some users will be upset when some of their customizations or applications have disappeared. Customizations (for applications and Windows itself) are stored in some random places, not just in the user profile. When restoring the entire OS partition, some users will call to ask "where has x gone?" or "Why doesn't Word show y anymore?" Set expectations among users so they know the environment might not be exactly the same as what they had the day before.
Creating your own recovery solution with Windows PE takes time, and you need to think about your users as you plan and engineer the solution. A recovery solution doesn't need to be overly complex—it just needs to be something that gets your user back up and running in a minimal amount of time with limited technical support.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, he 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.


 Field Notes: Free Food and Training Tips
Field Notes
Free Food and Training Tips
Michael Dragone

I Am a Systems Engineer for a title insurance company of about 150 people. Our computing needs are actually quite simple since our primary line-of-business application is Web-based. Therefore, we mainly interact with Internet Explorer® and, of course, Microsoft® Office.
With a relatively simple application deployment such as this, you might expect our users to have few, if any, day-to-day problems using these applications. For the most part, that's correct. Issues that arise are often the variety that the average TechNet Magazine reader could resolve within seconds.
Through experience, I've learned that good user education is critical to keeping these issues to a minimum. I'd like to share two of the things that we do with our users in the hopes that you might take similar steps with your own users.
The first is training classes. Every so often, we hold a class that covers new systems we've installed, new applications we'll be rolling out, and new policies in place. Likewise, if we're going to be introducing a major system change, we hold a special class just to cover that change and answer any questions. We do this in advance of the change so that our users are fully prepared.
For example, we're planning on rolling out a major upgrade to our phone system. Although our users will still be able to access their voicemail through Outlook® as they do now, the software they use to do so is changing. We plan on holding a training session in which the phone system vendor will demonstrate the new interface to our users and allow them to ask questions well in advance of the actual rollout.
We also cover existing topics that our users are having trouble with. If you've spent any time in your trouble ticketing system, you'll know what those issues are. For example, one of our users didn't understand why two separate systems had to have two different passwords. No amount of verbal explanation put this to rest until she saw it depicted on a PowerPoint® slide and experienced an "Aha!" moment.
In my experience I've found that, no matter the particular topic, the keys to a successful meeting are free food and a lighthearted tone. Make it easy for your users to ask any question, even the "dumb" questions.
My second tip is to simply walk around the office. Every day, I take 10 or 15 minutes to mingle with our users. If I see someone performing a task in a strange way, I stop and discuss what she is doing and why for a few minutes. Often I am able to show her an alternate method that is far easier. For instance, one of our users continually rearranged his Outlook toolbars by accident, but had no idea how to correct the problem. He suffered in silence until I noticed this one day. I showed him how to make changes to his toolbars so that when he accidentally rearranged them again he could restore them to the way he preferred.
Other users might have issues that they don't want to bring up to your help desk or technical support group for a variety of reasons. Some might feel embarrassed, thinking that the questions they have are silly and not worth the attention of IT. Others live with a bum keyboard or mouse, not realizing that IT often keeps spare replacements around for just these occasions. By taking a few minutes to visit with your users, you can resolve many of these issues and come up with ideas for your next training class. (And don't forget the free food.)
It's important to remember your users in all aspects of your work. Most, if not all, of the changes you make to your systems, policies, and procedures will have at least some user impact. Each user is unique and will react differently to these changes.
Oftentimes it's difficult for us who consider technology second nature to best serve our users who aren't as technologically savvy. With a little patience and some user training, you can help your users to like computers as much as you do. In small steps, of course.

Michael Dragone is a Systems Engineer for a title insurance company in New York. He is an MCDST and a MCSE: Messaging. In his spare time he enjoys long walks on the beach, playing with his dog, and fully patched servers.


 Windows Confidential: The Known DLLs Balancing Act
Windows Confidential
The Known DLLs Balancing Act
Raymond Chen

The Windows feature informally called "Known DLLs" refers to a list of DLLs (Dynamic Link Libraries) that are given special treatment by the kernel's module loader. When the loader sees a program with a load-time dynamic link to a known DLL, the known copy is used immediately, ignoring the search algorithm that normally applies to module loading. Some people might consider this a security feature (though an admittedly rather weak one), but in fact security was never the intent of this feature. Known DLLs was really all about performance.
The mechanics of the Known DLLs feature have changed over time. In some versions of Windows®, the kernel uses the list of known DLLs as a starting point, then looks at all the DLLs that those known DLLs link to, then all the DLLs that those DLLs link to, and so on. This process builds up the transitive closure of all the dependencies and treats them all as known. In other versions of Windows, this transitive closure is not built; instead, only DLLs listed explicitly as known are treated as known. In some versions of Windows, the known DLLs are preloaded by the kernel when the system starts; in other versions, no such preloading takes place and the kernel merely uses the list to save itself the trouble of having to search the path for a DLL.
It's not only the interpretation of the list of known DLLs that changes from version to version. The contents of the KnownDLLs registry key are also subject to change. The Windows performance team changes both the list of known DLLs and the rules by which the list is converted into a set of DLLs based on their understanding of how applications use Windows. As is typical in engineering, it's a game of trade-offs. Preloading known DLLs at system startup allows the applications using those DLLs to start up faster, but there is a price. It takes longer to start up the system, and memory consumption increases, since those DLLs remain in memory whether or not they are actually used. It's a game of improving the performance of some components at the cost of others. Striking the right balance is a difficult task and, as you can see, it's constantly being fine-tuned as the pattern of usage evolves.
One consequence of known DLLs that may not be readily obvious is that known DLLs take precedence over locally redirected DLLs. (We looked at locally redirected DLLs in the January 2007 edition of this column.) If you think about it, you may realize that this is actually expected behavior rather than a quirk. After all, the purpose of the list of known DLLs is to bypass the search path and thereby speed up DLL loading. If the kernel had to check for locally redirected DLLs, that would just slow things back down. You might think that adding just one directory to the search path would not be that big a deal, but when that one directory can be a network server halfway across the globe, adding even one directory can be an enormous performance drain.
Believe it or not, we've seen programs that rely on specific DLLs being known. There was one program that had a file called Version.dll in the application directory. Under normal rules, this private copy of Version.dll would override the one in the system directory, but in Windows XP, Version.dll is listed as a known DLL. This means that the copy in the application directory is ignored and the version in the system directory wins.
In Windows Vista®, Version.dll is no longer listed as a known DLL, probably because the performance folks determined that applications didn't use it enough to justify the cost. As a result, this program stopped working on Windows Vista because the application actually relied on the kernel ignoring the DLL that the program installed into its own application directory. The program was willfully installing a DLL onto the search path and then relying on Windows to ignore it! Surely if it wanted Windows to ignore a file, a much more efficient mechanism would simply be not to install the file in the first place. The kicker is that the company that wrote the program filed a bug claiming that it had found a security hole.

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He has no idea what his T-shirt size is anymore.