September 2008 September 2008
ISA Server: A Guide to Securing ISA Server 2006
Many organizations rely on ISA Server 2006 to secure their environment, but few take the important step of securing ISA Server itself. Here’s a guide to using the Security Configuration Wizard and Administrative roles to limit its attack surface and secure your ISA Server 2006 implementation. Alan Maddison
ISA Server: Enhance TS Gateway Security with ISA Server 2006
Using the new TS Gateway feature, Windows Server 2008 enables users to access their desktops from anywhere, without using a VPN. Find out how you can publish the TS Gateway through ISA Server 2006 and extend the ISA Server 2006 publishing scenario to include client health enforcement. Dr. Thomas W. Shinder and Yuri Diogenes
IIS 7.0: Top 10 Performance Improvements in IIS 7.0
The latest release of IIS introduces a modular and extensible platform with improved support for common deployment and management scenarios, enabling significant performance improvements. Here’s a look at 10 key areas in IIS 7.0 that provide these improvements. Mike Volodarsky
Mobility: Take Your Line of Business Applications Mobile
Many mobile professionals today need the line of business applications they use in the office (CRM, ERP, and the like) to be accessible from a mobile device when they are in the field. See how Windows Mobile and Mobile Device Manager allow you to deploy rich mobile functionality for critical line of business applications. Matt Fontaine
Security: Understanding Shared Account Password Management
Shared and privileged account passwords are commonplace, but far too many organizations fail to adequately manage these shared passwords. This creates a serious security issue. Explore the risks involved with shared and privileged accounts, and discover better approaches to managing more secure passwords. Chris Stoneff
Columns
From the Editor: Back to School: | Letters: Readers Speak Out: | Toolbox: New Products for IT Pros:
Exchange Queue & A: Aligning Disk Partitions, Planning for SCR, and More: In the September 2008 installment of Exchange Queue & A, we answer questions about calculating the number of Global Catalog servers you'll need, changing a server's site membership, and more.Henrik Walther | Utility Spotlight: Windows Memory Diagnostic: See how this free utility can help you determine whether problems you are experiencing while running Windows are caused by faulty memory.Lance Whitney | Inside SharePoint: SharePoint Directory Integration: Pav Cherny discusses the limitations of the built-in Directory Management Service in SharePoint and explains how you can replace this component with a custom solution that lets you synchronize SharePoint recipient information with other directory solutions.Pav Cherny
Windows PowerShell: String Theory: Despite its object oriented nature, Windows PowerShell is also able to parse complicated strings. Don Jones demonstrates how you can do this in Windows PowerShell using Select-String.Don Jones | Hey, Scripting Guy!: Stay Connected with Your Toaster: Discover how you can use disconnected recordsets—virtual database tables—to work around VBScript limitations relating to data-sorting and working with large data sets.The Microsoft Scripting Guys | The Desktop Files: Advanced Functionality in WDS: In his third installment on Windows Deployment Services, Wes Miller explores features that enhance performance and scalability, logging, and command-line automation.Wes Miller
Security Watch: Passwords and Credit Cards, Part 3: In the final part of this three part series, Jesper Johansson looks at how software vendors, security suites, and marketing efforts hinder true security efforts and he warns us about how these practices can lead to the collapse of the technology security ecosystem.Jesper M. Johansson | Field Notes: Innovation from Within: Romi Mahajan explains his theory of “Innovation from Within,” which emphasizes both human creativity and capital as keys to sustained comparative advantage.Romi Mahajan | Windows Confidential: Windows 95 Unplugged: Raymond Chen explains how a bit of diagnostic code unexpectedly brought the Windows 95 build to crawl.Raymond Chen


A Guide to Securing ISA Server 2006
Alan Maddison
At a Glance:
  • Best practices for securing your servers
  • Setting up the Security Configuration Wizard
  • A Security Configuration Wizard walkthrough
  • Assigning Administrative roles

Contents
Securing Your Servers
Setting Up the Security Configuration Wizard
Running the SCW
Administrative Roles
While many IT pros rely on ISA Server 2006 (Internet Security and Acceleration Server 2006) to secure their technology assets, few take the extra step of securing ISA Server itself. If you
have recently installed ISA Server 2006, you may recall that there was a reminder to do this immediately after installation is complete. Unfortunately, many of us IT pros rarely take (or have) the time to perform this important step, and so it ends up on that list of things to do that never get done.
In today's constantly changing security landscape, this failure to secure ISA Server is no longer acceptable. Fortunately, the tools used to secure ISA Server have made tremendous advances. No longer do you have to face many of the challenges in the Security Hardening Wizards found in versions prior to ISA Server 2004. Instead, you can rely on well-defined steps and tools, such as the Security Configuration Wizard (SCW) that ships with Windows Server® 2003.
In this article I will provide a brief recap of general best practices for securing servers. Then I'll take a step-by-step look at hardening strategies for ISA Server itself, using the Security Configuration Wizard to reduce the attack surface area of the ISA Server and Administrative roles to restrict access to the ISA Server.

