 TechNet Magazine May 2007

TechNet Magazine May 2007

Communications: Explore New Mobile Messaging Capabilities with Exchange 2007

Mobile messaging has changed the way people work, and this change has made the security of mobile devices a greater concern. Get an overview of how Exchange Server 2007 improves the user experience and helps you manage an increasingly mobile workforce.

Yee-Chen Tjie Communications: Better Compliance with Exchange Server 2007

The need to protect corporate assets and ensure regulatory compliance imposes a significant burden on IT departments. Find out how new features in Exchange Server 2007 can help you safeguard data and maintain regulatory compliance.

Alan Maddison Identity Management: Build a Single-Step Provisioning Workflow

Looking for a Web-based provisioning system? Find out how you can use MIISWorkflow to build an automated, singlestep user provisioning system based on Microsoft Identity Lifecycle Manager 2007.

Aung Oo Windows Administration: Simplify Group Policy Administration with Windows PowerShell

Windows PowerShell is set to make your job significantly easier. See how GPMC APIs written for Windows Scripting Host languages can be consumed directly from Windows PowerShell, greatly simplifying the way you manage Group Policy.

Thorbjörn Sjövold Windows Administration: A Guide to Deploying Terminal Services

There are numerous advantages to running your organization’s applications centrally, and getting started is now surprisingly easy. Here’s what you need to know in order to enable Terminal Services on Windows Server 2003 and implement Terminal Services throughout your organization.

James D. Silliman From the Editor: Security To Go

Joshua Trupin Letters: Answers to Your Questions

Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: Best Practices Analyzer, Multi-Core Processors, and More

Edited by Nancy Michell Utility Spotlight: Upgrade Toolkit for SharePoint Sites and Templates

Upgrading to Windows SharePoint Services 3.0 can pose challenges if you use customized sites and templates. Explore a new Solution Accelerator that provides tools and guidance to help you get the job done.

Luis Câmara Manoel and Peter Skjøtt Larsen The Business of IT: Crafting a Business Plan

With today’s squeeze on IT, you need to justify most any IT purchase or investment. You’ll need a business case that includes the right information and is presented in the right way. Find out how to create a successful business case so you can get the go-ahead on your next IT project.

Stephen Ibaraki The Cable Guy: EAPHost in Windows

The Extensible Authentication Protocol, which is a framework that enables extensibility for authentication methods, has had certain limitations on previous Windows platforms. Examine how the EAPHost architecture in Windows Vista and Windows Server “Longhorn” addresses these limitations.

Joseph Davies Windows PowerShell: The WMI Connection

Windows Management Instrumentation is an incredibly useful technology for exposing system information. Find out how Windows PowerShell can make WMI infinitely easier to learn and use.

Don Jones Hey, Scripting Guy!: Flowers Blooming. Dialogs Popping. Spring Is Here.

Ever wonder how you could send values to and from a dialog box in an HTML Application (HTA)? Here’s an explanation of how to create a dialog box and then pass information back and forth between the dialog box and the main HTA.

The Microsoft Scripting Guys Exchange Queue & A: OWA Timeouts, Cmdlet Troubleshooting, and More

Learn how to manage OWA timeout rules with the Exchange Management Shell, take a close look at .pst files, explore new Exchange 2007 security groups, and more.

KC Lemson and Nino Bilic Security Watch: Network Access Protection

Rogue devices being used behind the network perimeter pose a serious security risk. Microsoft Network Access Protection provides a flexible architecture for organizations of all sizes to protect themselves from non-compliant computers brought on to the network by employees, vendors, and visitors.

John Morello The Desktop Files: Revisiting Windows Deployment Services

Get an update on Windows Deployment Services, or WDS, which will ship with Windows Server "Longhorn," and get answers to some frequently asked questions pertaining to ImageX, WDS, and Windows PE.

Wes Miller Field Notes: Staying Sharp

As your career advances and your responsibilities change, you may suddenly discover one day that you’re not actually administering a system or managing an infrastructure. Just don’t forget to spend hands-on time with the latest technologies, as this is the best way to keep at the top of your game.

Joshua Hoffman Windows Confidential: Determining What Is Frequently Used

How does Windows determine the list of frequently used programs that appears on the Start menu? The concept started with a simple premise that soon required a lot of fine tuning. Here’s an inside look at the logic behind the design of this feature.

Raymond Chen


 Communications: Explore New Mobile Messaging Capabilities with Exchange 2007
Communications Yee-Chen Tjie

Explore New Mobile Messaging Capabilities with Exchange 2007
At a Glance:
  • Mobile device configuration
  • Policy enforcement
  • Advanced messaging
  • Mobile file access

Only a few years ago accessing corporate e-mail while away from your desktop computer was an uncommon and complex task. Today, not only do people expect to have remote e-mail access, but
it’s not unusual to see someone at the local coffee shop with a mobile messaging device. Mobile messaging has changed the way people work. It has enabled the nomadic employee to become more efficient at getting work done while away from the office.
Yet thanks to these recent advancements in mobile messaging technology, the security of mobile devices has become a concern. Companies are looking for better ways to protect sensitive business data residing on mobile devices.
The introduction of Exchange Server 2003 and a technology called Exchange ActiveSync® provided the capability for a Windows Mobile® device (Pocket PC phone or Smartphone) to connect securely to Exchange Server 2003 using HTTPS. However, mobile device management was lacking. With the release of Exchange Server 2003 Service Pack 2 (SP2) and the Messaging and Security Feature Pack (MSFP) on Windows Mobile 5.0, setting a global policy affecting all Windows Mobile devices connecting to Exchange became possible. These policies allowed for mandatory PINs of a specified length, inactivity timeouts before requiring PIN entry, and device wipe after a specified number of failed PIN attempts.
Exchange Server 2003 SP2 also added the capacity for remote wipe with the Exchange Mobile Admin Tool, shown in Figure 1. This tool offered administrators the ability to issue a wipe command for a lost Windows Mobile device. The next time the device connected to Exchange, the device would perform a hard reset, erasing all content in the device’s memory.
Figure 1 Exchange Mobile Admin Tool for wiping devices
Figure 1 Exchange Mobile Admin Tool for wiping devices
Although this was a good start in mobile device management and security, there remained a number of security requirements left to address. Exchange Server 2007 helps to fill these gaps.

Device Configuration and Enforcement
Exchange ActiveSync is enabled by default for all mailbox users in Exchange Server 2007. If you want this feature enabled for only a subset of users, start out by disabling it for all users. The Exchange Management Console does not let you disable a group of users for ActiveSync, but it’s easy to do using an Exchange Management Shell command such as this one:
Get-mailbox –server <servername> | Set-CASMailbox –ActiveSyncEnabled $false
This command retrieves all mailboxes on an Exchange 2007 server and pipes the information to a Set-CASMailbox command to disable ActiveSync for all existing mailboxes.
The next step involves the construction of Exchange Mailbox ActiveSync policies for your organization. The number of policies constructed will depend on the varied security profiles of your users. For example, a financial analyst who receives sensitive financial information in e-mail may need to have a more stringent security device policy than a general user.
To configure the ActiveSync policy, go to the Exchange Management Console navigation tree and select Client Access under the Organizational Configuration container. In the Actions pane, select New Exchange ActiveSync Mailbox Policy.
In the New Exchange ActiveSync Mailbox Policy dialog box, flexible policies can be created for settings that control whether to allow downloading attachments to a device or allowing non-provisionable devices (see Figure 2). Provisionable devices are Windows Mobile devices that are capable of applying and enforcing specified policies. Non-provisionable devices are those that can only apply a subset of the policy (or none at all).
Figure 2 Exchange Server 2007 ActiveSync mailbox policies
Figure 2 Exchange Server 2007 ActiveSync mailbox policies
Other features include the ability to configure settings for encryption and password recovery. If the Require encryption on the device option is turned on, all files on the device’s storage cards will be encrypted. The Enable password recovery option allows a user to retrieve the device PIN through Outlook® Web Access 2007.
Consider your password policies for devices very carefully before applying them. Long, complex PINs provide better security, but may make devices more difficult to use. A good balance between security and usability is the key in determining both password strength and the timeout period before a PIN is required. Turning on the Password expiration and Enforce password history options can also increase security, but might frustrate users if keeping track of passwords and PINs becomes too complex.
Exchange Server 2007 ActiveSync mailbox policies help improve device security, but some of its features require Windows Mobile 6.0, which is just becoming available on devices as we go to press. Of the features shown in Figure 2, Require encryption on device, Enforce password history, and Password expiration (days) all require the new version. However, you can still take advantage of the new Exchange Server 2007 flexible policies to target users who use devices with Windows Mobile 5.0 installed.
Once your policies are defined, you can apply them to users. In the Exchange Management Console, go to Recipient Configuration and select Mailbox. Choose the mailbox user you want to enable for an ActiveSync policy and select Properties from the Actions pane. Go to the Mailbox Features tab and double-click Exchange ActiveSync. In the Exchange ActiveSync Properties box, click the Browse button and select the ActiveSync policy you want applied to the user (see Figure 3). You can repeat the same steps to apply different policies to different users, or you can use the following Exchange Management Shell command to apply a policy to a group of users:
Figure 3 Applying ActiveSync mailbox policy
Figure 3 Applying ActiveSync mailbox policy
Set-CASMailbox –Activesyncmailpolicy
The final step is to train your end users and help desk. Tell your end users that a PIN of specified length will be required on their devices when they connect to Exchange Server 2007 (see Figure 4). Educate them on the security policies applied to them so they don’t view these changes as a hindrance to their daily work.
Figure 4 ActiveSync mailbox policy requires a PIN
Figure 4 ActiveSync mailbox policy requires a PIN
You’ll also want to make them aware of a new capability in Exchange Server 2007—self-service remote wipe using Outlook Web Access 2007. If a user loses his device, he can initiate a wipe of the device through the Options link in Outlook Web Access—without contacting the help desk (see Figure 5). This can be quite useful if a device is lost outside of regular work hours.
Figure 5 Managing a device through Outlook Web Access
Figure 5 Managing a device through Outlook Web Access
Finally, show your help desk how to remote-wipe devices. This is easily done by opening the Exchange Management Console, navigating to Recipient Configuration, and selecting Mailbox. From there, you choose the users you want to initiate the wipe for and select Manage Mobile Device from the Actions pane. The Manage Mobile Device interface is shown in Figure 6. Note that a user could have more than one Windows Mobile device connecting to Exchange 2007, so be careful to select the right one when initiating wipes.
Figure 6 Wiping a user’s device remotely
Figure 6 Wiping a user’s device remotely

E-Mail Handling and Search
Windows Mobile 6.0 lets you read e-mail in HTML format, set out-of-office notifications (see Figure 7), and flag e-mail messages. When e-mail messages are flagged on a Windows Mobile 6.0 device, they are treated the same as when you flag an e-mail in Outlook. Instead of marking e-mail messages as unread for you to follow up, you can now flag them and use the advanced capabilities of Outlook to follow up when you’re back at your desk. Reading e-mail in HTML provides a benefit not just to the mobile device user, but also to other recipients of the e-mail thread. When you reply to an e-mail using Windows Mobile 6.0, the e-mail isn’t converted to basic text, thus improving the experience of the other e-mail recipients who are also using Outlook.
Figure 7 Out-of-office message
Figure 7 Out-of-office message
Significant enhancements have been made to the calendaring features with Windows Mobile 6.0. You can now forward, reply, or reply all within a calendar entry, as well as see the acceptance status of all invitees.
Windows Mobile 6.0, used in conjunction with Exchange Server 2007, provides two new capabilities related to search and mobile document access. One of the challenges of using mobile devices is limited storage capacity. Because of this, many users only keep e-mail on their devices for one to three days. Users often also elect to grab e-mail messages from only one folder of their Inbox. Such a minimalist approach can be a problem when you want to access older messages or messages that are stored in different folders in your mailbox.
With Windows Mobile 6.0, a user can execute an over-the-air search across his entire mailbox via the Exchange Server 2007 search-and-index engine. An e-mail search can be initiated based on keywords across multiple folders (see Figure 8). A real-time fetch of the e-mail messages from the results of the search can then be performed.
Figure 8 Over-the-air e-mail search
Figure 8 Over-the-air e-mail search

Mobile Document Access
With the growth of document collaboration software, such as SharePoint® and limits on the maximum e-mail sizes allowed for transport, end users are attaching fewer document to e-mail and sending more links to file shares and SharePoint sites. Unless you can connect to your corporate network through a virtual private network (VPN), accessing these documents via a mobile device might seem impossible. For the nomadic worker, this could be a hindrance.
Windows Mobile 6.0 and Exchange Server 2007 enable users to access their data by way of UNC file shares and SharePoint sites, which can be made accessible in read-only mode. Exchange Server 2007 can proxy requests for these documents on behalf of the Windows Mobile device (see Figure 9). Even without a VPN connection to the corporate network, users are not limited to accessing only documents attached to e-mail messages; instead they can get to any document that resides in file shares or SharePoint sites.
Figure 9 Document access via UNC links
Figure 9 Document access via UNC links
To administer Mobile Document Access, open the Exchange Management Console and select Client Access under Server Configuration in the navigation tree. Then go to the ActiveSync tab, select the Microsoft-Server-ActiveSync object, and click properties in the Action pane. Under the Remote File Servers tab, you can configure the allow list and block list for hostnames of SharePoint sites and file servers.
Once this is done, go back to your Exchange ActiveSync mailbox policy and make sure that the checkboxes for Windows® File Shares and Windows SharePoint Services are checked (Figure 10).
Figure 10 Enabling document access
Figure 10 Enabling document access
Now you are on your way to providing better document access for all your Windows Mobile device users.

Summary
In today’s world of remote workers, Windows Mobile devices offer powerful ways to access information anytime, anywhere. Security and management of mobile devices have become major concerns for IT departments. Exchange Server 2007, together with Windows Mobile 6.0, ease the creation and targeting of policies for Windows Mobile devices that can help mitigate problems as well as provide a foundation for new capabilities for remote workers.
Resources for Windows Mobile
There are a number of resources available for you to learn more about Exchange Server 2007 deployment and Windows Mobile Messaging.
  • Exchange Server TechCenter
  • The Fundamentals of Mobile Access to Exchange 2007
  • Managing Exchange ActiveSync
  • Windows Mobile Virtual Labs
  • Windows Mobile 6 SDK

Yee-Chen Tjie is a Technology Specialist for Microsoft in the New England region. He focuses on mobility and unified communication solutions.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Communications: Better Compliance with Exchange Server 2007
Communications Alan Maddison

Better Compliance with Exchange Server 2007
At a Glance:
  • Managed Folders
  • Transport Rules
  • Message Classification
  • Journaling

Analysts estimate that as much as 75 percent of corporate documentation is created and communicated via e-mail. No doubt, a significant amount of your organization’s intellectual property lives on its messaging servers. This puts a lot of responsibility in the
hands of the administrators who maintain the messaging servers, which have come to house so much of your company’s critical data. Furthermore, the growing number of federal and local regulations (both in the United States and in other countries) that specify archiving and retention requirements for corporate data only make this job more complex and more critical.
The need to protect corporate assets and ensure regulatory compliance imposes a significant burden. In designing Exchange Server 2007, Microsoft has implemented a number of changes and new features to dramatically improve the compliance capabilities of Exchange while making the actual management easier. In this article, I take a look at the key changes in Exchange Server 2007 that will help with your regulatory compliance.

Understanding Compliance
Before I dive into Exchange Server 2007, I should discuss the requirements that are being addressed. There are generally three broad areas of compliance requirements: information retention, access control, and data integrity. For example, in the United States, SEC Rule 17A-4 specifies data retention policies for certain stock exchange members, brokers and dealers, and it requires financial organizations to be able to capture, index, archive, search, and retrieve their e-mail. Controlling access to data is incorporated into a number of well-known pieces of legislation, including the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (or GLB Act), and California Senate Bill 1386 (or SB 1386). HIPAA and the GLB Act regulate the security and confidentiality of personal data while SB 1386 mandates public disclosure of computer security breaches involving confidential data.
Furthermore, data integrity requirements have been incorporated into other important pieces of legislation, such as Sarbanes-Oxley (SOX), the PATRIOT Act, and Basel II. But these high-profile regulations are just a drop in the bucket. Some estimates put the number of regulations enforced world-wide at more than 35,000. Clearly there is motivation for companies to control the risk associated with how they retain information, control data access, and ensure data integrity. So how can you, as an administrator, manage this risk and what can you do to meet all these regulatory obligations?
The first step is to document compliance and retention policies. The next step is to implement and continually manage these policies. Exchange Server 2007 can help you enact these policies, through the use of managed folders, the Transport Rules agent, message classification, and the Journaling agent.

Managed Folders
Data retention (or records management) is a critical part of your compliance framework. Exchange Server 2007 has taken a big leap forward in how it allows administrators to manage data. In Exchange Server 2007, records management is based on three principles: obsolete messages are removed, required messages are retained, and users are responsible for classifying their own messages.
Most Exchange administrators are familiar with the Exchange Server 2003 Mailbox Manager policies, which could be applied to mailboxes. In Exchange Server 2007, managed folders provide a centrally managed way for administrators to create and deploy new default or custom folders that cannot be moved, renamed, or, in most cases, deleted. Using the SDK, it is also possible to create Web-based self-service applications that give users the ability to choose which folders should be added to their mailboxes.
As Figure 1 shows, the Exchange Management Console provides a wizard-based approach to folder creation. (This functionality is also exposed through the Exchange Management Shell New-ManagedFolder cmdlet.)
Figure 1 Using the Exchange Management Console to create a new folder
Figure 1 Using the Exchange Management Console to create a new folder
This launches the wizard shown in Figure 2. The process for creating the folders is very straightforward; you simply enter the name and description of the folder and then press the New button. Once the folder is complete, you will receive a confirmation.
Figure 2 An intuitive wizard makes it easy to create a new managed folder
Figure 2 An intuitive wizard makes it easy to create a new managed folder
With a data retention policy in place, you need to provide users with a simple means to sort and store their messages, ensuring that the data is retained in compliance with your organization’s requirements. Imagine you need to deploy three custom folders to your users so that they can identify mail for three, five, or seven years of retention. Once you have created the managed folders, the next step is to apply content settings to each folder. You do this using the Managed Content Settings wizard.
The messaging administrator is in control of setting content expiration (which is measured in days) and the action that should be taken upon the content once it actually expires. There are five actions to choose from:
  • Delete and allow recovery
  • Mark as past retention limit
  • Move to a managed custom folder
  • Move to the deleted items folder
  • Permanently delete
There are three parameters that you should pay particularly close attention to when configuring these settings. The first is the value for message expiration; since this is calculated in days, you should remember to account for leap years. Corporate management (not to mention a judge) will not appreciate content being deleted earlier than it should be, even if it is by just one day. The second parameter is when the expiration period starts. Typically this is the day the message was delivered to the mailbox, unless you are instructed otherwise by your legal team. The third parameter is the action that is performed once the content has expired. A best practice is to always permanently delete the item. The Content Settings also allow you to journal messages by forwarding them to an SMTP address.
Managed folders are applied to mailboxes using managed folder mailbox policies. The Exchange Management Console provides another wizard for creating these policies. The policies allow you to select and group multiple folders. This lets you link multiple folders to a single policy.
Typically, you would apply the managed folder mailbox policy during mailbox creation. Alternatively, you can use the Exchange Management Shell to apply a policy to an existing mailbox using the Set-Mailbox cmdlet. Say you want to apply a managed folder mailbox policy called retention to an e-mail account with the alias USER1. To do this, you would use the following command:
Set-Mailbox –Identity USER1
–ManagedFolderMailboxPolicy “retention”
Managed folders and the corresponding content settings provide a powerful mechanism for managing the retention and compliance process. Not only does it allow users to sort relevant e-mail and store data in folders that are managed centrally, but it also allows for journaling of these items to ensure that in the event of a discovery request or preservation order, you can easily comply with the court’s request.

Transport Rules
There are two Transport Rules agents in Exchange Server 2007. In terms of compliance, however, you are really only interested in the agent that runs on Hub Transport servers. This agent helps you apply policy-based compliance rules to messages flowing through your Exchange organization. (The Edge Transport Server Rules agent, on the other hand, helps you protect your organization against spam and viruses.)
Some of the common regulatory and compliance requirements administrators are responsible for implementing include:
  • Limiting interaction between different groups of senders and recipients
  • Preventing inappropriate content from entering or leaving the company
  • Filtering confidential information
  • Tracking or archiving messages that are sent to and received from specific users and groups
  • Redirecting inbound and outbound messages for inspection before delivery
  • Applying disclaimers
The Hub Transport server was chosen for this agent due to the role it plays in an Exchange 2007 topology. Changes to the topology in Exchange 2007 are significant and, as a result, Exchange is now much more tightly integrated with the Active Directory® topology. As mail flows through the organization, it will at some point be processed via a Hub Transport server. This Hub Transport server will query Active Directory for the current transport rule configuration and apply the rules to all the messages it handles.
Any transport rule configured on a Hub Transport server will be replicated to all other Hub Transport servers via the Active Directory service. You need to be aware of how your site and topology will impact replication and, in turn, you need to determine how quickly you can deploy an organization-wide rule.
You also need to keep in mind that a Hub Transport server maintains a recipient cache for recipient and distribution list lookup. The refresh interval, which is four hours by default, will affect the timing of rules being applied to your messages.
Transport rules on Hub Transport servers evaluate all meeting requests, regular messages, encrypted messages, and rights-protected messages that are sent between authenticated users. All e-mail messages that are sent anonymously are evaluated, regardless of message type, sender, and recipient.
Each transport rule consists of the following components: conditions, exceptions, and actions. Conditions are used to indicate which message attributes—such as headers, recipients, or senders—are used in the message identification process. Once a message meets all of the conditions for a particular rule, actions are applied unless the message matches a configured exception. Exceptions are optional. If configured, an exception will stop any messages that meet any one of the exception criteria from being processed by the transport rule. Actions, which are a required component for each transport rule, specify how a message should be processed. Figure 3 lists the available actions that can be applied based on transport rules that are configured on a Hub Transport server.
Figure 3 Available actions for transport rules on a Hub server (Close Figure 3)

Action | Action Name | Description
Log an event with message | LogEvent | Adds an event into the Application log of the local computer.
Prepend the subject with string | PrependSubject | Prepends a string to the start of the message subject field.
Apply message classification | ApplyClassification | Applies a message classification to the message.
Append disclaimer text | ApplyDisclaimer | Applies a disclaimer to the message.
Set the spam confidence level to value | SetScl | Sets the spam confidence level (SCL) on a message.
Set header with value | SetHeader | Creates a new message header field or modifies an existing message header field.
Remove header | RemoveHeader | Removes the specified message header field from a message.
Add a recipient in the To field addresses | AddToRecipient | Adds one or more recipients to the To address list of the message. The original recipients can see the additional address.
Copy message to addresses | CopyTo | Adds one or more recipients to the carbon copy (Cc) field of the message. The original recipients can see the original address.
Blind copy the message to addresses | BlindCopyTo | Adds one or more e-mail recipients to the blind carbon copy (Bcc) address list of the e-mail message.
Redirect message to addresses | RedirectMessage | Redirects the message to one or more recipients who are specified by the administrator. The message isn’t delivered to the original recipient or recipients, and no notification is sent to the recipients or the sender.
Send bounce message to sender with enhanced status code | RejectMessage | Deletes the message and sends a non-delivery receipt to the sender. The recipient doesn’t receive the message or notification.
Drop the message silently | DeleteMessage | Deletes the message. Notification is not sent to the recipient or to the sender.
To create a transport rule, you can use the Exchange Management Console and the Rules Transport wizard, shown in Figure 4. Alternatively, you can use the Exchange Management Shell to script rules creation.
Figure 4 Launch the Rules Transport wizard to configure a transport rule on a Hub Transport server
Figure 4 Launch the Rules Transport wizard to configure a transport rule on a Hub Transport server
Note that it’s also possible to use the SDK to write custom transport agents that process messages based on SMTP events within Exchange. This, however, is not for the faint of heart.