Securing Your Servers
There are many elements and best practices involved in securing servers, whether they are located in a datacenter or in the server room next to your office. As an administrator, it is your responsibility to understand what these best practices are and do your best to implement these requirements in a manner that is practical for your organization. As the emphasis on security has become more prevalent in recent years, many of us have become quite familiar with the tasks that form the core of these requirements, so I won't belabor the points but instead will provide only a brief overview.
The first step you must take to secure your environment is to ensure that your servers are physically secure. What this means in practical terms is that you must restrict physical access to your servers. In smaller environments this means making sure the server room door remains locked and the list of individuals with access to the room remains very small. In larger environments this basic requirement remains very much the same, but it can be implemented in a more sophisticated manner. Many organizations use electronic monitoring, for example. This allows them to audit entry to server locations and even restrict access to individual racks or cages depending on how job responsibilities are structured.
There are some unique factors to consider when dealing with the theft or physical compromise of an ISA Server or an ISA Configuration Storage Server. The nature of the information that can be obtained from the stolen server can potentially compromise all the ISA Servers and traffic (including encrypted traffic) in your environment.
If you suspect a server has been compromised, stolen, or otherwise, remove the affected server immediately (if it's still on site) and follow standard procedures for securing evidence. After you have taken these necessary steps, you need to begin the process of changing all confidential information—all certificates installed on the server should be revoked and all preshared keys and shared secrets should be modified. In addition, if you maintain a replica Configuration Storage Server, make sure that any data relating to the compromised server is removed.
Once your servers are physically secure, the next step is to ensure that there is a structured methodology for patching all the software, including the virtualization layer, the OS, and applications. Patches, upgrades, and hotfixes should be reviewed and applied regularly. But don't forget to test these updates before applying them to production systems. A patch won't do you any good if it ends up causing a problem that compromises application or data integrity.
If data integrity is compromised, you will need to rely on your backups. This brings me to another key element in securing your infrastructure. If you can't quickly and completely restore data if the need ever arises, the downtime can have a significant impact on your operations and, as a result, increase the cost of an intrusion.
Two other elements to consider are monitoring and auditing. Monitoring your applications and systems is a critical piece of any good security plan. If you don't take the time to review logs, particularly security-related logs, you are unlikely to ever find intrusion attempts before the damage is already done.
Likewise, auditing is critical. For many organizations, especially large environments, this is often formalized and even required by legislation. Regardless, it is important in any environment to review on a regular basis the controls and methodology used to secure your assets for your efforts to be effective.
Finally, since you're running ISA Server 2006 on Windows Server® 2003, it is important that you review the Windows Server 2003 Security Guide and implement the necessary recommendations. You can find the Windows Server 2003 Security Guide at microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx.
Microsoft currently recommends implementing the Baseline Security Policy template, but you should not implement any Internet Protocol Security (IPsec) filters.

Setting Up the Security Configuration Wizard
So how can you make ISA Server itself more secure? The primary tool for securing ISA is the SCW. This is an attack surface reduction tool. It creates security policies that target a server's services, network security, registry, and audit policy, configuring the system for just the services and features it requires. It is important to note that you should only configure ISA Server services that you intend to use. For example, the Web Proxy service is enabled by default, but you should disable this functionality if you don't intend to use it. Thus, you need to pay close attention to the configuration options the SCW presents to you.
The SCW isn't installed by default in Windows Server 2003, so the first step is to install it yourself using the Add/Remove Windows® Components applet in the Add or Remove Programs control panel. (Note that the SCW is installed by default in Windows Server 2008.) Once the Windows Components screen has loaded, scroll down and check the box for the SCW.
Once the installation is complete, the application can be found under Administrative Tools. Before you begin using the wizard you must update the SCW by downloading an update for ISA Server 2006 (available at go.microsoft.com/fwlink/?LinkId=122532). This update adds the roles for ISA Server 2006 Standard Edition, ISA Server 2006 Enterprise Edition, and ISA Server Configuration Storage Server.
After you download the update, you need to run the package and extract the files from it. After extracting these files, copy the two .xml files (isa.xml and isaloc.xml) to the SCW kbs folder—in a default installation of Windows Server, this will be c:\windows\security\msscw\kbs.
When you copy the files, you will be prompted to overwrite two existing files with the same name. These two files are for ISA Server 2004, so you should back them up before overwriting them. The final step is to copy the isascwhlp.dll file to the bin folder, which is typically found in c:\windows\security\msscw\bin. Once you have completed the addition of the ISA roles to the SCW, you will be ready to begin the installation.
Microsoft generally recommends that you only run the SCW once you have completed the configuration of ISA Server. If you are running Enterprise Edition, this includes the configuration of all the arrays and all the array members.

Running the SCW
The first step is to launch the SCW from Administrative Tools—remember that you need Administrative permissions to successfully complete the SCW process.
Figure 1 shows the first screen of the wizard. If you read through the text on this screen, particularly the warning that says "this wizard detects the inbound ports that are listened to by this server," you can understand why it is important to have your ISA Server and arrays fully configured prior to beginning this process.
Figure 1 Starting the Security Configuration Wizard
If you have not fully configured your environment, there is a good chance that you will need to revise the SCW configuration after completing the ISA configuration. The next screen, shown in Figure 2, asks which action you want to perform. You should select the option to Create a new security policy.
Figure 2 Creating a new security policy
You are then instructed to select the server that will serve as the baseline for the policy. Since you are creating a new policy, the default selection is to use the computer on which you are running the SCW. This behavior changes, however, depending on the action you choose to perform on the previous screen. Regardless, it is recommended as a best practice to have the SCW installed on the server you wish to use as the baseline. If the SCW is not installed on the target server, information used to complete the policy will be missing. Thus, to make your life easier, install and run the SCW from the server you want to serve as the baseline.
When you press Next, the SCW will begin analysis of your ISA Server. This analysis includes determining roles that are installed on the server, roles that are likely installed on the server, services that are installed, and basic networking information. When processing is complete, you can view the database by selecting View Configuration Database. The configuration database contains a lot of information, including all supported server roles, client features, and ports.
Then the SCW begins the process of walking you through Role-Based Service Configuration. Pressing Next takes you to the next screen, where you are prompted to select the server roles, as shown in Figure 3. The initial scan performed by the SCW is reliable, and you should find that the correct server roles have already been identified. However, it is very important that you double-check and remove any unnecessary roles. And if the server fulfills multiple roles, make sure all of the appropriate roles are selected.
Figure 3 Specifying server roles
One important point to remember if you are running ISA Server 2006 Enterprise Edition is that you have to consider the Configuration Storage Server. If the Configuration Storage Server is installed on a server that also acts as an ISA Server (this, by the way, does not follow recommended best practices but is often done nonetheless), you will need to make sure the Configuration Storage Server role is also selected. You should not use a baseline scan of a server that hosts both roles for servers that actually have just the ISA Server 2006 role.
Next you are prompted to select the client features of the server. In other words, you need to specify the services required by the server. For instance, nearly all servers will require the DNS client, and if a server is a member of a domain, then it will require the Domain member feature.
After you've done that, you are shown the Administration and Other Options screen. This is where you indicate the application, administration, and operating system options that use services or rely on network connectivity. Any services not selected by this point will be disabled. But after you make your selections and press Next, you are given the option to select any additional services you want to allow.
Then you move on to configure how unspecified services should be handled. This lets you define what should happen when services that are not included in the main database or installed on the baseline server are found when the policy is being applied. As a general best practice you should choose to disable unspecified services because this will limit any unforeseen attack vectors. Unfortunately, this option can have negative consequences if your servers are unalike in any significant ways; you also need to remember this setting if you add any applications or network services in the future.
The next section of the wizard, which is shown in Figure 4, allows you to review the services that are being modified by the SCW. This confirmation screen provides you with a comparative view of both the current status and the modified status of services after the policy is applied.
Figure 4 Review and confirm service changes
After you confirm the services that are going to be changed, you move onto the Network Security section. This is where the SCW would typically let you modify Windows Firewall and IPsec settings. But since you are configuring ISA Server 2006, you have no choice but to skip this section, as shown in Figure 5.
Figure 5 Skipping past the Network Security settings
The wizard then moves on to configuring Registry settings that focus on network authentication methods and security. The first screen in this section involves Server Message Block (SMB) signing. The SMB protocol is a core Microsoft networking protocol, and these settings allow for signed communications in order to reduce the likelihood of man-in-the-middle attacks.
The default settings, as shown in Figure 6, provide a good level of security for your ISA Server SMB communications. But you must take into account the impact that will be caused by signing all communications. If you don't have the spare CPU cycles, you should uncheck the second option. And don't forget to think about all the servers to which this policy will be applied—if you have servers with different workloads, you need to use the server with the highest CPU utilization as the guideline for whether or not you select this option.
Figure 6 Specifying whether to require signed communications
The next set of screens deal with the LMCompatibility level that the ISA Server should use. The first of these screens presents three choices. Unless you have legacy Windows clients (such as Windows 95 or Windows 98) or you use local accounts for access control, you should leave the default choice of Domain Accounts selected.
On the second screen dealing with LMCompatibility level, you provide information about your domain controllers. If you don't have any Windows NT® 4.0 domains, you can leave the default choice (Windows NT 4.0 Service Pack 6a or later OSs) selected. On this dialog, you should also select that the Clocks be synchronized with the selected server's clock option. Selecting Next will lead to some additional configuration options for inbound LAN Manager (LM) communication, as shown in Figure 7.
Figure 7 Indicating inbound authentication methods
This third screen pertaining to LMCompatibility level will determine whether the Windows NT LAN Manager (NTLM) version 2 is required and whether LM hashes are stored. You should make sure that neither of these options are selected, provided your environment will support this configuration, as deselecting these two options will improve security significantly. You are then presented with a Registry Settings Summary. Review each entry and confirm that the policy settings are correct.
Next, the wizard takes you to the final section—Auditing. One important point to note about any of the configuration options you make in this section is that they cannot be rolled back. But since auditing won't affect system functionality, you should not skip this section.
The default selection of "Audit successful activities" will not provide you with event log entries for logon failures. However, information regarding logon failures can offer valuable information about intrusion attempts. Thus, as a general best practice, you should select "Audit successful and unsuccessful activities".
You can then review your audit configuration and press Next twice to save your security policy. All that is required on this screen, shown in Figure 8, is a file name; however, you can also provide a brief description,. This description can prove useful in large environments where different Administrators share security responsibilities.
Figure 8 Providing a name and description for your security policy
Once the file has been saved, you are given the option of applying the policy immediately or later. If you choose to apply the policy later, the process is complete. If you discover that you made any errors in the policy configuration, you can roll back the policy, with the exception of auditing settings.

Administrative Roles
Reducing the attack surface of your ISA Server is a critical step in reducing the potential for breaches from external sources. However, it's also important to review the assignment of Administrative roles within ISA Server to limit the potential for compromise from internal sources. The Administrative roles and a partial list of common associated tasks are shown in Figures 9 and 10.
Figure 9 Roles and tasks associated with Standard Edition
Task | Monitoring Auditor | Auditor | Full Administrator
View Dashboard, alerts, connectivity, sessions, and services | Allowed | Allowed | Allowed
Acknowledge alerts | Allowed | Allowed | Allowed
View log information | – | Allowed | Allowed
Create alert definitions | – | – | Allowed
Create reports | – | Allowed | Allowed
Stop and start sessions and services | – | Allowed | Allowed
View firewall policy | – | Allowed | Allowed
Configure firewall policy | – | – | Allowed
Configure cache | – | – | Allowed
Configure a virtual private network (VPN) | – | – | Allowed
Figure 10 Roles and tasks associated with Enterprise Edition
Activity | Array Monitoring Auditor | Array Auditor | Array Administrator
View Dashboard, alerts, connectivity, and sessions | Allowed | Allowed | Allowed
Acknowledge and reset alerts | Allowed | Allowed | Allowed
View log information | – | Allowed | Allowed
Create alert definitions | – | - | Allowed
Create reports | – | Allowed | Allowed
Stop and start sessions and services | – | Allowed | Allowed
View firewall policy | – | Allowed | Allowed
Configure firewall policy | – | – | Allowed
Configure cache | – | – | Allowed
Configure a virtual private network (VPN) | – | – | Allowed
Perform NLB Drain/Stop | – | Allowed | Allowed
View local configuration (in registry of array member) | – | Allowed | Allowed
Change local configuration (in registry of array member) | – | – | –
As you can see, there is a high degree of segmentation in the administrative tasks associated with ISA Server. This, in turn, should make it easy for you to assign the correct roles to users within your organization.
Beyond this, what you need to remember is that the best approach to role assignment is to employ the concept of least privilege. Any given user should have only the least amount of privileges necessary to allow him to do his job.
It is also important to remember that members of the local Administrators group on ISA Server 2006 Standard Edition have the same rights as an ISA Server Full Administrator. With Enterprise Edition, members of the local Administrators group on the server with the Configuration Storage Server role have complete control over the Enterprise configuration. This means that you need to carefully review the membership of the Domain Admins group, assuming your ISA Server is a member of a domain, as well as any other group that is a member of the ISA Server's local Administrators group.

Alan Maddison is a Senior Consultant, specializing in Microsoft technologies, with Strategic Business Systems, a division of Brocade.


ISA Server
Enhance TS Gateway Security with ISA Server 2006
Dr. Thomas W. Shinder and Yuri Diogenes
At a Glance:
  • Two scenarios that use TS Gateway with ISA Server
  • ISA Server 2006 configuration
  • Testing and monitoring

Contents
Beyond the Perimeter
The First Scenario
Configuring ISA Server 2006
Testing and Monitoring Client Access
Monitoring from ISA Server
The Second Scenario
What about the Client?
Conclusion
Following on the success of Outlook Anywhere in Exchange Server 2007, Windows Server 2008 in turn delivers the capability to access your desktop from anywhere in a secure and controlled manner.
The new Terminal Server Gateway service (TS Gateway) in Windows Server® 2008 offers the flexibility of Windows® Terminal Server Services plus the ability to connect to a Terminal Server from anywhere over an HTTP connection. This service uses Remote Desktop Protocol (RDP) over HTTPS (SSL) to increase security while providing a single client interface for accessing Terminal Services resources.
This new TS Gateway service offers significant benefits to those who need to access their computers remotely:
  • No need to establish a Virtual Private Network (VPN) session prior to connecting to internal resources using RDP.
  • Enhanced security using Network Access Protection (NAP) and Windows Security Health Checks to control RDP connections.
  • No need to open TCP port 3389 inbound to enable more secure Web publishing through firewalls.
You can use Microsoft® Internet Security and Acceleration (ISA) Server 2006 to enhance the security of TS Gateway service while allowing external access to internal resources. You can set up an SSL-to-SSL bridging scenario in which ISA Server 2006 receives requests and passes them to the internal TS Gateway service, also using HTTPS. While bridging the request, the ISA firewall decrypts the SSL communications and performs application-layer inspection.
If the HTTP protocol stream passes inspection, then the communication is re-encrypted and forwarded to the Terminal Services proxy. If the protocol stream fails inspection, the connection is dropped.

Beyond the Perimeter
Microsoft has invested quite a bit of effort in security, and Windows Server 2008 is the most secure and robust version of Windows yet. But the company is also concerned with how users will implement its products and that users follow best practices to keep their environments secure. Best practices require a defense-in-depth approach that provides protection at multiple points of access, or layers. The layers relevant to our discussion here are Policies, Procedures and Awareness; Perimeter; Internal Network; and Host.
When you allow external users access to an internal resource through ISA Server, you need to understand the boundaries of each product involved. ISA Server 2006 and TS Gateway will provide security at the Perimeter layer, but for internal resources, you need to have policies in place that allow or deny access as necessary. Network Policy and Access Services (NPAS) lets you accomplish this, working at the Policies, Procedures and Awareness layer. Access to internal resources (drive, clipboard, printers, and so forth) is defined by Terminal Service Resource Authorization Policies, addressing the internal network layer.
In this article we will first examine how to publish the Terminal Services Gateway through ISA Server 2006. Then we'll extend our ISA Server 2006 publishing scenario to include client health enforcement using NAP. By using NAP, we can create client health policies that help us control access at the Host Layer.

The First Scenario
Our goal is to show how to publish the TS Gateway through ISA Server 2006. Figure 1 summarizes the computers and data flow during the connection. In this scenario we are implementing the Network Policy Server (NPS) Role on the TS Gateway itself; however, we will change this in the second scenario, where we will use a central NPS server. Follow the sequence below to understand how the communications work among the components of the TS Gateway publishing solution:
Figure 1 Publishing TS Gateway through ISA Server 2006
  1. The external RDP user initiates the connection. The first thing the client must do is resolve the external name of the TS Gateway (in this case, tsg.contoso.com). The external DNS resolves this name, which points to the external IP address of the ISA Server.
  2. An SSL tunnel is established between the RDP client and the external interface of the ISA Server. The ISA Server has a Web publishing rule on port TCP 443 that uses a certificate issued to tsg.contoso.com.
  3. After evaluating the rule and checking that the traffic is allowed, ISA Server will send a DNS query to the internal DNS server (located on the domain controller) to resolve the name of the server specified on the Web publishing rule.
  4. ISA Server then opens an SSL tunnel to the TS Gateway and passes the authentication request to it.
  5. The TS Gateway server validates the user's credentials and verifies that the user is authorized to establish the connection.
  6. After establishing that the user is authorized to establish the connection, the TS Gateway service receives the requests on TCP port 443 and forwards the RDP packets via TCP port 3389 (by default) to the internal Terminal Server where the application (such as a CRM application) resides.
From this point, any packets the RDP client sends to TS Gateway service through ISA Server are forwarded to the internal Terminal Server, and vice versa.
It is important to mention that the RDP over HTTPS behind the scenes is nothing more than a RDP/RPC/HTTPS. The RDP client encapsulates the RDP communications in an RPC header, which is subsequently encapsulated with an HTTP header that is secured using SSL (or Transport Level Security, TLS). All the components that you need for an RPC over HTTPS solution need to be present. This is why, when you install the TS Gateway Role service, it automatically installs the RPC over HTTP Proxy. To understand more about how this protocol works, we recommend that you read "Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing," which you can find on the ISA Server Team Blog (available at blogs.technet.com/isablog).
This implementation requires Windows Server 2008 with Terminal Service Gateway installed, and this feature depends on RPC over the HTTP Proxy. For the RDP over RPC over HTTP Proxy feature to function, Internet Information Services (IIS) 7.0 must be installed and running. You also need Network Policy and Access Services, but, if you prefer, you can configure TS Gateway to use the NPS server, formerly known as Internet Authentication Services (IAS), to centralize storage, management, and validation of Terminal Services Connection Authorization Policies (TS CAPs). Finally, you must obtain an SSL certificate for the TS Gateway server if you do not already have one. It is important to emphasize that the ISA Server 2006 must trust the certificate authority (CA) that issues the certificate. Therefore, make sure to import the certificate to the Trusted Root Certificate Authorities Store.
Active Directory® Domain Services is only required if you configure a TS Gateway authorization policy that requires users to be members of an Active Directory security group to connect to the TS Gateway server. For this particular setup, we will use Active Directory on a computer running Windows Server 2003 SP2.
When we finished installing the Terminal Services Gateway service, the screen in Figure 2 appeared, showing the components that were installed. To connect the TS Gateway, clients must be running one of the following: Windows Vista®; Windows XP with SP2 and RDP 6.0 or later; Windows Server 2008; Windows Server 2003 with SP1 or later and RDP 6.0 or later. For more information on TS Gateway configuration, see Windows Server 2008 TS Gateway Server Step-By-Step Setup Guide available at go.microsoft.com/fwlink/?LinkId=122251. Now let's look at how to configure ISA Server 2006.
Figure 2 TS Gateway installation summary

Configuring ISA Server 2006
The first step is to create a Web Listener that will handle the requests from the external RDP client. Our Web Listener has the following parameters:
  • Authentication: Basic
  • Authentication Validation: Windows (Active Directory)
  • Connections: Enable SSL (HTTPS) connections on port 443
  • Certificates: certificate issued to tsg.contoso.com
  • Networks: External
Next, you create the Web publishing rule. From the ISA Server 2006 perspective, the RDP client will use the same protocol that Outlook® Anywhere uses, so choose the Exchange Server 2007 Wizard. Simply follow these steps:
  1. Right-click on the Firewall Policy, select New, and then click Exchange Web Client Access publishing rule.
  2. On the Welcome to the Create a New Web publishing rule page, type the name of the rule and click Next.
  3. On the Select Rule Action page, select the option Allow and click Next.
  4. On the New Exchange publishing rule page, select the Exchange version, in our case Exchange Server 2007. Select Outlook Anywhere (RPC/HTTP(s)) and click Next. (Note: do not select the Publish additional folders on the Exchange Server for Outlook 2007 client option.)
  5. On the Publishing Type page, select the option to Publish a single Web Site or load balancer and click Next.
  6. On the Server Connection Security page, select Use SSL to connect to the published Web server or server farm and then click Next.
  7. On the Internal Publishing Details page, in the Internal site name box, type the name of the TS Gateway server. Select the Use a computer name or IP address to connect to the published server checkbox and then, in the Computer name or IP address box, type the server name. If you do not know the name of the TS Gateway server, click Browse to navigate to its location. Note that the name you use on this page must match the common or subject name on the Web site certificate bound to the TS Gateway Web site.
  8. On the Public Name Details page, from the Accept requests for dropdown list, select This domain name (type below) and then, in the Public name box, type the public name that matches the name of the certificate that was issued for this URL—in our case, the name was tsg.contoso.com. Then click Next.
  9. On the Select Web Listener page, click on the dropdown list and select the Web Listener that was previously created, and then click Next.
On the Authentication Delegation page, select the option No delegation, but client may authenticate directly, and click Next.
On the User Set page, verify that the default option (All Users) is selected, click Next, and then click Finish, and apply it.
If you double-click in the rule and go to the Path tab, you'll see that the only path we have is /rpc/*. This is due to the fact that we used the Exchange Server 2007 Outlook Anywhere Wizard.

Testing and Monitoring Client Access
As mentioned before, you need the RDP 6.0 or later client to connect to the TS Gateway. To configure the RDP client app, launch it and type the name of the Terminal Server you want to connect to in the Computer field. Click on the Options button, the Advanced Tab, and then Settings, then type the external name of the TS Gateway server, as in Figure 3. In our example, this is the name on the certificate bound to the Web Listener that is used by our Web publishing rule to accept incoming requests. Note that Windows NT® LAN Manager authentication is used in this example. When finished, click OK and then Connect. You'll get an authentication prompt. Type the credentials of a user with access to the Terminal Server and click OK.
Figure 3 Configuring the RDP client
Note that the RDP 6.0 client (for Windows XP and Windows Server 2003) will show the screen in Figure 3. You will be prompted for authentication twice—the first authentication is for the TS Gateway computer and the second one is for the Terminal Server you want to access. This is an important point because while you might think this is due to the ISA Server configuration, in fact the ISA Server is not handling authentication at all since the Web publishing rule applies to "All Users," which allows anonymous connections through the ISA firewall.
The RDP client that comes with Windows Server 2008 has a Use my TS Gateway credentials for the remote computer, as shown in Figure 4. With this option selected, you don't need to type your credentials twice, resulting in a better user experience. This single sign-on option is also available on Windows Vista after you apply SP1.
Figure 4 The Windows Server 2008 RDP client
You can monitor the connection through the TS Gateway Manager, using the Monitoring option. The TS Gateway service also provides details when a non-authorized user tries to connect to the server. In Figure 5, the Event Viewer shows a connection attempt from a user who doesn't have permission to connect through the TS Gateway.
Figure 5 Event logged into the TS Gateway service
For this event, the internal IP address of the ISA Server 2006 is logged because the option Requests appear to come from the ISA Server computer is enabled in the Web publishing rule. If you want to register the original client IP address, you will need to change the ISA Server 2006 Web publishing rule and choose the option Requests appear to come from the original client on the To tab.

Monitoring from ISA Server
Using the new features of the ISA Server 2006 Supportability Pack, it is possible to closely watch and understand each connection to the internal network. Figure 6 shows one connection highlighted and, on the Request: line, the RPC_IN_DATA verb indicating the URL for the RPC over HTTP Proxy.
Figure 6 ISA Server 2006 logging using the Supportability update
If you continue to look at the logging, you should see the other RPC over HTTP verb, RPC_OUT_DATA. It is important to be aware of which HTTP methods are used, which are RPC_IN_DATA and RPC_OUT_DATA for RDP/HTTP, because if you have the HTTP Filtering configured to block these methods, the traffic will be blocked on ISA Server. If you would like to lock down your environment, you can configure the RDP/HTTP Web publishing rule to allow only these two methods. For more information on the HTTP methods typically used for publishing, you should read the article "HTTP Filtering in ISA Server 2004" at technet.microsoft.com/library/cc302627.

The Second Scenario
For this scenario, TS Gateway will use an NPS Central Policy located on another server. We will enforce a NAP policy for the clients connecting remotely through the TS Gateway. The same components that were used in Scenario 1 are used again here, only the NPS server will be added. However, due to NAP enforcement, more components will be used on the client side, as Figure 7 shows.
Figure 7 Main components of the Scenario 2 topology
Here is the explanation of the individual components. On the Windows Vista client, a System Health Agent (SHA) consists of the client-side components responsible for monitoring and reporting the client's heath state. Windows Vista comes with the Windows SHA, but there are other vendors working to create their own SHAs.
The NAP Agent on the client is responsible for establishing communications with the NAP Enforcement Server when the client tries to access the network. The NAP Agent sends the client's Statement of Health (SoH) to that server.
On the TS Gateway, the TS Resource Authorization Policy (TS RAP) is the component that allows you to determine which computers will be available to receive incoming RDP requests. The TS RAP also determines which users are allowed to establish RDP connections to specific servers.
The Central NPS is responsible for controlling the conditions, constraints, and settings that regulate access to the internal computers. System Health Validators (SHVs) on the Central NPS are responsible for evaluating whether the SoH submitted by the client is compliant with the policy set by the administrator.
Now let's change the TS Gateway to point to a NPS Central Server. Open the TS Gateway Manager Console, right-click on the server's name, and choose the option Properties. On the server's properties window, click on the TS CAP Store tab and select Central NPS server. Next, type the name or IP address of the NPS server and click on the Add button. You'll see a Shared Secret window pop up. Type the secret and click OK, then click OK again to close the window. You must remember this secret because it will be used on the NPS server.
Assuming that the NPS is already installed on another server, here are the steps you will need to follow:
  1. Open the Network Policy Server console and, in the left pane, click on NPS (Local).
  2. In the right pane, click on Configure NAP. The Select Network Connection Method for Use with NAP page will appear.
  3. Under Network Connection Method, select Terminal Services Gateway (TS Gateway) from the dropdown box and click Next.
  4. On the Specify NAP Enforcement Servers Running TS Gateway page, click on the Add button.
  5. In the New TS Gateway window, type the friendly name and the IP address of the TS Gateway server. And then at the bottom of the window, type the shared secret, using the same secret as on the TS Gateway server's configuration. Then click OK.
  6. On the Configure Client Device Redirection and Authentication Methods page, you can specify which devices will be redirected and the allowed authentication method (password or smart card). For the purpose of this example, leave the default options and click Next.
  7. On the Configure User Groups and Machine Groups page, add the user group that is allowed to establish the connection. For this example, click on the Add Users button under User Groups: (Required) and choose Domain Admins. Click OK and then Next.
  8. On the Define NAP Health Policy page, you'll notice that the default SHV is already selected. Notice also that on the bottom part of this page, access is denied for non-compliant computers. Leave the defaults selected and click Next.
  9. On the Completing NAP Enforcement Policy and RADIUS Client Configuration page, review the options that were previously selected. You can also click on the hyperlink Configuration Details and a HTML page will open up with a summary of your selections. When you're finished, click Finish.
This wizard takes care of configuring the settings for a number of important policies (Connection Request Policies, Network Policies, and Health Policies), significantly reducing the work needed to configure NAP for this scenario.

What about the Client?
So now that the server is all set up and configured, what do you have to do regarding the client?
To take advantage of the NAP enforcement policy, the client needs to be either Windows Server 2008 or Windows Vista. For Windows XP, you need to have SP3 installed, which includes the NAP client.
Besides the operating system requirement, there are some relevant services and settings that need to be enabled on the client side. These include the following:
  • Adding the TS Gateway server name to the Trusted Server list on the client.
  • Starting the NAP Agent service and setting the service startup type to Automatic.
  • Enabling the TS Gateway Quarantine Enforcement client.
To simplify the deployment of this solution, Microsoft has created the Terminal Services NAP client configuration command (Tsgqecclientconfig.cmd), which can be downloaded from go.microsoft.com/fwlink/?LinkId=122267. After running the command, the client will be configured as a NAP enforcement client for TS Gateway. Note that the command must be run with elevated privileges.
Throughout this article our principle goal has been not only to describe and explain the new TS Gateway feature that is available on Windows Server 2008 and to show how to publish it securely through ISA Server 2006, but also to provide you with an overall perspective on the security advantages that the combination of both products can provide for your company.
In today's world, to be connected from anywhere is a key requirement for just about any successful business. However, it is also necessary that this connectivity doesn't come at the cost of providing an improved experience for the user. And, even more importantly, it is mandatory that all of this be done in a manner that ensures security.

Dr. Thomas W. Shinder is an MCSE and ISA Server MVP. He has worked as a technology trainer, writer, and consultant since 1996. Dr. Shinder is the author of six books on the ISA Firewall. He is also the thought leader and primary perpetrator of ISAserver.org, the largest community of ISA Firewall admins and devotees on the Internet.

Yuri Diogenes, MCSE+S, MCTS, MCITP, Security+, Network+, and CCNP, is the Security Support Engineer on the Microsoft ISA Server/IAG Team. He writes articles for the Microsoft TechNet Library and the ISA Server Team blog. Yuri has worked with Microsoft technology since 1993. Before joining Microsoft, he worked as a Microsoft trainer, support analyst, and consultant.


IIS 7.0
Top 10 Performance Improvements in IIS 7.0
Mike Volodarsky
At a Glance:
  • Minimize your application footprint
  • Reduce bandwidth costs
  • Use enhanced caching capabilities

Contents
Leaner Web Servers
Build on a Lean OS
Specialized Application Topologies
Improved Application Support
Increase Application Density
Bandwidth Reduction from Compression
Media Bit Rate Throttling
Output Caching
Converting ISAPI Code to IIS 7.0 Modules
Server Extensibility
Wrapping Up
When I meet with companies planning to adopt IIS 7.0, one question that inevitably comes up is whether moving to IIS 7.0 will improve the performance of servers or applications. The
answer is generally yes, but don't be surprised when you don't see performance improvements when you first migrate your applications to the IIS 7.0.
To understand this, you need to understand the nature of the latest release. IIS 6.0 was an engineering release aimed at accomplishing three things: stronger security, higher reliability, and improved performance. By contrast, IIS 7.0 is a platform release. Its purpose was to convert the high-quality base Web server core of its predecessor to a modular and extensible platform with support for key modern deployment and management scenarios.
Many of the architectural changes and new features may actually have a negative impact on the performance of the Web server—considering, for example, that one of the key changes broke out tightly optimized Web server code paths into standalone modules that get no special treatment from the Web server. However, thanks to a lot of performance work done by the IIS team, IIS 7.0 remains at performance parity with its predecessor and exceeds it in certain areas. As I can personally tell you from working on the Web server core and the Integrated pipeline, achieving this required a lot of ingenuity in design and hard work in the implementation of the product.
Nonetheless, IIS 7.0 has a much higher potential to deliver significant performance improvements and reduce performance-related costs for your server farm than any other IIS release in the past.
You are not necessarily going to see these benefits simply by migrating to IIS 7.0, but some environments will. For example, Microsoft.com saw a 10 percent improvement in CPU efficiency (you can find the complete analysis on the Microsoft.com Team Blog at go.microsoft.com/fwlink/?LinkId=122497). You may also notice pronounced improvements in specific areas, including secure sockets layer (SSL) and Windows® authentication (both now performed in the kernel), and better vertical scalability on multicore and multiprocessor machines.
Still, the real IIS 7.0 horsepower doesn't come from incremental performance improvements to existing features. Rather, the improvements come from new capabilities that you must actively make use of. These capabilities are often rooted in the flexibility and the extensible nature of the platform and in new performance features. In this article, I will show you 10 of the most important sources of the performance improvements you can unlock by moving to IIS 7.0.

Leaner Web Servers
The ability to deploy lean IIS 7.0 servers draws from the modular architecture of the server. Practically all of its Web server features are implemented as modular components that can be added or removed individually. Thus you can remove any server features that are not necessary for an application's operation, resulting in noteworthy benefits including a significantly reduced attack surface area, a smaller operating footprint, and improved performance.
The full IIS 7.0 Web server feature set contains 44 modules, including native IIS modules and ASP.NET modules that provide services for the Integrated pipeline. These modules deliver such services as authentication (Windows Authentication and Digest Authentication modules), application framework support (FastCGI module), application services (Session State module), security (Request Filtering module), and performance (Output Cache module). Yet a minimal Web server that simply needs to serve static content can be functional with just 2 modules!
The overhead from unnecessary modules can be fairly significant—for instance, in the case of request logging and failed request tracing modules. Removing such modules in environments where they are not required can result in higher total throughput, and faster responses that lower the time to first byte (TTFB) and time to last byte (TTLB) metrics for the server workload.
Figure 1 shows the results of a simple throughput test of an HTML file (static workload) and a hello world ASP.NET page (ASP.NET workload) when configured with the full set of features, the default set of features for that workload, and the absolutely minimal set of features needed for the workload. Even though most nonessential features are already disabled in the Full configuration, removing them completely in the Minimal configuration results in a considerable increase in throughput for both the static workload and the ASP.NET workload.
Figure 1 Throughput rates of the static workload and the ASP.NET workload in three different configurations with 100 concurrent clients
In addition, you may see improvements in the memory footprint and higher site density, especially in shared hosting environments or cases where a large number of worker processes are being used. This is typically gained by loading fewer DLLs into each process and eliminating any memory allocations occurring during module initialization and request processing. Figure 2 shows the memory usage (private bytes of the IIS worker process) in the same throughput test. While the improvements are not as pronounced in this example, the increases are in line with expectations, as the ASP.NET appdomain overhead is relatively higher than the baseline savings provided by the removed modules.
Figure 2 Memory usage (private bytes) of the static and ASP.NET workloads in three different configurations with 100 concurrent clients
IIS 7.0 provides additional control over which modules are enabled at the application level, as well as control over module usage based on workload through module pre-conditions. While this requires advanced configuration, it can provide additional benefits in multi-site environments or for apps that support multiple distinct workloads.
A word of caution: determining the functionality you require can be tricky. You must consider not only the minimal functionality needed to support your application framework, but also any of the additional features on which your application may indirectly rely. For example, your application may depend on specific authentication methods or rely on authorization semantics provided by various IIS features, in which case removing those may adversely impact the security of your application. Likewise, your application may rely on some of the modules for functional or performance effects, in which case removing them may result in incorrect behavior or performance loss.

Build on a Lean OS
Windows Server® 2008 also provides OS-level componentization that you can use to further reduce the surface area of your Web server. Server Core is a minimal installation option for the Windows Server 2008 operating system and contains a minimal set of core OS subsystems. Server Core is an ideal environment for lean IIS 7.0 Web servers.
But when evaluating Server Core, be aware that some limitations may impact your application. Server Core does not provide Microsoft® .NET Framework support, which means no ASP.NET, no .NET extensibility for IIS, and no IIS Manager. Also, local management tasks will require command-line tools since there is no Microsoft Management Console (MMC). From a performance perspective, if you are already properly taking advantage of IIS componentization, you may not see a difference in memory footprint or throughput of your application workload running on Server Core versus a full Windows Server implementation. This is because the work performed by IIS and your application is the same on both platforms. However, there is one place where you'll see a difference: the overall footprint of the server, both in terms of disk space and memory usage.
As an example, Figure 3 shows the difference in footprint after performing the static workload test on a full Windows Server 2008 configuration and on Server Core. While the IIS footprint is virtually identical in both cases, the lower overall OS footprint of Server Core allows the workload to be supported with significantly less memory. The lower footprint may actually allow you to deploy your application workload on less-powerful hardware, focusing on the processing demands of the application and not the operating environment. Of course, this makes Server Core an excellent option for virtualized environments.
Figure 3 Memory footprint of full Windows Server 2008 versus Server Core after performing the static workload test

Specialized Application Topologies
When optimizing for application workloads, you can separate the workload into distinct parts. For example, instead of running your application on a farm of 30 identical Web servers, you can run it on 10 Web servers, 5 application servers, and 3 proxy servers that perform caching and compression.
There are several reasons why this specialization works. First, the performance of many application workloads depends heavily on a variety of shared resources, such as memory, which may be contested between multiple parts of the application. The competition for these resources can create bottlenecks that prevent each server from being fully utilized across other resources. Separating parts of the application gives the parts ready access to the otherwise contested resources, resulting in higher efficiencies on the same set of hardware resources.
Second, specialization may enable the application to achieve greater cache locality, thereby improving performance. This includes low-level caches, such as the virtual memory Translation Lookaside Buffer (TLB), the file system cache, and other operating system and application caches. Another source of locality gains come from the CPU. By reducing the number of parallel activities that are taking place by focusing only on a specific part of the application, the application can reduce the number of context switches and maximize the work performed by the CPU.
Third, specialization enables workload-specific optimization, making each part of the application work more efficiently. Many of these optimizations are not possible when the entire application is supported on the same server due to conflicting needs of different parts of the application.
One common place where this occurs is the IIS and ASP.NET threading configuration, which significantly affects concurrency and indirectly affects memory usage, latency, and throughput for many applications. The IIS static file workload is highly asynchronous and requires a high concurrent request limit, but it thrives on a very low number of available threads. On the other hand, many of the ASP.NET features are synchronous and long-blocking and require a high thread count, while still others require a lower concurrency limit to reduce the impact on memory. By separating the static workload and breaking out parts of the request-processing pipeline into a separate process or server, you can optimize the concurrency of each individual workload.
Finally, specialization can enable greater overall scalability by allowing the application to scale out discrete workloads or application parts independent of one another. This can enable the application topology to deliver increased capacity and redundancy where it is most needed, rather than requiring you to apply the same template to the entire application. In this model, the specialized resources may be physical servers, virtual servers, or even application pools on the same machine.
When evaluating the potential benefits of specialization in your application topology, start by finding the processing or resource-intensive bottlenecks in your application. These areas should be the first candidates for specialization because they may provide a significant potential for optimization when isolated, and because they will demand the highest horizontal scale-out. Then, evaluate whether isolating them enables the rest of the application to utilize resources more effectively. Finally, you will need to evaluate the overhead from the connectivity mechanism needed to bring the isolated application components together.

Improved Application Support
IIS 7.0 comes with extended support for application frameworks through FastCGI, an open protocol that is supported by many open-source application frameworks that otherwise may not support stable and high-performance native integration with IIS. Unlike the CGI (Common Gateway Interface) protocol, which has been supported by IIS for a long time, FastCGI provides much improved performance on the Windows platform. This is primarily due to the FastCGI reusable process architecture, which eliminates the heavy per-request process creation overhead, enabling clients to take advantage of persistent keep-alive connections.
If you are supporting application frameworks on IIS using CGI or another mechanism, you might achieve improved performance (and in some cases, stability) by moving to the FastCGI protocol.
The first application framework to take advantage of this support is PHP. In fact, the IIS team has worked directly with Zend Technologies to make sure that the IIS FastCGI implementation works well with PHP and enables performance improvements in the PHP framework on Windows. (For more on the project, see the posting on my blog at go.microsoft.com/fwlink/?LinkId=122509.) If you have a mix of Web server technologies that include ASP or ASP.NET applications running on IIS, and PHP or other FastCGI-compliant application frameworks using other technologies, you may be able to consolidate these apps on the IIS 7.0 platform.
Moving PHP and other application frameworks to IIS 7.0 and FastCGI will allow you to take advantage of various IIS 7.0 features, including the ASP.NET Integrated pipeline. This provides a very convenient option for enhancing application frameworks with ASP.NET services without converting them to ASP.NET. And this also enables applications using different frameworks to collaborate. For an example of how this can be used to enhance existing apps with functionality and improve performance without changing any code, see my MSDN® Magazine article "Enhance Your Apps with the Integrated ASP.NET Pipeline" (available at msdn.microsoft.com/magazine/cc135973.aspx).

Increase Application Density
IIS 7.0 includes many enhancements intended to increase the density of apps that can be hosted on a single server. These enhancements are part of many features that IIS 7.0 delivers to improve the quality of shared hosting, which include improved site provisioning and better application isolation.
From a performance perspective, the improvements focus mainly on two aspects of increasing application density—increasing the number of applications that can be provisioned on an IIS 7.0 server and increasing the number of applications that can be active at any given time.
Note that IIS 7.0 makes it possible to provision a larger number of applications on each server than previously possible—in some internal tests, up to 100,000 sites on a single server was possible. This draws on the ability to create and configure a large number of sites and applications.
A word of caution: in order to achieve high-speed provisioning, you need to move to the new configuration APIs, as older configuration APIs cannot achieve it. Additionally, not all IIS configuration APIs provide the same performance characteristics, so a careful choice is required to ensure high performance. When in doubt, go for configuration options that leverage the new IIS configuration objects directly, including the Microsoft.Web.Administration namespace, AppCmd.exe command line tool, and the IIS COM configuration objects accessed from script, .NET, or C++ code.
The difference between how many sites can be provisioned and how many can be active is a very important distinction in the IIS architecture, which uses persistent applications and worker processes to perform request processing. In this model, active applications consume more resources on the server, but also provide better sustained performance due to caching and removed initialization costs.
Because each active application requires a certain amount of memory and a separate worker process (if the recommended application isolation model is being used), the number of active applications depends heavily on the application memory footprint. Therefore, while a single application that only serves static content may require only 3MB for its worker process (and can even share the same worker process with other static content applications), some dynamic applications may require 100MB or more of RAM even under low usage. This makes the memory overhead of the IIS worker process itself insignificant when compared to the application's footprint when defining the maximum possible density.
In the typical shared hosting scenario, it is common to see what is called an 80/20 distribution, where 80 percent of requests go to 20 percent of sites. This results in a small percentage of sites being active at any given time. To allow a higher number of active sites, IIS 7.0 provides active lifetime management. This can help you to reclaim memory from inactive applications in order to allow more active applications to be hosted.
IIS 7.0 introduces a new algorithm called dynamic idle, which proactively adjusts the idle timeouts of worker processes based on memory available on the server. As memory becomes low, idle applications are removed more rapidly, thereby allowing more active applications to be hosted. However, if the memory is available, the timeouts can remain large to provide better performance and maintain application state. In addition to allowing more applications to be active, dynamic idle also helps avoid low memory conditions that cause severe performance degradation due to thrashing.
To make hosting of many active applications possible, you should also take advantage of a 64-bit operating system, as this will allow the OS to address more than 4GB of memory. On top of this, you can configure the IIS worker processes to run in 32-bit mode (SysWoW64), where they consume less memory themselves while allowing the OS to address more memory than what's possible in a 32-bit environment.

Bandwidth Reduction from Compression
It comes as no surprise that bandwidth costs are one of the top costs of running an Internet-facing datacenter. In addition, the bandwidth required to deliver requested content is a key factor in the perceived responsiveness of your application.
One of the most effective ways to reduce the bandwidth needed to deliver the application responses is to use HTTP compression. This can reduce the size of the response by a substantial amount, often by a factor of 10 when applied to easily compressible text content such as HTML. The best part is that virtually all desktop browsers support it, and decompression costs on desktop hardware are minor compared to the latency savings from sending less data. And since compression is based on Content-Encoding negotiation defined in the HTTP 1.1 protocol, enabling it is safe for clients that do not support compression—these clients simply receive an uncompressed version of the content.
IIS 7.0 provides the two compression features introduced by its predecessor: static compression and dynamic compression. Static compression pre-compresses static content and saves it on disk, thereby allowing future requests to serve compressed content directly without compression overhead. Dynamic compression compresses the response in real time, and therefore enables compression for responses generated by applications. Any application framework on IIS 7.0 can take advantage of dynamic compression—including ASP, ASP.NET, or PHP.
Despite a common myth, dynamic compression usually does not have a prohibitive CPU overhead. In fact, dynamic compression often causes less than 5 percent of the total CPU utilization on a busy server. Dynamic compression can be deployed somewhat liberally to allow for maximum bandwidth savings for any application workloads.
You can further optimize compression overhead by configuring the compression strength in order to achieve the desired compression versus CPU overhead ratio. But it doesn't stop there—you can also configure your application to enable the caching of compressed content, which eliminates the compression overhead on cache hits by serving already-compressed content. Note that both ASP.NET and IIS Output caches have been upgraded with the optional capability to cache compressed content for clients that support it, as well as handle requests from clients that require uncompressed content.

Media Bit Rate Throttling
With increasing numbers of sites offering media content, the bandwidth costs for many businesses are skyrocketing. What's worse, a large percentage of media bandwidth is wasted because the media content sent to the client is never really used. Why does this happen?
Think about the last time you watched an online video or saw a video ad when browsing. Did you watch the video to the very end? It is common for users browsing video sites to watch only part of a video before moving on to the next video or leaving the page. However, a Web server using progressive download to deliver the video will typically send significantly more data than is required for those few seconds of playtime. Most of that data never gets used.
If your videos on average only get 5 seconds of viewing time but deliver (buffer) 30 seconds worth of video data in those 5 seconds, you are potentially wasting more than 80 percent of your bandwidth!
A year ago, to solve this problem for a customer adopting a beta release of IIS 7.0, I wrote a bandwidth throttling module that automatically detected the video bit rate and made sure that the server delivered the video to the client at roughly the same rate. The IIS media team picked up this module, which is known as the Bit Rate Throttling Module (see Figure 4) and is available at the iis.net download center (iis.net/downloads/?tabid=34&g=6&i=1640). You can learn more about it on Scott Guthrie's blog (available at go.microsoft.com/fwlink/?LinkId=122514).
Figure 4 Bit rate throttling minimizes bandwidth usage
The Bit Rate Throttling Module automatically detects the encoding rate of the most popular video types. You can control how much data you would like to pre-send to the client in order to eliminate initial buffering delays (fast start) and at what percentage of the encoded rate you would like to deliver the content. You can also configure many other options, such as maximum bandwidth and concurrent connections, and control the module programmatically.

Output Caching
Generally speaking, caching is the number-one way to improve the performance of applications that execute repeated work. Unlike application-specific performance improvements, which often require a lot of effort and chew away at the processing overhead of an app, caching eliminates the overhead of repeat requests for the same content.
Prior to IIS 7.0, both IIS and ASP.NET have offered caching capabilities in the form of the IIS kernel cache and the ASP.NET Output Cache. The IIS kernel cache provided maximum performance, but was restricted primarily to static content. The ASP.NET Output Cache was a far more complete solution for caching dynamic content, albeit with slower performance and less efficient memory management. The new Output Cache in IIS 7.0 bridges the gap between the IIS kernel cache and the ASP.NET Output Cache.
The IIS 7.0 Output Cache enables caching of dynamic content from any application, including ASP, ASP.NET, PHP, and any other IIS 7.0-compatible application framework. By providing basic support for content variability and expiration, this new feature makes it possible to implement caching for content that cannot be cached by the IIS kernel cache. Still, it enables the use of the kernel cache for content that does meet the restrictions.
Additionally, the IIS 7.0 Output Cache also provides a higher performance alternative to the ASP.NET Output Cache for ASP.NET content that does not require the advanced caching features (such as cache dependencies or invalidation) that are only available in the ASP.NET Output Cache.
When it comes to output caching, the challenges normally lie in defining the proper content expiration, invalidation, and variability policies that allow efficient response caching while maintaining the required cache correctness and freshness. Much of the time, you can do this simply by configuring the proper caching rules, though some situations require more complex policies that depend on runtime information. To handle this, the IIS 7.0 Output Cache provides programmatic APIs that can be used to ensure the required caching behavior. This unlocks the caching performance potential for content that otherwise would not benefit from caching. In addition, the ASP.NET Integrated Pipeline enables the use of the ASP.NET Output Cache for non-ASP.NET content.
Deploying output caching for dynamic content can be tricky and may require a multitier strategy for capitalizing on the efficiencies and flexibility of the different caching features on the IIS 7.0 platform. This often includes describing multiple parameters that affect the response and defining both expiration and invalidation strategies to maintain the freshness of the cache, and then determining which cache will support the required semantics.
But this complexity is almost always worthwhile. By implementing IIS 7.0 Output Cache, you can achieve improvements of up to several orders of magnitude in overall throughput of your application and a matching reduction of load on your database and business tier components.

Converting ISAPI Code to IIS 7.0 Modules
IIS 7.0 introduces a new server API on which all of the IIS 7.0 modules are based. This replaces the legacy ISAPI Filter and ISAPI Extension APIs used in previous versions of IIS. For new modules that do not need to support previous versions, the new APIs are easier to use, help produce more reliable server-side code, and are much more powerful.
However, IIS 7.0 provides an option to support existing ISAPI filters and extensions through a compatibility layer implemented through optional IIS 7.0 modules. This allows existing ISAPI components to function on IIS 7.0 without requiring a rewrite.
Although using existing ISAPI investments lowers the bar to IIS 7.0 migration, you should strongly consider porting the legacy ISAPI code to the new IIS 7.0 APIs. Doing so eliminates the overhead of the ISAPI compatibility layer and unlocks performance benefits that are not available for ISAPI components. Depending on the work being performed by the ISAPI component, these performance benefits can be fairly significant. For example, the IIS 7.0 module API provides built-in support for caching configuration metadata and other arbitrary data associated with sites, applications, and URLs, which can significantly speed up internal operations of the component.
Additionally, the IIS module API allows modules to perform long-running operations asynchronously, such as receiving request entity data or sending response. Performing these tasks asynchronously allows the server to scale to a very large number of concurrent clients (tens of thousands), instead of maxing out at tens or, at most, a few hundred concurrent clients due to limits on the number of request threads. Asynchronous processing can also eliminate the effect of processing on other requests and activities in the application, reduce memory usage, and enable much better CPU utilization.
On top of the specific performance-affecting patterns, the native API gives developers greater flexibility for request-processing tasks. This will let you improve the design of the server component and, in turn, enable large efficiencies. For example, certain filtering tasks that previously required wildcard ISAPI extensions and child request execution can now be performed in a module during the original request, and can also enable IIS kernel caching for the response.
This may require some prototyping and experimentation to determine the optimal design that maximizes the benefits of the migration. Due to the fundamental architecture differences between ISAPI and the IIS 7.0 module API, the direct porting route is not necessarily the right one. The good news is that the IIS 7.0 module API is also more straightforward to use than the ISAPI, which makes migration less difficult.

Server Extensibility
IIS 7.0 offers end-to-end extensibility. It requires a good deal of up-front knowledge about the server operation, but it also unlocks tremendous potential for application-specific performance gains. Armed with some understanding of the server architecture and request processing, you can take advantage of this extensibility to design custom performance solutions tailored to your application, workload, and hardware requirements.
This can come in the form of replacing any of the built-in IIS 7.0 features with custom implementations. While IIS 7.0 features have undergone a lot of optimization and performance testing, they, of course, have not been optimized for every possible use. Therefore, you may be able to improve the performance of specific modules by building in optimizations for your specific workload. For example, you may decide to re-implement the directory listing module to cache directory listings in memory instead of using file system APIs to enumerate files.
Alternatively, extensibility can be used to build new performance features. The built-in examples of such features include the Output Cache, the compression modules, and several other internal caches.
In order to determine the need for a custom performance feature, you need to understand the performance characteristics of your application and its workload as well as know the bottleneck you need to address. IIS 7.0 provides ample diagnostic support for performance analysis, which can make the requirements and possible design of the features you need more clear.

Wrapping Up
While the IIS 7.0 release is primarily a functional release, it offers noteworthy performance improvements derived from its modular architecture, configurability, and new performance features. These improvements can pave the way to significant business savings through server consolidation and reduced bandwidth costs, as well as provide a better user experience.
To properly leverage many of these improvements, it is often necessary to perform a thorough analysis of your current application platform and gain a fair amount of understanding of the IIS 7.0 architecture. To learn more about the IIS 7.0 architecture and features mentioned in this article, please visit iis.net. At mvolo.com, I will be blogging more about techniques that proactively leverage IIS 7.0 to improve application performance and reduce operating costs.
Mike Volodarsky is a former Program Manager on the IIS team at Microsoft. Over the past five years, he has driven the design and development of core features for ASP.NET 2.0 and IIS 7.0. Now he builds advanced Web server technologies for high-performance Web farms using IIS 7.0 and Windows Server 2008. Mike is the lead author of the book IIS 7.0 Resource Kit and writes actively for MSDN Magazine and his IIS 7.0 blog, mvolo.com.


Mobility
Take Your Line of Business Applications Mobile
Matt Fontaine
At a Glance:
  • Business need for mobile LOB apps
  • Robust platform for mLOB development and deployment
  • Over-the-air security, management, and provisioning

Contents
Enabling and Managing Remote Workers
Security and Device Management
Interoperability
IT and User Productivity
Development and Distribution
The Bottom Line
Beyond traditional voice, messaging, and productivity functions, many businesses today want mobile professionals to have access to the same line of business (LOB) systems they use in
the office through mobile LOB (mLOB) applications. Candidate systems typically include customer relationship management (CRM), enterprise resource planning (ERP), business intelligence (BI), finance, and accounting applications. Obviously, having mLOB functionality enables mobile users to access and use rich business applications and interact with data on the go in real time, thereby reducing time to sale, improving customer satisfaction, and increasing business productivity. Some typical business scenarios could include:
  • Sales teams can use Microsoft Dynamics™ CRM Mobile to view and update customer data from anywhere. Another mLOB application could give them access to real-time price and inventory data. Furthermore, salespeople could use specialized devices to collect sales documentation in the field, from filling out orders to collecting signatures. In fact, there are even point-of-sale applications for Windows Mobile® devices that can scan bar codes and read credit cards and then connect to back-end LOB data systems for processing.
  • Field service workers can be scheduled using ERP solutions that route personnel based on their appointments and location, and can be automatically tracked using GPS-enabled Windows Mobile devices. Field service employees pick up only the first job of the day; as they complete a job, they are automatically dispatched to the next one (see Figure 1).
  • In manufacturing organizations, Windows Mobile devices with Radio Frequency Identification (RFID) scanning capability can be used for inventory management in an RFID-enabled warehouse, instantly and wirelessly populating information to a database. Moreover, there are Windows Mobile devices that are ruggedized or designated "intrinsically safe" for hazardous working environments in order to deliver data where it is needed while meeting important safety requirements.
  • Mobile executives who go from customer meetings to board meetings to press events in a single day—perhaps far from the home office—can get financials, expense reports, or customer information wherever they happen to be.
These and many other business scenarios are driving leading-edge companies to adopt mLOB applications. This article will show you how Windows Mobile and Mobile Device Manager work together, thereby empowering IT pros to deploy the rich mobile functionality increasingly demanded by today's businesses.
Figure 1 An mLOB application showing a completed field service job

Enabling and Managing Remote Workers
Windows Mobile has proven to be a powerful platform for enabling remote workers in diverse industries because it works well with existing Windows®-based IT assets, its mobile messaging and unified communications (UC) are provided by Exchange Server and Office Communications Server, and both users and IT pros alike enjoy a familiar Windows experience that requires less training to use and understand.
With the release of Mobile Device Manager, Windows Mobile has become an even more compelling choice for mobile device deployment in business settings. Mobile Device Manager enables mobile devices to be provisioned, managed, and secured over the air using Active Directory® and Group Policy, just as if the devices were networked PCs or file shares. Policies and software can be pushed to phones automatically, and security, software, and hardware policies can be managed in a highly granular fashion with rich inventory-reporting capabilities.
The impetus behind these innovations is the notion that mobile devices should be natural extensions of IT systems rather than existing in their own middleware bubble. For companies wanting to move significantly beyond messaging, communications, and basic productivity on Windows Mobile devices, making mobile devices first-class citizens on the network is critical.
So, what if you are in one of the organizations that wants to go beyond the basics? Let's look at how the features of Windows Mobile and Mobile Device Manager make this possible by providing a great platform for mLOB applications.

Security and Device Management
The very capabilities that make mLOB applications attractive—that they provide anywhere, anytime access to business-critical information about customers, finances, inventory, and so on—also make security more challenging. Users input and access that information from small devices over public networks in a variety of locations.
Many companies already enable mobile access to LOB applications as well as to other shared resources and tools on the intranet through laptops with Virtual Private Network (VPN) connections. Mobile Device Manager extends this functionality to Windows Mobile devices with Mobile VPN (see Figure 2). The Mobile Device Manager Gateway Server enables an IPsec-encrypted tunnel between the Windows Mobile client and the network, providing secured access to information behind the corporate firewall over public connections such as the Internet or wireless packet data networks. Windows Mobile supports multiple types of encryption in this setting.
Figure 2 Advanced device management, security, and Mobile VPN with Mobile Device Manager

Interoperability
Encryption policies can be set and enforced for data on devices and storage cards. Workers using mLOB applications might download confidential information to their mobile devices, which are much easier to misplace than other network devices. Happily, remote device wipe can be performed on any Mobile VPN-enabled device with a data connection (see Figure 3). If a pharmaceutical salesperson, for example, downloads customer files from her company's CRM system onto her mobile device and then inadvertently leaves the device in a cab, serious consequences could result.
Figure 3 If a mobile device is lost or stolen, the information on it can be removed remotely.
Mobile Device Manager is designed to deal with such issues. In fact, Mobile Device Manager lets you manage almost every aspect of Windows Mobile device functionality and user policy, from disabling specific hardware features to controlling which applications can be installed to limiting access to certain network resources. All of this can be done from one solution, and all of it can be done over the air. When users have mLOB capabilities, these features become even more important. For example, you may want to prevent users from using Bluetooth networking, which could allow the downloading of data to uncontrolled devices. You may want only certain users to be able to install the mobile accounting software client, so you could set it to upload and install automatically to only those users who need it.
Additional Resources
  • Microsoft System Center Mobile Device Manager 2008
  • Introducing Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008: A Technical White Paper
  • Microsoft System Center Mobile Device Manager 2008 An Introduction for Business Audiences
  • Windows Mobile Line of Business Solution Accelerator 2008
Furthermore, Mobile Device Manager does not require corporate data to pass through a third-party Network Operations Center (NOC) that could represent another possible availability or security breakpoint. Essentially, Mobile Device Manager gives you complete control over mobile device deployments of almost any scale—control that makes it easy to deploy, manage, and secure mLOB functionality.
The network integration yields another advantage: all of the highly granular control is accomplished by means of Active Directory and Group Policy, without the need to manage mobile devices separately from other network clients. This saves money and time. Most important, however, it lets you employ consistent security and access policies. Group Policy is a highly efficient way to control mobile access to LOB data. Those who need access can be provided with it easily; those who don't can be restricted en masse or individually.
Another major consideration in managing mLOB deployments—and mobile devices in general—is interoperability with existing infrastructure. Unlike Windows Mobile, some mobile device operating systems are disconnected from other forms of IT, requiring their own languages, servers, and tools. These factors become increasingly important when you're providing complex applications and critical data access on mobile devices.
Windows Mobile and Mobile Device Manager supply that interoperability. As a Windows OS, Windows Mobile works well with other Windows-based IT assets, such as Microsoft® Exchange Server, Microsoft Forefront™, SQL Server®, and Microsoft Office Communications Server. This intra-family interoperability makes it easier to design and build cutting-edge mLOB functionality.
For example, Windows Communication Foundation (WCF), the Microsoft .NET Framework technology for enabling inter-application communication, can enable Exchange Server to be used as a message-passing utility for mLOB implementations using a service-oriented architecture (SOA). Occasionally connected workers can be kept current using a new Sync Framework that makes it easy to synchronize data between Windows Mobile devices using the SQL Server Compact 3.5 and corporate data on SQL Server 2008. These scenarios might be more difficult to implement without a mobile infrastructure that works with so many out-of-the-box network resources.

IT and User Productivity
Increasing productivity is an important goal of mLOB deployments. But if the capabilities are difficult for workers to use and for IT pros to manage, the costs may outweigh the benefits or at least reduce the return on investment (ROI). A goal of Windows Mobile development is to make it as similar as possible to the desktop Windows experience; the resulting familiarity can increase the value of the solution for all involved.
On the IT side, Windows Mobile—using Mobile Device Manager—is designed to bring Windows Mobile devices into the mainstream of the network. It does so by using familiar technology, especially Active Directory and Windows Server®. Mobile Device Manager is part of the System Center family of IT management solutions, used by a large number of IT pros around the world. Instead of having to learn an entirely new set of tools and practices, IT pros familiar with a Windows-based environment can use the Microsoft Management Console snap-ins they already know.
The same is true for users. The desktop-like experience of using Windows Mobile helps them get up to speed quickly. They can use the Office Mobile suite, including Office Mobile Outlook®, to get work done without learning new applications. They don't have to worry about device management because it's taken care of centrally. mLOB applications can be designed to work in ways familiar to users of the desktop versions of the same programs; new tools can be built to look and behave like typical Windows software. This user familiarity can result in fewer support calls and lower incident severity—a boon for IT pros as well.
Other aspects of the Windows Mobile and Mobile Device Manager platform also enhance productivity. Mobile VPN provides seamless and persistent connectivity even across networks, in addition to fast reconnect functionality, helping users connect when they need to and reducing another common source of help desk calls. The multiple device form factors supported by Windows Mobile enable companies to standardize on a small number of devices while still giving employees the ability to choose devices that meet their needs. Device diversity also allows for productivity-enhancing mLOB scenarios like bar code-based inventory management or routing with GPS-enabled devices.

Development and Distribution
The attributes that define LOB applications—data richness, power, and specialized functionality—tend to work best on a mobile platform that is designed for application-based productivity. Windows Mobile provides a desktop-like experience for mobile workers, making it easier to develop, distribute, and manage mLOB applications.
To begin with, Windows Mobile supports a version of .NET called the .NET Compact Framework. Since the .NET Framework is a programming toolset used by millions of developers worldwide, many IT operations already have the development skills in-house to customize and create mLOB applications for Windows Mobile. If they don't, those skills are readily available in the marketplace.
Windows Mobile also supports a large number of commercially available mLOB applications. Microsoft offers mLOB solutions as part of its Microsoft Dynamics product family, including Microsoft Dynamics CRM Mobile and Microsoft Dynamics AX Mobile Sales. Also, Microsoft Dynamics Mobile Development Tools provide developers with technologies for extending the software to the mobile environment. Microsoft has made a commitment to take other Microsoft Dynamics solutions mobile, with Microsoft Dynamics NAV support coming soon. And most major LOB solutions, such as SAP, Siebel, PeopleSoft, and SalesForce.com, provide Windows Mobile-compatible versions of their application suites.
Once they have been purchased or developed, mLOB applications can be deployed and managed over the air using Mobile Device Manager and Windows Server Update Services 3.0. Group Policy can be used to set which devices receive the application and what functions they can access. Note that application updates can be performed in the same easy manner.

The Bottom Line
A growing number of companies are providing mLOB applications to employees and executives, adding new considerations for those tasked with deploying and maintaining IT systems. Windows Mobile and Mobile Device Manager deliver on the vision of network-ready mobile devices, providing an easy-to-manage platform for mLOB development and deployment. It is a platform that maximizes security and user productivity while minimizing IT department headaches and infrastructure investment. And because Mobile Device Manager lets you scale mLOB deployments to a larger number of users, the cost of mLOB development and deployment per user is decreased while ROI per user is increased. Thus, the ease of managing Windows Mobile with Mobile Device Manager frees you to think creatively about how mLOB applications can be used most effectively—instead of how to get them working in the first place.

Matt Fontaine is a writer and consultant based in Seattle, Wash. He attends to a wide array of industries including high-performance computing, enterprise software, actuary, commercial real estate, engineering, construction, and consumer packaged goods. Matt is a proud alumnus of The Evergreen State College.


Security
Understanding Shared Account Password Management
Chris Stoneff
At a Glance:
  • Shared and privileged account password risks
  • How passwords are stored
  • Managing and securingshared passwords
  • Being compliant

Contents
Understanding the Problem
The Longer, the Better
Domain Violence
Excuses, Excuses, Excuses
What the Regulators Want
An Automated Approach
Think about It
One of the common things that administrators must deal with on an ever-increasing basis is the regular changing of the password for shared and privileged accounts, such as the built-in
administrator or root account, a firecall account, or perhaps even a process account. For the sake of definition, the built-in administrator or root account is the account that comes on every version of Windows®, Linux, and UNIX, and it always has the same Security Identifier (SID) or User Identifier (UID). Firecall accounts are those other accounts you create to help facilitate emergency access to a secure system. These firecall or administrator accounts are sometimes used by otherwise unprivileged users to gain access to key systems when problems arise. Finally, process accounts are the accounts you use to run services, tasks, COM+ applications, and embedded items, such as scripts and other binary files that must log in.
Now, you likely deployed your systems using install scripts or images. In addition, all your workstations or servers probably have the same administrator account name and the same 8-character password that more than likely has not been changed since the systems were originally deployed. For this reason, I use the singular term "password," as opposed to "passwords."
An administrator might be compelled to change these passwords as a matter of using best practices or meeting compliance requirements, such as those mandated by Sarbanes-Oxley (SOX), Payment Card Industry (PCI), or the Health Insurance Portability and Accountability Act (HIPAA). Sometimes an administrator is motivated when an ex-administrator or technician with knowledge of these passwords leaves the company, for fear of a publicized security breach or losing the ability to process credit cards. Despite these factors, it really comes down to the administrator having to change these passwords for the simple security of the company and the data the company is required to protect.

Understanding the Problem
There are a few factors that must be understood when you are dealing with these accounts and their passwords:
  1. The older a password becomes, the less secure the password becomes.
  2. Longer passwords are, as a general rule, harder to crack.
  3. How computers authenticate doesn't change just because they belong to a domain. In every domain lies the heart of a workgroup.
"The older a password becomes, the less secure the password becomes" is a misleading statement. What it really means is that given the will to break into a computer, all you really need is time. If someone asks, "How long does it take to break a password?" I generally say that there is no definitive answer and, instead, give some clues that can help determine the answer for a given system:
  • How many people know the password?
  • Do all of those people still work for the company?
  • If some of the people who know the account's password no longer work for the company, did they leave amicably?
  • Do you deny access to boot from the floppy disc, CD or DVD drive, or network?
  • Are the users of the computers also local administrators?
  • Do all of your systems use the exact same password for their privileged accounts?
Starting at the top of this list, it's fair to say that the more people who know a secret, the more likely it is that the secret will become public knowledge. I recall working for companies where the administrators felt it was more convenient to set the shared password to the same value and tell the IT staff as well as the interns what the passwords were, rather than typing in the passwords for them as required. Of course, as time continued, the company started finding machines with various unapproved settings and regular network users able to log into these accounts.
If all of those people who know the passwords still work for the company and are otherwise happy and dutiful employees, this access risk is slightly mitigated. But you never know when you might have a malicious user to contend with. If any of those users have left the company on bad terms, you have a loose, hostile element that knows how to break into your network using an otherwise untraceable account.
If you do not deny access to booting from anything other than the hard drive, then you also permit users to boot using non-authorized images, such as Windows PE or various Linux systems that can read directly from the computer's file system and gain access to the computer's secured storage. (I should point out that many breaches do occur from internal elements. Even if all the staff members and interns are still employed by the company, this is in no way an assurance that the passwords and systems are secure.)
I've know many people who have continued to log in to a network at a previous employer just because they could. It's mildly amusing that they are merely pointing out the poor practice of not changing system passwords, but it is also frightening to consider the damage they could do if they had malicious intents.
If you allow the ability to boot from a DVD or the network, then you may not be able to audit what people are doing. That is, a Linux boot disk or network image can often gain access directly to your file system. If your systems use the same user name and password for their privileged accounts, then you are setting your systems up for a major fall. More on these items later, though.
The password age and length are relevant depending on the method being used to crack a password. If you are dealing with a brute force method to determine passwords, then time is really what you are up against. The less frequently a password changes, the longer the window of time is for a cracker to obtain the password.
Similarly, longer passwords have exponentially more character variations and therefore require more time to crack. So it is important to consider whether your passwords are fewer than 7 characters, 8 to 14 characters, or 15 or more characters in length. And if the passwords are fewer than 15 characters and you are using Windows, do you disable LAN Manager (LM) hashes as part of the system configuration or by Group Policy?
How does the length of the password affect anything? In the case of Windows, the answer is simple. Omitting the history of Microsoft hashing processes, Microsoft implements two types of hashes for passwords, LM hashes and Message Digest 4 hashes (MD4). By default, Microsoft uses LM hashes, and the values are stored for all passwords up to 14 characters unless you explicitly turn off the storage of these hashes. These passwords are broken apart into two 7-character values—the first value for the first 7 characters and the second value for the second 7 characters, as shown in Figure 1.
Figure 1 Sample hash table
Account Name | RID | LM Hash | NT Hash | Password | Notes
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | 31d6cfe0d16ae931: b73c59d7e0c089c0 | Blank PW | The LM hash is identical to the 20-character password LM hash.
Administrator | 500 | 0182bd0bd4444bf8: aad3b435b51404ee | 328727b81ca05805: a68ef26acb252039 | 7 Char PW = 1234567 | The first portion representing the first 7 characters is identical to the 8-character password.
Administrator | 500 | 0182bd0bd4444bf8: 36077a718ccdf409 | 0182bd0bd4444bf8: 36077a718ccdf409 | 8 Char PW = 12345678 | The first portion representing the first 7 characters is identical to the 8-character password, but the second set is different.
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | b79d07c2ecb3d565: 033ece663f5a0b2e | 20 Char PW = 9876543210 9876543210 | The LM hash is identical to the blank password because an LM hash cannot be created with passwords longer than 14 characters.
Fred | 1221 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical | In these three examples, see how the LM and NT hashes are identical? This means all passwords are identical for all of these accounts. Microsoft does not ever vary the hashing algorithm.
Monday | 1385 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical
SvcAcctX | 1314 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical
Thus, if your password is only 7 characters long, it would be contained in a single LM hash. For years Microsoft has recommended using at least 8 characters in your passwords. The reason for this was that the 8th character would then mandate that the password be divided into two LM hash values.
It is important to note, however, that LM hashes are widely understood and very easy to circumvent. The only purpose for them in current solutions is to help maintain backward compatibility with down-level systems, such as Windows NT® 4.0.
Nowadays you should be using passwords (passphrases, really) that are at least 15 characters or, preferably, longer because by definition they will not generate an LM hash. If mandating the use of 15-character passwords is not a viable option in your environment, you should disable the storage of LM hashes in both the image creation process (by using local policy) and in your Active Directory® Group Policy.
This policy can be found at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Simply set the policy "Network security: Do not store LAN Manager hash value on next password change" to ENABLED.
It is important to remember that although good policy will dictate the use of uppercase and lowercase letters, as well as numeric or special characters, a better policy will also dictate a length of 15 characters or more.

The Longer, the Better
One current method used to break into computers is called Rainbow Tables, and it uses LM hashes as the exploit. But longer passwords can negate the effectiveness of Rainbow Tables.
I am amazed at how many administrators who wear the security cap seem to know very little (or nothing) about Rainbow Tables. There are various ways to create Rainbow Tables to deal with different algorithms. But these are merely a pre-computed list of all LM hashes from 0-14 characters.
The caveat of Rainbow Tables is that the attacker must obtain the LM hashes in the first place. This leads to the previous questions about how the system can be booted (to the CD or DVD) or whether or not your users are local administrators. Ultimately, these LM hashes can be extracted in a few seconds using free tools, such as pwdump. With the use of Rainbow Tables, the hashes are then searched for to determine the password.
To satisfy my own curiosity, I set a password on a system's built-in administrator account. It was 14 characters and contained various uppercase and lowercase letters as well as special characters and numbers. I then used Rainbow Tables that I downloaded for free from the Internet, and I was able to extract the password hashes for all the accounts on my system and determine the administrator's password in less than two minutes.
I must admit, it is pretty cool to watch the first LM hash being defeated, followed by the second hash, and then when you put them together you've got your password. To reiterate the point, if I had disabled my LM hashes using the policy I discussed previously, this particular attack vector would be severely limited, if not entirely blocked.

Domain Violence
Being in a domain doesn't fix the problem. Computers in a domain still authenticate in the same way. And, as I said before, in every domain lies the heart of a workgroup. This simple statement is not always obvious. I have had many conversations about this subject, and I find myself frequently reminding administrators what it takes to access a machine—a user name and a password. Then I must dive into a discussion of how Windows functions in a workgroup.
If you attempt to access a system, you will need to provide a user name and a password to the remote system. Through the use of integrated authentication, Windows will attempt to do this for you. This means that if you access another Windows system, Windows will use your currently logged in user name and password. So if you attempt to access another Windows system, you will never be prompted for that user name and password if the remote system has the same user name and password.
This is also referred to as pass-through authentication. The process works in workgroups as well as cross-domain. In the worst case, the system will ask you for a user name and a password, which means you simply have to retype your logon information.
Now even if you join a workstation or a server to a domain and Active Directory becomes your central account repository, all of the local Security Account Managers (SAMs) or local account stores on those systems don't just magically disappear. The only thing that seems to happen to those local SAMs is that they are no longer managed and secured, and herein lies the root of the problem. When was the last time you changed the built-in admin or root account on your systems? Better yet, download any reporting utility that can show you what the password age is for all your accounts and see if the results would pass an audit.
If you are still not sure what I mean, take any one of your domain workstations and logon as a domain account with administrator privileges. Open up computer management on your system and create a local user named ToldYouSo. Give the account a password and add it to the local administrators group of your system. Repeat this process on a second domain system.
Now, from either of those systems, log on as the local ToldYouSo account and attempt to access the second machine by going to \\systemName\c$. You will be able to access the administrative share, and you won't even be prompted for a password! I hope this example is not a surprise for you. But if it is, then please learn from this and allow me to reiterate: just because your system belongs to a domain does not change the fact that all of these systems still function as though they belong to a workgroup.
The point is that if you use passwords for your shared and privileged accounts that rarely, if ever, change, your shared and privileged accounts are at risk. All it will take to compromise your entire network is time.

Excuses, Excuses, Excuses
When I talk with administrators and even CIOs, I frequently hear the same top reasons for not changing these account passwords:
  • We have thousands of systems and not enough time or manpower to change these accounts.
  • We don't have the necessary budget.
  • We have completely disabled our administrator accounts.
  • We haven't been compromised yet, so we don't really think it's a problem.
  • The auditors didn't notice.
While I can empathize with the first two reasons, these are not valid excuses. I shudder to think that I may have personal information stored with companies that do not address this issue for any reason.
While it is true that not every system in your network has sensitive information stored on it, the users of these computers do potentially have access to sensitive information, such as your Social Security number, medical records, or financial data. As an admin of a system, a user can install key loggers and screen capture utilities, stop Group Policy from applying, introduce shims into various subsystems to capture and transmit data, and so on. And when the user is doing this at the individual computer level, your ability to catch this malicious user is made much more difficult since he is named Administrator.
Did you know that disabling the built-in administrator account in Windows does not stop your ability to logon as that account? Try this: restart your system in safe mode and logon as the built-in administrator account. You can probably use the password issued to the account from the original image and be successful. For more information on this behavior, see the Microsoft® Knowledge Base article "How to Access the Computer after You Disable the Administrator Account" (support.microsoft.com/kb/814777).

What the Regulators Want
Dealing with SOX, PCI, HIPAA, and other regulations can make your head spin. Understanding their requirements can be tricky, as they are expansive and not clearly defined. Generally, what all of these regulations are looking for can be summed up as follows.
First, you need to guarantee who has access to all privileged accounts and information at all times and provide a method for proving this. This is good behavior in all scenarios—a privileged account is an account with rights to do anything over any system. This is the built-in administrator. This is the firecall account. These are the accounts that your entire help desk staff and every administrator working for you probably knows.
When you choose to implement a solution to manage these shared account passwords, you are creating an audit trail to the built-in administrator account where one currently doesn't exist. You are gaining a password that is fluid. And since the solution is automated, you won't lose weeks of productivity time spent changing these passwords. Ultimately, since the solution provides auditing capabilities, your company will be a step closer to passing its audit.

An Automated Approach
The most effective way of dealing with accounts such as these is to regularly change the accounts so that no two accounts ever share the same password. With shared passwords, a compromise of one system would mean a compromise of the other. In other words, there should be no common local or domain accounts.
When you deal with automated solutions that can manage and randomize these passwords, avoid doing just the bare minimum of what's required by your auditors. For example, why use only 8 characters for your passwords when you can do 15 or 20, or 127, without any extra effort (see Figure 2)?
Figure 2 Use automation to create very long passwords
Also, consider randomizing your privileged accounts every day, as shown in Figure 3. There's no reason to do this only every 90 days when you can do it monthly or bi-monthly or even daily. After all, if the procedure is automated, it should not create any extra work for you. Plus, if you do this on a regular basis, you will force users to recover the passwords from the tool's audited retrieval interface, providing another audit trail where one hadn't previously existed. (If you presently store written passwords in an envelope in a safe in the back corner of someone's office, you have no audit trail for those passwords like you would if you used a password management solution.)
Figure 3 Randomize your privileged accounts every day
Finally, ensure that when passwords are recovered they can and will be re-randomized after a fixed period of time following recovery. I am not referring to the scheduled randomization jobs you created, I am talking about creating one-time-use passwords that are only valid for a matter of hours instead of a few months. Again, this method will force users to recover the passwords from the tool's audited retrieval interface, providing an audit trail.

Think about It
The issue of shared account password management must be addressed. This means you should obtain a method of reliably and regularly changing your passwords. The solution must be scalable and flexible. It must also provide secured access to the passwords, and it needs to audit every action taken by the tool as well as every action taken by every user of the tool. In addition, the passwords generated need to be unique on every system in order to avoid a break-in due to shared account information.
Many vendors have been addressing this problem for a number of years, and many more new vendors have crept into this field recently. Be sure to do your research and try out all new tools before you buy to ensure the solution you settle on is the right fit for your environment.

Chris Stoneff is a Product Manager at Lieberman Software (liebsoft.com), a security and systems management software developer. His biggest drive is not just to know how something works a certain way, but why.


Over the past few weeks, I've been fortunate enough to receive a refresher course in what it's like to be a working IT professional. As summer comes to a close and thoughts turn toward going back to school, this certainly seems appropriate. But I must admit, it was a bit of a shock just the same.
You see, the Magazine team here at Microsoft (the group responsible for publishing both MSDN Magazine and TechNet Magazine), is in the process of reviewing and enhancing our … well … process. We finally decided that, it being 2008 and all, we needed to let go of the remaining paper layouts and colored pencil markups and go completely digital. (I know, I know—we're such innovators!) Seriously, though, it was time for us to realize some of that extra efficiency those big software companies keep touting.
While adjusting to our new digital workflow, it quickly became apparent that we were being inhibited by the tool that tracked the status of articles. It was already "digital," but it was built on some pretty antiquated technology (which we hope to be ridding our world of forever) and was supplemented by little colored boxes printed at the top of each layout. High tech, huh? So I set out to build a proof-of-concept replacement, and I figured SharePoint would be perfect.
Let me skip ahead and just say that I have a newfound respect for the SharePoint administrators among you. This isn't a knock against SharePoint—if anything, it speaks to the power and flexibility of the platform—but creating a custom workflow solution in SharePoint is really hard! (Thankfully, we have our new Inside SharePoint column to help.) Getting my hands dirty with this challenge after a few years off the front lines was a clarion call for me, though—it is time for me to head into the classroom again.
There are a number of great resources out there to help you dig back into the basics, or ramp up on something new: everything from the new "How Do I?" series of videos on TechNet (technet.microsoft.com/cc138021), to the screencasts we're doing in the magazine (.com/video), to TechNet Edge (edge.technet.com), and more. But I think it's probably time to expand our "basics" coverage in TechNet Magazine itself. Not to boast, but I think we've been pretty good about providing the deep-dive technical material you've come to know and (hopefully) love. Still, I don't think it would hurt for us to re-examine the fundamentals every now and again. So enjoy what's left of your summer, because pretty soon, we're all going back to school. —Joshua Hoffman

Thanks to the following Microsoft technical experts: Nathan Bigman, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Trina Gorman, Gershon Levitz, Thomas Marquardt, Mandy Maxwell, Michael Murgolo, Sanjeev Nair, Michelle Rutzer, Jez Sadler, Jim Truher, and Shimon Yannay.


Letters Readers Speak Out

SharePoint Capacity Planning Tool
My company has fewer than 600 employees, and a large number of them do not actively use their PCs or our intranet. But there is a common outcry for corporate communication and collaboration. I think that Windows® SharePoint® Services (WSS) 3.0 would be perfect for our work environment, but my manager has only budgeted one server for this effort.
I tried to use the SharePoint Capacity Planning Tool, but it will not allow a single-server model to be simulated. Do you know of a simulation option for single server?
—Allen M.
I do not think there is an option for a single server. But it's difficult to size without considering all user behaviors. I would use a quad-core CPU and start with 8GB of RAM. Basically, a mid-range server should work fine.
Joel Oleson has compiled a large number of sizing references, and these are available for you to view on his blog at blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx. That may help you further in making the best decision to serve your company's needs.
—Pav Cherny, Columnist,
Inside SharePoint

Microsoft Bob
I know the intent of the Windows Confidential column "History Takes Up Space" (July 2008, technet.microsoft.com/magazine/cc565089) was to reveal that the Microsoft® Bob program was hidden on the Windows XP disk, but it is yet another slam at a program that my kids loved and used to learn basic computer word processing. Bob came with our first home computer, an NEC Ready with Window 95. And as they grew up, each of my children played with and used Bob for hours.
Bob was ridiculed as a bad technology product in the column, but it was actually great software that was simply presented to the wrong market . . . adults. It was geared for children, and had it been presented that way it would have been regarded in a different light and perhaps even had a different fate. Who knows, if presented as a kid's program from the get-go, it might still be around for my grandchildren to enjoy.
—Jim S.

Print Is Dead
It was very interesting for me to read your July 2008 Editor's Note, "Print Is Dead" (at technet.microsoft.com/magazine/cc595615). In my opinion, printed specialist books about information technology will soon be dead and substituted by digital media. But according to you, 90 percent of your readers surveyed prefer the printed media. Was this survey representative? Or did only those people whom you reached by printed media answer the survey? This group would not include the younger generation, who no longer subscribe to newspapers or magazines like yours but get all their information online and never heard about your survey.
A reader of printed text is not able to start a video or webcast out of the floating text. He is not able to click with the mouse on a printed Internet link to open a home page, newsgroup, or blog. He is not able to make a click with the mouse to download an add-in or a tool that was just mentioned in the printed text.
To sum up my point: the printed book is a bad compromise. The reader will soon realize that reading in the printed book offers only a fraction of the benefits of the DVD, and he can copy the whole content of the DVD onto his notebook and then have access to this content at any time and everywhere.
—Ulrich S.
Thanks for your note and your feedback! In response to your specific questions about the 90 percent of our readers who say they prefer print, the survey was conducted among both our print subscribers and Web readers (with an approximately equal mix of both) as part of our annual editorial research—presented electronically, not in print. The question was posed to those who said they have read both (print and online), and 90 percent of them said they prefer print.
While I completely agree with you about the benefits of publishing content online (rich media, global reach, clickable links, and so on), I still feel that reading an article on the printed page offers a more engaging experience. I feel more comfortable with—and more connected to—the content, and many others have shared similar feelings with us. That being said, the fact that each medium offers its own advantages is why we continue to publish TechNet Magazine using both. Thanks again!
—Joshua Hoffman, Editor-in-Chief


Toolbox New Products for IT Pros
Greg Steen

Monitor Your Servers
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
The more complex our infrastructures become, the more inundated with information we administrators are—with most of that information being logged into files or databases. But to make sense of all that information, you need an analytic engine and a tool to present the analyzed data in a meaningful form. One very handy tool to do this is Microsoft® SQL Server® 2005 Reporting Services. This tool can help you get all that data into an aggregate form and then present it in a human-readable format. And it can deliver the information to disparate locations automatically or on demand, effectively giving your business users the near real-time data they need to make smarter business decisions.
Planning for, deploying, and managing a successful Reporting Services infrastructure (or any new server infrastructure, for that matter) that both serves your company's needs and grows as your company grows will require preparation, know-how, and a bit of grit. If you are thinking about deploying a Reporting Services instance, Mastering SQL Server 2005 Reporting Services Infrastructure Design, by Joseph L. Jorden (Sybex, 2007) can help build your understanding and guide you through the keys to a successful operation.
The book does a good job of covering the sometimes forgotten aspects of systems implementation before delving into the technical details of a Reporting Services deployment. These rudimentary aspects involve determining why you are implementing the system and the requirements of that business use, and defining how to manage expectations of your end users. There's a chapter on strategies for change management in your reporting system. This section covers different approaches to change management and provides a template and guidelines for change management request forms. I'm not one to proclaim the advantages of bureaucracy, but a little structure here will ensure a much more stable environment.
After covering the business end of Reporting Services, the book dives into deployment, going into the basics of installation, scaling, automation, and configuration. It also offers tips on how to integrate with Microsoft Windows® SharePoint® Services (WSS). It gives you a good start on a deployment checklist to help you avoid stumbling blocks.
One of the cool new features of SQL Server 2005 Reporting Services is ad hoc reporting capabilities. This feature lets your users create reports on the fly. The book explains how to enable this feature and set up the Report Builder tool. Next the book jumps into how to create subscriptions for reports, which allow you to generate and distribute your reports on a schedule via e-mail, file share, or integrated SharePoint delivery.
All systems need maintenance over time, and the next chapter covers essential tasks such as backing up your instance, managing report content, and troubleshooting problems with the available logs. There is also a good chapter on security, which covers authentication and authorization options for your deployment.
Programmers will appreciate the chapter on extending Reporting Services as well as the chapter on accessing and manipulating reports through applications that are based on the Microsoft .NET Framework. The Report Definition Language (RDL) is one of the fundamental aspects of Reporting Services, and the book dedicates a chapter to some of the key elements available to you, the structure of an RDL file, and the basics of creating and deploying those files.
The book finishes up with a few tips and tricks for performance tuning your Reporting Services deployment. You'll find information on measuring performance, making modifications to configuration files, and using the Performance Console. There is also a nice appendix on how to integrate Reporting Services with SharePoint. If you are looking to roll out SQL Server 2005 Reporting Services in your environment, you should take a look at this book. It can really help you get off the line running.

Price: $49.99 (direct).

Audit Your Environment
Alloy Discovery Professional Edition
alloy-software.com
Being able to retrieve information quickly for a particular system in your coverage area is critical to performing your job, troubleshooting issues, and verifying that systems are up to date and in compliance with security and software policies. And having that information in a format that is friendly to the business user, and that allows for at-a-glance evaluations of your infrastructure, can be a great advantage (and, not to mention, can make you look good to management). If that isn't enough, this quick access to information can also help you isolate who is utilizing what software to ensure your users are properly licensed. One such inventory and audit tool you might want to take a look at is Alloy Discovery Professional Edition from Alloy Software.
This application is very easy to set up, and you can start the audit on a group or range of machines on your LAN very quickly. The UI groups your machines into an organized view much like that in Internet Explorer®, and once you have your group or groups of auditable machines set up, performing an audit on a group is done with a simple click. The information collected is quite extensive, ranging from hardware, software, and devices to printers, shares, and even events. You can also view asset tags, serial numbers, uptime statistics, environment variables, network configuration, and local user accounts. Basically anything you need to know about your environment you can gather without ever leaving your desk (though I do recommend taking a walk every once in a while for your personal health).
Aside from auditing machines on demand, you can also schedule audits. For machines that are outside your direct LAN and for those that you cannot remotely connect to with enough privilege to perform the audit task, Alloy Discovery provides an agent-based method of auditing target machines. This type of audit can be scripted and then scheduled to run on a periodic basis or run via the agent and then e-mailed from the agent to your main Alloy Discovery repository. Another option is to put the agent on a flash drive and walk around to the machines to initiate an audit. After the audit, you can then sync up the information automatically or manually depending on the method used with the main repository.
Alloy Discovery also has filters that you can apply to your audit results to analyze the overall inventory. For example, you can see how many machines would need a memory upgrade to support an application or which machines in your environment are running Windows® XP Professional versus Windows Vista® Business edition.
Once you have your data, you'll want to create reports. The app can publish reports to HTML pages into which you can drill down. And you can set up a scheduled task to generate these reports on an ongoing basis, a great option for your Network Operations Center. In addition, you can export all of the audit information to XML, CSV, or Microsoft Excel® to, for example, deliver proof to auditors.

Price: $795 (direct) for the base product, plus $3 for every node. ﻿
Keep tabs on your environment with Alloy Discovery

Manage Your Passwords
Password Corral
cygnusproductions.com
Passwords are a fact of life in today's interconnected world. (At least until everything is biometric-based or until we create some form of all-trusting utopia, but neither of those scenarios will be happening in the imminent future.) If you are like me, you probably have different types of passwords for different types of environments, and you vary those passwords across different mediums.
Beyond the normal mainstream uses, there are also all those system passwords for administrator accounts, service accounts, and various domain accounts. And, of course, there are different user names associated with all those different passwords. The list goes on and on. So how do you best keep track of all those passwords securely and easily?
One way is to use a password repository that locks up all the data into a strongly encrypted file, and a good solution to do this is the Password Corral. This easy-to-use and strongly encrypted application, which utilizes Diamond2 or Blowfish encryption to encrypt all your passwords into a file, has been around since 2001. It has been tried and tested over time and is still under active support and development for current and future releases.
After installing the program, you get your new password file going by creating a new user and selecting where you want the password file to be located on your system (or network drive). Now, it should go without saying that if you are going to keep all your sensitive password information for all of your accounts within a single Password Corral file, your Password Corral password should be incredibly strong and changed often. This will be the one password you will really need to remember and protect, so be smart about it.
Once you have authenticated, Password Corral provides a UI much like the one in Internet Explorer, with a hierarchical folder structure on the left and a details pane on the right. You can organize your passwords into a tree-like structure of folders. Each password can have a description, user name, password, reference URL, reference e-mail address, and comments about the account. In addition, you can tell the application what the password policy is for each account, specifying the number of days in the expiration cycle and the number of days remaining until a given password expires.
One of the view options includes filtering by expired passwords so you can see which of your accounts will require a reset on next use. Another cool feature is that you can have the program generate a password for you, saving you from having to invent your own strong passwords for every account. That password generator is customizable as well, allowing you to set it to your desired length, complexity, and character composition.
Another nice feature is that once you have entered all your passwords, you can easily search for them by any of the fields you have entered data for, which is great for finding those infrequently used accounts in a deep folder structure. You can also set a time-out on the application so that if you forget to close Password Corral, the application will lock automatically, protecting your sensitive information. The application will also default to clearing up your clipboard automatically upon exit in case you left the password you copied in your buffer after using it.
If you need constant access to your passwords, you can use the application's system tray icon option, which allows you to simply double-click to launch the application from there. If you want to use Password Corral and store your accounts elsewhere, the application also lets you import them from a file, saving you from having to do all the extra data entry. And if you choose, you can even export and print your passwords—just be sure to eat the paper when you're finished! All in all, this is a very useful free tool.

Price: Free.
Keep track of all your passwords with Password Corral

Audit File Usage
File System Auditor
scriptlogic.com
Maintaining an audit trail on shared file systems can save you a lot of headaches. More important, however, it is a necessity for meeting certain information retention policy standards. To help you find out who did what and when, you might want to check out File System Auditor from ScriptLogic. This application is a centralized management system that audits the use of files on target systems in near real time and stores the information in a SQL Server database for usage reporting.
File System Auditor supports Microsoft SQL Server Desktop Engine (MSDE), SQL Server 2000, and all versions of SQL Server 2005 (including the free SQL Server 2005 Express). Each monitored system will require an agent to be installed, which is used to monitor file usage and report back to the SQL Server. After installation, you'll use the Database Wizard to create the database repository where all the audit information will be recorded.
As a systems administrator, you are probably now thinking about bandwidth and verbosity on a heavily used system, but the application purportedly uses an intelligent auditing system that combines different actions into a single audit entry. In terms of bandwidth, File System Auditor uses only 100 bytes of data for the first access to a file and 10 bytes to 20 bytes for each access thereafter.
You may wonder why not just use native Windows auditing to do this, but the centralized administration, event coalescing, and reporting features of a dedicated monitoring app are a bit more flexible and usable. Plus, having all that information in a SQL database makes it much easier to reference from other systems.
After configuring your database, set up your Agents on the target servers via the Agent Configuration Console. You can either type in a server's name or browse for it using Active Directory®. File System Auditor also supports clustered file servers, so you can type in the name of your cluster instance. Next you install the agent service (with the click of a button if your account has remote access) and pick which Windows or SQL Server account the agent should use to connect to the File System Auditor database.
On a per-server basis, you can set up three different types of monitoring exclusions: Path Filters, Process Exclusion Filters, and User Exclusion Filters. Path Filters let you pick a path and choose whether to include or exclude certain folder and file events—such as permission changes, creation, and deletion—for either all files or files of certain types. Process Exclusions and User Exclusions let you do the same for file and folder events pertaining to a particular process on the target server, but don't support the file type filters.
After you set up and start collecting auditing events, you then launch the Report Configuration Console to put that audit data to use. To set up a report, you can set a number of filters on the data including users, certain file or folder events, paths, servers, processes, and date ranges. In addition, you can then schedule the report and have the app e-mail the published report via your SMTP server. Finally, to see what is happening to files on a system in real time, you can launch File System Auditor's Real Time Viewer to watch the raw events scroll by like "tailing" a log file.

Price: Starts around $800 (direct) for the program and one server license.
Audit file usage with File System Auditor

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


Utility Spotlight Windows Memory Diagnostic
Lance Whitney

Code download available at: Utility2008_09.exe (640 KB)

Contents
Getting Windows Memory Diagnostic
Testing Memory
One of the PCs you support is acting up—freezing, crashing, blue screening. Is some piece of hardware failing? Is some newly installed application causing trouble? Or could it be faulty memory? One way to find out for sure is with the free Microsoft® Windows® Memory Diagnostic utility. This tool will run a variety of tests on your PC's RAM to determine whether flaws exist in any of the modules.

Getting Windows Memory Diagnostic
To use Windows Memory Diagnostic, download and execute the program's single file—mtinst.exe—from oca.microsoft.com/en/windiag.asp. Note that you do not have to install Windows Memory Diagnostic. The tool presents you with two options, as shown in the screenshot:
Figure 1 Windows Memory Diagnostic options for creating bootable media
  • Create Startup Disk, from which you can create a startup floppy disk with the program.
  • Save CD Image to Disk, from which you can save an ISO image of the program to your hard drive. Then you can burn that image onto a CD and make it bootable using CD creation software. After you build your bootable media, reboot your PC and start the diagnostic from the floppy or CD.
Testing Memory
When the program loads, it immediately begins scanning your RAM. The Windows Memory Diagnostic tool starts in Standard mode, which includes 6 different, successive memory tests, each of which uses a unique algorithm to scan for different types of errors. A screen displays each individual test as it runs, listing its progress and the range of memory addresses being scanned. After those 6 tests complete, the tool runs another pass using the same tests and will continue running pass after pass until you exit the software. Typically, though, one pass should be enough to tell whether or not the memory is faulty.
For more exhaustive testing, you can switch to Extended mode, which runs 11 separate memory tests. There's also a Basic mode that runs only 2 tests, but, to be thorough, you'll want to stick with the Standard and Extended modes. If you run the extended test suite, it is suggested that you let Windows Memory Diagnostic run overnight.
After each test completes, the tool displays a Succeeded or Failed message. A Failed message is followed by details about the failure and typically indicates a fault with one of your RAM modules. Depending on your PC environment, the diagnostic may be able to narrow down a memory problem to a specific module.
In this case, an option to View errors by memory module will appear in the menu. This option can help you determine specific modules that are failing and should be replaced.
In the Advanced options screen, you can switch among Basic, Standard, and Extended mode. Here you also can turn off the processor's cache during the scans, which forces the tool to access data directly from RAM, ensuring more thorough testing. The System Information command lists the capacity and type of RAM installed in each slot.
Windows Memory Diagnostic supports x86-based platforms, including Intel Pentium and Celeron processors and AMD K6, Athlon, and Duron CPUs. However, the tool can address only up to 4GB of RAM and will not scan beyond that range.
You will also find a version of this diagnostic installed in Windows Vista® under Administrative Tools and on the Windows Vista installation media under the Repair option. The Windows Vista version does not provide as much visual feedback or as many options, however. So you will want to be sure to keep the standalone edition handy for the next time one of your PCs starts acting up.
Lance Whitney is an IT consultant, trainer, and technical writer. He has spent countless hours tweaking Windows workstations and servers. Originally a journalist, he took a blind leap into the IT world 15 years ago.


Inside SharePoint SharePoint Directory Integration
Pav Cherny

Code download available at: SharePoint2008_09.exe (2,775 KB)

Contents
SharePoint Directory Management Service
Custom Directory Management Service
SharePoint and ILM
Conclusion
Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 include directory synchronization capabilities in the form of a Directory Management Service that can provision mail-enabled contacts and group objects for SharePoint resources in Active Directory. Provisioning these types of
recipient objects for SharePoint® resources enables users to select SharePoint libraries, lists, and groups directly from the Microsoft® Outlook® address book when sending documents and other information.
SharePoint recipient objects also provide a way to control message transfer and format conversions in an Exchange Server organization. Among other things, you can prevent unauthenticated senders, such as spammers, from submitting messages to SharePoint libraries by setting message delivery restrictions in Active Directory®.
The SharePoint directory management capabilities are limited, however, and at the time of this writing, assume Exchange Server 2003 as the underlying messaging system. For now, if you use Exchange Server 2007 or a third-party messaging system, you need to extend or replace the built-in directory management features with a custom solution in order to achieve the desired level of interoperability.
In this column I briefly review the SharePoint directory management features and then discuss an approach to overcoming existing limitations. My premise is that the built-in Directory Management Service meets only the most basic user requirements. Environments with a variety of messaging systems and directory platforms need greater flexibility and functionality. By replacing the built-in component with a custom solution, you can synchronize SharePoint recipient information with any directory solution that provides an API or import capabilities.
To prove this point, I show you how to synchronize SharePoint recipient information in way that is compatible with Exchange Server 2007. Similarly, you can use a custom solution to synchronize recipient information with IBM Lotus Notes or other systems.
You also gain the ability to centralize directory provisioning processes based on a metadirectory service, such as Identity Information Server, which is included in Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1). Specifically, I show you how to integrate SharePoint with ILM 2007 to coordinate the provisioning of directory objects for SharePoint document libraries. You can find the tools, source code, and step-by-step instructions to build this solution in the companion material for this column, available in the Code Downloads section of .com.