Message Classification
The new Message Classification tool uses metadata to describe the intended use or audience of a specific message. On the client-side, this metadata can be used by Outlook® Web Access (OWA) or Outlook 2007 to display a user-readable description of the classification. On the server side, the Transport Rules agents can act upon the message based on its classification.
The default message classifications included with Exchange Server 2007 are A/C (Attorney/Client) Privileged, Attachment Removed, Company Confidential, and Company Internal. However, many organizations will want to create their own classifications. You can create new classifications using the new-MessageClassification cmdlet in the Exchange Management Shell. For example, if you need to restrict access to financial data, you could create a message classification called Financial—Confidential:
new-MessageClassification –Name finance –DisplayName “Financial—Confidential”
-RecipientDescription “This message contains confidential financial data.”
–SenderDescription “Restricts recipients of messages that contain confidential financial data”
Note that while only three parameters are required—Name, DisplayName, and SenderDescription—you should at least add RecipientDescription to achieve a basic level of functionality. Figure 5 shows this new classification now listed in the OWA interface.
Figure 5 The list of message classifications includes the newly created Financial—Confidential
Figure 5 The list of message classifications includes the newly created Financial—Confidential
This command does not use the locale parameter and therefore would apply to all locales within your Exchange organization. If you support global operations, you will probably want to make your custom message classifications locale-specific.
In addition, you should remember to correctly set the permissions on the classifications. By default, all new message classifications are created with read permissions assigned to authenticated users. However, you should segment the message classifications so that users only have access to the message classifications that are appropriate to their roles. Also, note that each classification can have a relative priority to other message classifications. This priority specifies the ordering of descriptions and it determines which classifications are associated with a forwarded or replied message.
Once you have created the necessary classifications, the next step is to create transport rules that use the classifications. (These message classifications, of course, don’t have to be action-related—they can be merely informational.) As Figure 6 illustrates, you have many options when combining message classifications with transport rules. I’ve created a transport rule that monitors for messages classified as Financial. If a message is marked as such, the transport rule agent examines the recipients. If any of the recipients are not a member of the Financial Dept distribution group, the message is returned to the sender with a custom non-delivery message.
Figure 6 Creating a transport rule for messages classified as Financial
Figure 6 Creating a transport rule for messages classified as Financial
Message classification can also be used to enforce "ethical walls" in your organization. For instance, it is sometimes necessary to restrict communications between certain individuals and departments. Message classification can be used for this purpose.

Journaling Agent
When ensuring compliance, journaling can be a powerful, though sometimes challenging, weapon. Fortunately, Exchange Server 2007 offers much more flexible journaling capabilities. It now supports both standard journaling (at the mailbox database level) and the new premium journaling (per recipient), which enables journaling for individual users and distribution groups. This makes the process for complying with requests—such as holds or court-issued preservation orders—much simpler. In addition, you have more control over the impact journaling will have on storage and performance.
For example, one of the most flexible new options comes in the form of support for journaling based on dynamic distribution groups. Say your organization has an ongoing need to place a hold on the e-mail messages of certain individuals. Perhaps this is for an internal HR investigation or a court case. With a dynamic distribution group, the administrator can add and remove users to an established group that is already being journaled. This provides a quick and easy way to provision ad hoc journaling.
Using the Exchange Management Console and the Dynamic Distribution Group wizard, you have the option to select the user container and, as shown in Figure 7, to filter the included mailboxes based on the value of certain Active Directory attributes. Selecting one of the custom attributes, also shown in Figure 7, allows the administrator to control which users are being journaled by adding or removing this value.
Figure 7 Using the Dynamic Distribution Group wizard to configure journaling rules
Figure 7 Using the Dynamic Distribution Group wizard to configure journaling rules
For an in-depth look at journaling in Exchange 2007, refer to David Strome’s December 2006 article "More Powerful Journaling in Exchange 2007". You can find additional information in "Overview of Journaling".

Alan Maddison is a Senior Consultant in the Microsoft technology practice of MTI Technology Corporation. His primary focus is on Active Directory, Exchange Server, and virtualization.


 Identity Management: Build a Single-Step Provisioning Workflow
Identity Management Aung Oo

Build a Single-Step Provisioning Workflow
At a Glance:
  • Using MIISWorkflow
  • Implementation and configuration
  • Extending MIISWorkflow

If you’ve been looking for a Web-based interface for requesting and approving accounts and your organization employs Microsoft Identity Lifecycle Manager 2007 (ILM 2007, formerly Microsoft Identity Integration Server 2003),
then the MIISWorkflow application may provide a simple and effective solution. MIISWorkflow is part of the MIIS 2003 Resource Tool Kit 2.0 and has been available since December 2004. Although not necessarily a complete solution for every environment, it is a good starting point for building a custom application that fits your organization’s needs.
MIISWorkflow provides approval-based provisioning functionality to ILM 2007 by integrating a Web application. It is a one-step, workflow-driven provisioning system that accepts requests from users and routes them to approvers (typically managers) with sufficient authority to make decisions regarding the specific requests. Based on the approver decision, ILM proceeds with user account provisioning in connected directories using business rules defined in ILM.
This application can facilitate only a single-step workflow; it cannot create complex workflow features, such as a multiple-step approval process with parallel paths or a workflow process with a graphical interface. If your organization does not require these complex workflow features, you can use the MIISWorkflow sample provided by the MIIS Resource Tool Kit to implement a solution.
I’ll focus here on the Human Resource department of a fictitious company. In general, HR systems are the authoritative source for all employee information within an organization. However, while these systems usually have detailed data for permanent employees, they often lack information about temporary workers, such as contractors and student interns. The data contained in an HR system may not track which systems users can access, including the user account information. I’ll show you how to build a simple tracking system for temporary workers within an organization.

Building on MIISWorkflow
An example of how organizations can take advantage of the MIISWorkflow is to create an application that works in conjunction with existing HR systems. When a new employee is hired, user information is added to the HR system. You can design ILM flows that send the information to the MIISWorkflow database and then utilize the workflow application to route user information to approvers before ILM provisions the account in connected directories.
If your organization does not use HR systems to track temporary workers, the MIISWorkflow application can be used as the authoritative data source to manage their accounts in enterprise directories. Since the workflow application reduces the paper-based administrative work needed to obtain approvals, users do not have to wait for days to access accounts in directories and applications. You can also use MIISWorkflow to enable rapid revocation of access, thus enhancing organization security.
MIISWorkflow can also be used as an audit tool to track the number of systems that a user can access, the request and termination dates for each account, and the requestor and approver of each account. The ability to generate reports with detailed account history can facilitate an organization’s compliance with regulatory acts such as Sarbanes-Oxley and HIPAA.
The MIISWorkflow application runs on IIS and uses directory integration and provisioning features of ILM 2007 to provision and deprovision accounts in connected directories. Components of the workflow application include a collection of ASP.NET Web pages, a SQL Server™ database, a management agent, and an authorization policy store (see Figure 1). The application uses SQL Server for data storage, Active Directory® for authentication, and a policy store with Windows® Authorization Manager (commonly known as AzMan) for authorization.
Figure 1 MIISWorkflow application architecture
Figure 1 MIISWorkflow application architecture
The application can be extended and customized using C# and ASP.NET. MIISWorkflow consists of these five .aspx pages: ContractorApproval, ContractorHistory, ContractorRequest, ContractorStatus, and ContractorUpdate. These pages allow administrators to request, update, approve, and track the status of each user account in the system. Note that, by default, the MIISWorkflow application is set to use IIS Integrated Windows Authentication to take advantage of Kerberos.
The workflow application triggers ILM based on the action of the approver, and ILM provisions or deprovisions user accounts in connected directories using defined rules. Immediately after an action has been taken on the request, the application triggers ILM and requests do not have to wait until the next ILM synchronization cycle for provisioning and deprovisioning to occur in connected directories.
The workflow application requires the MIISWorkflow database to store users’ account information. This is separate from the database where ILM stores metaverse information, but it is configured on the same SQL Server instance. When authorized users request an account through the workflow application, the information is saved by MIISWorkflow. The information is then rendered through an ASP.NET Web page when an approver accesses the page. MIISWorkflow also stores histories of actions and other information about the account in the database. ILM imports the information from the MIISWorkflow database using a SQL Server management agent that comes with the application and provisions or deprovisions the account as necessary.
AzMan, used by MIISWorkflow for authorization, provides role-based access control (RBAC) for managing tasks that users are allowed to perform in the application depending on their assigned roles. (See go.microsoft.com/fwlink/?LinkId=85825 for more information on RBAC.) After a user has been authenticated in Active Directory, thus allowing access, the workflow application checks roles defined in the AzMan authorization store to authorize the operations a user can perform. There are two roles predefined for the application: contractor requestor and contractor approver. Users or groups with the contractor requestor role can only put in a request through the application, but users or groups with the contractor approver role have the ability to create requests and approve or deny requests.
The MIISWorkflow application authorization policy is stored in an XML file. Either Windows users and groups or application groups can be assigned to defined roles. Application groups allow an LDAP query to perform a runtime look up of a user’s Active Directory or Active Directory Application Mode (ADAM) account object based on the attribute value; the user is in the group such that (department=‘marketing’), for example, returns true.

Application Walkthrough
Application administrators control access to the application using AzMan. Depending on how the application is utilized in your organization, you can grant a contractor requestor role to all domain users or only to selected groups. The contractor approver role should only be granted to users and groups who have authority to approve or deny requests. Selected HR administrators, as well as system and group administrators, usually possess this role. By default, the MIISWorkflow application uses IIS Integrated Windows Authentication as its authentication method, so the application will authenticate users through their Windows desktop logon credentials—this means that users will not be prompted again for credentials to authenticate against the application.
A user in the contractor requestor role can point the browser to the contractor request page in the application and supply information about the contractor to request an account for that contractor. Figure 2 shows the contractor request page.
Figure 2 New Contractor Request page
Figure 2 New Contractor Request page
The person in the requestor role fills in the pertinent contractor information and submits the request. There is a link to approve requests and a link to check status on the page, but requestors cannot access the approver page unless they are also in contractor approver role. A requestor can click on the Contractor Status link to view his own requests, but will not be able to view the status of requests submitted by others.
Only a contractor approver has access to the contractor approval page in the application, where he can approve or deny the request after reviewing the information. Figure 3 shows the interface of the Contractor Approval Web page.
Figure 3 Contractor Approval page
Figure 3 Contractor Approval page
A contractor approver can see requests submitted by all requestors. Any contractor approver can approve the request and only one approval or denial is necessary to route the request to the next stage. The request will disappear from the contractor approval page once action has been taken by the approver. This minimizes redundant approver actions.
To review new requests and to take action on pending requests based on organization requirements, an approver needs to access the contractor approval page regularly as there is no notification mechanism in the application to tell the approver of new requests or a backlog. As soon as the approver approves or denies the request from the page, the application triggers ILM and accounts are provisioned or deprovisioned in connected directories based on the approver’s action.
Figure 4 Contractor Status page
Figure 4 Contractor Status page
The status of pending requests and records of completed requests can be tracked from the contractor status page (see Figure 4). A requestor can undertake several actions from this page. You can view your own requests, including information such as employee ID, first name, last name, department, status, and last modified date. You can also edit the existing information, view history, and terminate a contractor’s account. You can modify first and last name and department information, and resubmit the information for approval. And, finally, you can view a log of actions taken on the request along with the date and time of each action from the contractor history page (see Figure 5).
Figure 5 Contractor History page
Figure 5 Contractor History page
The MIISWorkflow application makes account termination seamless by allowing a requestor to terminate contractor accounts from the contractor status page. The requestor can click on the terminate link to immediately disable or delete contractor accounts in connected directories. The advantage of this ability to terminate contractor accounts from the workflow application is that system administrators do not have to search for the contractor account in each directory and manually delete accounts. Since the MIISWorkflow application immediately triggers ILM to deprovision those accounts in connected directories, there is no lag time to delete those accounts.

Configuring the Application
The configuration of the MIISWorkflow application involves setting up a service account, setting up the database for the application, configuring ILM to work with the workflow application, configuring IIS, and configuring the policy store. The application contains prebuilt scripts and configuration files to simplify this process.
The MIISWorkflow application comes with a T-SQL query file to make the process of creating a MIISWorkflow database easier. You can load the query file in the Query Analyzer and execute the query to automatically create the database.
Configuration of IIS involves creating a new IIS application pool and a virtual directory, and setting authentication and access control to host ASP.NET pages. The application also comes with an XML file with predefined roles to configure an authorization policy store. You can assign users and groups to existing roles and create new roles using the AzMan MMC.
The final step is to configure the management agent in ILM to import data from MIISWorkflow database to ILM. You do this by importing the management agent configuration in the XML file and copying a prebuilt extension file for the SQL Server management agent. Both the XML file and the management agent extension file are provided with the application. There is a readme file with step-by-step instructions on how to configure each of these steps.

Extending the Application
The MIISWorkflow application provides a starting point for developing simple workflow integration with MIIS and you may need to make a few customizations to extend the application. Besides simple modifications such as changes to the Web pages, there are many other ways to extend this application.
You could add a notification feature so that an approver would receive an e-mail message when there is a pending request. This feature could also send a reminder message to the approver, within a specified number of days, if no action has been taken on the request. If you require more information about users than the default page provides, you can add fields to both the contractor request page and contractor update page. You can add more roles to the application, such as an auditor role that would allow a user to view the history of every request, not only the requests she has submitted.
More complex workflow features, such as a multi-step workflow and the ability to design a workflow using graphical designer, are not within the scope of this application. However, you can use Windows Workflow Foundation to develop a more robust application with complex workflow features.
You’ll find the MIIS Resource Tool Kit at go.microsoft.com/fwlink/?LinkId=85829. Download it today and get started building your own identity workflow solutions.

Aung Oo is an identity management subject matter expert within Microsoft Consulting Services (MCS). Aung has been designing, developing, and deploying enterprise directory and identity management solutions for both commercial and government customers since the first release of Microsoft Identity Management.


 Windows Administration: Simplify Group Policy Administration with Windows PowerShell
Windows Administration Thorbjörn Sjövold

Simplify Group Policy Administration with Windows PowerShell
At a Glance:
  • What is Windows PowerShell?
  • How GPOs were managed previously
  • Migrating scripts to Windows PowerShell
Download the code for this article: GroupPolicy2007_05.exe (154KB)

Microsoft Group Policy technology didn’t catch on overnight—it was somewhat difficult to understand and required that you adopt Active Directory, a strange, new service that looked nothing like the Account/Resource domains that were the standard at the time. Today, Group Policy
is the management backbone of nearly every organization with a Windows® infrastructure. I have a feeling this is exactly what will happen with Windows PowerShell™, the latest management technology from Microsoft. In fact, Windows PowerShell is likely to make your job as a Group Policy administrator significantly easier.
In this article, I show how the Microsoft® Group Policy Management Console (GPMC) APIs written for Windows Scripting Host languages like VBScript (and COM-based scripting languages in general) can be consumed directly from Windows PowerShell to simplify the way you manage Group Policy in your environment.

Scripting Group Policy Tasks
When Microsoft released GPMC a few years ago, Group Policy administrators suddenly had a number of handy features at their disposal. In particular, the Group-Policy-focused MMC snap-in represented a huge step forward for Group Policy management, especially compared to Active Directory® Users and Computers. Moreover, there was a brand new API that let administrators use COM-based languages such as VBScript to perform Group Policy administration of tasks, such as backing up and restoring Group Policy Objects (GPOs), migrating GPOs between domains, configuring security settings on GPOs and links, and reporting.
Unfortunately, GPMC did not provide the ability to edit the actual configured settings inside the Group Policy Objects. In other words, you could perform operations on the GPO container, such as reading GPO versions, reading modify dates, creating brand new GPOs, backing up and restoring/importing GPOs from different domains, and so forth, but you couldn’t programmatically add or change the content of the GPO, for example adding a new redirected folder or a new software installation. What you generally did instead was create the GPO and configure all settings manually using the Group Policy Object Editor, then back it up and import it into a test environment. When everything was verified and working properly, you would import it into the live environment. Despite the missing feature, the use of scripts instead of manual interaction with the GPMC API resulted in a tremendous amount of time, effort, and error saved in day-to-day Group Policy administration.

The Next Level
How is Windows PowerShell different from scripting languages like VBScript? For starters, Windows PowerShell is a shell and, at least for our purposes, you can think of a shell as a command-line interpreter. Though VBScript can be run from the command line, a VBScript file cannot be run line by line. A Windows PowerShell script, in contrast, can be created on the fly as a series of individual commands. In addition, Windows PowerShell has functions that work much like subroutines in VBScript, and that can be created in real time at the Windows PowerShell command prompt.
Even better, Windows PowerShell is built on the Microsoft .NET Framework, while VBScript relies on older COM technology. This means that the vast amount of .NET code being produced today can be used directly from within Windows PowerShell.
What it comes down to is that with Windows PowerShell, you get full scripting support and interactive mode, all in one package. The examples I provide here will all be command-line input so you can type as you read; however, they’ll work equally well if you put them in a Windows PowerShell script file and run it.

Recreate Old Scripts Using Windows PowerShell
The last thing you want to do when you start with a new technology is toss out all your previous work. There are three approaches you can use to access COM objects from the GPMC API, or basically to reuse any old VBScript out there. You can select one of these three options:
  • Create a Windows PowerShell cmdlet using a programming language like C# or managed C++.
  • Use Windows PowerShell to access the ScriptControl in MSScript.ocx to wrap old scripts.
  • Wrap the COM calls in reusable Windows PowerShell functions or else call the COM objects directly.
I’m going to focus mainly on the third option, but let’s have a quick look at all the options first.

Creating a Windows PowerShell Cmdlet
Microsoft included a large number of cmdlets with Windows PowerShell, allowing you to copy files, format output, retrieve the date and time, and so on, but you can create your own cmdlets as well. The process is fully documented at msdn2.microsoft.com/ms714598.aspx . To summarize, here are the steps:
  • Create a class library DLL in a .NET programming language such as C#.
  • Create a new class and inherit from the base class cmdlet.
  • Set attributes that determine the name, usage, input parameters, and so forth, and add your code.
Because Windows PowerShell is built on the .NET Framework, any types, such as a string, object, and so forth, that are being returned or passed as parameters are exactly the same in the code as in Windows PowerShell; no special type conversion is needed.
The real power of this solution is that you have a complete programming language at your disposal.

Wrapping Old Scripts Using the ScriptControl Object in MSScript.ocx
Obviously, you need the VBScript engine to run a VBScript file. What is not so obvious is that this engine is a COM object and, since you can use COM objects from Windows PowerShell, you can invoke the VBScript engine. Here’s how this could look:
$scriptControl = New-Object -ComObject ScriptControl
$scriptControl.Language = ‘VBScript’
$scriptControl.AddCode(
    ‘Function ShowMessage(messageToDisplay)
    MsgBox messageToDisplay
    End Function’)
$scriptControl.ExecuteStatement(‘ShowMessage
    “Hello World”’)
If you enter this code in the Windows PowerShell Command Line Interface (CLI), the VBScript function ShowMessage is called and executed with a parameter, resulting in a Message Box displayed with the text Hello World.
Now some of you might think, "Great! I’ve mastered the art of using COM from Windows PowerShell and I can stop reading this article and start filling the ScriptControl object with my collection of old GPMC scripts." Unfortunately, that’s not the case. This technique quickly becomes very complex and tough to debug as soon as the scripts get larger.

Wrapping COM Objects
So the best option is the third: wrapping the COM calls in reusable Windows PowerShell functions, which lets you consume the COM objects in the GPMC API. The line below shows how to create a .NET object directly in Windows PowerShell. In this case, it’s a FileInfo object that can be used to get the size of the file:
$netObject = New-Object System.IO.FileInfo(
“C:\boot.ini”) # Create an instance of FileInfo
               # representing c:\boot.ini
Note that # is used in Windows PowerShell for inline comments. Using this newly instantiated FileInfo object, you can easily get the size of boot.ini by simply typing the following code:
$netObject.Length # Display the size in bytes of the
                  # file in the command line interface
Wait, weren’t we supposed to talk about COM objects and VBScript conversion? Yes, but look at the following command:
$comFileSystemObject = New-Object –ComObject Scripting.FileSystemObject
You’ll notice that the syntax is basically the same as I used previously to create native objects from the .NET Framework, with two differences. First, I added the –ComObject switch that points Windows PowerShell toward the COM world instead of the .NET world. Second, I use a COM ProgID instead of a .NET constructor, in this case Scripting.FileSystemObject. The ProgID is the same name you’ve always used. In VBScript, the equivalent would be:
Set comFileSystemObject = CreateObject(
    “Scripting.FileSystemObject”)
To get the file size using VBScript, add the line above to a file, together with the following code:
Set comFileObject = comFileSystemObject.GetFile(
    “C:\Boot.ini”)
WScript.Echo comFileObject.Size
Then run it using Cscript.exe, for example. In Windows PowerShell, you would do it like this (directly from the Windows PowerShell command line if you like):
$comFileObject = $comFileSystemObject.GetFile(
    “C:\boot.ini”)
$comFileObject.Size
Of course, to convert a VBScript that reads the size of a file, I could have used the Windows PowerShell cmdlet that manages objects in drives, but I wanted to show you how easy it is to access COM from Windows PowerShell. Note that though I tell Windows PowerShell to create a COM object, the object that actually gets created, $comFileSystemObject here, is a .NET object that wraps the COM object and exposes its interface. In the scope of this article, however, that doesn’t really matter.

Windows PowerShell in Action
Now that you’ve seen how to access COM from Windows PowerShell, let’s focus on Group Policy. The examples here will show short code snippets to give you an idea of how to use the GPMC APIs from Windows PowerShell, but you’ll find a full set of Window PowerShell functions to manage Group Policy in the code download related to this article, online at technetmagazine.com/code07.aspx. Figure 1 lists the functions included in the download.
Figure 1 Custom functions in the download (Close Figure 1)

Function Name | Description
BackupAllGpos | Backs up all GPOs in a domain
BackupGpo | Backs up a single GPO
RestoreAllGpos | Restores all GPOs from a backup to a domain
RestoreGpo | Restores a single GPO from a backup
GetAllBackedUpGpos | Retrieves the latest version of GPO backups from a given path
CopyGpo | Copies the settings in a GPO to another GPO
CreateGpo | Creates a new empty GPO
DeleteGpo | Deletes a GPO
FindDisabledGpos | Returns all GPOs where both the user and computer part are disabled
FindUnlinkedGpos | Returns all GPOs that have no links
CreateReportForGpo | Creates an XML report for a single GPO in a domain
CreateReportForAllGpos | Creates a separate XML report for each GPO in a domain
GetGpoByNameOrID | Finds a GPO by its display name or GPO ID
GetBackupByNameOrId | Finds a GPO backup by its display name or GPO ID
GetAllGposInDomain | Returns all GPOs in a domain
As you read this section, feel free to start the Windows PowerShell command line and type in the commands. Remember that the some commands are dependent on previous commands, however. In other words, some of the objects created initially will be used later on, so stay in the same Windows PowerShell session. If you close the session, you’ll have to start over from the beginning, retyping all the commands.
So, let’s create a new GPO using Windows PowerShell. The Group Policy team at Microsoft included a number of fully working VBScript samples with GPMC that you can take advantage of to speed things up. They’re in the %ProgramFiles%\GPMC\Scripts directory, where you’ll also find a file called gpmc.chm that contains the GPMC API documentation. Let’s have a look at the CreateGPO.wsf script and dissect it to see what makes it tick.
Near the top you’ll see this line:
Dim GPM
Set GPM = CreateObject(“GPMgmt.GPM”)
This is basically the starting point of any Group Policy management session or script because it instantiates the GPMgmt.GPM class that allows access to most of the GPMC functionality. Let’s go ahead and do this from Windows PowerShell instead:
$gpm = New-Object -ComObject GPMgmt.GPM
Now that you have the starting point for Group Policy management, the next step is to figure out what you can do with it. Normally, you’d turn to the documentation for this type of information, but Windows PowerShell has a really cool feature. If you type the following line, you get the output shown in Figure 2:
Figure 2 Get-Member output
Figure 2 Get-Member output
$gpm | gm
Pretty cool if you ask me. Note how the Get-Member (or gm) cmdlet lets you see the properties and methods the object supports right from the command line. Of course it’s not the same as reading the documentation, but it makes it easy to use objects you’re already familiar with when you don’t remember the exact number of parameters, the exact name, and so forth. One important point to note is that when you look at the GPMC documentation node listings, it looks like the GPM object and all the other classes are prefixed with the letter I; this is due to the internal workings of COM and doesn’t really concern us here; it is intended for C++ programmers writing native COM code and denotes the difference between an interface and the class that implements it. Also note that when using the GPMC APIs, there is only one object you need created this way, and that is GPMgmt.GPM; all other objects are created using methods that start with this GPM object.
Let’s continue now with the creation of a new GPO.
Figure 3 illustrates how simple it is to create a GPO. Note that I’ve left out some code, including error handling (for example, what will happen if you are not allowed to create GPOs), and I’ve hardcoded a domain name, but you should get the idea.
Figure 3 Create a GPO (Close Figure 3)
$gpmConstants = $gpm.GetConstants()
# This is the GPMC way to retrieve all
# constants
$gpmDomain =$gpm.GetDomain(“Mydomain.local”, “”, $gpmConstants.UseAnyDC)
# Connects to the domain where the GPO should
# be created, replace Mydomain.local with the
# name of the domain to connect to.
$gpmNewGpo = $gpmDomain.CreateGPO()
# Create the GPO
$gpmNewGpo.DisplayName = “My New Windows PowerShell GPO”
# Set the name of the GPO
Now that you know how to create a GPO, let’s open an existing one instead. You still have the reference to the domain, $gpmDomain, so type in the following:
$gpmExistingGpo = $gpmDomain.GetGPO(
  “{31B2F340-016D-11D2-945F-00C04FB984F9}”)