SharePoint Directory Management Service
Unlike Exchange Server, which uses Active Directory for almost all configuration and recipient information, SharePoint relies on configuration and content databases. SharePoint must therefore propagate recipient information for mail-enabled libraries, lists, and groups from its databases to a directory. After all, messaging clients expect to find recipient information in an address book, which is typically generated from directory objects.
Out of the box, SharePoint includes a Directory Management Service for this purpose, which is part of the E-mail Integration Web service (SharepointEmailWS.asmx) that you can configure in SharePoint 3.0 Central Administration, on the Operations page, under Incoming e-mail settings. Figure 1 illustrates how the built-in Directory Management Service works.
Figure 1 SharePoint Directory Management Service architecture
When you enable a Web farm for directory management and then assign a library, list, or group an e-mail address to receive messages, such as by using EmailSettings.aspx, you implicitly call the E-mail Integration Web service to provision corresponding recipient objects in Active Directory. First, SharePoint stores the e-mail address information in the content database. Next, SharePoint sends the provisioning request on your behalf to the E-mail Integration Web service using the identity of the Web application pool account. If the provisioning request fails, you end up with e-mail address information in the content database but without corresponding recipient objects in Active Directory.
Additional Resources
  • SharePoint Products and Technologies Web Site
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services Developer Center
  • Microsoft SharePoint Products and Technologies Team Blog
Provisioning requests can fail for a number of reasons. The most common reason is missing IIS metabase access permissions. Because SharepointEmailWS.asmx is designed to be a Web service for application pool accounts, this Web service checks the IIS metabase to see if the caller is an application pool account and denies access if that's not the case, regardless of your SharePoint site and Active Directory permission levels.
SharepointEmailWS.asmx performs this access check under the identity of the caller, however, so the calling application pool account needs access to the metabase to verify its own access permissions. This forces you to grant your application pool accounts elevated permissions in order to succeed.
Of course, elevated permissions on a Web server are a source of security concerns. There are better ways to control access to an ASP.NET Web service. Moreover, SharePoint expects to find the Directory Management Service in the Central Administration site, yet this site is not permanently available in a Web farm locked down to reduce the attack surface. So if you want to use the built-in Directory Management Service in your SharePoint production environment, you must accept a weakened security configuration.
Further limitations that exist stem from the fact that the built-in Directory Management Service is based on a tightly coupled client/server architecture. Microsoft.SharePoint.dll uses System.DirectoryServices.dll directly, so you cannot implement your own logic to customize the provisioning process. For example, the built-in Directory Management Service implementation does not write all recipient attributes to support Exchange Server 2007, and there is no option to customize the attribute generation rules.
The inability to implement your own logic also implies that you cannot customize the provisioning process, for example, to implement custom approvals. SharePoint supports approval processes for groups, but this feature is based on the Central Administration site. Only SharePoint Farm Administrators can approve pending requests, yet SharePoint administrators are not necessarily in charge of approving Active Directory provisioning processes.
Perhaps even more importantly, there are no approval processes for mail-enabled document libraries and lists. If you enable directory management, you essentially grant all site administrators in your Web farm the right to create mail-enabled contacts and groups in Active Directory. Nor is it possible to structure recipient management based on organizational units (OUs), because all recipient objects per Web farm are placed in the same OU.
You cannot move the recipient objects to another OU because the Directory Management Service expects to find the recipient objects in the SharePoint OU, and you must grant the SharePoint Central Administration application pool account administrative permissions in Active Directory. Also, there is no way to implement two-way synchronization between SharePoint and Active Directory. Changing object attributes in Active Directory does not propagate the changes back into the SharePoint environment.