# Open an existing GPO based on its GUID,
# in this case the Default Domain Policy.
$gpmExistingGpo.DisplayName
# Show the display name of the GPO, it
# should say Default Domain Policy
$gpmExistingGpo.GenerateReportToFile($gpmConstants.ReportHTML, “.\DefaultDomainPolicyReport.html”
This gives you a full HTML report of the settings in the Default Domain Policy, but you can obviously use any of the methods and properties, like ModificationTime, which tells you when the GPO was last modified, to figure out when any of the settings in the GPO changed.
This is extremely useful. Most likely you’ve been in a situation where the phones start ringing like crazy with users complaining that their computers are acting weird. You suspect this is related to a changed, added, or deleted GPO setting, but you don’t have a clue which GPO to look in. Windows PowerShell to the rescue! If you enter the script shown in Figure 4 at the Windows PowerShell command line, you get all GPOs that have been changed in the last 24 hours.
Figure 4 Discovering modified GPOs (Close Figure 4)
$gpmSearchCriteria = $gpm.CreateSearchCriteria()
# We want all GPOs so no search criteria will be specified
$gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# Find all GPOs in the domain
foreach ($gpmGpo in $gpmAllGpos)
{
if ($gpmGpo.ModificationTime -ge (get-date).AddDays(-1)) {$gpmGpo.DisplayName}
# Check if the GPO has been modified less than 24 hours from now
}
Note the –ge operator, which means greater than or equal to. It might look strange if you’re used to the < and > operators in other scripting or programming languages. But those operators are used for redirection, for example to redirect the output to file, and thus could not be used as comparison operators in Windows PowerShell.

Wrapping Up
The code in Figure 5 lists the full script for copying the settings in one GPO to another GPO. You should now have a good idea of how you can use this new technology with Group Policy and how you can reuse any COM object or VBScript code that consumes a COM object.
Figure 5 Copy the settings in one GPO to another GPO (Close Figure 5)
###########################################################################
# Function  : CopyGpo
# Description: Copies the settings in a GPO to another GPO
# Parameters : $sourceGpo     - The GPO name or GPO ID of the GPO to copy
#           : $sourceDomain   - The dns name, such as microsoft.com, of the domain where the original GPO is located
#           : $targetGpo      - The GPO name of the GPO to add
#           : $targetDomain   - The dns name, such as microsoft.com, of the domain where the copy should be put
#           : $migrationTable - The path to an optional Migration table to use when copying the GPO
# Returns   : N/A
# Dependencies: Uses GetGpoByNameOrID, found in article download
###########################################################################
function CopyGpo(
 [string] $sourceGpo=$(throw ‘$sourceGpo is required’),
 [string] $sourceDomain=$(throw ‘$sourceDomain is required’),
 [string] $targetGpo=$(throw ‘$targetGpo is required’),
 [string] $targetDomain=$(throw ‘$targetDomain is required’),
 [string] $migrationTable=$(“”),
 [switch] $copyAcl)
{

 $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
 $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
 $gpmSourceDomain = $gpm.GetDomain($sourceDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC
 $gpmSourceGpo = GetGpoByNameOrID $sourceGpo $gpmSourceDomain
 # Handle situations where no or multiple GPOs was found
 switch ($gpmSourceGpo.Count)
 {
   {$_ -eq 0} {throw ‘No GPO named $gpoName found’; return}
   {$_ -gt 1} {throw ‘More than one GPO named $gpoName found’; return}
 }
 if ($migrationTable)
 {
   $gpmMigrationTable = $gpm.GetMigrationTable($migrationTable)
 }

 $gpmTargetDomain = $gpm.GetDomain($targetDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC

 $copyFlags = 0
 if ($copyAcl)
 {
   $copyFlags = Constants.ProcessSecurity
 }
 $gpmResult = $gpmSourceGpo.CopyTo($copyFlags, $gpmTargetDomain, $targetGpo)
 [void] $gpmResult.OverallStatus

}
Windows PowerShell will be, just as Group Policy already is, a natural part of any Windows management environment. But there are millions of lines of VBScript out there that will have to be migrated or maintained, and hopefully this tutorial will help.
There are a number of sources you can use to enhance your Group Policy administration and other areas where you’ve previously used VBScript, including the Windows PowerShell functions in the download, and a great VBScript-to-Windows PowerShell conversion guide on the TechNet Web site that provides hints on how to do common tasks in Windows PowerShell when you know the equivalent in VBScript. You’ll find it at microsoft.com/technet/scriptcenter/topics/winpsh/convert.
In addition, the GPMC API is fully documented; you can download the information from the Group Policy site at microsoft.com/grouppolicy.
Last but not least, if you haven’t already installed Windows PowerShell, what are you waiting for? Download it from microsoft.com/powershell. Have fun.

Thorbjörn Sjövold is the CTO and founder of Special Operations Software (www.specopssoft.com), a provider of Group Policy based Systems Management and Security extension products. Reach him at thorbjorn.sjovold@specopssoft.com.


 Windows Administration: A Guide to Deploying Terminal Services
Windows Administration James D. Silliman

A Guide to Deploying Terminal Services
At a Glance:
  • Deploy Terminal Services in a few easy steps
  • Optimize Office in your TS environment
  • Manage your users efficiently using TS

Flash back to 1998: Microsoft releases Windows NT 4.0 Terminal Server Edition, code-named "Hydra." Microsoft licensed technology from Citrix Systems, creating its first thin-client/
server offering. For system administrators, "Hydra" was a difficult deployment. Fast-forward a few years and Terminal Services has changed dramatically. It's fully integrated into the kernel and sets up easily with a built-in installation wizard, requiring no separate CD or Internet download. Given the relative ease of installation, there are many reasons why deploying Terminal Services in your organization makes sense. The most immediate advantage is having all your applications run on a central server or servers, so that client architecture and hardware is not an issue. All the end user needs is a Remote Desktop Protocol (RDP) client to connect to the central servers. Fortunately, RDP clients are available for most current architectures.
In this article, I show you how to enable Terminal Services on an existing Windows Server® 2003 installation, how to apply Terminal Services Group Policies, and how to use the Custom Installation Wizard to automate Microsoft® Outlook® profile settings. When we're finished, you will have a fully deployed Terminal Server to serve up applications to your users.

Getting Started
The first step you'll need to take to set up Terminal Services is to open the built-in Configure Your Server Wizard that is located in Windows Server 2003 Administrative Tools. Select Terminal Server and then click Next until the wizard completes. The installation program warns you that it will have to automatically reboot the machine to initialize the changes. After the reboot, the server will be in Terminal Server mode.
Make sure, by the way, that you've got your Terminal Services Client Access Licenses (CALs) in hand before you start or no one will be able to connect after your successful deployment. Now join the box running Terminal Services to your Active Directory® domain and log in with an account that has Domain Admin privileges. If you're not on a domain, it will be difficult to proceed because you won't be able to enforce Group Policies. For this article, the server where you're installing Terminal Services is called TS01.
Next, launch Active Directory Users and Computers from the Admin Tools and create a new Organizational Unit (OU) where you'll place the Terminal Server. For simplicity's sake, let's give the OU the highly original name Terminal Servers. Locate your Terminal Server, TS01, and move it into your new Terminal Servers OU.
Next, download and install the Group Policy Management Console (GPMC) from microsoft.com/windowsserver2003/gpmc. This management utility allows you to set up a new Group Policy, assign permissions to it, and then edit the policy so you can turn applicable policy settings on or off for any of the users who will be connecting. GPMC is an essential tool for Terminal Services deployment because it has a built-in Modeling wizard that immediately reflects which policies have been applied to a user and which have not.
Launch the GPMC console from Administrative Tools, and locate your new Terminal Servers OU on the left side of the Group Policy Management window. Right-click the OU, choose Create and Link a GPO Here as shown in Figure 1, and give it a utilitarian name like Terminal Server Policy #1.
Figure 1 Creating and linking a new GPO
Figure 1 Creating and linking a new GPO
You'll notice that an Authenticated Users group magically appears in the Security Filtering box on the right side of the GPMC window. This group is added by default to all Group Policy Objects (GPOs). Click on the group and then click the Remove button. You want to set up a Terminal Services group instead in your Active Directory tree to which to apply your GPOs when users log on to TS01. Let's call our Terminal Services group BottleWashers. Go ahead and add them into your Active Directory structure using Active Directory Users and Computers from Administrative Tools. You'll also need to add BottleWashers to the Remote Desktop Users group on TS01 and on any other Terminal Servers that you install.
Make sure you are on the Scope tab now. Click on the Add button in the Security Filtering box and then add BottleWashers as a group. The BottleWashers will automatically get the Read and Apply Group Policy rights to Terminal Server Policy #1. These two permissions are the default Group Policy rights and they're necessary for any policies to apply to an object.
Next, add your server, TS01, into the Security Filtering box as well. For this operation, there is an additional step. First click Add and then under Object Types, make sure you place a checkmark in the Computers tab; otherwise the GPMC will not be able to locate TS01 in Active Directory. The final result should look like Figure 2.
Figure 2 Adding TS01 under Security Filtering
Figure 2 Adding TS01 under Security Filtering
Likewise, the correct policy rights will automatically be applied to TS01 by adding it into the Security Filtering box. It's a good idea at this point to click on the Delegation tab at the top of the right-hand GPMC screen, and then find Domain Admins, which is also listed by default on any new policies. Click the Advanced button in the bottom right-hand corner of the screen.
You will now be viewing the Security Settings for the Group Policy object. Be sure to place your focus on Domain Admins and then find the Apply Group Policy setting on the bottom. On the right-hand side, check the Deny option. When you click OK, you'll receive the standard warning message that's issued any time you set a Deny permission. This step prevents your new TS policy from being applied to Domain Admins—a result that would be less than desirable.
Remember that I advised you to have your Microsoft CALs in order? You will need to review the licensing paperwork and determine which Terminal Services CALs you purchased. There are two flavors of CALs for Terminal Server: User and Device. You can obtain more information on licensing at microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx.
Basically, per-user licensing enables one user to consume only one Terminal Server license, regardless of the number of devices (PCs) from which the user connects.
If you do not have a Terminal Server license server already in your domain, locate a member server that can take on the role. Though it's supported, it's best not to make TS01 the licensing server because if you add more Terminal Servers to your organization at a later time, you would not be building much fault-tolerance into your infrastructure. Go into Control Panel on your proposed licensing server. Open Add/Remove Programs | Window Components | Terminal Server Licensing, and follow the prompts to enable the licensing server. After this completes, click on Start | Run and enter:
tscc.msc
This brings up the Terminal Server Configuration\Server Settings tree. It's here that you click on Server Settings | Licensing and choose Per User or Per Device. The default is Per Device. If you already have a Terminal Server licensing server in your domain, there is a setting within Terminal Server Policy #1 that indicates the server that's holding the License Server role. After you complete this task, go to Start | Run again and type:
licmgr.exe
Now you need to activate your CALs so users can connect. Conveniently, you can do this either by phone or Web. Users should then be able to connect to your Terminal Server but there will be no enforced policies, so let's start setting a few important ones. Some that Microsoft recommends are located in the Knowledge Base article "How to lock down a Windows Server 2003 or Windows 2000 Terminal Server session".

Enabling Policies
The main thing to keep in mind is not to start enabling policies right and left without knowing exactly what each policy does, or you may get some unintended results down the line. A better approach is to start with a few essential policies and test them extensively in a lab environment.
The first policy you may want to enforce is the Loopback Policy. To enable it, launch GPMC, locate the Terminal Server Policy #1, right-click on it and then select Edit. Go to Computer Configuration | Admin Templates | System | Group Policy and enable the User Group Policy loopback processing mode setting. After enabling this policy, you set its Mode value, which can be either Replace or Merge. For the best results in Terminal Services, select Replace.
Another Terminal Server setting you should enable is Add the Administrators security group to roaming user profiles, located in Computer Configuration\Administrative Templates\System\User Profiles. This setting ensures that you, as an administrator, always have full control over user profile folders. It needs to be set sooner rather than later, as it will not apply if the folders have already been created after the user logs in for the first time (see Figure 3).
Figure 3 Enabling the Add Administrators security group value
Figure 3 Enabling the Add Administrators security group value
You will find a whole range of policies in Computer Configuration\Administrative Templates\Windows Components\Terminal Services. Consider enabling these:
  • Restrict Terminal Services users to a single remote session
  • Set path for TS Roaming Profiles
  • TS User Home Directory
Note, however, that restricting Terminal Services users to a single remote session will not prevent users from logging in more than once, as you would think it would. Instead, when a user attempts to launch a second Terminal Services session, he simply takes over the first logged-on session.
Roaming profiles are an essential element of proper Terminal Server operation. By default, when a user logs on to a Terminal Server, a local profile is created on the Terminal Server C: drive, even if you've hidden the C: drive from users. The default behavior for a roaming profile is to synchronize the local profile to a roaming profile share on the network when the user logs off. A Group Policy can be set to purge this local profile when the user logs off.
The next two Terminal Services policies mentioned above, Set path for TS Roaming Profiles and TS User Home Directory, are related to roaming profiles. These settings are often hardcoded in an Active Directory user's Terminal Services Profile Path box. It's much easier and preferable to set the Terminal Services paths via Group Policies. In the case of Active Directory Users and Computers' Terminal Services Profile paths, if you set up a new user or copy an existing user, the TS Server Profile Path information has to be added manually every time—a major pain. It's much better to set these paths to a network share and use a GPO to configure them for you.

Folder Redirection
Now let's take a quick look at another very important Terminal Services component, Folder Redirection, which optimizes the TS experience by preventing excessively long logons and logoffs. The folders you can redirect are Application Data, Desktop, My Documents, and Start Menu. These four folders have to exist on a network share and they require specific access control lists (ACLs). Have a look at Knowledge Base article "How to Dynamically Create Security-Enhanced Redirected Folders by Using Folder Redirection in Windows 2000 and in Windows Server 2003" for further information on this topic.
The advantage of Folder Redirection is that the whole user profile does not have to be copied every time a user logs on or off. Terminal Services recognizes that these folders reside on the network and basically just provides a pointer to them.
It is advisable with roaming profiles and Folder Redirection to explore the Distributed File System (DFS) to simplify maintenance of your network shares. Due to space constraints, I won't go into DFS in this article, but you can explore it further at the DFS Resource Center.
You'll find the Folder Redirection settings in User Configuration\Windows Settings\Folder Redirection (see Figure 4). The Folder Redirection folder values are very straightforward. You may want to remove the checkmark in each Folder Redirection setting that reads Grant the user Exclusive Rights, otherwise administrators will not be able to access the folders.
Figure 4 Folder Redirection settings location
Figure 4 Folder Redirection settings location

Install Microsoft Office
Now that you have some essential polices in place, let's get ready to install Microsoft Office 2003 or the 2007 Microsoft Office system. Microsoft Office is optimized for Terminal Services, so there isn't much that needs to be changed during the installation. High-bandwidth items within the Office suite are turned off by default. At this point, you will need to download and install the Group Policy Administrative Template Files (ADM files) so you can control policies within the Office suite.
The ADM files you need are located at microsoft.com/office/orkarchive/2003ddl.htm. For our purposes, you only need to download two files: Office Template Files (ORKSP2AT.exe) from , and the Custom Installation Wizard. However, the second file is only necessary if you are going to deploy Office 2003. The 2007 Office System does not use the wizard; all you have to do is simply click on Start | Run, and type Setup /a and it launches automatically.
After you unpack the first file, ORKSP2AT.exe, you'll see a number of files. The office11.adm and outlk11.adm files are the ones you'll focus on (see Figure 5).
Figure 5 Office Template files
Figure 5 Office Template files
Launch Windows Explorer and copy these two files to %systemroot%\inf. Go back and launch the GPMC console again. Locate Terminal Server Profile #1 under Group Policy Objects, right-click on it and then select Edit. Now go to Computer Configuration\Administrative Templates within the defined policy. Right-click on Administrative Templates and select Add/Remove Templates, as in Figure 6.
Figure 6 Adding Administrative Templates into the GPO
Figure 6 Adding Administrative Templates into the GPO
You'll see that the two files are available to you now. Add them one at a time. These template files appear in User Configuration\Administrative Templates\Microsoft Office 2003 and in User Configuration\Administrative Templates\Microsoft Office Outlook 2003. You can browse these template settings and enable or disable them as you wish.
I won't go into many settings here, but two that you may want to remove are the Office Assistant and Outlook AutoArchive. Note that some settings, such as Exchange Cache Mode and Junk Mail filtering are disabled by default in Terminal Services, so it is not necessary to disable these policies.
You will find more information in "Outlook Features That Are Disabled with Terminal Services". The Office Assistant can be easily disabled by selecting User Configuration\Administrative Templates\Microsoft Office 2003\Assistant\Options in Group Policy.
In a Terminal Services environment, you don't want to continually prompt your users to take some action. One particularly intrusive example of prompting involves Mail AutoArchive settings for Outlook. If this setting is ignored within your Group Policy, your users are prompted to AutoArchive at specific intervals. Disabling this setting takes it entirely off their Outlook Preferences menu. Of course, you may want to AutoArchive, so you can fine-tune the settings in the policy User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Tools | Options\Autoarchive.
The next step to take to ensure a successful Terminal Services deployment is to set up an Outlook PRF file so users will not be prompted to configure their Outlook settings manually. This may seem like a Herculean task, but it's not. It requires installing the OrkTools and using the Custom Installation Wizard to create a PRF file that tells the Outlook setup wizard how to behave. The 2007 Office System has a mechanism that makes the process obsolete, though you can still use a PRF file with Office if you want.
Let's set up an Outlook PRF file with the CIW. You won't actually run through the entire CIW routine, only the part necessary to export the modified PRF file. There are only a few steps.
First, launch and unpack the second file you downloaded earlier, (the Custom Installation wizard). After you launch the wizard from Start | Programs | Microsoft Office 2003 Resource Kit, you'll be asked for the location of the Office 2003 MSI file. Insert your Office 2003 disk and indicate the name and path to the MSI file.
Now jump ahead in the CIW, directly to page 17 of 24, so you can skip the rest of the CIW and simply create the PRF file. At Step 17, select New Profile and give it a name such as Outlook, then click Next. You are presented with a screen that allows you to select an Exchange Server (as in Figure 7). Type in the name of your Exchange Server and click Next to proceed.
Figure 7 Configuring an Exchange Server connection
Figure 7 Configuring an Exchange Server connection
It's a good idea to add the Outlook Address Book to the profile you are creating. Doing so lets users select their Contacts when they are composing a new message. This step alone could save you lots of manual work down the road. You can also configure additional customized features here if you select the Add button. Now click Next and all that's left to do is to export the PRF file.
At this point, you'll need to create a batch file and place it in your Netlogon share on your domain controller, not on TS01. The batch file will launch any mappings you need and set up the PRF file for deployment. I've made the task easy by writing the WMI scripts for you. However, please only use these scripts as a guide; you need to insert the information relevant to your situation. If you prefer, you can use another script processor, like KiXTart.
Your batch file (logon.bat) should include these lines:
REM Logon.bat
@echo off
wscript %0\..\clean.vbs
wscript %0\..\outlook.vbs
The Clean.vbs file will remove the First-Run registry key so that Outlook will process the PRF file:
' Clean.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
    sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\
    Outlook\Setup"
sValueName = "First-Run"
oRegistry.DeleteValue HKEY_CURRENT_USER, sKeyPath, _
    sValueName
Outlook.vbs will add the proper Outlook setup key to the registry for each Terminal Server user. You need to provide your own path in the SValue= setting and don't forget to add your actual customized PRF file into the real network directory:
sValue = \\Serv01\PRF\Outlook.prf
Change this path and place your Outlook.prf file in it:
' Outlook.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
  sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\Outlook\
    Setup"
oRegistry.CreateKey HKEY_CURRENT_USER, sKeyPath
sValue = "\\Serv01\PRF\Outlook.prf"
sValueName = "ImportPRF"
oRegistry.SetStringValue HKEY_CURRENT_USER, _
    sKeyPath, sValueName, sValue
The next item on your deployment agenda is to install Office 2003 or the 2007 Microsoft Office system on TS01. As I've mentioned, Microsoft Office is optimized for a Terminal Services environment. There is no longer any need to create custom Transforms. You can turn off Office features beyond the ones that are preselected, but it's not mandatory. Conversely, you can also turn on features but doing so may have adverse bandwidth repercussions. Remember to test any features you enable in a lab environment before deploying them in a production situation.
Before you install either version of Microsoft Office, you will want to place TS01 in the proper user mode. There are two possibilities to choose from: Install and Execute. You should be in Install mode before performing any software installations. To place TS01 into Install mode, type this at the command prompt:
C:>change user /install
After the installation completes, put TS01 back into Execute mode by typing:
C:>change user /execute
Install mode is automatically launched if you run a Setup.exe or Install.exe file on TS01. All Microsoft products have these launch files. However, some apps don't use either, so go with the Change command to be safe. What if you forget what mode you're in? Just execute the command below, which will tell you:
C:>change user /query
If you've made it this far, things are good. You can now go to a Windows client workstation, click on Start | Run, and then type this command:
mstsc
If you're using Windows 2000, you can download the Microsoft Terminal Services Client (Mstsc) utility.
A Remote Desktop Connection screen should now appear. Simply type in the Terminal Server name or IP address to connect. There are many available selections under the Options button, such as whether to connect local drives or printers, or change the video resolution. You can also hardcode TS01 into the Options area and then save the RDP profile to your desktop. By default, the RDP profile is called Default.RDP.

Administrative Tasks
If you want to perform some administrative tasks on TS01, your best bet is to use this command because it simulates actions just as if you were physically sitting at the console:
Mstsc /console
If you're administering a number of different Terminal Servers, you may want to use the Remote Desktops utility located in Administrative Tools because you can add all your remote Terminal Servers into a single Tree format.
One last command you should know about is Tsadmin, which lets you view which users are connected to your Terminal Server and which Windows processes users have open. It also allows you to shadow your users, a huge benefit to administrators. Note, though, that if you launch TSadmin from your workstation, you won't be able to shadow users. You will only be able to see the connections. You have to be logged in directly to the TS01 in order to shadow users, send them a message, or log them off.

Conclusion
You should now have a solid understanding of Terminal Services, so deploying a Terminal Server on your own will be a snap. There are lots of topics for further exploration, including Group Policy settings and DFS, but if you remember the basics, like not going overboard when you set your GPOs, and testing them extensively before unleashing them on your users, you'll have made a very good start.

James D. Silliman, MCSE, a Senior Systems Engineer at DirectApps, Inc., specializes in terminal server deployments. DirectApps architects .NET solutions and provides hosting and ASP services. You can reach him at James@directapps.com.


 From the Editor: Security To Go
From The Editor
Security To Go
Joshua Trupin

Today’s workplace can go anywhere. In the past decade, the concept of "your office anywhere" has really taken off. No longer do you have to be present at your desk to do your work. Mobility technologies allow you to be productive on the road, at home, on the train, even in your car during red lights (proceed with caution). It’s truly a wonderful world. Except if you’re an IT pro facing perhaps your greatest challenge: securing and managing devices that can get up and walk away.
Security in the 1980s meant reacting to reports of new viruses by telling people to put their floppies inside plastic bags to keep them away from each other. (No, seriously. When I did this at a former employer, no machines were infected!) If a rogue program did end up infecting a machine, it was contained unless someone walked an infected floppy to the next cubicle. Sometimes it was easier for IT pros to just sneak around and remove everyone’s 5.25" drives when they were out to lunch. The lucky ones had a 10MB hard drive for their data.
In the 1990s, it became progressively harder to catch users who were infecting their own machines because they started to get viruses through the Web. Unlike a decade earlier, you couldn’t protect machines by knocking diskettes out of someone’s hand with a fancy slo-mo special-effects dive anymore.
These days we get a handle on securing the enterprise, distributing group policy, and setting up firewalls, quarantines, and chokepoints. And now what? The enterprise itself starts walking around! Right out the door. So what do you do?
Securing the assets in your office is only half your challenge in today’s IT climate. Any organization is only as strong as its weakest point, and having employees walk around with mobile devices and laptops connected to your network can be begging for trouble. Our lead story this month talks about how to secure mobile devices so that you—the weary administrator—can sleep at night.
Of course, we’ve got much more in this issue. We’re looking at managing regulatory compliance with Exchange Server, network access protection, deploying Terminal Services, Windows PowerShell, SQL Server, and so much more that it would take a whole page to tell you all about it. (Actually two, judging by our Table of Contents.)
What is the most unusual security situation you’ve encountered at your company? Drop by the TechNet Magazine blog (blogs.technet.com/tnmag) and join the conversation. Editors are standing by! —Joshua Trupin

Thank you to the following Microsoft technical experts: Alex Balcanquall, Tad Brockway, Anah Cameron, Jeroen de Borst, Michael Higashi, Ryan Hurst, Paul Limont, Sherman Lovell, Michael Murgolo, Shivakumar Seetharaman, John Speare, David Strome, and Jim Truher.

Joshua Trupin


 Letters: Answers to Your Questions
Letters
Answers to Your Questions

Making Images
In the article "Getting Started with Windows® PE" (September 2006), Wes Miller makes reference to mkimg.cmd. This command file doesn’t exist anywhere on my Windows Vista™ system, which has both the Windows Automated Installation Kit (WAIK) and the Business Desktop Deployment Solution Accelerator (BDD) 2007 installed. In the current distributions, I have mkimg_pe2004.cmd and mkimg_pe2005.cmd. However, they call to a bldini.cmd file that also doesn’t seem to exist. Where can I find these files?
—Jim A.

The article was actually published prior to the release of Windows Vista and refers exclusively to the version of Windows PE available for Windows XP and Windows Server® 2003 (known as Windows PE 1.6). A subsequent article was published in our November 2006 issue discussing Windows PE 2.0, which is the version available for Windows Vista. You can find that article on our Web site.
You can build and customize Windows PE 2.0 images with the tools found in the WAIK—specifically, the "mkimg" command has been replaced by "peimg". You can find a walkthrough of building a Windows PE 2.0 image in the WAIK online documentation.

Security Myths
In response to the suggestion that long passwords are preferable to complex ones ("Deconstructing Common Security Myths," May/June 2006), what do you suggest is the best way to make these retrievable when needed? Long passwords may be difficult to dedicate to an individual’s memory. I’ve also heard the advice to use a different password for each system requiring access, but this can create similar problems with storage and retrieval.
— Ian R.

We asked our good friend and contributor Steve Riley, who quickly replied:
Interesting point about mental retrievability (yes, I just made up that word). I would argue that it’s easier to remember a sentence used as a pass phrase than to remember an arbitrary collection of characters in a complex password. And if you employ a mapping method, then you can remember a large number of pass phrases. For instance, say that your pass phrase for Hotmail® is "My dog and I got the mail." It’s easy to remember because there’s an association (getting the mail) with the destination (e-mail site). Employ the mapping method and you get "My dog and I went shopping." as your pass phrase for eBay, "My dog and I went to work." as your pass phrase for your domain account at the office, and even "My dog and I admired some art." as your pass phrase for your favorite, ah, picture site.
Sources for pass phrases are almost limitless. I know someone who uses only quotes from Monty Python movies. Another uses only five-word phrases where each word begins with consecutive letters on the keyboard ("Queen willie eats rancid turnips."—QWERT). With a little creativity, pass phrases can help eliminate most of the problems associated with passwords while strengthening the secret used to prove one’s identity.

"Deconstructing Common Security Myths" is a great article. It turned my assumptions right on their pointy little heads. But if software allowed the generation and use of unique character sets (not the ones you have in Webdings®, I mean ones never seen before) in an independent program, wouldn’t that shift the weighting towards complexity since nobody could ever have a complete set of all possible unique characters, and only the user knows which ones were generated and used? I’d rather recreate a short line of such characters than type in "War and Peace" if I lose my USB key.
—H.D.

Interesting idea, but we’re not sure exactly how you’d be able to remember a unique, never-before-seen character. Unless you’re The Artist Formerly Known As Prince.

Sysprep
In the article "Techniques for Simplifying Desktop Image Creation" (May/June 2006), Shelly Bird says that when you’re building a Sysprep folder, "The process starts with building the master image on a legacy system with basic hardware..." What exactly does she mean by this? I am currently looking at the BDD and still cannot find anything in there that would suggest deploying with a single image. How do I obtain this information?
— Jon S.

In the article you refer to, the author is talking about creating a standardized reference configuration that can be captured as an image and redeployed to other computers. In other words, you take the most simple hardware you have in your environment (as a lowest common denominator), install Windows and configure it with your basic specifications (any modifications you want to make that you want deployed throughout your organization), install any applications that you want included as well, and then prepare it for deployment using the Sysprep tool (which removes any hardware specific information, allowing the image to be redeployed to new hardware).
The best guidance for this process exists in the Computer Images System Feature Team Guide which is part of the BDD. The Computer Imaging System component of the BDD includes a downloadable tool to help you customize and prepare your image. See microsoft.com/technet/desktopdeployment/bdd/standard/ComImgFea.mspx for more information.

Converting Authentication
I use SQL Server™ 2005 at work. How can I change my authentication from Windows Authentication to SQL Server Authentication (with sa login)?
— Sara J.

This topic from the SQL Server Books Online should help you address your problem: msdn2.microsoft.com/ms188670.aspx. However, we strongly advise that you stick with Windows Authentication because of the security implications of using sa (especially without a password). We no longer use sa/nopass in our code samples for just this reason.

Effusive Praise
I very much enjoy reading TechNet Magazine each month. I enjoy it so much that I take a few copies with me in my backpack or in the car at all times wherever I happen to go: at work, at home, pretty much everywhere. I wish I could carry the entire magazine either on my Tablet PC or Pocket PC Phone. I would love to see an audio version of the content for my MP3 player. Overall, the magazine is AWESOME. I love it, I love it, I love it. I tell all my colleagues about it and I advertise it like a bible.
— Erasmo M.

You want audio content? You got it! We offer a TechNet Magazine podcast each month. Just go to the TechNet Magazine site (www.technetmagazine .com) and click the Podcast link on the left. We’d love you to hear from us!

Jigsaw Poster
The Active Directory® Component Jigsaw poster in your March/April 2006 issue was by far the best graphical representation I have ever seen of how Active Directory works in Windows Server 2003. I managed the project to get our world-wide org onto Windows 2000 and into Active Directory, and this type of poster would have made all our jobs a lot easier. Even now, our Enterprise Administrators don’t always agree on the components that are clearly outlined on this poster and access to this type of information would go a long way to enable them to work more cohesively and consistently. Is this poster available as a download?
— Mike C.

We can’t tell you how many requests we’ve received for this poster. It seems that lots of people out there have the same questions you do. We’ve made the poster available as a download at go.microsoft.com/fwlink/?LinkID= 80428, but don’t try to print it out on letter-sized paper. It’s much too big.

Setting Up Outlook E-Mail Signatures
I’m working as a System Administrator for my company and I am in the midst of writing a script to standardize the Outlook® Signature for all the users in my domain. I’ve been using the sample code in your column "Setting Up Outlook E-Mail Signatures" (October 2006). But I do have a small problem: when I try to customize and set the font colors of the signature using the following code, the font color remains black:
objSelection.Font.Color = wdRed
I can change the font and the font size, but not the font colors.
— Edison P.

We asked the Scripting Guys what’s up with that (we have a special red phone that connects directly to them), and they said:
We believe changing font colors requires you to use the wdColor enumerations. Try this:
  • Define this constant in the script:
wdColorRed = 255
  • Assign the color using this code:
objSelection.Font.Color = wdColorRed
That should do the trick.

Getting Windows PE
Our company has a Microsoft® Select licensing agreement; could you help me find out who I need to contact to obtain the fifth generation of Windows PE for use in our organization? In particular, we are seeking to utilize the ability to boot from USB flash drives.
— Thom S.

Windows PE is available as a benefit of Software Assurance. You can determine if your licensing program includes this benefit by viewing the Benefits Comparison Chart. If so, Windows PE will be available for download with your organization’s Microsoft Volume License Services account (you can log in at https://licensing.microsoft.com). If you need assistance in accessing this Web site, we suggest contacting your organization’s licensing coordinator or your Microsoft licensing representative.


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

Analyze HTTP Traffic
HttpWatch Professional Edition
httpwatch.com

HTTP, the basis for browser to Web site communication, is an incredibly useful layer-7 protocol. Furthermore, with the advent of Web services, many Windows® Forms applications use HTTP for downloading program updates and phoning home for validation. Finding problems, performance tuning, or verifying the security of application-to-application communications over HTTP can be difficult, but HttpWatch Professional Edition can help you troubleshoot Web-to-browser issues.
HttpWatch displays the details behind Web requests
HttpWatch displays the details behind Web requests
HttpWatch Professional integrates with both Internet Explorer® 6.0 and Internet Explorer 7, and it can appear either at the bottom of the browser or as a standalone tool alongside the browser. As soon as you click its Record button, HttpWatch starts to capture and log traffic, displaying all the details underlying your Web requests. You can see the raw HTTP stream, any redirections that occur on your page request, the query string key-value pairs associated with the request, the HTTP method, HTTP compression information, and any chunked encoding information. In addition, HttpWatch shows you detailed information about any cookies associated with the request, giving you the path, domain, expiration date, and value of the cookie. And since the application
runs as a plug-in to Internet Explorer, you can also see all the details of decrypted HTTPS requests.
You can delve into the network-level performance data of your requests with HttpWatch, as it shows you response times to the millisecond, DNS lookups, TCP connects, IP address information, ports, and the bytes sent and received from your browser. Think you know everything that is going on with each request? I am always surprised to see how many parts are involved in each request to a single HTML page. Fortunately, HttpWatch includes an option to filter the display by content-type, response code, URL, headers, or a specific content string. This lets you isolate your area of inquiry and quickly hone in on the particular details you are interested in.
The product Web site promotes the tool as a way to troubleshoot issues with your customers. The application allows saving request information, so customers can send you details pertaining to problematic requests. This can be useful for troubleshooting. The proprietary HWL file can be e-mailed with just a couple of clicks. Once you receive this file from your customer, you can view it with the standalone log file viewer included in the installation package. You can also export the request data to CSV and XML so the data can be used in other applications.
HttpWatch has an exposed automation API, giving you the ability to record HTTP-level information during testing to help you find performance bottlenecks. The package installs three examples of how to use the API—one in C via an interop library, and two via COM for JavaScript and Ruby. If you use Ruby with Watir for testing purposes, check out the product Web site for a tutorial on how to integrate HttpWatch into your testing platform.
Price: $249 for a single user license.

Book Reviews
Microsoft Solutions Framework Essentials
microsoft.com/mspress

To deliver successful technology solutions, companies need effective processes and clear communications. Michael S. V. Turner's book, Microsoft Solutions Framework Essentials (Microsoft Press, 2006), gives you the fundamentals of the Microsoft® Solutions Framework (MSF) version 4.0, and shows you how to use them to develop and implement tested process and communications practices.
Turner starts with excellent advice, telling you not to drop everything in your current process and organization structure at once as you apply MSF guidelines and practices. Instead, he suggests implementing a part of the MSF into your product or project development and then evaluating its success. When that evaluation is complete and successful, choose another aspect of the MSF that would suit your project and introduce it into your standard project cycle. In this way, you can both adapt the MSF to your environment as well as mitigate any unforeseen issues arising from the changes.
The book targets anyone—technical or not—involved in the delivery of technology solutions. The chapter entitled Building an MSF Team shows how both technical and non-technical people can and should work to deliver successful solutions. It cautions, however, that this can be one of the more difficult parts of the MSF to implement since it involves changes to day-to-day responsibilities.
Central to the change of structure is the idea of forming a team of advocates in which members work as peers representing distinctive perspectives, and providing additive benefits to the overall process. (Of course, this does not eliminate the need for an authoritative decision-maker.) As described, the MSF advocates are split into seven groups: Product Management, Program Management, Architecture, Development, Test, User Experience, and Release/Operations, each with its own make-up and responsibilities. For organizations with larger groups, the book provides some advice on how to scale-up the idea of advocacy groups to support larger teams and groups.
Risk is a constant in any project and you'll find a wealth of reorganization tips that can help you and your team handle risk effectively. Minimizing project risks is important, and the risk management process is broken into six steps that can make this successful: identification, analysis and prioritization, planning and scheduling, tracking and reporting, change control, and learning from past experience. Moreover, you must continue to evaluate risk throughout the project cycle. The points delineated in this section can really help you mitigate the possibility of failure.
Solution delivery fundamentals are covered in detail, including enactment tracks where you envision, plan, build, stabilize, and deploy your solution, as well as define what each advocacy group is responsible for in each stage. You are introduced to the MSF Governance Model, a more detailed view of each of the tracks of a solution delivery life-cycle: Envisioning, Planning, Building, Stabilizing, Deployment, and finally Governance (that is, guiding the solution delivery).
Though you may think your role in your organization doesn't require the tools and processes discussed in this book, reading it will nevertheless give you new insight into your current processes—whether you're in operations, development, or project management. Even if your job is not related to software development, the topics Turner covers will provide you with a starting point for improving efficiency and the communication channels within your organization.
Price: $44.99.

Edit Files
UltraEdit
ultraedit.com

Every serious IT pro needs a power-packed editor in his toolbox. One editor that I consider to be essential is IDM Computer Solutions' UltraEdit. It supports all the standard features and capabilities you'll get with any worthy text editor, including ASCII character insertion, macros, search and replace by regular expression, external application launching, UTF support, and fast handling of huge text files. However, UltraEdit has a few not-so-common capabilities that make it especially valuable.
For basic editing, you get a 100,000-word multi-language integrated spell checker, auto-completion, and code syntax highlighting for standard languages such as C#. You can set automatic word wrap at a specified column with a hard return—a great feature for formatting text-based e-mail that must have lines less than a certain length. In this scenario, you can then send the e-mail via UltraEdit with just a couple clicks of the mouse. The application is integrated with Windows Explorer, so opening a file for editing is as simple as a right-click followed by a left click.
Code syntax highlighting in UltraEdit
Code syntax highlighting in UltraEdit
UltraEdit is not limited to text files. It capably handles binary files and gives you a standard hex editor view of the hex values, line references, and potential ASCII values. While in hex edit mode, you can cut, copy, and paste values as well as do standard search-and-replace. UltraEdit includes an integrated FTP client that supports connections over both FTP and SFTP. In addition, you can open standard Secure Shell (SSH) or TELNET connections.
For Web developers, the application contains an integrated HTML validation tool for checking Web pages. UltraEdit also has a column mode for working with text-based database files and delimited log files; this mode simplifies editing by allowing you to easily jump between, sum, and edit your data. UltraEdit can even group a set of files into a project or workspace, allowing you to open a bunch of related files with a single click. All in all, UltraEdit has a host of features that can make your IT life easier and more efficient.
Price: $49.95 direct for a single user license.

Manage your Mobile Configuration
Net-Switch
net-switch.com

It's a common problem. You move from environment to environment (from the datacenter cage, for example, to your QA environment) with your laptop in hand. And you find yourself constantly having to re-assign your laptop's static IP address and default printer. If this sounds familiar, you might want to check out Net-Switch. This handy utility allows you to set up and save multiple network configurations, each with its own default printer assignment so you don't have to remember or manually type in those numbers every time you move from one environment to another.
Net-Switch handles laptop settings
Net-Switch handles laptop settings
The application is incredibly easy to use. Just name the configuration, pick a network adapter, assign a static IP with its associated mask, gateway, and DNS servers (or select DHCP), set a default printer, and you're good to go. It's an inexpensive way to rid yourself of a daily hassle.
Price: $19.95 direct.

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

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: Best Practices Analyzer, Multi-Core Processors, and More
SQL Q&A
Best Practices Analyzer, Multi-Core Processors, and More
Edited by Nancy Michell

Q I have some questions about the Best Practices Analyzer (BPA) rule concerning the use of Schema Qualified Tables/Views. As per the BPA documentation, this rule doesn’t check schema qualification on temporary tables. The BPA report flags references to temp tables created within stored procedures. Should they be qualified? If so, with what schema? I would think the temp tables should be qualified to their owners just like other tables.
A The BPA recommendation to schema-qualify table and view references doesn’t really apply on SQL Server™ 2005, as user-schema separation has fixed the problem that required this practice on earlier versions of SQL Server. Schema-qualification was required to enable query plan reuse by different users who, in SQL Server 2000, had different default schemas. They could use dbo objects without qualification, but SQL Server had to check the default schemas for the objects first, preventing query plan reuse. Since user-schema separation allows different users to share a default schema and, in the typical case, all database users to access objects in their default schemas, ad-hoc plans with unqualified table and view names will normally be shared and reused across users. Unqualified table and view names inside stored procedures never suffered from this problem in the first place, further weakening the rationale for this practice. BPA in SQL Server 2005 will not include rules like this because it does not have a T-SQL parser. Instead, it will check for improper configuration and security settings.

Q I’m encountering strange behavior on SQL Server 2005 SP1. If I delete records on a table and perform inserts on the same table at the same time, the inserts are locked until the delete transaction is committed. Is there some way I can find out what’s blocking?
A Yes. You can run the Dynamic Management Views (DMV) script in Figure 1 to find locks and blockers.
Figure 1 Find blocking and locks (Close Figure 1)
-- script to show blocking and locks
SELECT
  t1.request_session_id AS spid,
  t1.resource_type AS type,
  t1.resource_database_id AS dbid,
  (case resource_type
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id)
   WHEN ‘DATABASE’ THEN ‘ ‘
   ELSE (SELECT object_name(object_id)
      FROM sys.partitions
      WHERE hobt_id=resource_associated_entity_id)
  END) AS objname,
  t1.resource_description AS description,
  t1.request_mode AS mode,
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address
GO

Q In addition to hyperthreading and dual-core technology, chip vendors are beginning to release processors with additional cores (four, eight, and more). I am considering purchasing a new server with multi-core processors to support a SQL Server 2005 Standard Edition deployment and am curious if, when using a four-core processor, I will only be able to make use of a single physical CPU (since Standard Edition is limited to four CPUs)?
A For the purposes of both licensing and CPU edition support, SQL Server considers only the number of physical sockets/CPUs, regardless of the number of cores on the processor. So, for example, the fact that SQL Server 2005 Standard Edition supports up to 4 CPUs means it will support 4 physical CPU sockets, regardless of the number of cores in each one (if you have 4 physical CPUs with 4 cores each, your Standard Edition deployment would have 16 logical CPUs to make use of). Moreover, even though you have 16 cores/logical CPUs, the licensing requires only that you pay for the 4 physical CPUs, not all 16 cores. For more information on SQL Server and multi-core, see microsoft.com/sql/howtobuy/multicore.mspx.

Q I’m about to purchase some new database servers. Should my organization go with 64-bit or stick to the tried and tested 32-bit versions?
A It depends. This is a very common question now as vendors transform their hardware from x86 to x64. The first question you should ask is what the memory pressures on your database server will be. If your SQL Server instance will consume less than 3GB of RAM over the life of the hardware (typically three years), then 32-bit x86 is reasonable provided that will be the direction for other servers (domain controllers, DNS servers, application servers, Web servers, mail servers). If the SQL Server instance will consume more than 16GB or there will be multiple instances per server (or cluster), you should seriously consider a move to 64-bit technologies. If there will be more than eight processors, IA64 is the standard recommendation. However, as x64 four- and eight-core CPUs start hitting the streets in quantity, there may be a significant cost argument for going with x64 rather than IA64.
When moving to x64 (or IA64), deploying the same architecture in development, test, and performance environments may not have been included in initial cost estimates. But you should also consider whether you want to get stuck with old technology halfway through your hardware lifecycle. In 18 months it will be almost impossible to source purely x86 hardware. If you go with that kind of solution now, upgrading over the next year or two will be expensive as it will be a rip-and-replace scenario. Going for 64-bit hardware now will give you more options over the next few years.
So a good time to make the jump to 64-bit is when you’re purchasing new hardware, at the commencement of a core application release cycle, or when you’re upgrading from SQL Server 2000 to SQL Server 2005.

Q I have log shipping enabled between two servers. Over the weekend, a hardware problem on the primary server caused log shipping to stop. When I returned to monitor log shipping, I could see that the LS_backup_dbname was running fine despite several hours of downtime.
On the secondary server, however, the copy job appears to be working fine but the restore job seems to be skipping files and eventually failing over and over again. It runs, but skips every file and then fails. So my time since last restore is now 849 minutes. What I’ve done in the past in similar situations is simply re-initiate the shipping configuration—that is, I turn it off and turn it on again so I wind up taking a fresh backup and restoring it to the secondary server, and log shipping begins again. Is there a better way to manage this scenario?
A What you are probably seeing is the effect of having missing backup files. As you know, the log shipping backup, copy, and restore jobs run independently. Old backup files in the copy location are also removed based on the schedule you specify. If you had a period of time where the restore job was not running, it might have exceeded the interval, which would result in missing backup files. The log shipping restore job has logic that tries to recover from different types of failures caused by different operational conditions. Basically, it scans through the files when errors are encountered and tries to find the correct backup files. If a correct backup file is not found, I suspect something has removed the needed files or possibly you reconfigured the backup part of log shipping?
One solution would be to manually restore up through the transaction log backup files that were inadvertently created by the other backup job. The problem with just copying them to the log shipping copy location is the name conventions recognized by log shipping. But once you have manually restored through that point, the normal restore should pick up and continue.

Q I need to know how to use T-SQL to find the size of total and free physical memory. Is there an easy way to get this information?
A Just run the query in Figure 2 and you’ll get the data you’re looking for.
Figure 2 Get memory (Close Figure 2)
With VASummary(Size,Reserved,Free) AS
(SELECT
  Size = VaDump.Size,
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 0 ELSE 1 END),
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 1 ELSE 0 END)
FROM
(
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
    AS Size,
    region_allocation_base_address AS Base
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address <> 0x0
  GROUP BY region_allocation_base_address
  UNION
  SELECT CONVERT(VARBINARY, region_size_in_bytes),
    region_allocation_base_address
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)

SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024
    AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0

Q I would like to store the sa (system administrator) password in a file encrypted with a symmetric key to make database creation from an application easier. Can I do this?
A First of all, you should really never use sa from an application. Plus, you should use Windows Authentication instead of SQL Server authentication.
If you need to perform highly privileged activities, you should do the following: Define the minimal permissions necessary to perform the action. Define a database role that contains those permissions. Assign a user to that role. Create a stored procedure with the EXECUTE AS clause that will perform those functions. For an explanation of the Execute As clause, visit msdn2.microsoft.com/ms188354.aspx.
Of course, disregarding whether the account in question is the sa account, and bearing in mind that Windows Authentication is not always an option, the more basic question is: how do you securely store a password for a SQL Server login account in such a way that the application that needs to use that password can access it, but unauthorized users or applications can’t?
Encrypting the password is a step in the right direction, but it just shifts the problem from protecting the password to protecting the encryption key.
Assuming this is a Microsoft® .NET Framework-based application, take a look at the Enterprise Library at msdn2.microsoft.com/aa480453.aspx and the recommendations in the patterns & practices section of MSDN® at msdn.microsoft.com/practices. The Enterprise Library contains several application blocks that would be useful to you, including a configuration block, a cryptography block, and a data-access block; these can help you to (at least) securely store your passwords, but even more, they can help you to manage your data access overall.
If the Enterprise Library isn’t an option (maybe you’re not using the .NET Framework), then you should familiarize yourself with the CryptoAPI: msdn2.microsoft.com/aa380255.aspx. Here you will find core cryptographic functionality distributed with the OS that can allow you to tie cryptographic keys to a user principal or to a machine, which can simplify key management (which becomes the issue once you’ve encrypted your password).

Q I want to move my SQL Server 2000 two-node Cluster Server (Active/Active—on 64-bit hardware) from Domain A to Domain B within the same forest. The SQL Server database is in the SAN. The Active Directory® architecture calls for an empty root domain with two child domains (Domain A and Domain B). Domain B is going to be the domain in which all the infrastructure components will be placed. It is a Windows Server® 2003 Enterprise environment, with additional domain controllers running Windows 2000.
Is it possible to change the domain membership of the SQL Server Cluster server from Domain A to Domain B?
A For starters, take a look at "How to Change Domains for a SQL Server 2000 Failover Cluster" and at "How to Move a Windows Cluster Server from One Domain to Another". The same process applies for a multi-instance cluster. The only difference is that you’ll have to repeat steps for each instance as appropriate. It’s never "recommended" that you change a cluster’s domain, given the complexities involved, but it has been done many times. The only other way would be to do as you stated, rebuild a new instance side-by-side and migrate the data.
Each project is different and a wide variety of tools are used to perform the actual domain-level change (including security considerations, account migrations, sid mappings, and so forth). Often that’s the toughest part of the process, not the actual change itself.

Thanks to the following Microsoft IT pros for their technical expertise: Sunil Agarwal, Laurent Banon, Steve Bloom, Chad Boyd, Matt Burr, Shaun Cox, Cindy Gross, Bobby Gulati, Matt Hollingsworth, Arnost Kobylka, Mikhail Shir, Fernando Pessoa Sousa, Stephen Strong, and Ramu Veeraraghavan.


 Utility Spotlight: Upgrade Toolkit for SharePoint Sites and Templates
Utility Spotlight
Upgrade Toolkit for SharePoint Sites and Templates
Luis Câmara Manoel and Peter Skjøtt Larsen
Download the code for this article: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

With the recent arrival of Windows SharePoint Services (WSS) 3.0, many administrators are faced with the task of upgrading their existing WSS 2.0 sites and data to their new WSS 3.0 environments. Though WSS 3.0 provides extensive tools that adequately migrate site data and
upgrade site structure, additional work might be necessary to upgrade the structure of customized sites or site templates.
However, additional work might be necessary to upgrade the structure of customized sites or site templates. Fortunately, the Microsoft® Solution Accelerator team has released the Upgrade Toolkit for Windows® SharePoint® Services Sites and Templates, which provides guidance and tools around this practice (see the "WSS Resources" sidebar). This column focuses on some of the challenges and solutions associated with upgrading customized sites to WSS 3.0 environments. But first, see the "WSS Terminology" sidebar for some definitions of common terms.

The Upgrade Process
Why should you upgrade? There are a number of new WSS 3.0 features that might compel site owners to upgrade:
  • Recycle Bin, which lets users retrieve inadvertently deleted documents.
  • Folder item level security, which allows site administrators to control which people or groups have access to folders.
  • E-mailing to lists, which allows lists such as blog post lists on a SharePoint site to receive content through e-mail.
  • Site Actions button, which lets users easily create sites and pages, edit pages, and manage site settings.
  • Breadcrumbs, which provide immediate navigational context for the user.
  • Mobile views, which enable mobile users to take advantage of convenient offline synchronization capabilities.
  • RSS feeds, which let RSS-enabled programs such as Internet Explorer 7.0 and Outlook® 2007 retrieve information from lists.
  • Versioning in document libraries, which allows minor versioning and control for document check out before edit.
Because the site and template upgrade process depends on taking specific steps prior to and following the actual server upgrade to WSS 3.0 (see Figure 1), the definition of site and template upgrade requirements is an important step in the overall WSS 3.0 upgrade strategy. Site owners and server managers should work together to determine which sites and templates should be instantiated and upgraded into a WSS 3.0 environment. Once these custom sites have been selected, the upgrade work can begin.
Figure 1 WSS site and site template upgrade workflow
Figure 1 WSS site and site template upgrade workflow

Identify Customized Site Templates
How do you determine if the sites have been customized? WSS 3.0 provides the pre-upgrade scan tool that generates a report on changes made to site templates for the entire farm. You should run this tool before starting migration to select which site templates require special attention.
The tool provides a report in XML format as shown in Figure 2. The element unghostedPage indicates that a site has been customized.
Figure 2 Pre-upgrade scan tool report on changes made to site templates (Close Figure 2)
<?xml version=”1.0” encoding=”utf-8”?>
<summary>
  <sites>
    <site url=”http://mscc-shr-v3-01” storage=”172767226”>
      <webs>
        <web url=”http://mscc-shr-v3-01/Board of Directors-Basic”>
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/default.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/EditForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/Upload.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/WebFldr.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/EditForm.aspx” />

Custom Site Definitions
Most of the customized WSS 2.0 sites you’ll want to upgrade were probably built from templates created from standard WSS site definitions. It is possible, however, that some of the customized site templates were built on customized site definitions. This may be the case if developers in your organization created customized site definitions or if you purchased third-party applications or templates built on customized site definitions. This column will cover only the standard site definition scenario. For more information on the custom site template scenario, consult the "WSS Resources" sidebar.
Having verified that your .stp files and sites are indeed built from standard site definitions, which means that upgrade site definitions exist in WSS 3.0, you can proceed to install and instantiate your sites.
To upgrade specific WSS 2.0 site templates, first you’ll need to install the templates on a WSS 2.0 server (see Stage 1 in Figure 1). Then you’ll need to create sites based on each of the installed templates.
To streamline the process of installing multiple .stp files, instantiating multiple sites, and cleaning the server of any temporary files after the upgrade process is completed, the solution accelerator provides a set of scripts that leverage Stsadm.exe commands (see the "Solution Scripts" sidebar for details). Stsadm.exe is a command-line application that offers a complete set of WSS operations for managing SharePoint servers and sites. The solution scripts automate this process by letting you batch install and instantiate or to perform these tasks sequentially. The time savings can be considerable if many .stps are to be installed and many sites to be instantiated.
Solution Scripts
The installation and site creation process uses two scripts that run Stsadm.exe:
  • MigInstStp.cmd installs the site templates using the Stsadm.exe addtemplate operation. This operation has the parameters _SOURCEFILELOCATION, _SOURCEFILENAME, and _FILETITLE.
  • MigMakeSite_1.cmd creates the new sites. MigMakeSite_1.cmd runs the Stsadm.exe createweb operation. This operation has the parameters _SERVERURL, _SITENAME, _SITETEMPLATENAME, and _SITETITLE.
Run these scripts on the local WSS 2.0 server with access to the location of your saved site template (.stp) files. To run these scripts, you must be a member of the local Administrators group on the server or a member of the WSS Administrators group with site create permissions. The Upgrade Toolkit for Windows SharePoint Services Sites and Templates guide provides a detailed description on how to take full advantage of these scripts. With your .stps installed and your sites instantiated, you are now ready to proceed to server upgrade. The WSS 3.0 upgrade approaches are explained in detail in “Upgrading to Windows SharePoint Services 3.0” (see the link listed in the “WSS Resources” sidebar).

WSS Terminology
Windows SharePoint Services has its own unique terminology. Here’s a brief glossary of commonly used terms.
Site Definition This is a set of files that defines a specific type of site. A site definition includes .xml, .aspx, .ascx, and Master Page files, as well as list template files and content files stored in a special folder on the front-end Web server. WSS comes with a set of standard, out-of-the-box site definitions that includes Team Site, Blank Site, and Document Workspace. Initially, these are the only site templates stored in the site template gallery and available in the Select a template list on New SharePoint Site.
Site Template Site templates define how to instantiate a SharePoint site. In order to create a new SharePoint site, you must select a site template upon which to base the site. For example, you can create a new site named "Board of Directors" based on a standard "Blank Site" template. You can then add lists, libraries, Web Parts and other customizations to the instantiated site. To make these customizations available to others, you can then save this site as a template named "Board of Directors" that is based on the "Blank Site" site definition. WSS saves the customized site template as a .stp (site template) file, places it in the site template gallery, and displays it in the "Select a template" list on the New SharePoint Site page so users can later create new sites based on it. Site templates contain a series of site configuration files, including .xml, .aspx, image, and others that are then compressed into a single .stp file. (.Stp files are similar in function to .cab files.) The most important of these files is Manifest.xml, which contains critical information such as site structure and navigation, lists and libraries, placement of Web Parts, custom list definitions, and the site definition on which the customized site template is based.
Application Template These are Windows SharePoint Services site templates that are developed to meet the requirements of specific business processes or tasks. They are published by Microsoft and are available for download free of charge to WSS customers.
Customized Site This is a SharePoint site with a user interface that has been modified.
Master Page This is an area where default layout information, such as banner, navigation controls and other menus can be stored for a consistent interface throughout the site.
Ghosted Pages These are pages whose contents are not stored in the WSS content database but rather are read from a site definition file. Ghosted pages have not been customized.
Unghosted Pages These are pages that have been modified from the site definition file, and whose contents are stored in the WSS content database.

After Server Upgrade—Site Inspection
Now you’ve arrived at Stage 2 in the upgrade workflow (refer back to Figure 1). The steps you take in this stage of the site and template upgrade include the following:
  1. Open and verify the upgraded sites.
  2. Apply the default Master Page.
  3. Fix feature and layout issues with the new sites.
  4. Save the corrected sites as new WSS 3.0 site templates.
  5. Redeploy the new WSS 3.0 site templates on the server.
  6. Create sites from the redeployed site templates.
  7. Open the new sites and check that they function as expected.
  8. Initiate the clean-up process.

Resetting to Site Definition
When you first open your upgraded site, you will see that it still very much resembles a WSS 2.0 site. To make the site appear more like a WSS 3.0 site, you must first reset to the site definition in your new WSS 3.0 site. This will fix most of your layout problems and you will not lose any customizations made to Web Parts, provided these Web Parts already reside in a Web Part zone that exists on the site definition page. This action will also apply the default Master Page to all of your sites’ pages.
A Master Page, as its name suggests, is an area where default layout information, such as banner, navigation controls, and other menus can be stored for a consistent appearance. This allows you to make design changes on the Master Page and have the changes propagate across the entire site. By applying Master Pages, all WSS 3.0 native functionality will be enabled in your upgraded sites.
Though the site should now look and function like a native WSS 3.0 site, you are still likely to find a few problem areas, such as Discussion boards, customized Web Parts, hyperlinks, and themes.

Fixing What’s Broken
A number of problems can occur in upgraded and customized site templates. Here are some of the most common problems and some simple ideas on how to fix them.
The WSS 2.0 default style sheet is still applied to a site. Remove the old style sheet in SharePoint Designer.
Web Parts are missing or in the wrong places. Move or insert Web Parts using SharePoint Designer.
Web Parts don’t function correctly. Remove Web Parts that are incompatible with WSS 3.0, and contact the Web Part developer to inquire if corresponding Web Parts have been built for WSS 3.0 environments.
Customized lists and libraries don’t look right. Save your existing data; then recreate the customized list or library and import the saved data.
Enabled WSS 3.0 features are not available. Team collaboration capabilities may have to be explicitly activated the under Site Features.
Hyperlinks no longer work. Hardcoded hyperlinks may require manual updating.
The theme has changed. Apply the appropriate WSS theme.

Almost Done
As the end of the process approaches and the problems have all been fixed, it is time to perform a final verification of the sites. You should save the corrected sites as WSS 3.0 site templates, perform a new .stp installation and site instantiation (you can use the handy scripts here as well), and finally, open the site to verify that all issues have been addressed and your upgraded sites and .stps are ready for further distribution in your work environment.

Alternatives to Upgrading
Upgrading templates using the automated tools and processes described here may not always be the best approach. If you are using highly customized third-party templates, it may be prohibitively difficult to upgrade the templates on your own and it might be better to wait for a new version of the template. In other cases, creating a brand new template on WSS 3.0 and then implementing the features of the old template may be the best option.

Application Templates
There is a set of Microsoft-developed application templates available for WSS 2.0 and for WSS 3.0. The new WSS 3.0 set includes upgraded versions of some of the WSS 2.0 application templates. If you have been using any of these templates, you can upload the upgraded WSS 3.0 version into your WSS 3.0 environment.
If you have been using one of the WSS 2.0 application templates that has not been upgraded for WSS 3.0, the solution accelerator provides you with a set of WSS 2.0 application templates that have been upgraded to work in a WSS 3.0 environment.

Summary
The Upgrade Toolkit for Windows SharePoint Services Sites and Templates will prove extremely valuable in helping you retain your 2.0 templates, sites and customizations in your 3.0 environment. For additional information on this topic, and to get the Toolkit, visit the sites indicated in the "WSS Resources" sidebar.
We would like to thank Betty Houser for her valuable contributions to this column and to the solution accelerator.
WSS Resources
  • Pre-Upgrade Scan Tool
  • Upgrade Toolkit for Windows SharePoint Services Sites and Templates
  • Upgrading to Windows SharePoint Services Version 3.0 (Windows SharePoint Services 3.0 Technical Library)
  • Deploy Upgrade Definition Files and New Site Definitions

Luis Câmara Manoel is a Program Manager in the Microsoft Solution Accelerator group. He has been with Microsoft for a year. Previously Luis worked as a project and program manager at Novell Inc and Volera in Provo, Utah. Luis can be contacted at luiscam@microsoft.com.
Peter Skjøtt Larsen is a Product Manager in the Microsoft Solution Accelerator group. He has been with Microsoft for over four years in development and marketing. Previously he developed client and server software for the financial, engineering, and telecom industries. Peter can be contacted at petela@microsoft.com.


 The Business of IT: Crafting a Business Plan
The Business of IT
Crafting a Business Plan
Stephen Ibaraki

This is probably old news to many readers, but you can’t make an IT purchase or investment these days without a good justification for it. Making purchases merely for the sake of possessing the latest computing innovation is a retired theme. Unfettered, unplanned technology was once considered the route to marketplace
domination and growth. This concept ended with the dot-com implosion and resulted in the squeeze on IT. Today, there must be real value returned to the business from IT projects.
With tightening budgets, how can an IT investment be justified? The answer lies in making a business case incorporating a comprehensive, unified technology solution. What would this look like? What are the vital elements to making a business case? How do you employ a business plan model to justify an IT project? What should you look for when integrating the right technology solutions within the business case? I will give you some ideas to consider for making your case.

Building Businesses
A successful business or organization must generate quantifiable value for stakeholders, which includes employees, customers, partners, suppliers, and owners. This value must be clearly defined and measured with continuing adjustments for improvement.
In an increasingly connected world, a business must enable effective collaboration with internal and external networks, thus maximizing relationship interaction in real time. Who wants to wait for a service, an answer to a query, a product delivery? Who wants a delayed project or inaction due to communication breakdown? With the advent of the Internet and the ever increasing speed of globalization, the competition can be next door, or on another continent. Therefore, a business must create differentiation in this competitive environment. How does an organization separate itself from the crowd?
Furthermore, a business must be agile: it must be continually aware of the internal and external environment and be able to quickly select and then implement a business initiative from an array of choices. In doing so, the business takes advantage of its strengths and corrects its weaknesses to harness new opportunities. These opportunities allow growth with new markets, new customers, new products and new services. A business must also assess and mitigate threats including competitive forces. All this is done with an emphasis on productivity and efficiency improvements while managing operational costs and risk.
A technology investment has to foster that agility, resulting in faster time to market, instant response to customer needs, anticipation of competitive threats, higher productivity, improved efficiency, and lower operational costs and risk.
So far, I have discussed the drivers behind business success and how IT must support and align with these drivers. In fact, if this does not occur, IT becomes a cost overhead whose existence can not be justified! Taking a business plan approach will give you the business case for ensuring business success. This translates into IT success.

Creating a Business Plan
It is vital to link IT investment with increased business value—differentiation, lower costs, market focus, collaboration, and innovation. A business plan approach meets this need.
The basic elements of an IT business plan are outlined in Figure 1. What is the objective of your plan? The mission and vision statements describe what the business does today and what it wants to become in the future. Make sure you clearly explain how your IT project supports this overall goal. You’ll need to spell out the links between the IT investment and the business objectives, specifically how the IT objectives support the strategic direction of the business—there must be alignment.
Figure 1 Business plan elements (Close Figure 1)

Element | Description
Purpose | Outlines links between the investment and business objectives.
Vision | The business outcome and how IT will support this goal.
Mission | The current business and how IT enhances this business mission.
Business opportunity | The market to be captured and value to the business.
Business model | The products or services IT offers to capture the business opportunity.
Target markets | The customers (or potential customers) to be served.
Integration with IT | Alignment of products and services with technology resources.
Competitive analysis | The list of competitors, along with strengths and weaknesses.
SWOT analysis | Strengths, Weaknesses, Opportunities, Threats.
Resource analysis | The existing infrastructure and the projected resources required.
Metrics for IT success | The aspects of the plan that can be measured.
Financial projections | The time frame for return on investment.
Your statement of the business opportunity should explain how IT enables or supports the new business opportunity and what value it will return. What is the specific business model? What products and services does the business offer in return for revenue? How big is the potential market and what amount can be captured as a result of improvements in IT? How does IT grow this business model? You should explain how IT investment can improve workflow and business process within the stated business model—improve operations, lower costs, increase efficiency, enable collaboration, power communications, scheduling, and messaging. All of these can drive lower costs or higher productivity. Don’t forget to call out innovation in the operation of the business that can be achieved through IT.
Furthermore, you should talk about your target markets. Consider how your IT plans enable the business to increase penetration into existing target markets or new markets. Discuss what delivery systems are being used for products and services, and how IT support can provide better service and delivery to those markets.
This should lead directly into an examination of how your business’s products or services are integrated with IT technology What specific products and services are keyed on the integrated and unified technology platform? How does IT support the products or services? How does this tie into the business objectives? This is your launchpad for suggesting how IT can improve service management, project delivery, and internal and external relationships. IT enables business change—improving service level expectations, providing effective oversight, prioritization, regulatory compliance, privacy, and security. All of these points should be addressed by your business plan.
Your competitive analysis covers the landscape in which your business is competing. Who are you competing against? What are their strengths and weaknesses? Point out how your competitors are employing technology and how they have improved their market position. Does IT provide your business with a competitive edge over its rivals? Explain how IT improves your business agility, enables growth, speeds entry into new markets, supports new customers, enhances service to existing customers, and so on. How does technology provide differentiation and advantages for your business? How does IT increase the barriers to entry for competitors?
A SWOT analysis takes a formalized look at the strengths, weaknesses, opportunities, and threats related to your business. What are the external opportunities and threats to the business? How does IT improve the internal strengths of the business to take advantage of new external opportunities? How will IT overcome internal weaknesses and position the company to engage new opportunities as a result of these efforts? How are external threats reduced or mitigated through IT investments?
Make sure to consider the resource requirements for an IT investment before, during, and after implementation. This includes people, hardware, and infrastructure. What existing knowledge or infrastructure can you take advantage of, and what will you need to budget for? How long will it take to recover the costs of new training or equipment? If there are advantages of new investments beyond your specific business plan, be sure these are noted as well.
To know whether your business plan meets your expectations, you should spell out in advance the metrics for success. What aspects of your plan can be measured? How often will you measure for success and what will you do if you are not supporting the objectives effectively? What are the backup plans if unexpected disruptive forces are encountered?
No business plan is complete without financial projections. What is the total cost of ownership and how will that cost be justified in new business opportunities? And what is the value of these opportunities? Where and in what ways will the return on investment be realized in achieving business success? What are the time frames for return on investment? How does IT improve the financial goals of the business through revenue and profitability growth and lower costs?

Moving Forward
There are no guarantees that your plans will actually work. But making the effort to think about and develop a business plan puts you in the driver’s seat. You will have thought through all of the potential issues and either revised your plan or outlined contingencies. You will also have a clear idea of the costs and benefits involved, including the costs of not proceeding. Finally, there’s no way to know whether you’ve succeeded or failed miserably without some sort of yardstick to measure against. Those metrics will come in handy for showing the boss how important your plan was for the business come bonus time.
For an ongoing dialogue about the business of IT, I recommend the IT Managers Connection at blogs.technet.com/cdnitmanagers. There are also a number of business plan related resources available from the Microsoft Web site. The Small Business Center provides a tutorial on writing a business plan at microsoft.com/smallbusiness/resources/startups/business_plans_ entities/how_to_write_a_business_plan.mspx, and Office Online (office .microsoft.com/en-us/templates) has a number of business plan templates in addition to those provided with the 2007 Microsoft Office system.

Stephen Ibaraki is an award-winning Professor of Business and Technology and a 35+ year veteran of business and IT. He currently serves as Vice-Chair for the international Network Professional Association (NPA).Contact Stephen at www.StephenIbaraki.com.


 The Cable Guy: EAPHost in Windows
The Cable Guy
EAPHost in Windows
Joseph Davies
Prerelease information in this column about Windows Server “Longhorn” is subject to change.

When an access client connects to a protected network, it must use a negotiated authentication method to verify itself to an authentication server. For example, the access client and authentication server may agree to use a specific password authentication protocol, such as Microsoft Challenge Handshake Authentication
Protocol version 2 (MS-CHAP v2). However, when an access client and authentication server use built-in and hardcoded authentication methods, it is difficult to add new protocols.
The Extensible Authentication Protocol (EAP) is an architectural framework that provides extensibility for authentication methods for commonly used protected network access technologies, such as IEEE 802.1X-based wireless networks and Point-to-Point Protocol (PPP) connections such as dial-up and VPN. EAP is not an authentication method like MS-CHAP v2, but rather a framework on the access client and authentication server that allows networking vendors to develop and easily install new authentication methods known as EAP methods. For more background information on EAP, see the Microsoft EAP Web page at microsoft.com/eap.
Although EAP has been supported in Microsoft® Windows® since Windows 2000, the architecture of EAP in Windows XP and Windows Server® 2003 has extensibility limitations for EAP methods and supplicants, which are software components that can use EAP over a specific type of link layer. The EAPHost architecture in Windows Vista™ and in the next version of Windows Server, code-named "Longhorn," addresses these limitations, making it much easier for third-party network vendors to extend Windows for new supplicants and for EAP methods.

EAP Support in Windows Server 2003 and Windows XP
Windows Server 2003 and Windows XP use EAP for wireless or wired connections that authenticate with 802.1X and for PPP-based connections such as dial-up or VPN-based remote access or site-to-site connections. Specifically, these operating systems contain an implementation of EAP that adheres to RFC 2284, and include IEEE 802.1X and PPP supplicants. Figure 1 shows the EAP and supplicant architecture for Windows XP and Windows Server 2003. It should be noted, however, that the EAP implementation in Windows XP Service Pack 2 (SP2) and Windows Server 2003 SP1 does not support RFC 3748 (the current Internet standard for EAP) and other EAP RFCs.
Figure 1 EAP and supplicant architecture for Windows XP and Windows Server 2003
Figure 1 EAP and supplicant architecture for Windows XP and Windows Server 2003
An EAP API provides the means for extending authentication in Windows XP and Windows Server 2003. Although third-party vendors can develop and install new EAP methods, the built-in PPP and 802.1X supplicants cannot use all the installed EAP methods. For example, a vendor might create a new fingerprint scanning EAP authentication method, but that method might not be available for wireless connections.
Because of the limitations of the built-in supplicants, some third-party software and hardware vendors develop their own supplicants, which typically replace and disable built-in supplicants and the entire EAP architecture. This alternative presents a few issues, however. First, replacing the built-in supplicants and EAP architecture incurs developmental costs and causes delays. In addition, if an enterprise customer does not develop its own supplicants, it can incur per-seat costs to license and install a third-party product.

Features of EAPHost
EAPHost provides the following new features:
Support for additional EAP methods. EAPHost will support the installation and use of all the EAP methods listed on the EAP Registry at www.iana.org/assignments/eap-numbers, and other popular authentication methods such as Lightweight EAP (LEAP), developed and provided by Cisco Systems, Inc.
Network discovery. EAPHost supports network discovery as defined in RFC 4284.
RFC 3748 compliance. EAPHost conforms to the EAP State Machine and addresses a number of security vulnerabilities that have been specified in RFC 3748. Previously, supplicants had to implement their own state machines. Additionally, EAPHost supports capabilities such as Expanded EAP Types (including vendor-specific EAP methods).
EAP method coexistence. EAPHost allows multiple implementations of the same EAP method to coexist simultaneously. For example, you can install and select the Microsoft version of Protected EAP (PEAP) and the Cisco Systems, Inc. version of PEAP.
Modular supplicant architecture. EAPHost supports a modular supplicant architecture in which new supplicants can be easily added without having to replace the entire EAP implementation as you did in the previous version.
For EAP method vendors, EAPHost supports EAP methods already developed for Windows XP and Windows Server 2003 and an easier method of developing new EAP methods for Windows Vista and Windows Server "Longhorn." EAPHost also allows better classification of EAP types so that the built-in IEEE 802.1X supplicant can use them.
For supplicant vendors, EAPHost provides support for additional supplicants for new link layers. Because EAPHost is integrated with Network Access Protection (NAP), new supplicants do not have to be NAP-aware. In order to participate in NAP, new supplicants just need to register a connection identifier and a callback function that informs the supplicant to reauthenticate. For more information about NAP, see John Morello’s Security Watch column in this issue of TechNet Magazine, as well as the NAP Web page at microsoft.com/nap. For information about how to develop EAP methods or supplicants for EAPHost, see Extensible Authentication Protocol Host at msdn2.microsoft.com/aa364249.aspx.

EAPHost and EAP Infrastructure Architecture
EAPHost architecture consists of the EAP infrastructure architecture for EAPHost, the EAPHost architecture on the EAP peer (the authenticating client), and the EAPHost architecture on the authentication server. Figure 2 shows the components of the EAP infrastructure architecture for EAPHost on computers running Windows Vista or Windows Server "Longhorn." On these operating systems, the EAP peer has a layer of supplicants (such as the built-in supplicant for 802.1X), the new EAPHost architecture for EAP peers (facilitating communication and management of supplicants and EAP methods), and a layer of EAP methods to perform authentication.
Figure 2 EAP infrastructure architecture for EAPHost
Figure 2 EAP infrastructure architecture for EAPHost
The authentication server for Windows Server "Longhorn" has the Network Policy Server (NPS), the new EAPHost architecture for authentication servers, and a layer of EAP methods. Previously known as the Internet Authentication Service (IAS) in Windows Server 2003, NPS is a Remote Authentication Dial-In User Service (RADIUS) server and proxy and a policy server for NAP.
The supplicant on the EAP peer uses a link-layer technology such as PPP or 802.1X to send and receive EAP messages on the link between the EAP peer and the pass-through authenticator (a network access server such as a wireless access point or a remote access server). The pass-through authenticator and NPS on the authentication server use RADIUS to send and receive EAP messages on the IP-based network between the pass-through authenticator and the NPS.
After the EAP peer and the authentication server negotiate the use of a specific EAP method, the logical communication consists of EAP messages sent between the negotiated EAP method on the EAP peer and the authentication server.
Figure 3 shows the EAPHost architecture on the EAP peer running Windows Vista or Windows Server "Longhorn." This architecture consists of supplicants, EAPHost components, EAP method management components, and NAP components.
Figure 3 EAPHost architecture on the EAP peer
Figure 3 EAPHost architecture on the EAP peer
Windows Vista and Windows Server "Longhorn" include an 802.1X supplicant for 802.1X-based wireless and wired connections. A PPP supplicant for dial-up or VPN-based remote access or site-to-site connections is being investigated for a future update to these two operating systems. Additional supplicants developed by third parties can also be added. The EAPHost API allows the supplicants to use EAP for connections. For more information, see the article at msdn2.microsoft.com/aa364249.aspx.
EAPHost components include the EAP Client State Machine/Protocol Validator, which maintains the EAP peer state machine (see RFC 3748) and validates EAP messages. Also included is the EAP Method Manager, which manages the various EAP methods whether they are EAPHost-compatible or not, and helps to make EAP methods available to applications and services. And finally there’s the EAP Library Manager, which facilitates with the loading and unloading of EAP method libraries.
EAP method components include:
Built-in EAP methods. They include PEAP, EAP-Transport Layer Security (TLS), and EAP-MS-CHAP-V2.
Two host APIs. These host non-EAPHost-compatible EAP methods (Legacy EAP API) and third-party EAPHost-compatible EAP methods (EAPHost Method API).
Legacy Translator Method. This translates between the non-EAPHost-compatible EAP methods written to the Legacy EAP API and the EAPHost Method API.
EAP Method Proxy Manager . This hosts third-party EAP methods, whether or not they are compatible with the EAPHost.
The EAP Method API is the new API for EAPHost-compatible EAP methods. EAP methods export the APIs defined in EAP Method API. EAPHost loads the EAP methods and calls into the exported API functions.
The NAP components include the following items:
EAP NAP EC Messenger . This component facilitates communication of NAP-related data, such as statements of health and events, between the EAPHost NAP Enforcement Client (EC) and other components of EAPHost.
EAPHost NAP EC . This interacts with other NAP components to provide health validation and enforcement of limited access when an 802.1X-authenticated connection does not comply with NAP system health requirements.
NAP Agent. This maintains the current health state of the client and facilitates communication between the installed NAP ECs and the layer of System Heath Agents (SHAs). Each SHA is defined for one or more system health requirements.
As Figure 3 shows, third-party vendors can develop new supplicants and new EAPHost-compatible EAP methods. You can also use existing EAP methods developed for Windows Server 2003 or Windows XP.
Figure 4 shows the EAPHost architecture on the authentication server running Windows Server "Longhorn" and NPS. This architecture is the same as that for the EAP peer for supporting EAP methods. Instead of supplicants, the authentication server has NPS, which uses the EAPHost API to use and configure EAP methods. Within the EAP components, the EAP Server State Machine/Protocol Validator does the job of maintaining the EAP authentication server state machine and validating incoming EAP messages.
Figure 4 EAPHost architecture on the authentication server
Figure 4 EAPHost architecture on the authentication server
EAPHost on the authentication server allows third-party software vendors to develop and install new EAPHost-compatible EAP methods and supports EAP methods that have already been developed for Windows XP and Windows Server 2003.
For both the EAP peer and the authentication server, EAPHost also provides an EAPHost UI Proxy API (not shown in Figures 3 and 4), which EAPHost-compatible methods can use to display dialog boxes that require user interaction. The EAPHost UI Proxy API allows third-party vendors to add their own dialog boxes for a more seamless user experience.

Conclusion
EAPHost in Windows Server "Longhorn" and Windows Vista updates the EAP implementation in Windows for the latest Internet standards and provides a new modular architecture to extend Windows with EAP authentication methods and supplicants. Networking vendors can extend the existing user experience in Windows without replacing the entire Windows EAP implementation by developing new supplicants written to the EAPHost API and new authentication methods written to the EAPHost Method API. EAPHost also supports existing EAP methods developed for Windows Server 2003 and Windows XP.
EAPHost for Windows XP
Microsoft is scheduled to release an update for Windows XP SP2 that includes the EAPHost architecture, support for RFC 3748, and an EAPHost-based supplicant for wired 802.1X connectivity. With the update, EAPHost supplicants that are developed for Windows Vista will also work on Windows XP SP2. For the latest information about this update, see the NAP product team blog at blogs.technet.com/nap.

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 TechNet Cable Guy column.


 Windows PowerShell: The WMI Connection
Windows Powershell
The WMI Connection
Don Jones

One of the technologies I relied heavily upon in the world of VBScript was Windows Management Instrumentation, or WMI. Interestingly, Windows PowerShell has strong connections to WMI—and not just in a technical sense. Jeffrey Snover, who architected Windows PowerShell, was also a key player in the creation of
Wmic.exe, a Windows Server® 2003-era command-line tool used to work with WMI. In many ways, Wmic.exe foreshadowed Windows PowerShell™ in that it worked in a somewhat similar fashion. (For more information on WMIC, see John Kelbley’s article from the September 2006 issue of TechNet Magazine, available online at microsoft.com/technet/technetmag/issues/2006/09/WMIData.)
Windows PowerShell has support for WMI that’s delivered in the same consistent, object-based way as you get with the rest of the shell’s capabilities. This makes WMI infinitely easier to learn and use—especially in ad hoc situations—than earlier technologies, like VBScript.

A WMI Primer
If you read scripting books and articles, it’s nearly impossible not to see WMI mentioned. However, it’s easy to get so mired in actually using WMI that you forget how it is built under the hood—and how it’s built is especially important to how it works in Windows PowerShell.
WMI is primarily a system of organized classes that represent management information from the Windows® operating system and other Windows-based hardware and software products. A class is really nothing more than an abstract description of the properties and capabilities some given software or hardware component possesses. For example, a logical disk class might describe a device that has a serial number, a fixed storage capacity, an amount of available capacity, and so forth. Meanwhile, a class that describes a Windows service might specify that the service has a name, that it can start and stop, its current status, and so on.
In WMI, classes represent all the things that WMI can manage. If WMI doesn’t have a class for something, it can’t manage that component. Microsoft documents the core Windows WMI classes at msdn2.microsoft.com/aa394554.aspx; other products—such as Internet Information Services, SQL Server™—document their WMI classes separately.
Because there are so many classes, WMI organizes them into a hierarchy of namespaces. For example, the namespace containing the core Windows OS classes is called root\cimv2, while Microsoft IIS 6.0 stores its classes in root\MicrosoftIISv2. Conveniently, the root\cimv2 namespace is the WMI default namespace, a setting shared by Windows PowerShell, making it easy to work with those core classes.
An "instance" is an actual, real-world occurrence of a class. If, for example, your computer has two logical disks, you’ll have two instances of the Win32_LogicalDisk class. If you have 50 services running on your computer, WMI will see 50 instances of the Win32_Service class. Working with WMI is essentially a matter of asking WMI to give you one or more instances, and then either examining the properties of those instances to find the management information you need or executing the methods of those instances to make management changes, such as starting or stopping a service.
WMI uses a client-server architecture. Every version of Windows since Windows 2000 has come with WMI built in (later versions have expanded the number of available classes), meaning you have both the WMI client and the WMI server software readily available. When you use WMI, you’re actually sending a request to the WMI Service running on whichever computer you’re interested in. That WMI Service retrieves the WMI instances you specify and returns them to you so you can work with them. That’s where Windows PowerShell enters the picture—it simplifies the process of asking for instances, getting them back, and working with them.

Getting a WMI Object
WMI class instances are loosely referred to as objects, so it makes sense that the way to retrieve those instances in Windows PowerShell is the Get-WMIObject cmdlet. This cmdlet has a convenient alias, gwmi, which I’ll use for most of my examples. In its simplest form, you simply specify the WMI class name you want to retrieve and then sit back and look at the results (see Figure 1). When I ran gwmi win32_service, Windows PowerShell connected to the WMI service on my local computer (since I hadn’t specified another computer) and connected to the root\cimv2 namespace (since I hadn’t specified a different namespace). Windows PowerShell retrieved all instances of the specified class and, since I hadn’t told it to do anything else with these instances, converted them into a textual representation. In other words, Windows PowerShell took those objects and produced some text that I, as a human, could read.
Figure 1 When running gwmi win32_service, Windows PowerShell returns all instances of the specified class in a readable text format
Figure 1 When running gwmi win32_service, Windows PowerShell returns all instances of the specified class in a readable text format
Specifically, Windows PowerShell converts WMI objects into text by reading and displaying the names and values of selected class properties. For the Win32_Service class, it selects a set of six properties.
Actually, Windows PowerShell converts any object to text in this way. The properties it chooses to display are, for the most part, defined in a set of .format.ps1xml files located in the Windows PowerShell installation folder. These format definition files are digitally signed by Microsoft. It is recommended that you do not change these files, although you can provide your own formatting files. (This is a topic I will discuss in greater detail in a future column.)
The gwmi cmdlet can help you explore your computer to find out what classes are available. Running gwmi –namespace "root\cimv2" –list, for example, gets you a complete list of classes in that namespace. Remember, though, that the classes on your computer are only relevant if you’re managing your computer; if you’re managing a remote computer, you’ll want to find out about the classes available on that system. For this, you’ll want to use gwmi’s –computer parameter to connect to a remote computer. For example, gwmi –namespace "root\cimv2" –list –computer ServerA will list all the classes in the root\cimv2 namespace on the remote computer called ServerA.

Remote WMI
In version 1.0 of Windows PowerShell, gwmi is about the only cmdlet that directly supports remote management. This is due primarily to the fact that remote control is built into the underlying WMI architecture. And, because Windows PowerShell is simply utilizing that existing architecture, it’s subject to that architecture’s security features. Here’s an example:
C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>
In this instance, I tried to connect to a remote computer—called MediaServer—that I don’t have permission to access. As an administrator, I should have permission to work with this computer’s WMI service, but it’s likely that my local workstation credentials aren’t sufficient. I might, for example, be logged on in a different, untrusted domain, or I could be logged on with a less-privileged account. Fortunately, gwmi supports a –credential parameter that allows me to specify an alternate set of user credentials for my WMI connection. Below, you’ll see a very simple example:
gwmi win32_service –credential mydomain\administrator –computer mediaserver
My credential—more specifically, my username—is provided in the DOMAIN\Username format.
Note that there’s nowhere you can enter a password—Windows PowerShell will prompt me for that. Windows PowerShell deliberately doesn’t provide a way to enter a password on the command line because doing so would enable you to hardcode passwords into script files, which is an absolute security risk. However, there is another way you can work with this –credential parameter, and that’s by creating a sort of credential object, called a PSCredential, ahead of time. The key is the Get-Credential cmdlet:
$cred = get-credential mydomain\administrator
When I run this, I’m still prompted for the matching password. This time, however, the credential object that is created is stored in the $cred variable. If I look at the contents of $cred, I’ll see the name but not the password:
PS C:\> $cred

UserName
--------
mydomain\adminstrator
I can then reuse that credential object as much as I want:
gwmi win32_service –credential $cred –computer mediaserver
This simplifies repeated WMI connections to a remote computer by predefining a reusable credential object. It is worth noting, however, that the Get-WMIObject cmdlet does not currently support specifying authentication levels (otherwise known as impersonation) in the same way VBScript supports it. See msdn2.microsoft.com/aa389290.aspx for more information.

Self-Discovery
One of my favorite things about Windows PowerShell is that it doesn’t dumb things down. I showed you how Windows PowerShell selected only a set of properties for the Win32_Service class I queried. The shell still has access to all of the properties, though, and can even tell you what they are. To do this, simply pipe the object (or objects) to the Get-Member cmdlet (or its alias, gm), as shown in Figure 2.
Figure 2 Piping an object to the Get-Member cmdlet tells you what methods and properties you can access
Figure 2 Piping an object to the Get-Member cmdlet tells you what methods and properties you can access
In addition to properties, the shell also lists available methods, meaning I don’t necessarily need the documentation to find out what a class can do. I can see that the class itself provides the means to change an instance’s configuration, pause a service, stop a service, and so forth.
To utilize these methods, or display other properties, it’s often easiest to put the instances into a variable:
$server = gwmi win32_operatingsystem
$server.reboot()
This sample will retrieve the only available instance of the Win32_OperatingSystem class (that class has only one instance per computer) and save it into the $server variable. It will then use the $server variable to access the instance’s Reboot method, restarting the computer. Be careful with that one!

Rich Query Language
If you’ve used WMI under VBScript or another technology, you’re probably accustomed to retrieving WMI class instances using a query written in WQL, the WMI Query Language. Its SQL-like syntax makes it easier to retrieve specific instances—such as a specific service—rather than all instances of a given class. Fortunately, gwmi also lets you specify a query, like so:
gwmi –query “select * from win32_service where name=’alerter’”
This syntax of gwmi (which was added just before Windows PowerShell was officially released) is incredibly useful and makes it very, very easy to migrate complex WMI queries that you may have developed for other purposes. And, as always, Windows PowerShell will return rich objects with their own properties and methods, offering you complete access to the management power of WMI.

Moving Forward with WMI
WMI continues to be developed for future versions of Windows, adding new classes and capabilities. And it continues to be added to new Microsoft products. While most Microsoft products haven’t yet released versions built specifically on Windows PowerShell, its ability to connect to WMI is one of the biggest benefits that make Windows PowerShell useful today.
I’ve only just scratched the surface of what WMI can do. Still, I hope I’ve inspired you to explore Windows PowerShell and discover for yourself what capabilities are available.

Don Jones is the Director of Projects and Services for SAPIEN Technologies, and coauthor of Windows PowerShell: TFM (SAPIEN Press). Contact Don through his Web site at www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Flowers Blooming. Dialogs Popping. Spring Is Here.
Hey, Scripting Guy!
Flowers Blooming. Dialogs Popping. Spring Is Here.
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2007_05.exe (151KB)

Ah, spring is here. And are we ever glad. After a winter of record rainfall, ice storms, snow storms, and wind storms—one of which sent a large tree crashing into one of the Scripting Guys’ backyards, missing the house by inches and sending the Scripting Dog into hiding behind the couch—spring is finally here, and we’re enjoying a little cool rain before some warmer Pacific Northwest rain sets in for the summer.
While we watch the drizzle outside, we thought this would be a good time to get a little adventurous with our scripting and look at HTML Applications (HTAs). And when we say adventurous, we mean it. We’re not going to do any kind of introduction here; we’re going to assume you already know what an HTA is and how to create one. If you don’t, you should check out the HTA Developers Center on the Script Center. In particular, you’ll want to read the two articles in the HTAs for Beginners section. Once you’ve done that, you’ll be all caught up and ready to come back here.
In this column, we’re going to show you how to create dialog boxes. Not only that, but we’ll show you how to pass information back and forth between the main HTA and the dialog box. Yes, the fresh air of spring really has made us ambitious, hasn’t it? Enjoy it while it lasts.
As you might know, there are two kinds of dialog boxes: modal and modeless. The difference is that when you open a modal dialog box, you can’t return to the main window from which the dialog box was opened until you close the dialog box. When you open a modeless dialog box, you can move back and forth between the windows. However, if you close the main window, your modeless dialog box will also close.
Creating a modal dialog box works exactly the same way as creating a modeless dialog box. The only difference is that to create a modal dialog box you call the ShowModalDialog function, and to create a modeless dialog box you call the ShowModelessDialog function. Both functions accept the same parameters. Let’s start by looking at a simple HTA that opens a modal dialog box (see Figure 1).
Figure 1 Simple starter dialog (Close Figure 1)
<html>
<head>
<title>Modal Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”MainModal”>
</head>

<script language=”VBScript”>
Sub ShowDialog
 intReturn = _
    ShowModalDialog(“modaldialog.hta”)
 textbox.Value = intReturn
End Sub
</script>

<body>
<button onclick=”ShowDialog”>
 Show Dialog Box</button> <p>
<input type=”text” name=”textbox”>
</body>
</html>
Here we’ve created an HTA titled Modal Example. In the <body> area of our HTA, we’ve added two elements: a button labeled Show Dialog Box and a textbox named textbox, both of which you can see in Figure 2. When you click the button, the ShowDialog subroutine runs.
Figure 2 Actual HTA modal dialog
Figure 2 Actual HTA modal dialog
The ShowDialog subroutine is pretty simple. We call the ShowModalDialog function, passing as a parameter the name of the HTA file we want to display as the modal dialog box, in this case modaldialog.hta. (We’re assuming modaldialog.hta is in the same folder as this HTA. If it’s not, you’ll need to include the full file path here.)
We also capture a return value (intReturn) from ShowModalDialog. We display this value in the textbox. You’ll see in a moment how we get this return value. One important thing to note is that the call to ShowModalDialog will not return until the modal dialog box is closed. That means the return value won’t be assigned to the textbox until after the dialog box is closed.
Now let’s take a look at modaldialog.hta, the dialog box that our calling HTA opens (see Figure 3). In this HTA, we’ve created two elements: a listbox named listbox and a button labeled OK, as shown in Figure 4. We’ve added four items to the listbox labeled Option 1, Option 2, and the like, and assigned corresponding values, 1 through 4, to each of those items. When the OK button is clicked, the CloseWindow subroutine runs.
Figure 3 modaldialog.hta (Close Figure 3)
<html>
<head>
<title>Modal Dialog Box</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModalDialog”>
</head>

<script language=”VBScript”>
Sub CloseWindow
  window.returnValue = listbox.Value
  window.Close
End Sub
</script>

<body>
<select size=”3” name=”listbox”>
 <option value=”1”>Option 1</option>
 <option value=”2”>Option 2</option>
 <option value=”3”>Option 3</option>
 <option value=”4”>Option 4</option>
</select>
<p>
<input type=”button” id=”idBtn” value=”OK” onclick=”CloseWindow”>
</body>
</html>
Figure 4 HTA that represents the modal dialog box
Figure 4 HTA that represents the modal dialog box
The CloseWindow subroutine is pretty simple. The first thing we do is read the value of the item in the listbox that has been selected and assign that value to the window.returnValue property. For example, if the user chose Option 2, the value 2 would be assigned to window.returnValue. We then call the window.Close method to close the dialog box.
At this point, control returns to the main HTA. Remember our call to ShowModalDialog:
intReturn = _
  ShowModalDialog(“modaldialog.hta”)
The return value assigned to intReturn is the value we assigned to window.returnValue in our dialog box HTA. So if we choose Option 2 in the dialog box, which assigns the value 2 to window.returnValue, intReturn will be equal to 2, and the following line of code displays that value to the textbox:
textbox.Value = intReturn
Now that we’ve seen how to get a value from a dialog box, let’s see how we’d get a value to a dialog box. This time we’ll use a modeless dialog box (see Figure 5), but remember, modal and modeless work the same, so this same process will work with a modal dialog box.
Figure 5 Going modeless (Close Figure 5)
<html>
<head>
<title>Modeless Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModelessMain”>
</head>

<script language=”VBScript”>
Sub ShowDialog
  intReturn = _
    window.ShowModelessDialog _
    (“modelessdialog.hta”, _
    lstServers.Value, _
    “dialogHeight:400px;dialogWidth:300px”)
End Sub
</script>

<body>
<select size=”1” name=”lstServers”>
 <option value=”server1”>Server1</option>
 <option value=”server2”>Server2</option>
 <option value=”server3”>Server3</option>
 <option value=”server4”>Server4</option>
</select>
<p>
<input type=”button” value=”Retrieve Processes” onclick=”ShowDialog”>
</body>
</html>
Figure 7 Data passed to modeless dialog
Figure 7 Data passed to modeless dialog
This time we’ve created a dropdown listbox named lstServers (you can tell it’s a dropdown because the size is equal to 1). There’s also a button labeled Retrieve Processes. When the button is clicked, the ShowDialog subroutine runs. The ShowDialog subroutine has only one line, the call to the window.ShowModelessDialog function, as shown here:
intReturn = _
  window.ShowModelessDialog _
  (“modelessdialog.hta”, _
  lstServers.Value, _
  “dialogHeight:400px;dialogWidth:300px”)
The first parameter we pass to this function is the name of the HTA we want to run in the dialog box, in this case modelessdialog.hta. The second parameter is the Value property of our listbox. Remember, the Value property contains the value of the selected option in the listbox. So if the user selected Server2 from the listbox, the Value would be server2. This parameter is how we pass information to the dialog box. (If you want to pass multiple values, you could pass them in this parameter as an array or maybe a collection.)
We’ll see in a moment how the dialog box receives the value in this parameter. But first, notice we put in a third parameter:
“dialogHeight:400px;dialogWidth:300px”
This parameter contains a string that specifies the height and width we want for our dialog box. In this case, we’ve specified a height of 400 pixels (400px) and width of 300 pixels. As we saw in our modal example, we can leave this parameter blank and the dialog box will be displayed as the default size for the computer.
Now let’s take a look at modelessdialog.hta (in Figure 6) and see how the dialog box reads in the value that is passed to it.
Figure 6 modelessdialog.hta (Close Figure 6)
<html>
<head>
<title>Modeless Dialog</title>
<HTA:APPLICATION
  APPLICATIONNAME=”Processes”>
</head>

<script language=”VBScript”>
Sub window_onLoad
  strComputer = window.dialogArguments
  Set objWMIService = GetObject(“winmgmts:” _
    & “{impersonationLevel=impersonate}!\\” _
    & strComputer & “\root\cimv2”)
  Set colProcesses = objWMIService.ExecQuery   _
    (“Select * from Win32_Process”)

  strHTML = “<h1>” & strComputer & “</h1><p>”
  For Each objProcess in colProcesses
    strHTML = strHTML & objProcess.Name & _
       “<br>”
  Next

  DataArea.InnerHTML = strHTML
End Sub
</script>

<body>
<span id=”DataArea”></span>
</body>
</html>
In this HTA, the only element that we have specified is a span, which contains the full area of the dialog box. In our script section, we’ve defined a window_onLoad subroutine. This subroutine will run as soon as the HTA is opened (in this case, by the call to ShowModelessDialog). Take a look at the first line in this subroutine:
strComputer = window.dialogArguments
We’re assigning to the variable strComputer the contents of the property window.dialogArguments. And what do you think is in this property? See, you must be waking up with the Spring too. That’s right, it’s the value passed in the second parameter of the call to ShowModelessDialog. If Server2 was selected in the main window, strComputer now contains the value server2.
The rest of the subroutine simply retrieves all the processes from strComputer and displays them in the span area. You can see the results of this operation in Figure 7.
Happily, you now have the whole summer to play with HTA dialog boxes. Unless, of course, you happen to live in the Southern Hemisphere, in which case winter is coming and you might have some difficulty if you wind up with as many power outages during your winter as we had around here during ours.

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: OWA Timeouts, Cmdlet Troubleshooting, and More
Exchange Queue & A
OWA Timeouts, Cmdlet Troubleshooting, and More
KC Lemson and Nino Bilic

Q We recently migrated from Exchange Server 2003 to Exchange Server 2007. We are receiving complaints that Outlook® Web Access (OWA) is timing out for Restricted Users who have selected the "This is a private computer" option when logging into OWA 2007. What is the appropriate Exchange Management Shell command to verify the timeout for private computers?
A Let’s back up a second. First I’ll explain why there’s a separate selection for a private computer versus a public computer (see Figure 1) and I’ll show you how these options behave differently. The intention is to give the user a way to tell Exchange what level of security is necessary—whether you’re logging on to OWA using a public kiosk at an airport, for example, or logging on using your home computer. The Exchange administrator can choose to treat those session types differently. For instance, the administrator can make authenticated sessions time out faster on public machines (in, say, a matter of minutes) than on private machines (up to three days maximum). The administrator can also configure other settings differently depending on the user’s selection. For example, the administrator might set access to SharePoint® document libraries and Windows® file shares to be allowed only for the private logon. Of course, this relies on the user specifying the right option. If admins don’t trust users to make the right decision, they can give each option the same timeout values and other configuration options.
Figure 1 The public and private computer session types allow for different timeout settings and other configuration options
Figure 1 The public and private computer session types allow for different timeout settings and other configuration options
The option in question is one we carried over from Exchange 2003, when forms-based authentication was first introduced to OWA. (Historical note: the first implementation of forms-based authentication was designed in part by a brilliant program manager. I won’t reveal her identity, but I will tell you that she later found fame and fortune writing a bimonthly column for TechNet Magazine.)
The setting is actually stored in the registry, but since Windows PowerShell™ has an interface to update the registry, you can configure this setting using the Exchange Management Shell. The following example sets the timeout to 1440 minutes, or one day, when users choose the private computer option during logon:
set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout
-value 1440 -type dword
Of course, since the setting is in the registry, you can update the key yourself using regedit, should you so choose:
#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>
Either way, you’ll need to restart IIS to ensure that OWA picks up the new setting. You should be able to do this by selecting Start | Run and then running iisreset /noforce.

Q We encourage everyone at work who uses the full MAPI Outlook clients to archive all less-than-urgently needed items into personal folders (.pst) files. However, the archived items are then not available when users log into Outlook Web Access from home. How can we make these .pst files available through the OWA interface?
A I’m sorry to tell you that OWA does not support access to .pst files. OWA was built from the ground up to be an online-only client. We have done a lot of work to make sure we don’t leave any traces of personal data on the local machine—this includes features like the secure logoff mechanism first delivered in Exchange 2003 and the WebReady Document Viewing in Exchange 2007, which ensures that cached copies of attachments aren’t left on the hard drive. So accessing .pst files from OWA does not fit in with our goal of making it a simple-to-deploy, online-only client.
That said, .pst usage in general is an interesting scenario that we’d like to discuss. We met with a customer last fall who had users with mailbox quotas of about 200MB, and nearly every user had at least one, if not more, .pst files. Because this organization had a policy that enabled wiping and replacing user machines with minimal effort, all users were required to store their .pst files on a network share. That network share was, in turn, backed up by a central system.
First, there are known problems when accessing .pst files from network shares. Just as OWA was designed from the beginning to be online-only, .pst files were originally intended to be stored locally. No matter how excellent your network is, it’s subject to latency and other problems that can make remote storage of data (that also needs to be accessed by users at the same time) problematic.
Second, this organization had what we would call a smallish mailbox quota (we, admittedly, live in the lap of luxury with a corporate mailbox of around 2GB) because it didn’t want to have all of that data in Exchange—because it would then be responsible for backing up all that data. Yet, with users storing the data in .pst files on a network share that was backed up, the administrators weren’t really saving themselves any work. In fact, it was probably creating more work due to a variety of factors, such as: no single-instance storage across multiple .pst files; helpdesk costs related to problems with .pst files (such as forgotten passwords and general network flakiness); difficulty cleaning up messages in .pst files after a virus attack; difficulty discovering messages in .pst files when a legal matter arises; overhead of maintaining a different backup system; and so on.
So we urge you to consider all of the costs around your configuration decisions. You might find that the costs add up and another configuration may ultimately make a better choice.

Q I’m having a problem with an Exchange Management Shell command. It’s just not working. What’s wrong?
A We can’t answer that question, but we can tell you that in order to get the best help possible—wherever you may be looking—you should use the built-in cmdlet in Windows PowerShell called start-transcript to log the commands you’re trying and the results you get. This lets you then paste the exact details into an e-mail message, blog post, or question on a forum.
Open up an Exchange Management Shell session and type start-transcript, as in Figure 2. Exchange Management Shell will automatically start logging all future commands into a text file like the one in Figure 3 (don’t worry, the app will tell you the location of the text file). To stop logging, you simply type stop-transcript.
Figure 2 Use the start-transcript cmdlet to log the commands you use and their results
Figure 2 Use the start-transcript cmdlet to log the commands you use and their results
Figure 3 Windows PowerShell saves a transcript of the commands you use and stores it in a .txt file
Figure 3 Windows PowerShell saves a transcript of the commands you use and stores it in a .txt file
Having the full list of commands you used and the results returned is an immense help to anyone troubleshooting your problem. But before sharing the log with anyone you don’t know or trust, make sure you review it for any confidential or sensitive data that may have been returned.

Q I see that the Exchange 2007 setup creates a new Organization Unit (OU) in the root domain. It is called Microsoft Exchange Security Groups and it holds five new Exchange 2007 security groups. Can we move those groups to a different OU? How about to a different domain?
A This question refers to five universal security groups (USGs) that are created in the root domain during the preparation stage of Active Directory. The groups in question are:
  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop
In the days of Exchange 2000 and Exchange 2003, the ability to move the default security groups around (Exchange Domain Servers and Exchange Enterprise Servers) was limited. OK, a better way to say this is that you could move them, but you would break things in the process. (Check out support.microsoft.com/kb/260914 for more details on this problem.) So this was very limited indeed.
In Exchange 2007, things are different. The default five groups can be moved. You can move them to a different OU within the same domain or to a different domain altogether.
In case you ever "lose" those five groups and don’t know where you moved them to—meaning which OU or domain—you can always check the value of the otherWellKnownObjects attribute on the following container:
CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com
As groups get moved around, their location is updated on this attribute, giving you a way to always find out where the groups are. Neat!

Q I found a Global Security group called "Exchange Install Domain Servers" in my domain. What is it for?
A You are definitely keeping tabs on your Active Directory®. Indeed, there will be a group called Exchange Install Domain Servers in every domain that has Exchange 2007 servers installed. This group is created in the Microsoft Exchange System Objects (MESO) OU. If you examine this group, you will see that it is being made a member of the root domain’s Exchange Servers group, which is a Universal Security Group.
To put it succinctly, Exchange Install Domain Servers is a group used to work around possible long Active Directory replication cycles if you are running Exchange 2007 setup in one of your child domains. For example, say you have a root domain called Root, a child domain called Child, and a child domain of Child called Grandchild. (We know, the naming scheme is brilliant! Think you can guess what our passwords are?)
To start setting up Exchange 2007 in this org, you first have to extend the schema and prepare your Root domain. This creates the original five USGs we discussed in the previous answer.
Then, say you need to run setup in the Grandchild domain. In order to be able to start the Exchange 2007 services in the local domain, setup puts a computer account of the Exchange 2007 machine into the Exchange Servers group from the Root domain. But since you are now in the Grandchild domain, the membership of the Exchange Servers group might take a while to replicate.
Exchange Servers is a universal group and its membership replicates throughout the forest. Due to potential replication latency, it is possible that setup in the Grandchild domain could fail to start services, as permissions would not be replicated by the time setup was done. That is why when the first Exchange 2007 server is set up in a domain, it will create the Exchange Install Domain Servers group in the local domain.
The Exchange computer account will be placed as a member in that group as part of the setup. A membership in this group gives services enough permissions to start at the end of setup, even if the membership of the Exchange Servers group has not yet replicated from the Root domain. Note that local domain replication is usually faster than replication between domains.

Q The Exchange 2007 documentation tells me I should be running setup with the /PrepareLegacyExchangePermissions switch, even before I extend my schema for Exchange 2007. Why is that? (And could you have made the name of this switch any longer?)
A We’re glad to hear you are reading the documentation before running Setup. How do you like it?
The /PrepareLegacyExchangePermissions (or /pl for short) is a switch that, in so many words, gives Exchange 2000 and Exchange 2003 Recipient Update Services (RUSes) permissions to write to the Exchange Information and Personal Information property sets. During the Exchange 2007 schema extension process, several attributes (such as Proxy Addresses) are moved from the Active Directory Public Information property set into the Exchange Information property set. By default, Exchange 2000 and Exchange 2003 RUSes don’t have the rights to write to the Exchange Information property set. In real life, this means that if you run your Exchange 2007 schema extension first, you will break your Exchange 2000 and Exchange 2003 RUSes because they will be unable to stamp any new recipients! (If you want to read more about those property sets, please go to our blog at msexchangeteam.com.)
Therefore, it is very important that you run the /pl switch before the schema is extended for Exchange 2007. You should also make sure that this change replicates to all domains that have Exchange 2000 or Exchange 2003 recipients (so RUSes exist for those domains). If new domains are added to the forest at a later time and you need to put Exchange 2000 or Exchange 2003 RUSes into them, you should run /pl switch in those domains too.
On that note, when running a /pl switch for the first time, life will be much simpler if you run the switch with an account that has Enterprise Admin rights. Then, setup from root domain will identify which domains need to have /pl run on them and it will run the /pl switch on all of those domains. If you are not using an Enterprise Admin account, you will have to run a /pl switch using a Domain Admin for each domain individually. Fortunately, the Exchange 2007 documentation lays out all the permissions requirements.
And finally, you asked whether we could have made this switch any longer. Just try to say /PrepareLegacyExchangePermissions three times quickly:
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
We thought of making this /Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname, but then we opted for the shorter and friendlier /PrepareLegacyExchangePermissions.
OK, we just made that up. But you can always use the much shorter /pl. And that one is true—we swear!

KC Lemson is the User Experience Manager for Exchange Server. She spends her free time waiting for e-mail to arrive to tell her where she should invest her kids’ college funds.
Nino Bilic, a Technical Lead for Exchange Server, is busy keeping tabs on how many games of Halo he can get away with during a typical work day.


 Security Watch: Network Access Protection
Security Watch
Network Access Protection
John Morello
Prerelease information in this column about Windows Server “Longhorn” is subject to change.

One of the biggest security threats facing organizations of all sizes today is rogue devices behind the network perimeter. Regardless of how well an organization may have protected itself against external threats from the Internet, its security may be at risk from a well-intentioned employee unwittingly turned into a vector of
malware transmission by a worm or trojan. Nowhere is this more true than in the IT environments of small and medium-sized organizations, where staff members’ personal and business laptops may be one and the same and where network access control technologies are often too expensive and too complex to deploy. However, it’s usually precisely these organizations that pay a high price for downtime, so protecting against these threats is critically important.
Network Access Protection (NAP) technology from Microsoft allows organizations of all sizes to proactively check the health of computers as they join the network and to persistently ensure that they stay healthy throughout the time they’re connected. NAP provides a flexible, policy-based architecture for organizations to protect themselves from non-compliant computers intentionally or inadvertently brought on to their networks by employees, vendors, and visitors. NAP is built around four basic pillars: policy validation, isolation, remediation, and ongoing compliance.

NAP Overview
The first core service provided by NAP is policy validation. Policy validation is the process in which NAP evaluates a system against a set of administrator-defined rules and classifies the system’s state of health.
IT administrators specify a set of policy elements that NAP uses for comparison purposes when computers attempt to connect to the network. Computers that match the policy elements are considered healthy, while those that fail one or more of the checks (as specified by the administrator) are deemed unhealthy. These policies can check for things such as the presence of antivirus and antispyware software, whether a host firewall is active, and whether the computer is missing any security updates. Additionally, because NAP is built to be extensible, independent software vendors can create their own plug-ins for NAP that allow for application-specific checks to take place.
Another core service provided by NAP is network connectivity restriction. Depending on the policies defined by an administrator, NAP can place machines into various states of network connectivity. For example, if a machine is deemed to be unhealthy because it’s missing critical security updates, NAP can place that machine into a quarantine network, where it can be isolated from the rest of the environment until it is returned to a healthy state. Without NAP, the unhealthy client would have unfettered access to the organization’s network. If malware were able to compromise the machine through holes the missing updates would’ve plugged, it would be able to actively attempt to spread its infection to the rest of the network. Figure 1 gives you a general idea of the architecture.
Figure 1 General NAP architecture
Figure 1 General NAP architecture
Simply restricting connectivity, though, is not an efficient way to handle unhealthy machines (after all, your users still have work to do). So NAP also provides remediation services in which unhealthy, quarantined machines can correct their health problems without administrator intervention. In the example above, the restricted network would only allow the unhealthy computer to access specific network resources required to install the missing updates, such as the organization’s Windows Server® Update Services (WSUS) computer. In other words, with NAP in place, the unhealthy machine is only able to access those network resources that allow it to get healthy; it cannot send traffic to the rest of the network until it is cured.
The final pillar of NAP is ongoing compliance, in which these health policies are enforced throughout the time the computer is connected to the network, not just at the initial connect. From our example, consider what would happen after the computer updated itself and became healthy (and thus was granted unrestricted network access). If that computer later fell out of compliance because, for example, the Windows Firewall was disabled, NAP could automatically re-quarantine that machine. NAP also allows administrators to configure auto-remediation, in which the noncompliant state is automatically corrected without additional user intervention, even long after the initial network connection is complete.
NAP can utilize several different techniques for controlling network access. For organizations with managed network switches, 802.1X can be utilized to provide port-based access control at the network hardware layer. NAP also provides the ability to utilize IPsec-based enforcement, where secure networks are created through IPsec associations and are layered over physical networks. With IPsec-based enforcement, NAP controls access to the secure zone by dynamically creating and removing certificates used by the IPsec engine. Finally, NAP can provide DHCP-based enforcement. In this case, the DHCP server provides unhealthy clients with IP leases from restricted pools. These leases use separate DNS suffixes and IP routes to control which resources a restricted client can access.
The NAP server component is built on the next version of Windows Server, code-named "Longhorn," specifically into the new Network Policy Server (NPS), the greatly enhanced successor to Internet Authentication Services. For organizations utilizing 802.1X-based enforcement, the network hardware must support 802.1X authentication and dynamic VLAN capabilities (the NAP Partners site in the "NAP Resources" sidebar provides more detail about specific hardware vendors). For DHCP-based enforcement, a NAP-enabled DHCP service, such as the one available in Windows Server "Longhorn," is required. On the client, NAP support comes built-in to Windows Vista™. NAP support will also be available as an add-on to Windows® XP, along with a new 802.1X supplicant which will enable 802.1X enforcement on Windows XP.
In addition, NAP integrates into the Windows Security Center, as well as third-party health agents, to report health information. Because of this, NAP is able to make policy validation decisions based on any of the data exposed through the Security Center.
NAP is a highly capable enterprise-level policy-management solution, so it’s impossible to cover all the features and deployment strategies in a single article. Thus, this article is focused on deployments for small and medium-sized organizations where IT staff time is already spread thinly and where a NAP deployment can be streamlined to provide a rapid return on the investment required for deployment. Many of the lessons and general guidance, though, are equally applicable to any NAP design in any size organization. Note, however, that my example walkthrough is not designed to be a step-by-step setup guide, but rather a general overview of the major focus areas of a successful DHCP based NAP deployment. See the "NAP Resources" sidebar for a link to a more detailed setup guide.

Contoso’s Problem Set
To take a closer look at how NAP can address the unique needs of small and medium-sized organizations, let’s use Contoso, Inc. as an example. Contoso is a fictitious medium-sized organization with 250 computers in three main offices. It has a highly mobile workforce, with many users telecommuting or connecting back to the main office from remote customer locations. As a result, about half of its total computer population is made up of laptops and Tablet PCs. Like many organizations, Contoso has faced increasing security challenges as its workforce has become more mobile. Some users with mobile computers have picked up malware from customer sites or home offices and have brought infected computers on to the internal Contoso network.
Contoso has also struggled with ensuring that these remote computers are kept up-to-date. Often, users work from customer locations for long periods before returning to a Contoso office. In these situations, the machines they have are often months behind on security updates, which increases the overall risk to the rest of the machines on the Contoso network. Contoso needs a solution that can ensure that all machines connected to its network, whether remotely or locally, are secure and healthy.
How can NAP help Contoso achieve its goals? Recall the main pillars of NAP. Through policy validation, NAP can check the health of all machines connecting to Contoso’s network. Policy validation can determine whether a machine has timely antivirus signatures and whether it is fully patched with all security updates. When the NAP policy validation routines determine a machine is unhealthy, NAP can restrict network connectivity for the unhealthy hosts. This ensures that a machine that was used offsite and has contracted malware is unable to spread the problem to other parts of the network. NAP will restrict the unhealthy computer’s connectivity so it can access only the remediation resources defined by Contoso’s IT administrator. For example, the unhealthy computer would have access to the Contoso WSUS server and the server hosting antivirus signatures. Finally, NAP can ensure that after the machine becomes healthy, it will be kept in a continuously healthy state. In the example I’ve shown you here, if the unhealthy host was used by a telecommuter over VPN and the user turned off the host firewall, NAP would automatically remediate the problem. As soon as the firewall was disabled, the NAP infrastructure would quarantine the computer, re-enable the firewall, re-evaluate the health of the machine, and, after determining that it’s healthy, place the machine back on the unrestricted network. NAP’s four pillars directly address key security needs for Contoso’s dynamic and mobile computing environment.

NAP Design
For many small and medium-sized organizations, DHCP-based enforcement for NAP is the fastest and easiest implementation option. This is because DHCP enforcement requires no additional network changes and no additional services beyond DHCP and NPS. While IPsec and 802.1X enforcement options are more flexible, they also require additional changes in the network and new services to deploy. For lower complexity environments, using DHCP provides the major benefits of NAP at a much lower implementation cost and with less ongoing operational commitment.
In Contoso’s environment, a computer running Windows Server "Longhorn" is used as the core of the NAP deployment. Because NAP requires a Windows Server "Longhorn" NPS, it cannot be deployed on previous releases of Windows Server. DHCP-based enforcement for NAP also requires a Windows Server "Longhorn" DHCP server. To consolidate services, Contoso can deploy both NPS and DHCP on the same server; they coexist without issue. So, the basic NAP server infrastructure for Contoso is quite simple: a single computer with Windows Server "Longhorn" runs both the policy and enforcement components.
On the client-side, Contoso’s computers running Windows Vista already have the necessary capabilities to support NAP. The only client-side change required for the machines running Windows Vista is to enable the NAP functionality, which can be accomplished through Group Policy. For Contoso’s computers running Windows XP, a NAP client package must be installed separately. Computers running Windows XP that are domain-joined have, by default, the Windows Security Center functionality disabled. If the NAP policy uses status information from Security Center to evaluate computer health, the Security Center must be running for NAP to operate properly. So, for Contoso’s computers running Windows XP, the admins have turned the Security Center on through Group Policy. Beyond these changes, nothing else is required on the client side in order to support NAP.

Contoso NAP Deployment
After Contoso has made the required Group Policy changes discussed earlier, installing Windows Server "Longhorn" is the next step in the NAP deployment. All versions of Windows Server "Longhorn" include the required NAP components, so Contoso can use whatever edition best fits its needs. Once the installation is complete, the IT administrator will use the Server Manager tool to add new roles to the machine. For the DHCP-based enforcement that Contoso is using, the required roles are Network Access Services and DHCP Server. The Add Roles Wizard will assist the administrator in handling any dependencies and including any additional features that may be desired on the server. Once the roles are added, Contoso is ready to begin configuring NAP.
Contoso’s administrator will use the Server Manager tool to access the DHCP snap-in for the Microsoft Management Console (MMC) and add a new scope. Configuring the Windows Server "Longhorn" DHCP server will cause all existing DHCP services on the IP segments it services to be replaced. Once the scope has been created and populated with the right options based on Contoso’s network, NAP must be enabled on it. This is done on the Network Access Protection tab of the scope properties (see Figure 2).
Figure 2 Enabling NAP
Figure 2 Enabling NAP
NAP switches machines between either restricted or unrestricted network access within the same scope by using a new NAP user class scope option. This special set of scope options (including DNS servers, default DNS suffix, and so on) is used when leases are provided to unhealthy clients. For example, whereas healthy clients would be provided a default DNS suffix of "contoso.com", unhealthy clients are given a suffix of "restricted.contoso.com" as shown in Figure 3. Once the DHCP scope options are configured, the Network Policy Server can be set up and rules created.
Figure 3 Restricted access
Figure 3 Restricted access
The NPS policy is made up of four major components. System Health Validators (SHV) define what checks are performed to assess the health of a computer. Remediation Servers Groups contain the list of systems that unhealthy machines are allowed to access to become healthy (WSUS, for example). The System Health Validator Template component is used to define the actual health states. For example, Contoso could say a "Compliant" machine is one that passes the Windows Security SHV, but allows the client to fail another SHV check provided by its antivirus vendor. Finally, these components are combined into a set of Network Policies, which contain the logic that determines what happens to machines based on their health state.
System Health Validators are lists of items that the NAP agent checks and reports the status of to the NPS. A default NAP deployment includes the Windows SHV, which plugs into the Windows Security Center and allows NAP to check the status of all security components reported through the Security Center. This includes firewall, antivirus, automatic update, and antispyware components.
Recall that NAP is designed to be extensible and to allow third parties to create their own SHVs to provide more detailed checks of individual components (see microsoft.com/windowsserver2003/partners/nappartners.mspx for more information). For example, the Windows Security SHV allows NAP to check whether or not antivirus is enabled and up-to-date. However, the Windows Security SHV cannot perform more detailed checks about the antivirus application, such as how frequently the machine is scanned or other application-specific options. The antivirus vendor, however, could create its own SHV that plugs into its application more deeply and exposes more application-specific checks than the default Windows SHV. This SHV would work in concert with the Windows SHV and any other SHVs that may exist; a NAP deployment may have many SHVs in use simultaneously (see Figure 4).
Figure 4 Windows Security SHV
Figure 4 Windows Security SHV
Remediation Server Groups are used to specify what resources an unhealthy machine is able to access. These groups often include resources such as WSUS or Systems Management Server (SMS) servers, as well as antivirus update servers. It’s critical to include not only the servers themselves, but also the name resolution servers used by clients to find them. Because Contoso’s clients are configured via Group Policy to use the server called wsus.contoso.com for Automatic Updates, the Remediation Servers Group must include not only the IP address of the WSUS server, but also that of the DNS server that clients use to convert the fully qualified domain name (FQDN) into a numerical IP address. Without allowing access to these name resolution resources (which may be both DNS and WINS, depending on how clients are configured), clients will not be able to resolve the IP addresses of the remediation resources and, thus, will not be able to access them. Figure 5 shows the DNS and IP settings for the sample.
Figure 5 DNS names and IP addresses
Figure 5 DNS names and IP addresses
System Health Validator Templates are used to define what constitutes a healthy computer. Validator Templates take the results of SHV checks and states whether a machine is healthy or unhealthy based on whether they pass or fail one or more of these checks (see Figure 6).
Figure 6 Compliance checks
Figure 6 Compliance checks
In the Contoso environment (as with many small and medium-sized deployments), there are only two states defined. A healthy computer is one that passes all SHV checks. A noncompliant machine is one that fails one or more of these checks. Organizations can choose to implement more complex logic if needed (for example, creating different compliance standards for users based on role, department, geography, and so on), but should be aware that doing so has the potential to make problem identification and troubleshooting more difficult and time-consuming.
All these components are brought together with Network Policies. Network Policies are defined by administrators and instruct the NPS how to treat computers based on their health state. These policies are evaluated from top to bottom (as displayed in the NPS UI) and processing stops once a policy rule is matched.
Again, simplicity is the goal for the Contoso network, so only a few policies are required. First is the Compliant-FullAccess policy. This policy states that machines that pass all SHV checks are granted unrestricted network access. Specifically, when a machine’s health is evaluated, and all checks pass, the NPS will instruct the DHCP server to offer the machine an IP lease with "normal" scope options. This Compliant-FullAccess policy should normally be listed first in the processing order, since most machines should be compliant when checked. Having this policy listed first reduces processing load and time on the NPS.
The next policy used is Noncompliant-Restricted. In the Contoso environment, any machine that fails one or more SHV checks (thereby matching the Noncompliant System Health Validation Template) corresponds to this policy. When this policy is matched, the NPS instructs the DHCP server to offer the client an IP lease with the special NAP "restricted" scope options. This allows the noncompliant computers to access only those resources defined in Contoso’s Remediation Servers Group.
The third policy used is for backwards compatibility. Recall that, by default, NAP support is available for Windows XP and later operating systems (though independent software vendors may develop NAP clients for older Windows versions and non-Windows operating systems). If Contoso has Windows 2000 still in production, it may create a rule (Downlevel-Full-Access in our example) that allows machines that are not NAP-aware to be granted normal access to the network (given default scope options by the DHCP server). This policy should be evaluated last and only needs to be created and enabled when downlevel machines require network access (see Figure 7).
Figure 7 Access settings for downlevel machines
Figure 7 Access settings for downlevel machines
What if Contoso has resources on its network that are not and will never be NAP-capable, such as printers or other hardware? Further, what if Contoso has machines that are NAP-capable but that it wishes to exempt from policy checks, either permanently or on a temporary basis? An easy way to exempt these machines is by MAC address. To provide these machines with a bypass around NAP checks, Contoso administrators can create a new policy (Exempt by MAC) that grants full network access. This policy uses a condition statement where the RADIUS client property of Calling Station ID matches the MAC address of those devices that require a NAP bypass. When a machine matches this policy statement, NPS will instruct DHCP to offer a lease with "normal" scope options. This policy should be listed first in the evaluation order to reduce overall processing time and load on the NPS. Machines matching this policy do not need any SHV evaluation, so there’s no purpose in devoting cycles on the NPS to checking them (see Figure 8).
Figure 8 Ignoring certain machines
Figure 8 Ignoring certain machines
When combined, these policies will help ensure that Contoso’s NPS quickly and accurately evaluates machines connecting to the network. They also provide for exemptions when needed for downlevel computers and devices or for times when a temporary bypass is required for NAP-capable devices.

Conclusion
NAP encompasses a broad set of technologies and, particularly in more complex scenarios, requires thorough planning and testing. While I focused on a less complex scenario, the NAP Web site includes more detailed guidance for deployments of all sizes. The Web site also includes planning assistance for 802.1X and IPsec-based enforcement technologies, which are often a better fit than DHCP-based enforcement for enterprises.
NAP provides a capable and extensible platform for evaluating the health of computers connecting to a network. For small and medium-sized organizations, DHCP-based enforcement can provide many benefits with low implementation and management costs. NAP is a key benefit of Windows Server "Longhorn" and can help your organization improve security and compliance.
NAP Resources
  • Network Access Protection
  • Setting Up Dynamic Host Configuration Protocol Enforcement for Network Access Protection in a Test Lab
  • mNetwork Access Protection Partners
  • “Introduction to Network Access Protection” whitepaper WebCast

John Morello has been with Microsoft for six years in a variety of roles. As a Senior Consultant, he has designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He’s currently a Senior Program Manager in the Windows Server group working on anywhere access technologies.


 The Desktop Files: Revisiting Windows Deployment Services
The Desktop Files
Revisiting Windows Deployment Services
Wes Miller

I've spent several of my recent columns discussing deployment technologies related to Windows Vista and to the next version of Windows Server, code-named "Longhorn." The one constant in software is change, and so I have a bit of an update for you regarding Windows Deployment Services (WDS), which will ship in
Windows Server® "Longhorn." I've also accumulated quite a few questions from readers and from discussions I've participated in over the past few months, and I'll take a portion of this column to answer some of these questions related to ImageX, WDS, and Windows® PE.

New Features and Enhancements
When WDS was originally envisioned, the hope was that the functionality shipped as an add-on to Windows Server 2003 would be nearly identical to the functionality of the version that would ship later in Windows Server "Longhorn." However, the team developing WDS for Windows Server "Longhorn" has been working diligently on three key new features that are expected to be exclusive to WDS on the upcoming server platform.
These new features are multicast deployment, enhanced TFTP download performance, and Extensible Firmware Interface (EFI) network boot support for x64 systems. These features are significant and highly beneficial for WDS users and administrators, so let's take a look at each one to see what's new. An important note, however: these features are not scheduled to be included in any future version of WDS for Windows Server 2003.

Multicast
Long before I began working on the Windows team, multicast was one of the most discussed and requested features for Remote Installation Services (RIS), and even for Windows deployment in general. Customers who had used third-party deployment technologies knew what multicast deployment could do. A few scenario-specific deployment technologies within Microsoft—Automated Deployment Services (ADS) in particular—implemented multicast, but none delivered it for OEM and enterprise deployment, and it remained a frequently requested feature every time I discussed deployment with OEM or enterprise customers.
The key advantage of multicast is allowing multiple computers to receive a communication simultaneously. That is to say, the sender (the WDS server in this case) sends the information to be communicated only once. Each client must then listen to the entire communication from end to end to receive it. Since all clients are specifically listening to one network address simultaneously, the benefit is twofold: enhanced deployment speed since the network is less congested with multiple clients performing the same task; and decreased network saturation since every client is listening to the single stream.
The downside of multicast has historically been, well, the very infrastructure of multicast itself. Imagine the game of "telephone" that many of us played as children. You probably can recall the steps:
  1. You say a phrase to the person next to you.
  2. This second person hears the phrase.
  3. The second person then repeats the phrase to a third person.
  4. The cycle continues through all the people present.
Now, the inherent problem with multicast is that in order for you to tell four people the entire phrase they all have to be in the room and listen simultaneously. If a fifth person walks into the room, unless they know to listen immediately, you will have to repeat the entire phrase to them again.
Multicast works in generally the same way. You send a binary image (usually a sector-based disk image) over the wire. All clients who need to receive it generally must wait in a queue if they aren't ready immediately when the image is first being broadcast. Even more annoying, if clients lose too much data due to network problems or performance, they either need to drop out of the communication queue entirely (since they can't ensure they received the entire disk image), or the entire group has to slow down to suit the needs of the client experiencing problems. In a scenario where you are deploying hundreds of systems simultaneously, ensuring that all clients boot at the same time and that the speed deficiencies of one don't affect the others is a cause of much focus when designing a multicast system.
The WDS team has changed all that by delivering a new multicast engine that takes advantage of the file-based Windows Imaging Format (WIM) infrastructure to allow for some very unique capabilities. You can perform the same staged multicast scenarios possible with most third-party multicast software, but the multicast solution for WDS delivers much more.
First, client computers can join at any time in the transfer. The multicast broadcast is a "round robin" broadcast of file streams that will continue to broadcast until every client computer's needs have been met. Because of this, it doesn't matter when clients come online. They listen to the WDS server, and when the server has completed the image file broadcast, it starts over from the beginning. If a client misses a file, it just listens until the file comes around again (think of horses on a carousel).
Second, the protocol is completely new and features congestion control and flow control—meaning that it works well on production networks without interfering with existing network communication. A common fear of network admins—justified with some multicast solutions—is that by turning them on you flood the network with traffic when, ironically, you were actually trying to make communication more efficient.
Third, the solution was designed to be independent of WDS and Active Directory®. This means you do not need to have either Active Directory or an active WDS implementation in order to take advantage of it. ImageX multicast can be performed independently, lending itself to many more scenarios. The multicast client is a command-line application that can run within Windows Server "Longhorn" (and its associated release of Windows PE), Windows Vista™, Windows XP Service Pack 2 (SP2), or the recently released Windows Server 2003 SP2.
There are new management tasks in the WDS MMC and in the WDSUtil application to set up and configure multicast. There is also a change to the user interface of the WDS client indicating that multicast is being used.
The WDS management tools allow administrators to monitor real-time transmission progress to clients (including removing clients from a transmission). The management tools also offer full logging and reporting, meaning that administrators will now have a method to log installations—something that RIS was sorely lacking.
Multicast in WDS for Windows Server "Longhorn" is one of the more exciting announcements I've heard in a while. It's great to know that the team was able to meet this often-requested customer wish in a way that should work quite well for OEM and enterprise consumers.

Enhanced TFTP Download Performance
Trivial File Transfer Protocol (TFTP) is a key component of the Pre-boot eXecution Environment (PXE), itself the backbone of both RIS and now WDS. TFTP was chosen not because of its network efficiency or its robustness, but largely due to the fact that it is an extremely small protocol (being stateless, non-secure, and UDP-based), lending itself to encapsulation in a boot ROM, necessary for systems to PXE boot from the network.
For Windows Server "Longhorn," the TFTP Daemon (TFTPD) was completely rewritten in such a way that it made possible significant improvements in TFTP download times (a major enhancement now that all WDS deployment is based around a Windows PE boot from RAM image). This is good news for customers who have wished for better performance in downloading Windows PE from RIS or WDS on Windows Server 2003.
As the PC world begins moving away from the ubiquitous BIOS (the backbone of x86 PCs today) to the EFI, Microsoft has prepared WDS to work with newly available x64 server systems that boot using EFI, rather than BIOS. The included functionality will allow x64 client systems to PXE boot from a WDS server.

Questions
With the WDS update in hand, I would like to take the remainder of this column to answer some questions that I have either received in e-mail or seen discussed recently online, and that I think may be of general interest to my readers.

Q Is it possible to use WDS in a non-DHCP environment? My network doesn't allow DHCP or PXE traffic.
A Yes, you can conceivably use WDS in a non-DHCP environment, but the solution doesn't scale since you must create unique CD media for each installation you intend to support—each with its own unique IP address. It's probably more advisable to use DVD media for installation. If you must install via WDS without DHCP, perform the following steps:
  1. Create a WDS Discover image with a statically defined server (this is pointing to the specific WDS server you will be installing from).
  2. Allow DHCP traffic to port 4011 on this destination WDS server. Even though you will not be using DHCP, you must allow this as it is how WDS clients handshake with the server.
  3. Create unique Windows PE media with a static IP address instead of DHCP.
Note that this solution is painful because the client media must be unique to avoid IP address collisions and you must point to a specific WDS server on your network. Since PXE (itself based upon DHCP) is the backbone of WDS, you can see why WDS works much better if DHCP is allowed in your environment.

Q I want to PXE boot Windows PE 2.0 from a PXE server other than WDS. How can I do this?
A The Knowledge Base article at support.microsoft.com/kb/926172 may provide some guidance for getting Windows PE 2.0 working from a non-WDS PXE server, but note that Microsoft support for this is somewhat limited.

Q What is the BDD? Is the Windows Automated Installation Kit (WAIK) a part of it?
A The BDD (actually, the Business Desktop Deployment Solution Accelerator) is a framework for guidance on how to use Windows deployment tools (such as the WAIK) in a manageable and reproducible way. The WAIK is not a part of the BDD directly, but the BDD will pull together all of the necessary tools, including the WAIK, for you to install if they have not already been installed. So while BDD doesn't technically include the WAIK, it does require the WAIK in order to work. Please visit microsoft.com/desktopdeployment for more information on the BDD.

Q Where can I get WDS for my Windows Server 2003 system?
A WDS is available as a part of the WAIK download in the WDS directory (see go.microsoft.com/fwlink/?LinkId=85377).

Q How can I configure Windows PE 2.0 to boot with a static IP address, and support DNS configuration?
A To configure a static IP, use the unattend.xml sample in Figure 1 and put it at the root of your CD, USB flash drive, or other bootable media for it to be picked up. If you want to have DNS support as well, you will also need to run the following command:
Figure 1 Figure 1 unattend.xml (Close Figure 1)
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component
   name="Microsoft-Windows-TCPIP"
   processorArchitecture="x86"
   publicKeyToken="31bf3856ad364e35"
   language="neutral"
   versionScope="nonSxS"
   xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)"
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