Custom Directory Management Service
Now that I've established that the built-in Directory Management Service leaves some room for building additional flexibility, let's discuss some alternatives. The good news is that SharePoint lets you implement your own directory management service. You need only register your Web service as a remote Directory Management Service in SharePoint 3.0 Central Administration, on the Operations page, under Incoming e-mail settings.
For detailed step-by-step instructions to deploy and register a custom Web service, see the worksheet "Directory Integration Based on a Custom Directory Management Service.xps" in the companion material. Also, my custom Web service shows how to provision Exchange Server 2007-compatible recipient objects in Active Directory without cmdlets or Exchange management tools. The corresponding source code is in the EmailIntegrationService folder. Figure 2 illustrates the solution architecture.
Figure 2 Custom Directory Management Service architecture
The interface of the custom Web service must adhere to the Directory Management Service interface, as documented in the SharePoint SDK. If you search the MSDN® Web site (msdn.microsoft.com) for "SharepointEmailWS," you can find all the required details. You can also check out the Service.cs file in the EmailIntegrationService\App_Code folder in the companion material. This file implements the required Web service interface, while the actual code to provision Active Directory objects resides in SPRecipient.cs. For example, the UpdateRecipientAttributes function in SPRecipient.cs generates the required Exchange Server 2007 attributes. SPRecipient.cs is the code file that you must replace if you want to develop your own custom directory management service.
A custom directory management service is a good tool for overcoming elevated permission requirements and integrating SharePoint with third-party directory or messaging systems. You do not have to check the IIS metabase to limit Web service access to application pool accounts. Instead, you can add an <authorization> section to your Web service's web.config file (see the companion material for an example).
Several issues remain, however, because you can't control if and when SharePoint calls your directory management service. Among other things, SharePoint does not call the Directory Management Service when you are deleting a mail-enabled document library or list, and so an invalid recipient object remains in Active Directory. Whether you use the built-in Directory Management Service or a custom solution, you cannot guarantee that the recipient information in Active Directory is consistent with the SharePoint resources.

SharePoint and ILM
To achieve reliable directory integration, you should consider deploying a professional directory management package, such as ILM. This system relies on a pull-based directory synchronization model. Management agents pull information from their connected sources, import it into a common metadirectory, and export information from the metadirectory into their connected systems. Source systems do not generally push their information into the metadirectory. By pulling information, you can ensure consistency with each synchronization cycle.
Another benefit is that ILM includes several management agents to support Active Directory, Lotus Notes, and a variety of other systems out of the box. You only need to implement a custom management agent for SharePoint in order to synchronize SharePoint information with another supported directory platform in your environment.
You must implement the logic to retrieve the desired information from SharePoint, save the information in an import file, and transfer the imported information into the metadirectory. But you don't need to implement the logic to export that information from the metadirectory into Active Directory or another directory platform. Figure 3 illustrates how to implement synchronization from SharePoint to Active Directory using ILM. It is also possible to achieve synchronization in the other direction to provision SharePoint resources for directory objects, though this might be considered unnecessary or optional.
Figure 3 Identity Lifecycle Manager-based directory integration
A good starting point for developing a SharePoint management agent is Alex Tcherniakhovski's article "Connecting ILM 2007 with SharePoint Services Lists" at blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx. Alex shows how to build an ILM-based directory management solution that relies on InfoPath®-based provisioning requests submitted to a document library. Alex's management agent retrieves all approved requests from the document library and creates corresponding metadirectory objects that can then be exported into connected directories.
But by default, SharePoint does not generate InfoPath-based provisioning requests when you mail-enable a list or group. You can achieve this through a custom directory management service, but then you'll encounter the consistency issues mentioned earlier because SharePoint does not call the directory management service under all circumstances. For this reason, I recommend that your management agent retrieves the desired SharePoint recipient information directly from the lists and groups in your site collection. If you need approval processes, you can then generate InfoPath-based provisioning requests for new resources in the management agent and subsequently process all approved requests.
You have several options to retrieve SharePoint information. You can read the information directly from the content databases, use the SharePoint object model, or take advantage of SharePoint Web services.
Accessing content databases directly is not recommended because the database structures might change in future versions, which would break your directory management solution.
Using the SharePoint object model directly in your management agent is similarly tricky because the object model requires you to run the code locally, yet installing ILM on a Web server in every SharePoint farm in your environment can complicate the directory management infrastructure.
You might think to use SharePoint Web services, but that creates another difficulty because the desired information is not easily accessible through SharePoint Web services, such as e-mail address information for SharePoint groups or the Incoming E-Mail Server Display Address.
In the end, it seems best to implement a custom SharePoint Web service that uses the SharePoint object model to retrieve the desired information, returning it to the caller in the form of an XML document. Now you can centralize the ILM deployment and integrate any number of farms and site collections through individual instances of the custom SharePoint Web service, as illustrated in Figure 3.
There is one remaining aspect worth mentioning, which is that ILM-based directory integration does not eliminate the need for a custom directory management service. This custom service does not need to perform any work because ILM provisions the directory objects, yet you must provide a custom service so that you can enable directory management in SharePoint 3.0 Central Administration. Otherwise, for example, you will not be able to assign e-mail addresses to groups in the first place. Figure 4 shows the resulting solution architecture.
Figure 4 Web Service-based SharePoint directory integration
You can turn the custom directory management service included in the companion material into a dummy service by setting the OpMode parameter in the web.config file (<add key="OpMode" value="dummy"/>). In this configuration, the custom service always returns SUCCESS in response to provisioning calls without performing any work.
In addition, the custom service exposes a ResolveUsers method that the SharePoint management agent can call to resolve NetBIOS-based user account names into distinguished names, which is a required step when provisioning groups. (SharePoint returns group membership information as a list of NetBIOS-based user account names, but Active Directory expects distinguished names.) And that's it! For details on how to deploy the resulting solution, see "Configuring Directory Integration based on ILM 2007.xps" in the companion material.
WSS 3.0 and MOSS 2007 include a Directory Management Service to integrate SharePoint with Exchange Server 2003 for messaging-based cross-platform collaboration.
There are several limitations, however. Users must replace the built-in Directory Management Service with a custom solution. You could also use a professional directory management solution, such as ILM, to integrate SharePoint into a directory management infrastructure. This provides the greatest level of flexibility and helps to ensure information consistency through a pull-based synchronization model.

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


Windows PowerShell String Theory
Don Jones

Contents
A Real-World Case
Complex Matches
It's a Stringy World
When I speak at conferences, such as Tech•Ed or TechMentor, I get into the habit of making proclamations—general-rule announcements that help users remember key points about things like Windows PowerShell. My latest proclamation is, "If you're parsing a string in Windows PowerShell, you're doing something wrong."
This comes from my philosophy regarding Windows PowerShell™ being an object-oriented shell. If you're doing things like dumping lists of services into a text file and then parsing that text file to see which services are started, you're working too hard. That's a valid approach in a text-based OS such as UNIX, but Windows PowerShell (as well as Windows® itself) lets you use objects in a much more efficient way.
Video
Watch Don Jones demonstrate how you can use Windows PowerShell to parse complex strings.

Even your own scripts should produce objects, not formatted text, so that the shell's various formatting, filtering, exporting, and other commands can be used to manipulate the output from your scripts. (In my July 2008 Windows PowerShell column, you can read more about the concept of custom objects as script output.)
At a recent TechMentor in Orlando, Fla., one of my students reminded me that nearly all rules, especially general rules, have exceptions. "What about finding stuff in an IIS log file? Don't you pretty much have to parse text in that case?"
Well, er, yes. And fortunately, as object-friendly as it may be, Windows PowerShell is no slouch when it comes to parsing strings of text. And now that you mention it, IIS log files, firewall log files, and other text-based logs are perfect examples.

A Real-World Case
I actually had to parse a set of firewall log files for a company I was working for. An employee had been caught viewing some inappropriate Web sites, and as part of the follow-up investigation, the Human Resources department needed a comprehensive list of the Web sites he'd been visiting. While that's a bit tough to pull out of a single day's log file, the folks in HR wanted to go back for weeks—a task I was not eager to do manually.
The company's Dynamic Host Configuration Protocol (DHCP) server indicated that the employee's computer had been using the same IP address (let's say 192.168.17.54 for the purposes of this example) for several months. That, of course, is not unusual since it was a desktop computer that was rarely turned off. And since the firewall log kept a record of source IP addresses, I knew that Windows PowerShell could be of help.
The secret lies in the often-overlooked Select-String command. And you'll also need a working knowledge of regular expressions (which I covered back in the November 2007 installment of Windows PowerShell).
The Select-String command will accept a file path full of text files, a regular expression, or a simple string to look for. It will then output each line from each log file that matches the regular expression or simple string. To begin my task, I simply wanted to get every line containing the IP address of the employee's desktop computer. Each log file line contained a date and a time stamp, which is all the folks in the Human Resources department were after.
Here's the command:
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
The –simpleMatch parameter specifies that the pattern I provided is just a simple string, not a regular expression. Figure 1 shows some of the output, which could also be piped to a file. It is important to note that the output includes both the file name and line number that the match was found in, which can be very useful if you want to go back at some point and dig for more information.
Cmdlet of the Month: Start-Sleep
Here's a cmdlet that can give you just what you need in the middle of a long workday—a little nap. Start-Sleep offers a quick break—for your Windows PowerShell scripts, that is.
It's not uncommon to need a quick pause in a script. For example, say you need to start a service, wait a few seconds for it to get up and running, and then perform some other tasks that depend upon that service. Start-Sleep is exactly what you need for this behavior. Running Start-Sleep 10, for instance, will cause the shell to pause for 10 seconds. If you need more precise control, you can run Start-Sleep -milli 100, for example, to pause for 100 milliseconds. Start-Sleep completely suspends the shell, including scripts, pipelines, and everything else, for the amount of time specified. Now if only someone would write that Start-Nap cmdlet I've been longing for.
Figure 1 Output from a Select-String command

Complex Matches
After I provided the HR folks with exactly what they asked for, they realized that it wasn't what they wanted after all. My report included visits to numerous IP addresses, such as 207.68.172.246 (the MSN® Web site). The next request from the investigator was to trim down my report to include only visits to a specific IP address, which they had identified as belonging to one of the Web sites in question. For this column, I won't reveal the real IP address that came up in the investigation. Instead, I'll use 207.68.172.246 for this example (although the MSN Web site typically isn't considered inappropriate).
This request could be a bit more difficult. In the log file I was working with, the source and destination IP addresses were right next to one another and separated by a comma. So I could simply change my search string to "192.168.17.54,207.68.172.246" and repeat the search.
In a more complex log file, however, it's possible there would be variable data stored between the two IP addresses, and so a simple string match won't work. In that scenario you would have to resort to a regular expression, which will also work well on simpler log formats, so that's what I'll demonstrate here.
Within a regular expression, the period character is a wild card for any single character. And I can use the sub-expression (.)* to search for any number of characters in between my two IP addresses. However, it is necessary that I use a backslash to escape the literal periods that appear in the IP addresses themselves.
The resulting command is:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
I removed the –simpleMatch parameter since I'm using a regular expression this time. The resulting output showed only those visits from the particular employee's computer to the specific Web site identified as inappropriate. The output also included the date and time stamp information that the investigator wanted. Figure 2 shows a portion of output you might get when you are running a command such as this.
Figure 2 Narrowed search results that show only visits to a specific site
But I can go one better and pipe the output to Format-Table and use its ability to display calculated columns. I can have the table include the file name of the log file and the line number at which the match was found, and I'll even display the matching line itself. However, I can have the shell replace the regular expression match with an empty string so only the remainder of the line—the date and time stamp in my example—will display. This is an advanced trick, but it further demonstrates how Windows PowerShell can manipulate string data and produce highly customized output, all in a single command line:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
Figure 3 shows what my final results might look like.
Figure 3 Formatted output from a Select-String command

It's a Stringy World
I am quick to proclaim the object-oriented nature of Windows PowerShell as one of its greatest strengths. But there are, nonetheless, times when objects aren't an option.
Windows PowerShell may live in an object-oriented world. Fortunately, the Windows PowerShell team recognized that your world frequently contains external data in formatted strings, and so they included the Select-String command. Armed with Select-String and a familiarity with regular expressions, you can use Windows PowerShell to write one-liners that will parse the most complicated strings.

Don Jones is the coauthor of Windows PowerShell: TFM and author of dozens of other IT books. Reach him through his blog at www.concentratedtech.com.


Hey, Scripting Guy! Stay Connected with Your Toaster
The Microsoft Scripting Guys

Code download available at: HeyScriptingGuy2008_09.exe (150 KB)

If there's anything that sums up this modern world of ours it's these two words: stay connected. Thanks to cell phones, you no longer have to be home in order for people to give you a call; they can reach you wherever you are, at any time of the day or night. (Oh. How … nice.) Thanks to wireless computing, you don't have to be at the office to do your work; now you can work from home, from the beach, from just about anywhere you can think of.
True story: the Scripting Editor's parents recently went on a camping trip, but they were forced to rough it—just like the great explorers Lewis and Clark—when they ran into problems connecting to the campground's wireless network. Thank goodness the satellite TV still worked!
And that's not the half of it. GPS devices let you know exactly where you stand, within a matter of feet; depending on the device, they can also let other people know exactly where you stand. (The old phrase "you can run but you can't hide" was never more true than it is today.) If he wanted to, the Scripting Guy who writes this column could have his checking account phone him every time a check clears; likewise, he could have his car e-mail him monthly status reports. As if that wasn't enough, the toaster has offered to walk the dog and water the plants any time he goes on vacation.
Well, OK, so maybe that last part hasn't happened—yet. But if he wanted to, the Scripting Guy could buy an Internet-enabled toaster. Then he could phone his toaster on his way home and have piping hot toast waiting for him as he walked through the door. To be honest, we don't know why you'd want to have piping hot toast waiting for you when you walk through the door. But if you did …
Of course, if everyone's goal is to stay connected, it should come as no surprise that the Scripting Guys—who have never been slaves to trendiness—advocate that you become more disconnected. Does that mean that the Scripting Guys recommend you throw away your cell phone or laptop computer? No; even the Scripting Guys are smarter than that. However, what they are advocating is that you add disconnected recordsets to your scripting arsenal. But if you want to throw away your cell phone or laptop computer, well, we won't stop you.
Note According to a survey taken by Harris Interactive, 43 percent of Americans have used a laptop computer while on vacation in order to check and send work-related e-mail. And more than 50 percent of Americans use their cell phones while on vacation to check their e-mail and/or voicemail. And that doesn't include the 40 percent of Americans who take no vacation over the course of a year.
It goes without saying that a lot of people would happily add disconnected recordsets to their scripting arsenal, except for one thing: they have no idea what a disconnected recordset is. Well, in case you aren't familiar with the concept, a disconnected recordset is (more or less) a database table that isn't tied to an actual database; instead, it's created by a script, it exists only in memory, and it disappears the moment the script ends. In other words, a disconnected recordset is a made-up data structure that exists for only a few minutes and then disappears, taking your data with it. Gee, that sounds really useful, Scripting Guys. Thanks for your help!
OK, we admit it: disconnected recordsets don't sound too terribly exciting. And, the truth is, they aren't. But they can be extremely useful. As veteran VBScript writers know all too well, VBScript doesn't exactly have the best data-sorting capabilities in the world. (Well, not unless you consider no data-sorting capabilities to be the best data-sorting capabilities in the world.) Likewise, VBScript's ability to deal with large sets of data is limited, at best. Outside of the Dictionary object (which restricts you to working with items that have, at most, two properties) or the array (which is largely limited to single-property lists of data), well … that's about it.
The disconnected recordset lets you take care of both of those issues (and more). Need to sort your data, particularly multi-property data? No problem; like we said, a disconnected recordset is the virtual equivalent of a database table, and there's nothing easier in this world than sorting a database table. (OK, if you want to get picky about it, we suppose that not sorting a database table is easier than sorting a database table.) Or perhaps you've got a large set of items, items with multiple properties, that you need to keep track of? No problem; did we mention that a disconnected recordset is the virtual equivalent of a database table? Do you need to filter that information in some way, or maybe search that data for a specific value? Oh, if only there were some way to use the virtual equivalent of a database table …
Good point: maybe it's about that time to just show you what we're talking about. (Assuming we even know what we're talking about.) For starters, let's say we have the baseball statistics shown in Figure 1, statistics gleaned from the Web site MLB.com and stored in a tab-separated values file, C:\Scripts\Test.txt.
Figure 1 Statistics stored in a tab-separated values file
Player | Home Runs | RBI | Average
D Pedroia | 4 | 28 | .276
K Kouzmanoff | 8 | 25 | .269
J Francouer | 7 | 35 | .254
C Guzman | 5 | 20 | .299
F Sanchez | 2 | 25 | .238
I Suzuki | 3 | 15 | .287
J Hamilton | 17 | 67 | .329
I Kinsler | 7 | 35 | .309
M Ramirez | 12 | 39 | .295
A Gonzalez | 17 | 55 | .299
That's all well and good, but suppose what we'd really like to do is show this list of players sorted by the number of home runs they've hit. Can a disconnected recordset help us with something like that? We're about to find out; take a look at Figure 2. Yes, there is a lot of code here, isn't there? But don't worry; as you'll soon see, its bark is far worse than its bite.
Figure 2 A disconnected recordset
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
To begin, we define four constants:
  • ForReading. We'll use this constant when we open, and read from, the text file.
  • adVarChar. This is a standard ADO constant for creating a field that uses the Variant data type.
  • MaxCharacters. This is a standard ADO constant used to indicate the maximum number of characters (in this case, 255) that a Variant field can hold.
  • adDouble. One final ADO constant, for creating a field that uses a double (numeric) data type.
After defining the constants, we encounter this block of code:
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
This is the part of the script where we actually set up and configure our disconnected recordset. To accomplish this task, the first thing we do is create an instance of the ADOR.Recordset object; needless to say, that creates our virtual database table (that is, our disconnected recordset).
We then use this line of code (and the Append method) to add a new field to the recordset:
DataList.Fields.Append "Player", adVarChar, MaxCharacters
As you can see, there's nothing fancy going on here at all: we simply call the Append method followed by three parameters:
  • The name of the field (Players).
  • The data type for the field (adVarChar).
  • The maximum number of characters that can be stored in the field (MaxCharacters).
After adding the Players field, we can add a second field: HomeRuns, which has a numeric (adDouble) data type. When we've finished with that task, we then call the Open method to declare our recordset open and ready for business.
Next we create an instance of the Scripting.FileSystemObject and open the file C:\Scripts\Test.txt. This portion of the script actually has nothing to do with the disconnected recordset; it's there only because we need to retrieve data from a text file. The first line in the text file contains our header information:
Player     Home Runs     RBI        Average
We don't need this information for our recordset, so the first thing we do after opening the file is call the SkipLine method to skip this first line:
objFile.SkipLine
Now that we've moved to the first line with actual data in it, we set up a Do Until loop designed to let us read the rest of the file line by line. Each time we read in a line from the file, we store that value in a variable named strLine, then use the Split function to convert that line to an array of values (by splitting the line each time we encounter a tab):
arrStats = Split(strStats, vbTab)
Admittedly, that's kind of a quick overview, but we expect that, by now, most of you are pretty good at retrieving information from text files. To make a long story short, the first time through the loop the array, arrStats, will contain the items in Figure 3.
Figure 3 Contents of the array
Item Number | Item Name
0 | D Pedroia
1 | 4
2 | 28
3 | .276
Now we're ready to have some fun:
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
Here we're adding the information for player 1 (D Pedroia) to the disconnected recordset. To add a record to the recordset, we begin by calling the AddNew method; this creates a new, blank record for us to work with. We use the next two lines of code to assign values to two recordset fields (Player and HomeRuns), then we call the Update method to officially write that record to the recordset. And then it's back to the top of the loop once more, where we repeat the process with the next line—the next player—in the text file. See? There might be lots of code here, but it's all pretty simple and straightforward.
So what happens after all the players have been added to the recordset? Well, after we close the text file, we execute this block of code:
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
In line 1 we use the MoveFirst method to position the cursor at the beginning of the recordset; if we don't do that, we run the risk of showing only some of the data in the recordset. We then set up a Do Until loop that will continue until we've run out of data (that is, until the recordset's EOF—end-of-file—property is True).
Inside that loop, all we do is echo back the values of the Player and HomeRuns fields (note the somewhat odd syntax used to indicate a particular field: DataList.Fields.Item("Player"). And then we simply call the MoveNext method to move on to the next record in the recordset.
Needless to say, that was really easy. When all is said and done we should get back the following:
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
As you can see, that's—well, come to think of it, that's really not all that good, is it? Granted, we did get back the players' names and home run totals, but we didn't get those home run totals in sorted order. Dang; why didn't the disconnected recordset sort our data for us?
There's actually a good reason: we didn't tell the recordset which field we wanted to sort on. But that's easy enough to correct: just modify the script to add sorting information right before the call to the MoveFirst method. In other words, make that part of the script look like this:
DataList.Sort = "HomeRuns"
DataList.MoveFirst
Obviously there's no trick involved here; we simply assign the field HomeRuns to the Sort property. Now take a look at the output we get when we run the script:
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
Much better. Well, except for one thing: usually home run totals are listed in descending order, with the player having the most home runs coming first. Is there any way to sort a disconnected recordset in descending order?
Of course there is; all we have to do is tack on the helpful DESC parameter, like so:
DataList.Sort = "HomeRuns DESC"
And what does the DESC parameter do for us? You got it:
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
Incidentally, it's perfectly legal to sort on multiple properties; all you have to do is assign each of those properties to the sort order. For example, suppose you'd like to sort first on home runs and then on RBIs. No problem; this command will do the trick:
DataList.Sort = "HomeRuns DESC, RBI DESC"
Give it a try and see for yourself. It's not as much fun as checking your e-mail while on vacation, but it's close.
Note Keep in mind that you can't sort on a field that hasn't been added to the recordset. What does that mean? It means that before you add a property such as RBI to the Sort statement, you need to add these lines to your script in the appropriate locations:
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
And if you want to look at the output, you also need to modify your Wscript.Echo statement:
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
Let's see, what else can we do with disconnected recordsets? Oh, here's something. Suppose we retrieve all the information for all the players and then sort that data by batting average. (Among other things, that means we need to modify our original script to create fields named RBI and BattingAverage.) The output looks like this:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
That's fine, but what if we just want a list of the players hitting .300 or better? How can we limit the displayed data just to the players who match some specified criteria? Well, one way is to assign a Filter to the recordset:
DataList.Filter = "BattingAverage >= .300"
A recordset filter serves the same general purpose as a database query: it provides a mechanism for limiting returned data to a subset of all the records in the recordset. In this case we're simply asking the Filter to weed out all the records except those where the BattingAverage field has a value greater than or equal to .300. And guess what? Filter will do exactly what we ask it to:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
If only our kids would respond that same way, eh?
By the way, you can use multiple criteria in a single filter. For example, this command limits the returned data to records where the BattingAverage field is greater than or equal to .300 and the HomeRuns field is greater than 10:
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
By contrast, this filter limits data to records where the BattingAverage field is greater than or equal to .300 or the HomeRuns field is greater than 10:
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
Give both of those a try and you'll see what the difference is. And what the heck: just for fun, here's another filter you can try:
DataList.Filter = "Player LIKE 'I*'"
As it turns out, you can also use wildcards in your filters. To do so, use the LIKE operator (as opposed to the equals sign) and then use the asterisk the same as you would when carrying out an MS-DOS® command like dir C:\Scripts\*.txt. In the preceding example, we should get back a list of players whose name starts with the letter I; that's because the syntax we employed says, "Show me a list of all the records where the value of the Player field begins with an I and then is followed by, well, anything." Give it a—well, OK; you know the routine by now.
By the way, you aren't stuck with batting averages like 0.309, either. (Typically batting averages are expressed without the leading 0, .309, for example.) But that's fine; you can simply use the FormatNumber function to format the batting average any old way you want:
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
Simply include this function in your Wscript.Echo statement when you display the number (or alternatively, you could assign the output to a variable and put the variable in your Echo statement):
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
Fun stuff, huh?
Unfortunately, though, it looks like we're out of time for this month. In summary, we'd just like to say that—sorry, the phone is ringing.
Anyway, we wanted to note that—oh, great, now the cell phone is ringing. And we just got e-mail from the toaster. Important stuff: our piping hot toast is ready and do we want butter or jam? Gotta go, but we'll see you all next month!
Dr. Scripto's Scripting Perplexer
The monthly challenge that tests not only your puzzle-solving ability but also your scripting skills.

September 2008: Scripting Search
Here's a simple (or maybe not so simple) word search. Find all the VBScript functions and statements from the list. But here's a twist: the remaining letters will spell out a hidden word, which just so happens to be—you guessed it—a Windows PowerShell™ cmdlet!
Word List: Abs, Array, Atn, CCur, CLng, CInt, DateValue, Day, Dim, Else, Exp, Fix, InStr, IsEmpty, IsObject, Join, Len, Log, Loop, LTrim, Mid, Month, MsgBox, Now, Oct, Replace, Set, Sin, Space, Split, Sqr, StrComp, String, Timer, TimeValue, WeekdayName.

ANSWER:
Dr. Scripto's Scripting Perplexer
Answer: September 2008: Scripting Search

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


The Desktop Files Advanced Functionality in WDS
Wes Miller

Contents
Command-Line Management
Image Store
Multicast
WDS Logging
Other Issues
Wrap-Up
For the past two installments of this column, I've been exploring Windows Deployment Services (WDS). I began by looking at the history of Pre-boot eXecution Environment (PXE)-based deployment tools from Microsoft, followed by an overview of WDS. This month I'll delve into some advanced topics—
WDSUtil (the powerful command-line utility for WDS), the WDS Image Store, WDS logging, and working with multicast functionality in WDS for Windows Server® 2008.
When Remote Installation Services (RIS) shipped in Windows® 2000 and Windows Server 2003, it was never as feature-rich as many would have liked. Three areas in particular stand out:
  • Performance (more scalable deployment)
  • Logging/auditing
  • Command-line automation
You'll see as we proceed through this month's column that with the initial release of WDS, and more specifically with WDS in Windows Server 2008, significant advances were made on each of these fronts.

Command-Line Management
I noted last month that WDS delivered a greatly improved management console. But even more important for most enterprises, WDS supplied a new command-line utility for management, WDSUtil.exe (see Figure 1). WDSUtil is installed with the WDS Optional Component on Windows Server 2003 (SP1+WDS or SP2) and with the WDS Role on Windows Server 2008.
Figure 1 Setting the architecture discovery option to yes with WDSUtil
WDSUtil is an amazingly powerful utility, but it is complex. Effectively, everything you can do via the Microsoft® Management Console (MMC), and more, can be done via WDSUtil. In fact, for a great example of this that's also one of the best ways to diagnose if you're having problems, try running:
wdsutil /get-server /show:config
The results almost completely mirror what you would see in the entire WDS MMC—though WDSUtil can output it in an easily perused format you could then output to a text file.
Not enough information? Try running the following command instead, which returns even more:
wdsutil /get-server /show:all /detailed
And you can stop and restart the WDS server by running:
wdsutil /stop-server
wdsutil /start-server
You'll find a command reference for WDSUtil at go.microsoft.com/fwlink/?LinkId=112194. If you prefer, you can also download a .chm version of this (along with all the WDS 2008 docs) at go.microsoft.com/fwlink/?LinkId=89381.
With RIS, there wasn't an easy way—unless you were an Active Directory® Service Interfaces guru—to find out via the command line whether a specific MAC address or GUID was associated with a Machine Account Object (MAO) in Active Directory. With WDSUtil, you can query based on either.
GUIDs can be confusing, as you can enter them in as binary strings or as a GUID string, and the only difference is the byte ordering and the absence of hyphens. MAC addresses can be entered with or without hyphens using either of the following lines of code:
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
You can get device information by binary string using this command:
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
Or you can get device information by GUID string using this command:
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
Many of your computers are probably capable of running the 64-bit version of Windows, but some, unfortunately, don't report their architecture correctly. You can let WDS attempt to determine whether a system is x64-capable by running a small net-boot program provided as a part of WDS. As Figure 1 shows, you can do this with the following:
wdsutil /set-server /architecturediscovery:yes
In fact, the WDSUtil set-server command lets you configure a huge number of server settings. To see the possibilities, run the command:
wdsutil /set-server /?
If you have upgraded a Windows Server 2003 WDS server to Windows Server 2008, you can convert any RIPrep images to Windows Imaging Format (WIM) images by running:
WDSUtil /convert-RIPrepImage
Though WDSUtil can convert RIPrep images, any remaining RISetup images (traditional RIS/legacy WDS scripted installations) can't be converted.
The power of WDSUtil lies in its ability to automate repetitive tasks. The commands in Figure 2 give you an idea of the capabilities of WDSUtil. Whether you're rolling out new WDS servers, adding or modifying images across multiple servers, administering your multicast infrastructure, or specifying what network boot program to use for a specific boot client, WDSUtil provides some serious power that wasn't previously available in RIS.
Figure 2 WDSUtil commands
Command | Description
/add | Adds devices, images, or image groups.
/approve-AutoAddDevices | Approves pending Auto-Add devices and allows you to set configuration information for them.
/convert-RiprepImage | Converts a legacy RIPrep image to a WIM image.
/copy-Image | Duplicates an image within an image store.
/delete-AutoAddDevices | Deletes all or specific pending Auto-Add devices.
/disable | Disables a WDS Server or Transport Server.
/disconnect-Client | Disconnects a client from a multicast transmission or namespace.
/enable | Enables a WDS Server or Transport Server.
/export-Image | As with /export in ImageX, this exports an existing image from the image store to a WIM image.
/get | Gets properties and attributes for a device, image, image group, WDS server, or transport server.
/initialize-Server | Configures a WDS Server for use after first installation.
/new | Creates capture or discover images, multicast transmissions, and namespaces.
/progress | Displays progress while a given command is being executed.
/reject-AutoAddDevices | Rejects all or specific pending Auto-Add devices.
/remove | Removes images, images groups, multicast transmissions, and namespaces.
/replace-Image | Replaces (overwrites) an image with a new image.
/set | Sets properties and attributes for a device, image, image group, WDS server, or transport server.
/start | Starts a WDS Server or Transport Server.
/stop | Stops a WDS Server or Transport Server.
/uninitialize-Server | Reverts the changes made to the server during server initialization (reverts it to an unconfigured state).
/update-ServerFiles | Updates the files in the server's REMINST share with the latest versions from the server's System32\RemInst directory.
/verbose | Displays verbose output while a given command is being executed.

Image Store
Last month I mentioned how the Single Instance Storage (SIS) used by RIS to store files more efficiently on disk has been abandoned in WDS. Now, all native mode (WIM) images, regardless of OS, are kept in the WDS Image Store. As I've indicated in past columns, that single instance functionality saved you space in .wim files when the volume images had related files. The WDS Image Store functions the same way. In fact, it uses WIM functionality to store images.
To work with the Image Store, you need to have at least one Image Group; WDS initialization will generally prompt you to create one. You can also create a new Image Group as you add an Install Image, and the image will be added to it (see Figure 3).
Figure 3 Creating a new Image Group
So what is the Image Store? Look under your RemoteInstall directory, in the Images directory, and you'll find directories for each Image Group you created. As Figure 4 shows, there's one .wim file for each Install Image you imported into the Image Group and a single .rwm file (Resource WIM).
Figure 4 The contents of an Image Group
Look carefully at the files in Figure 4. This Image Group consists of:
  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
Now compare the sizes of those files with those from the MMC (shown in Figure 5). The size of each .wim file in Figure 4 is a fraction of the size of the Res.rwm file. Why? Well—in order to save space, the .wim files shown are simply stubs of actual files. They contain the metadata to restore the .wim file but don't actually contain the file resources. All file resources in an Image Group are stored in the .rwm file for that Image Group.
Figure 5 Images shown in Server Manager
To edit an Install Image in an Image Store, you can either export the image, make your edits, and then replace the image (or import it anew), or you can interact with it by disabling the appropriate Install Image from the MMC and making your edits by mounting and modifying the .wim file.
One issue that RIS always had was image replication. When you copy SIS'd files over the wire, the SIS is lost since it's an NTFS attribute. This meant you had 40GB of RISetup and RIPrep images and you were replicating them to another server, even if the SIS Groveler had reduced them down to as little as 5GB, you were still replicating 40GB over the wire. This is not the case with the WDS Image Store. In fact, because of the architecture of the Image Store, you can save it on a Distributed File System (DFS) server and use DFS-Replication (DFS-R) to replicate it from site to site.
The specifics for this vary, depending on the version of WDS. For Windows Server 2003, see Chapter 7, "Working with Images," in the documentation downloadable at go.microsoft.com/fwlink/?LinkId=81031. For Windows Server 2008, see "Storing and Replicating Images Using DFS" at go.microsoft.com/fwlink/?LinkId=121960. Since the resources are all stored in the .rwm file, even when you copy an Image Group from one server to another, the amount of data crossing the wire is a fraction of what it would be if each entire .wim file was being transmitted (or in the old RIS SIS architecture).
So when do you create a new Image Group, and when do you use the old one? The rules are generally the same as for a .wim file. Though you could put an image of Windows XP Professional SP3 into an Image Group predominantly made up of Windows Server 2008 images, this wouldn't make much sense, as you're not saving much space. As with .wims, you'll want to generally have an Image Group for at least:
  • Each specific release of Windows—where a release is both an SKU (Windows XP Professional) and a Service Pack revision (SP3).
  • Windows Server 2003 and earlier: each localized language release (not Multilanguage User Interface). Prior to Windows Vista®, localized builds were entirely different binaries, so they didn't store well in a .wim file in terms of single instancing.
  • Each Service Pack of each release. While you may be able to store Windows Server 2008 and Windows Vista SP1 images together, consider whether that functionally makes sense in your organization.
The Image Store, even more than SIS before it, works well to conserve space—both on disk and over the wire, and generally requires little work to keep it functioning happily.

One of the greatest weaknesses of RIS was its lack of scalability. Multicast deployment is all about rectifying that. People often think of multicast as "faster" deployment, but it isn't really about faster—it's about "more." You could deploy multiple systems via RIS. In fact, RIS could handle simultaneous deployment of about 75 systems.
But long before you approached that point, performance was impacted and each installation took progressively longer. Worse, as the number of installations increased, so did the potential for failure. At the same time, multiple installations saturated your network with Server Message Block (SMB) network traffic (so that during deployment, employees might not be able to get to critical network resources such as Microsoft Exchange Server).
Multicast is about scaling up your deployment numbers. Whether you're deploying four servers or a conference center with 100 systems, multicasting lets you complete that deployment without taking forever and without saturating the network. While you can use multicast to deploy to a single system, it isn't until you've got multiple systems listening to the transmission that the benefit of scale is realized.
In order to use multicast, you need to have routers that support multicast. Generally, this means Internet Group Management Protocol (IGMP) snooping should be enabled. You also must have Windows PE 2.1 (Windows Server 2008 RTM or Windows Vista SP1), as the version (2.0) that shipped with Windows Vista RTM is not capable of receiving a multicast transmission.
You should also ensure that if you have multiple WDS (or other multicast) servers on the same network, you specify a custom IP address range. This can be easily changed via the WDS MMC by right-clicking the server, clicking Properties, and then clicking the Network Settings tab.
When performing a multicast broadcast, the multicast server can either adjust to the speed at which the slowest client can receive, or it can regulate the speed at a higher level and drop clients that can't keep up. For reliability, WDS will run at the speed of the slowest client receiving the transmission.
If you find that transmission performance is slower than you expect, run wdsutil /Get-MulticastTransmission/Show-clients. This will reveal the master client that is throttling the transmission. You can then disconnect that client, and it will revert to using SMB instead of multicast. For an example script that auto disconnects slow clients, go to go.microsoft.com/fwlink/?LinkId=121961.
To create a multicast transmission, you can either right-click an Install Image and select Create Multicast Transmission, or you can right-click Multicast Transmissions in the WDS console and select Create Multicast Transmission. As you create the multicast transmission, you can create either an Auto-Cast or Scheduled-Cast. Auto-Cast is useful when you have several clients coming online regularly, all needing the exact same image; new clients will be added automatically to the ongoing transmission that was initiated for the very first client requesting an install image. Scheduled-Cast lets you set a group size that, if reached, will cause a transmission to begin.
You can also set the transmission to start at a specified time. Once clients are utilizing the multicast transmission, you can view them by clicking on the image name. In the right-hand pane, you will see specifics about the clients connected to the transmission.
Generally, your end users will use multicast from the WDS Setup client. There is, however, a command-line utility, named WDSMCast, that is shipped in the Windows Server 2008 Windows Automated Installation Kit (WAIK) and lets you request a .wim file via a multicast transmission from WDS. The .wim file must be transferred in its entirety and applied to the client—so you will want to ensure adequate disk space for the image to be stored and applied. Next month, I'll discuss how you can integrate WDSMCast into your own custom deployment process.

WDS Logging
WDS is capable of performing considerable logging and tracing, though much of this is disabled by default to save space. There are two types of event logging—when a client writes to the Windows event log and writing to trace logs for other aspects of WDS.
In Windows Server 2008, however, WDS does perform quite a bit of logging by default. These logs are available under Administrative Tools | Event Viewer. The WDS logs are visible in the Event Viewer under Applications and Services Logs | Microsoft | Windows | Deployment-Services-Diagnostics. Conveniently, these are the same logs that are visible when you view the WDS role in the MMC (see Figure 6).
Figure 6 Viewing WDS events in Server Manager
WDS client logging (visible in the event logs in Figure 6) can be started by running WDSUtil with the following arguments:
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
You can enable trace logging on several different subcomponents of WDS as well. To configure tracing, set a DWORD registry value accordingly under the registry key(s), shown in Figure 7. All trace logs are stored under \Windows\tracing. You will then need to restart the appropriate component for logging to begin.
Figure 7 Setting up trace logging
WDS Component | Registry Key | Registry Value | Log Name
Server | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
Multicast | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
Management Components | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS also has performance counters (described at go.microsoft.com/fwlink/?LinkId=121962) you can monitor in the event of system performance problems (or to carry out system performance analyses ahead of time). As noted earlier, you can get more detailed information if you encounter issues by using the /detailed, /verbose, or /progress switches with WDSUtil.
If you are having problems with WDS clients connecting or interacting with a WDS server, Microsoft Network Monitor (Netmon) is an excellent tool for debugging the issues. Network Monitor is available for download at go.microsoft.com/fwlink/?LinkId=121491.

Other Issues
I have been seeing a couple of issues that are worth mentioning. The first is memory—remember that at its core, WDS is based on Windows PE 2.x. This means that WDS clients need at least 384MB of RAM—and realistically you should ensure 512MB for optimal performance. Remember also that Windows PE 2.x cannot boot on non-Advanced Configuration and Power Interface (ACPI) systems—and this doesn't always mean old hardware. There are reports of relatively recent systems that don't support ACPI.
Note that those systems also won't support Windows Vista or Windows Server 2008. For systems that don't support ACPI, you'll need to either keep a Windows Server 2003 or earlier WDS or RIS Server available with those clients prestaged to it, or install Windows via a non-PXE mechanism.
Finally, bear in mind that if you want to boot Windows PE 1.x from your server, you will need to also use a Windows Server 2003 or earlier WDS or RIS server, as WDS in Windows Server 2008 cannot boot a Windows PE 1.x image (RAMDisk or PXE).

So far I've delved into WDS history, fundamentals, and advanced topics. Next month I'll take a look at some custom WDS scenarios—specifically, how you can interact with WDS and tweak it to perform the tasks you need it to, often without utilizing the existing WDS/setup experience.

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


Security Watch Passwords and Credit Cards, Part 3
Jesper M. Johansson

Contents
Overloading Updating Technologies
Inconsistent Messages about Security
It's All about the Checkboxes
A Call to Arms
In the last couple of issues of TechNet Magazine, I discussed how security professionals and the IT industry at large confuse consumers and actually hinder effective security efforts. In the first two installments of this series, I focused on such issues as solutions that provide misleading information to consumers, overload the
logon workflow, and teach bad behaviors. So far, I have shown you many different examples of how the industry, in its zeal to appear concerned about consumer security, has actually made the situation far worse than it needs to be. In this third and final installment, I will show how some of the most important technologies available to consumers are not living up to the expectations those consumers should have for those solutions. This all leads up to my call to arms.

Overloading Updating Technologies
One of the primary tenets—an indisputable requirement, in fact—of staying safe electronically is to keep all your software up to date. Nearly every major software provider now has some form of semi-automatic mechanism for keeping at least some of its software up to date. However, it's not quite that simple.
First, the more software you have, the more software you have to update. And the more vendors you get software from, the more update mechanisms you have to work with. This is a confusion factor.
For example, if you just leave the defaults in place, Internet Explorer® will update itself. But Internet Explorer is really just a container for other technologies. The potential impact of that was demonstrated at the CanSecWest conference in 2008, when Shane Macaulay used a combination of vulnerabilities in Java and Adobe Flash to hack a Mac. (Details were a bit scarce when writing this column, as the flaw had still not been disclosed.) My point, though, is that neither of these technologies is a built-in component, and yet they are both available on most computers because they are so widely used on the Internet. Both are a bit of a challenge to keep updated—each has an automatic update mechanism yet neither mechanism fires very often.
In addition, most end users simply don't realize those technologies are there and need to be updated. In many cases, these technologies were provided in the OEM image on the computer, which, to the consumer, is indistinguishable from the operating system. As far as the end user is concerned, when Windows® Update says there are no updates, there are no updates.
The second problem is that the update mechanisms are often more complicated than necessary. Any update mechanism that does not have a completely automatic mode is unlikely to receive wide use because users are generally unaware that they need to run the update tool. Further, in most cases, the user must be an administrator to install the updates. And in a worst case scenario, the user must be an administrator just to be notified of an update being available.
Finally, it is becoming increasingly common for vendors to use software-updating technologies to deploy completely unrelated software that the user did not have installed—toolbars and so on. The software updating technologies have transitioned from being intended very specifically to deploy updates for software to being used as a way to distribute additional software.
Two very visible cases of this are the Microsoft® Windows Update service (shown in Figure 1) and Apple Software Update (shown in Figure 2). Both Apple and Microsoft have chosen to use their update mechanisms to not only update software but to deploy new software that the user did not originally install.
Figure 1 Using Windows Update to deploy Silverlight
Figure 2 Using Apple Software Update to distribute Safari
In Apple's case, you are offered both iTunes and Safari even if you only have QuickTime installed. Interestingly, they are also all selected by default.
In the case of Windows Update, the most recent new software deployed using the update service is Silverlight™. Microsoft has used this technique in the past to distribute new software. To its credit, at least Microsoft did not check the box to install the new software by default.
This approach, to distribute new software via an update mechanism, causes two problems for users. First, many will end up with more software on their computer than they started with. As you know, all software of any substance has bugs, and some of those bugs may result in potential security vulnerabilities. And some of those vulnerabilities will eventually be used in some form of attack. As a result, some number of users will be attacked through software they do not need or even use, which was deployed to their computer via a software update mechanism.
Another effect is that users may get the wrong idea about the value of software update mechanisms. If users find that software update mechanisms are being used to deploy new software, as opposed to new updates, they may see the update mechanisms as a hassle and stop using them. Just imagine how a user must feel after being attacked through a vulnerability that comes from a program that he never uses but received through a software update mechanism.
There are few things more dangerous to the health and safety of the technology ecosystem than users losing trust in the technologies that should keep them secure. Once users lose that trust, those technologies will start to be rejected and eventually fall out of use. If technologies that are critical to protection, as update technologies are, fall from favor, the entire technology ecosystem will be at risk. Protecting this ecosystem is why Microsoft distributes security updates even to computers that are known to be running pirated software.
In comparison, I truly respect the clean and purpose-built Mozilla Firefox update interface, shown in Figure 3. I certainly hope that Mozilla continues to avoid the temptation to distribute additional software via its Software Update tool.
Figure 3 The Software Update interface for Firefox is one of the cleanest in the business

Inconsistent Messages about Security
It would be nice if the industry would actually settle on a common message to consumers. While competition in the industry is essential, consumers need to learn what security should mean to them. Unfortunately, they cannot do that if the industry keeps sending conflicting messages. Frankly, I would settle for companies being consistent across their own messaging.
While the industry will probably never settle on such a common message, there does at least need to be consistency and honesty in messaging. Given the critical importance in making sure customers continue to trust security technologies, the industry as a whole needs to do better.
Similarly, we also need to question what provides actual value today. For instance, I don't believe antivirus software is nearly as effective or even critical today as the industry may have you believe. Consider the computer that my seven-year-old son uses and the computer in my kitchen. Both have antivirus software installed and in the three years since they were installed, neither has ever alarmed for anything. Now, I'm not saying that we should abandon antivirus software—at this point, it is a core component of the technology ecosystem. Clearly, if we were suddenly to remove all antivirus software, the attackers would quickly take advantage of that and we would start seeing more infections.
The point here is that the industry needs to think about what features users really need in their security products, how effective these features are, and how companies can communicate these needs and values to consumers. As it stands, users today receive far too many conflicting, exaggerated, and often untrue messages about security.

It's All about the Checkboxes
As an example, the security software industry is all about suites. Today, security software is almost exclusively distributed as bundles of seemingly unrelated features. And there is practically no information on which of those features users actually need.
This seems to result in a race to fill more checkboxes. While checklists provide a good way to compare products, they can also give rise to features that are not necessary or even desirable, or that even make sense. Figures 4 through 7 show four different lists of check marks from four different security software vendors. Is it safe to assume that the product with 17 check marks is superior to the one with only 10 check marks?
I actually find these figures quite amusing. In Figure 4, the product received a check mark for being a new version. And the product in Figure 5 gets a check mark because it, according to the company's claim, "stops attacks from nefarious Web sites." The product in Figure 6 gets extra points because it "protects children online." Obviously nobody would want a product that fails to protect children. The winner, however, gets the creativity award for including such features as registry clean-up and hard-disk defragmentation in a security suite. The former is rarely if ever needed and the latter is already built into the OS. In fact, the Windows OS already includes solutions for 15 of the 17 check marks shown in Figure 7.
Figure 4 This top-of-the-line product has only 10 check marks
Figure 5 This product with 11 check marks must be better
Figure 6 Hold on, this one has 12 check marks
Figure 7 But this product with 17 check marks must be the best solution, right?
There are some disturbing trends here. Not only are these products duplicating functionality that is already included in the operating system (while neglecting to mention that fact in the marketing literature), they are also making outright false claims. For example, no security software in the world can truly stop attacks from anywhere—they can only help prevent them. Nor can any product really hide your presence from attackers.
The problem is that the business of software security has largely been built on protecting users from vulnerabilities made possible by products created by other vendors. But those vendors are constantly getting better at protecting their own customers and, as a result, the security software industry is finding its business model threatened. The security software industry certainly does have a lot to offer, though, as new risks surface, but the vendors need to help customers manage risk, not simply guard against threats that are no longer really threats.

A Call to Arms
If there is one thing I would like readers to take away from this three-part series, it is that we as an industry need to level with our users and customers. We need to explain the risks and how users can address these risks. And we finally need to start equipping people to protect themselves.
My biggest concern about all these "solutions" is that there is a serious possibility that they will ultimately degrade security in the long term. If users, and even IT managers, actually believe that these products will solve real security risks, especially all the risks they misleadingly claim to solve, we may lose the opportunity to teach people how to truly protect themselves.
Take password authentication systems as an example. If users believe that the weak add-ons to password-based authentication systems I discussed in the first part of this series are actually protecting them, they may become even more lax and use even weaker passwords. In the worst cases I highlighted in this series, the technology actually forces the user to use weaker security than what would have been used if the new technology weren't implemented. This means that by the time the malicious users figure out how to defeat these systems, which often is not hard, we will be in an even worse state than we're in now. That could result in a significant trust problem, causing people to abandon solutions with real value.
We need to take action now to protect the technology ecosystem that sustains our businesses. Innovation must, of course, be encouraged, but we must also be very careful to avoid letting innovation for the sake of innovation get in the way of real risk analysis. Otherwise, we will have only security theater, and eventually security theater will come crashing down around us.
The same holds true for the other examples I've discussed. Take the meaningless security eye candy, for instance. It does absolutely no good to users, it lulls them into a false sense of security, and it lets online service providers get away with optimizations that actually cause indirect harm to users. Meanwhile, the net cost would be just a few thousand dollars, or perhaps tens of thousands in the most extreme cases, to provide proper information to users. Is it really too much to ask that vendors spend that little bit of money on efforts to protect their customers and their business?
This has many implications. First, we must address the perception that users are incapable of making decisions and must be prevented from doing so. Users are not incapable of being taught to make decisions. After all, these users have made many decisions, such as deciding to purchase a computer, or to use your site, or to purchase one of your products or services. Just as people need to learn to drive a car safely, they must also learn to use a computer safely. The attacks are targeting the users personally today, and technology cannot be relied upon to make the decisions. Rather, security technologies must be decision support systems, providing the right information at the right time in order to enable the user to make an intelligent decision.
Some of the worst user interfaces in the world have come from security solutions because the applications have been designed to either hide any kind of decision-making from the user or to dump all the available data (in an unfriendly manner) to the user. Neither approach works. The former puts users at risk because the technology cannot be depended on to make the right choice. And if the technology is perceived as hindering the user's business objectives, it will not be long until the technology is disabled. The latter approach, meanwhile, fails because people do not want to be bothered with IP addresses, process IDs, and other data that is meaningless to them. They just want to know what the computer is doing with their passwords and credit cards. This, after all, is what security is really about.

Jesper M. Johansson is a Software Architect working on security software and is a contributing editor to TechNet Magazine. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security, and is an MVP in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit.


Field Notes Innovation from Within
Romi Mahajan

In his book The Future of Management, renowned management guru and business strategist Gary Hamel argues that long-term comparative advantage stems from the creation of an innovation culture that is itself a product of the evolution of management technologies. Whereas along many axes, industry has innovated and reinvented itself countless times, most companies still are steeped in a hierarchical management culture. This prevents any truly innovative culture from emerging simply because it does not yield decent returns on human creativity and capital.
Such hierarchies are anathema to innovation; and human creativity, when unleashed, is the core fuel for long-term innovative comparative advantage. When human creativity is constrained, upwards of 80 percent of workers are not engaged in what they do. Hamel believes this is not only a business failure but a moral one as well.
At a very basic level, this should be a clarion call to industry to banish excessive hierarchy. At its essence, the argument is fundamentally anti-bureaucratic. Decision-making power should not be reposed with out-of-touch managers and rich executives.
Hamel argues that management, not IT, is the source for innovation. IT, after all, can be commoditized and, therefore, how can it render comparative advantage? If IT is not the source of innovation, and if productivity gains, uptime, reliability, quick on-boarding of new applications and single sign-on (and their ilk) can't render comparative advantage, then what indeed are we all so busy worrying about?
Are you willing to look deep into the soul of your IT organizations and your companies as a whole to see if, just perhaps, Hamel has a valid point? How can you make sure that IT is not considered a commodity?
In incorporating the best of Hamel's concepts and using them to help IT organizations secure their future as hubs of innovation, I've developed a theory called Innovation from Within. The optimal use of both human creativity and capital is the key to sustained comparative advantage, and great organizations must make innovation intrinsic to their function. Organizations must embrace community, not bureaucracy. And, most significant, management too often stands in the way of real innovation—only when management evolves is true innovation possible.
Let's look at IT organizations. IT staff members tend to be intelligent, dedicated, and keen to make an impact. Often called upon to do more with fewer resources, they spend most of their time performing their core jobs, leaving little time for innovation.
My concept of Innovation from Within applies Hamel's theory to the field of IT. The core principles are:
  • Given the inherent creativity of IT staff, it's in our best interest to ensure an IT management model that utilizes this potential.
  • Innovation comes from the systematic and irreverent process of thought-trial-error-revision, a process that is inherent in IT.
  • When community is embraced deeply and openly, technical solutions emerge. IT can lead the way here, starting with itself!
  • In IT, people are the only source of comparative advantage.
  • IT management needs to evolve from a focus on project and budget to a new and exciting focus on innovation management.
  • IT should not be about cost containment, but rather about the creation of great outcomes.
Are you ready to believe in this theory? Can we apply the concept of Innovation from Within and demonstrate that IT organizations are the right place to conduct this grand experiment? Are managers ready to divest power and to embrace their own communities? Is management ready to give up its power and embrace our collective brilliance?

Romi Mahajan is Chief Marketing Officer of Ascentium Corporation. Before joining Ascentium, he spent more than seven years at Microsoft, where his last role was as Director of Technical Audience and Platform Marketing. Romi is widely published in the areas of technology, politics, economics, and sociology.


Windows Confidential Windows 95 Unplugged
Raymond Chen

Although 32-bit programs for Windows® 95 could use your average 32-bit compiler, and 16-bit programs could use your average 16-bit compiler, Windows 95 itself needed a special compiler, one that understood both the 32-bit and 16-bit worlds and could bridge that gap. Windows 95 also needed a custom linker that understood how to glue these two types of code together, and it needed a custom linker for VxDs (the driver format for Windows 95).
The Windows 95 team relied on the languages and tools division to provide these special-purpose compilers and linkers. I'm sure the languages division found this to be a strange request: "You want us to write a compiler that does X, Y, and Z, and it's going to be used to compile only two DLLs in its entire lifetime?" It's true. But these were, after all, two pretty important DLLs.
Despite the apparent absurdity of the request, the languages and tools division came through, and the highly specialized compiler and linker became part of the Windows 95 build process. Of course, the compiler wasn't fully formed out of the gate. The Windows team received a preliminary version, and then periodic updates as new optimizations were implemented and bugs were fixed.
One day the Windows 95 build unexpectedly slowed to a crawl. A file that used to take a few seconds to link suddenly took minutes. The file was still generated successfully, but it took forever. And this wasn't on just one developer's machine—the problem hit everybody across the entire team. Did our code suddenly hit some pathological case in the linker? Did we stumble across a linker bug?
After some debugging, we identified the source of the problem. The most recent version of the linker contained some diagnostic code that the languages folks forgot to remove before handing the code off to the Windows team. This diagnostic code logged its output to a file that was stored on a computer sitting in the office of a member of the compiler team. And the computer happened to be turned off. (This brings to mind Leslie Lamport, who famously described a distributed system as one in which you can't get any work done because a computer you never heard of is down.)
That version of the linker had been running happily for weeks. Every time anybody tried to link a VxD when building Windows 95, an update was made to the file sitting on that developer's computer. As long as that computer remained turned on and connected to the network, nobody ever noticed. But one day that computer was turned off, and everything slowed to a crawl.
Once the problem was identified, it didn't take very long for the compiler folks to give the Windows team a patch that removed the diagnostic code from the linker.
There are different punch lines to this story depending on who tells it. When I tell the story, the punch line is, "And that compiler developer later transferred to the Windows team and ended up being my boss." I've often enjoyed retelling this story as a form of gentle teasing.
However, if my boss tells the story, the punch line is very different: "And it turns out, I didn't even write that diagnostic code. It was one of my colleagues, who decided that instead of filling up his own computer with diagnostic information, he'd fill mine!"

Raymond Chen's Web site, The Old New Thing, and identically titled book deal with Windows history and Win32 programming. His DNA is filled with dead code.