Q Is it possible to boot Windows PE from a Fibre Channel controller?
A Yes, provided Fibre Channel HBA supports registering the boot volume via Int13 so that it appears in the BIOS as a bootable volume for Windows PE. You must also add the Fibre Channel controller's driver as you would any other out-of-the-box storage controller driver.

Q Windows PE 2.0 always boots from a RAMDisk. Some of my systems don't have enough RAM to boot that way. Can I boot Windows PE 2.0 without a RAMDisk?
A Yes, you can. Systems with less than 256MB of RAM in particular may require a non-RAMDisk implementation of Windows PE in order to boot. There is a Microsoft support article in the works that will describe how to do this. A couple of important caveats: you will not be able to swap media, as you can with a RAMDisk, and it will boot more slowly than a RAMDisk-based version of Windows PE 2.0.

Q I have tried to boot Windows PE 2004 and Windows PE 2005 (1.5 or 1.6) from media other than DVD, and copy an image (or other data) off of a DVD. I'm not booting from the DVD, just copying data from it, but it isn't working. The DVD is readable under a full installation of Windows, but under Windows PE I receive an error stating that the volume is corrupt or unreadable. Can I fix this?
A Yes, you can. By default, Windows PE 1.x doesn't have support for UDF-formatted media. DVDs are, by definition, formatted with either ISO bridge support (a dual format of ISO and UDF) or just UDF. You need to add the UDF driver to your Windows PE installation for this to work. The driver is already there; it's just not installed. To install it, do the following:
  1. In Notepad, open the txtsetup.sif file in your I386 (or MiniNT, if a hard-disk installation of Windows PE) directory.
  2. Find the section called [CdRomDrivers.Load] and look for the line with the driver named cdfs.sys. Below that line, add the line udfs = udfs.sys. The entry should look similar to this:
[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys
3. Find the section called [CdRomDrivers] and look for the line with cdfs in it. Below that line, add the line udfs = "Universal Disk File System". The entry should look similar to this:
[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"
4. Save and close your txtsetup.sif and recreate your Windows PE image as necessary. You should now be able to read any UDF-formatted DVD media from within Windows PE.

Q I have a number of older systems, on which I am running Windows XP, that do not support ACPI. Would I be able to use Windows PE 2.0 on these systems in order to migrate them to Windows Vista or perhaps to reinstall Windows XP?
A No, you can't. Windows PE 2.0 only supports Advanced Configuration and Power Interface (ACPI)-compliant systems, and will not boot on those systems. If you need to use Windows PE on those systems, use Windows PE 1.6 or earlier.

Q I have written my own application in Visual Studio® 2005 that I would like to run on Windows PE (1.x or 2.0). Will it work?
A That depends on how your application is written. If you are using unmanaged C++, then yes, your application should work. If you are using any of the managed code languages (C# or J#, for example) or writing any managed C++ code, then it won't work. Since the Microsoft® .NET Framework (any version) is not available on Windows PE, managed code will not run.

Q I'm trying to write my own application for use on Windows PE 2.0 and I need some help. Where is the best place to look?
A I suggest that you start with the Windows PE Developer's Guide whitepaper.

Q I have booted Windows PE 2.0 from a CD several times, but the drive letter (the RAMDisk) is always X. How can I actually tell what drive letter it really booted from?
A If you look in the registry, the following key should reflect the actual drive letter that Windows PE initially booted from:
HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
If you find that this key has not been populated because a third-party shell was used within Windows PE, running the following command will update it to the correct value:
start /w wpeinit UpdateBootInfo

Q Is it possible to use ImageX and WIM files to back up my systems?
A It is theoretically possible, but I wouldn't recommend it. ImageX can't back up any locked or open files like a true backup tool can. I recommend continuing the use of a true backup utility that allows you to protect open and locked files.

Q If I capture a WIM file uncompressed, will it deploy any faster than the same volume image compressed?
A Not significantly, no. Capturing takes longer, due to compression. However the application of the image to a target system does not take significantly longer regardless of the compression type used (none, XPress, or LZX). I recommend making your compression choice based upon your actual image size needs and the amount of time you can dedicate to capturing.

Q Do I need to repartition and format the disk if I am planning to apply a WIM image to it?
A Yes, you do. In order to do a clean image of a system, you will first need to clean the volume with the diskpart tool (or delete and recreate the destination partition). Alternatively, you can format the volume completely, before applying.
Furthermore, you must remember that versions of Windows prior to Windows Vista used a different boot sector—so if you're using Windows PE 2.0 to deploy Windows Server 2003 or earlier, you need to run the following command from within Windows PE to set the boot sector to one that Windows Server 2003 and earlier can boot from before beginning Windows setup or applying a WIM of it:
bootsect /nt52 sys C: /force

Conclusion
I hope you have found the WDS update and the answers to these questions useful and of interest. I appreciate all your questions and will do my best to answer them whenever I have space in this column. Please keep them coming by sending mail to the e-mail address listed in my bio.
Windows Vista Harware Assessment
Baldwin Ng

Good news—your manager finally responds to your proposal from a month ago. Apparently, he has been seriously considering your idea of an organization-wide rollout of Windows Vista and has begun to see the benefits and cost savings of managing a single operating system. However, he is not totally convinced that it makes financial sense to replace all of the PCs for the Windows Vista installation. He wants concrete, detailed information on which PCs can migrate to Windows Vista right now and which ones could be migrated given some minor upgrades such as additional system memory and hard-disk space. And he wants an answer by end of the week. So, where do you begin? How do you get the answer in a few days when your organization does not have any sophisticated asset or network management tools? To make things worse, your predecessor did not leave you enough information about the network assets that already exist.
Microsoft has just released Windows Vista Hardware Assessment, a solution accelerator that helps you determine your organization's readiness for Windows Vista (see microsoft.com/technet/wvha). This tool quickly assesses the PCs on a network and generates detailed readiness reports of their hardware and device compatibility in a matter of hours in most midsize organizations, all without installation of any software agents on the PCs across your network.
Building upon the powerful inventory collection and reporting technologies previously developed for the Microsoft Assessment and Deployment Solution (ADS), Windows Vista Hardware Assessment creates a set of readiness reports through a three-step process:

1. Hardware Inventory
Through the use of Windows Management Instrumentation (WMI), Active Directory®, and other Windows networking protocols such as NetServerEnum, this tool discovers computers on a domain as well as workgroup computers. Once inventory is completed, all system resources and device information is stored in a SQL Server™ 2005 Express database. The current release of this tool supports network discovery of up to 5,000 machines. Future releases will likely scale to larger networks.

2. Compatibility Analysis
Using the most up-to-date device and BIOS databases from the Windows team, the tool analyzes each PC's readiness around hardware and device compatibility for Windows Vista. In addition, driver information is pulled through a regularly updated Web service so that you can get the latest information each time you run the tool.

3. Readiness Reporting
The last step is the autogeneration of a set of readiness reports in the form of Microsoft Word documents and Excel® spreadsheets. These reports provide the readiness status together with upgrade recommendations for each PC.
Windows Vista Hardware Assessment complements other Windows Vista solution accelerators including Business Desktop Deployment 2007 and Windows Vista Security Guide. For more information, take a look at Solution Accelerators Home Page.

Baldwin Ng is the Product Manager in the Microsoft Solution Accelerators Team focusing on the creation of automated software tools to help customers and consultants adopt Microsoft software in a quicker and more effective way. He can be reached at Baldwin.Ng@microsoft.com.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, TX. He has worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Reach Wes at technet@getwired.com. Wes thanks Scott Dickens, the Program Manager for Windows Deployment Services at Microsoft, for assisting him with the new WDS features section.


 Field Notes: Staying Sharp
Field Notes
Staying Sharp
Joshua Hoffman
Download the code for this article: Microsoft Virtual Server 2005 R2 (1946KB)
Download the code for this article: Microsoft Virtual PC 2004 SP1 (18637KB)

Ah, the field. I knew it well. Prior to taking on my current role (as technical editor of this fine publication) almost two years ago, I was an active IT pro in the field. I spent five years with Microsoft Consulting Services and several years in the IT departments of various Fortune 100 companies. Then I was lured away to this gig. Not that I’m complaining—we have a great group of people here, plus I get to know and work with all of you readers! And if I never have to take a plane to work at 6:00 on a Monday morning again, that would be OK too.
But there is a downside to my new job. Many IT professionals would argue that the best way to learn something new in our line of work (and stay up-to-date) is by actually doing it. Practical, hands-on application is a powerful educational tool. But careers advance, responsibilities change, and suddenly you find that you’re an IT pro without a system to administer or an infrastructure to manage. And things change very quickly. Since I took on this new role, there’s a new version of Windows® with a new deployment framework, new security infrastructure, new network stack, and a few other features. Oh, and there’s new version of Office, too. And Exchange Server. And SQL Server™. And Microsoft® Operations Manager. Plus, there are a few new tools out there: Windows PowerShell™, MMC 3.0, the Windows Automated Installation Kit. I hope I didn’t leave anything out.
It turns out that in two years, a lot can change. So if the best way to learn is to do, and your job no longer includes the "doing" part, how can you possibly keep up?
Well, I certainly hope this magazine helps. I know it helps me. We have a lot of great authors who really know their stuff, and I am constantly benefiting from their expertise. But just the same, sometimes you really do need to get hands-on. I usually start with Virtual PC (or Virtual Server), both of which are free downloads from the Microsoft Web site (you’ll find links in the downloads section of our Web site. With virtualization technology, I can quickly build my own Active Directory® or customize a deployment of Windows Vista™ right on my laptop. No extra hardware required. Going through the process myself makes a big difference when I’m trying to understand how something works.
The only catch with Virtual PC is that you need to actually build the virtual environment (install the OS, configure everything properly, and so on), which is great if that’s what you’re looking to learn about. But what if you just want to explore a specific feature or function of a product? For example, what if you want to learn about new compliance features in Exchange Server 2007? Installing and configuring Windows Server®, Active Directory, and Exchange Server from scratch seems like a lot of work. Enter TechNet Virtual Labs. In my humble opinion, Virtual Labs is one of the best training resources to come along in a very long time. The Virtual Lab team has already done the hard part—they have over 180 preinstalled, preconfigured virtual machines that cover various combinations of over 20 products. Each one comes with a set of training exercises to help walk you through common tasks and new features. And the best part is that the entire process runs in a browser environment, hosted on Microsoft-managed servers, so you don’t need to dedicate your own hardware resources.
So, yes, it does get harder to stay current if you’re not on the front lines anymore, but it can be done! I’ve pointed you towards some of my favorite resources. And as my good friend Edward Dake pointed out in this column several months back, among the best resources we have is each other. You can always ask for help.

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


 Windows Confidential: Determining What Is Frequently Used
Windows Confidential
Determining What Is Frequently Used
Raymond Chen

Click the Start button and up pops the Start menu. On the left-hand side is a list of programs. How is that list of programs chosen? We started with the general principle that programs you’ve recently run most often are the ones that should show up on the front page of the Start menu. Keeping this principle in mind, we soon found it was necessary to do some fine-tuning.
The basic rule is that each time you launch a program, it earns a point. Conversely, the longer you don’t launch a program, the more points it loses. The Start menu shows the programs that have the most points. Simple, right? This is not the part of the selection algorithm that confuses people. After the basic rule is applied, the fine-tuning kicks in, and that’s the part that people find most puzzling.
Before we go into the fine-tuning, there are some things that aren’t obvious from the basic rule. Notice that the rule talks about launching programs, not shortcuts. Some programs install multiple shortcuts, and it doesn’t matter which shortcut you use to launch a program. If they all point to the same executable, then that program accumulates all the points earned through the different shortcuts.
Start Menu
This also means a program can earn points even if you don’t use the Start menu to run it, as long as you run it from Explorer. If you run a program manually, say by opening the folder and double-clicking the executable, it still earns points and can eventually be promoted to the front page of the Start menu.
Now, once a program earns enough points to make it to the front page of the Start menu, Windows® has to decide which shortcut icon to show if there is more than one shortcut pointing to the program. Not surprisingly, ties are broken in favor of the most frequently used shortcut.
As part of the fine-tuning, certain programs are filtered from the list. For example, a program that you’ve pinned to the Start menu will not appear because there’s no point in showing you two icons for the same program. After all, you pinned the program to your Start menu because you run it often.
Another fine-tuning step filters out noise. Many programs were showing up because they were shortcuts to common helper programs like Notepad or Wordpad—such as a shortcut to display a Read Me file. These shortcuts needed to be filtered out so they wouldn’t be nominated as, say, the Notepad representative. Incidentally, a program can register itself as not eligible for inclusion in the front page of the Start menu by creating a NoStartPage value in its application registration.
The basic rule also didn’t account for a program that you launch once and keep running all the time. According to a strict interpretation of the rule, this program would earn a point when you launched it and then lose that point over time. (In this case, "frequently" is an astounding understatement for "all the stinking time!") So we added another rule: for each consecutive day a program is kept running, it earns a point. This is enough to keep the program afloat in the points race, but not so much as to overwhelm the programs that you actually launch. After all, if you keep the program running all the time, you don’t need to launch it frequently.
In Windows Vista™, a few additional fine-tuning rules were added. For example, when choosing among candidate shortcuts for a program that has never been run from the Start menu, a shortcut with no command line parameters is now preferred. And the program you ran most recently will always appear on the list, regardless of its point count.

Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. His call is important to you and will be answered in the order it was received.