 TechNet Magazine January 2007

TechNet Magazine January 2007

SharePoint: An Overview of Microsoft Office SharePoint Server 2007

The new version of SharePoint is poised to meet all your collaboration and information management needs in a single, integrated platform. Here’s a tour of the new features and tools in MOSS that will change the way your enterprise works.

Thomas Rizzo SharePoint: 7 New Features That Enhance Security in SharePoint

With SharePoint tapping into more enterprise data and becoming more integral to business workflow, security becomes far more critical. Find out how these seven new features in MOSS can quickly improve security in your organization.

Adam Robert Buenz SharePoint: Find It All with SharePoint Enterprise Search

Your company loses time and money while employees try to track down information. Enterprise search can help. MOSS offers an enterprise search tool that can find information quickly, whether it’s tucked away on an intranet site, living in a line of a business application, or even residing with a single employee.

Matt Hester SharePoint: Powerful Command Line Administration for SharePoint

Don’t get bogged down with a GUI. There’s a far more powerful and much faster way to manage SharePoint, which lets you perform administrative tasks from a command prompt and even script common procedures.

Todd Klindt SharePoint: Wiki While You Work

Wikis offer a new, more flexible way to collaborate, promoting an unstructured approach to thinking and exchanging ideas. And MOSS 2007 makes it incredibly easy to implement wikis in your organization. Here’s what you need to know to start building and using wikis in the workplace.

Mauro Cardarelli From the Editor: Sometimes industries

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen Utility Spotlight: Internet Explorer Administration Kit

Lance Whitney SQL Q&A: Data Archiving, Linked Servers, Measuring Bandwidth, and More

Edited by Nancy Michell The Cable Guy: TCP Receive Window Auto-Tuning

Joseph Davies Windows PowerShell: Windows PowerShell Constructs

Don Jones Hey, Scripting Guy!: Be Careful What You Say

The Microsoft Scripting Guys Exchange Queue & A: We Have All the Answers (Because We Made Up the Questions)

KC Lemson and Paul Bowden Security Watch: Services Hardening in Windows Vista

Wole Moses The Desktop Files: Windows Automated Installation Kit

Wes Miller Field Notes: Tech Support for In-Laws

James Snell Windows Confidential: Getting Out of DLL Hell

Raymond Chen


 SharePoint: An Overview of Microsoft Office SharePoint Server 2007
SharePoint Thomas Rizzo

An Overview of Microsoft Office SharePoint Server 2007
At a Glance:
  • SharePoint Web integration
  • Content management
  • Business intelligence

Two phenomena are changing the way businesses operate in what Microsoft calls the "new world of work." First, teams that work together are more frequently working in different locations and
even during different hours of the day. As a result, collaboration software has become even more important for spanning the globally connected nature of work. Second, the use of digital information is growing explosively while compliance rules surrounding this business data become ever more complex. Companies are struggling with enabling collaboration and sharing, as well as ensuring information security and privacy. A solution that bridges all of these requirements-communication across continents and time zones, effective collaboration tools, and secure data handling-is absolutley critical to making the most of your information and people assets.
The introduction of Microsoft® Office SharePoint® Server (MOSS) 2007 brings together a variety of technologies into a single integrated platform and set of enterprise services. These technologies range from collaboration to portals to enterprise search to workflow and business process. MOSS represents the next generation of SharePoint Portal Server (SPS) built on top of Windows® SharePoint Services (WSS). An easy way to understand how MOSS and WSS work together is to refer to the pie chart in Figure 1. The green shaded areas are provided by WSS and since MOSS builds on WSS, the entire pie is delivered by MOSS. MOSS specifically provides the portal, search, enterprise content management, business process and forms, and business intelligence pieces.
Figure 1 Service Built on MOSS and WSS
Figure 1 Service Built on MOSS and WSS
The rest of this article will step you through the technology highlights in MOSS and how you can use these advancements to make your users more productive.

SharePoint Meets Web 2.0
Web 2.0, Enterprise 2.0, composite applications, community-driven content-whatever you want to call it, Internet technologies such as AJAX, RSS, blogs, and wikis are giving users more control over their content, more control over their collaboration, and more control over the way data flows to them. Furthermore, they want the interactivity of Windows with the ease of deployment and use that the Web provides. But dropping Internet concepts into an enterprise setting introduces new problems. For example, can you verify and trust the source of the service? Does it integrate cleanly with your existing infrastructure?
MOSS 2007 provides a number of new features while improving the existing collaboration platform by providing built-in abilities for document management and alerting, adding new capabilities like blogs (see Figure 2), wikis, and a Web Part for publishing and receiving RSS feeds. When using Microsoft Office Outlook® 2007, you can perform bidirectional synchronization of your collaboration data such as calendar, tasks, and contacts between Outlook and Microsoft SharePoint. If you want to change a contact or move an appointment, you can make the change in either Outlook or SharePoint and the changes will appear in the other program.
Figure 2 MOSS 2007 Supports Blogs and Wikis
Figure 2 MOSS 2007 Supports Blogs and Wikis
Outlook also supports taking your document libraries offline. You can make changes to the documents disconnected from your network and then sync those changes back when you are next online.
In addition, MOSS has the capability to audit and enforce compliance rules around the community-driven content so that providing these new capabilities does not require customers to sacrifice manageability or security.
A major advancement in MOSS 2007 is increased personalization of the portal experience. MOSS introduces a revamped My Site that fully utilizes the functionality of a SharePoint site. Users can create lists, document libraries, or subsites under their My Site and customize the viewing of these sites for both their personal and workgroup views. The My Site also provides new Web Parts for organization hierarchies and colleague tracking, including alerts when metadata for your colleagues change, such as their phone number, title, office location, or other information. Figure 3 shows a customized My Site in MOSS.
Figure 3 My Site Supports More SharePoint-Centric Features
Figure 3 My Site Supports More SharePoint-Centric Features

Enterprise Search
When hard drives were small, remembering where things were stored was not often a problem. However, with the explosion of storage and what seems the limitless ability of users to fill it, search has become a critical component of any information architecture. MOSS provides improved features for searching enterprise repositories, built on the search platform originally provided in SPS 2003. MOSS 2007 continues to crawl file shares, Web sites, Exchange Server, and Lotus Notes repositories, all of which are considered unstructured data repositories.
What SPS did not easily provide was the ability to search structured repositories such as line of business applications or relational databases. In addition, structured and unstructured repositories are supplemented by the metadata and expertise individual employees contribute to the organization. MOSS can search structured repositories through a new technology called the Business Data Catalog (BDC), and can search people and expertise through the new Knowledge Network.
The BDC provides the ability to connect to, crawl, and search systems that expose their data either through ADO.NET providers or Web services. You create an XML configuration file that contains the necessary information about the system you want to connect to. This can include the name of the server or endpoint, how to enumerate and retrieve objects from that system, any filtering that the backend system supports, and how the backend data should map to SharePoint data. Then you can use the enterprise search features in SharePoint to search BDC data like you crawl other enterprise repositories.
By default, SharePoint creates a profile page for each business entity from your backend system. You can customize these profile pages like you do other pages in SharePoint. Figure 4 shows a customized profile page that returns both business data and other information. Also, SharePoint includes a number of Business Data Web Parts that allow you to display BDC data in your pages and also optionally filter data on those pages based on available metadata. Since the business data is mapped to SharePoint, you can access your data inside SharePoint lists using the new Business Data column type. There are no more data entry errors and data cleansing since the data contained in the list is coming from the authoritative backend system.
Figure 4 Pulling Business Data into SharePoint Pages from Backend Services
Figure 4 Pulling Business Data into SharePoint Pages from Backend Services
Knowledge Network provides a rich way to search for people and expertise. Social networks within the enterprise are the way business gets done. In many cases, employees could be more productive if they could find experts to help them with the business problems they are working on. However, if your direct circle of colleagues does not have the knowledge you need, you probably stop searching for that expertise. With Knowledge Network, rather than relying on physical social networking, software helps build the social map of your organization and allows you to search that social network. You can sort results by social distance and filter by metadata properties like title or department.
As with any solution that deals with people and their personally identifiable information, Knowledge Network provides a rich security and privacy model so that users have to opt into the network and can control what is displayed to which parties in the network. Knowledge Network crawls your server-side information such as your SharePoint My Site. It also has a client-side component that plugs into Outlook and Instant Messaging to crawl your e-mail and contacts. On the client-side, you can control when the scheduled crawl occurs and what is published from the client crawl to your server profile. One of the downfalls of expertise systems is keeping the data up to date about people. With Knowledge Network, the software maintains all the updating of the information while allowing users to control the visibility and accessibility of that data.

Enterprise Content Management
Moving beyond just managing documents, MOSS 2007 provides a robust enterprise content management solution by adding support for managing records, Web content, and electronic forms. The records management capabilities of SharePoint include the ability to build a managed repository that meets your compliance needs such as content retention, auditing, barcoding, and labeling. Through tight integration with Exchange Server, the records repository can contain e-mail messages as official records in addition to the information created and stored inside of SharePoint. The records management capabilities let you perform legal discovery through searching records and legal holds so that you can break retention policies (depending on legal proceedings that require you to hold the content longer than retention policies specify).
In the realm of Web content management, MOSS 2007 now takes the place of Microsoft Content Management Server 2002. With this change, SharePoint now can serve your Web needs spanning from intranet to extranet to Internet-facing sites. By having all of these capabilities in SharePoint, you only have to support one technology across your entire infrastructure. SharePoint supports content deployment so you can have separate testing servers and deployment servers. Furthermore, SharePoint has made site customization easier through its support of ASP.NET 2.0 Master Pages. Plus, for multilanguage scenarios, SharePoint supports site variations so that a single site can have multiple variations and automatically redirect based on the language settings of the browser client viewing the page.
For electronic forms, SharePoint adds a new capability called InfoPath® Forms Services, which allows you to convert your InfoPath forms to electronic forms. The process involves creating your InfoPath forms, checking a box in the designer so that it warns you if you attempt to use features that will not convert to the Web, and saving your form to a trusted location inside a SharePoint list. Then, your users can use just a Web browser to view, edit, and submit your forms.
A significant feature request from users of SPS 2003 was to improve the workflow capabilities, since many customers wanted to embed workflows on the content they store in SharePoint. MOSS goes much further than just improving workflow, by adding the new Windows Workflow Foundation features of the .NET Framework 3.0. This allows you to build workflows against the Windows Workflow Foundation and have those workflows function inside of SharePoint. In addition to hosting Windows Workflow Foundation, SharePoint also includes a number of workflows out of the box including document approval and document signature workflows. Figure 5 shows how to configure an out-of-the-box workflow in MOSS.
Figure 5 Setting Up Workflows in MOSS
Figure 5 Setting Up Workflows in MOSS
MOSS allows you to monitor your workflows so you have the current task status as well as the history. In addition, SharePoint integrates with the Office clients so that end users can kick off workflows from inside their Office apps. Plus, they can quickly see when they have workflow tasks assigned to them and can complete those tasks without ever leaving their Office apps.
MOSS also extends its reach to business intelligence portals. These portals normally contain reports, charts, and tables of data that you can sort and filter, featuring graphics that may help visually represent the status of the data. With MOSS, building business intelligence portals is simply a matter of creating a new page using the Business Intelligence (BI) dashboard template. The BI dashboard by default includes a key performance indicator (KPI) list and the Excel® Web Access Web Part.
The KPI list is a new list type in MOSS that enables you to connect to information sources such as Excel, SQL Server™ Analysis Services, SharePoint lists, or manually entered information, and allows you to track your KPIs from these data sources. With the KPI list, you can see current values, target values, trends, and status using visual indicators.
Excel Web Access is part of Excel Services in MOSS, a server-side version of Excel that lets you calculate and display your Excel information through a Web browser. To use Excel Services, you can publish your spreadsheet directly from the Excel desktop application to a trusted location in SharePoint. Users can then view the spreadsheet or charts from Excel using their Web browsers. Then, if there are any parameters or filtering, users can employ these capabilities to modify the Web browser rendering of the Excel information.

Learning More
While I have only been able to cover a small subset of all the new capabilities in MOSS, there is a wealth of online resources to continue your journey of learning. My recommendation is to start with the SharePoint Team Blog and the SharePoint Server TechCenter.

Thomas Rizzo is a director in the SharePoint group at Microsoft. Previously, Tom worked in the SQL Server and Exchange Server groups. He is also the author of four books. You can reach him at thomriz@microsoft.com.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 SharePoint: 7 New Features That Enhance Security in SharePoint
SharePoint Adam Robert Buenz

7 New Features That Enhance Security in SharePoint
At a Glance:
  • Authentication providers
  • Native encryption features
  • Alternate Access Mapping and zones
  • Information Rights Management

Implementing effective security measures for your Microsoft Office SharePoint Server (MOSS) 2007 environment can significantly reduce management overhead while allowing teams to
collaborate and share business data in a safe environment. Innovative authentication features built into MOSS 2007 let you employ Web-based security standards through custom authentication providers, Internet-style forms-based authentication, and Web single sign-on (SSO). Furthermore, MOSS offers granular rights management of business assets such as 2007 Microsoft® Office system files, native encryption features, and reduced client authentication obligations.
Here are seven security features provided by MOSS 2007 you can quickly put to work.
1. Pluggable Authentication Provider An authentication provider is a component that lets you verify user credentials. Configuring that authentication provider for your MOSS environment is an important security decision when setting up Internet-style SharePoint® authentication. MOSS continues to support the Windows®-based authentication methods available in previous SharePoint versions, including Integrated and Basic authentication (while adding Digest authentication) for resolving users to tangible Windows identities. However, resolving to a Windows identity is no longer the only option. You can even employ multiple authentication providers so that, for example, internal users log in via Windows authentication while external users do so with a separate, pluggable provider.
MOSS is built upon ASP.NET 2.0, which enables the use of pluggable authentication providers. This lets you use configurable directories for storing user information as long as there's an ASP.NET 2.0 membership provider (and optional role provider) that corresponds to the member data store. Pluggable provider credentials can be hashed, encrypted, or stored in plain-text depending on the node values stored in the machine.config file that correspond to the membership provider. Several membership providers are available for use with MOSS, some of which include an LDAP V3 membership provider (which ships with MOSS), plus a SQL ServerTM membership provider and Active Directory® membership provider available with ASP.NET 2.0.
The membership and role providers that can be implemented are not limited to the shipped providers. Using the ASP.NET 2.0 membership architecture, it is feasible to create custom providers that use membership stores like Microsoft AccessTM or Oracle databases, XML files, or even flat text files. A custom authentication provider inherits from the ASP.NET MembershipProvider interface, which in turn inherits from the ProviderBase class (see Figure 1).
Figure 1 .NET Membership Class Hierarchy
Figure 1 .NET Membership Class Hierarchy
There are some implications of using ASP.NET 2.0 authentication (as opposed to Windows authentication) with MOSS that should be taken into consideration. The most significant for many users is reduced Microsoft Office client interoperation resulting from the fact that the Web service communication between MOSS and Office clients was originally designed for use with Windows identities.
Additionally, certain MOSS services, notably those related to crawling and indexing content, must use a Windows account even when using a pluggable provider. To do this using an authentication type that doesn't resolve to a Windows identity requires creating an additional MOSS zone that will employ Windows authentication. (I'll discuss zones later in this article.)
If you have a mandated PKI infrastructure based on security mechanisms such as smartcards where public keys or certificates are carried by clients, this typically requires that a Windows identity be resolved for proper client certificate acceptance and authorization, depending on implementation. This may, in turn, require creating an additional MOSS zone or other authentication configurations.
2. Forms-Based Authentication and Web Single Sign-On Another exciting authentication mechanism that is available to MOSS 2007 is forms-based authentication based on ASP.NET 2.0. In previous versions of SharePoint, this could only be achieved through a custom Internet Server Application Programming Interface (ISAPI) extension or by employing the CustomAuth ISAPI extension from the IIS 6.0 Toolkit. And even with those solutions, SharePoint still needs the account to resolve back to a Windows user identity, constraining perimeter-based deployments.
Forms-based MOSS authentication utilizes pluggable authentication and role providers to enable Internet-style security mechanisms that don't restrict customers to an old-fashioned NT login prompt. Instead, you can build a customized login process geared toward your users' needs. To protect the authentication process further, forms authentication cookies and authentication tickets are encrypted and tamper-proof.
The form identity provider does not have to reside locally and can, in fact, plug into an external identity management system, which in turn would provide the validation of the user credentials. This functionality is known as Web single sign-on, and it employs an HTTP module for external authentication. In such a scenario, you can federate identities between your organization and business partners whereby they are able to use their own organizational logins to authenticate to your MOSS implementation.
3. Encrypting MOSS Application Connection Strings It's not good a security practice to place valuable connection string information in plain text in a web.config file. The exposed information could enable a user to create an object instance to the SQL database server and manipulate valuable data. However, using inherent ASP.NET 2.0 functionality you can encrypt the data using either of two available technologies: Windows Data Protection API (DPAPI) or RSA encryption. DPAPI capitalizes on the built-in cryptographic functionality of Windows to encrypt and decrypt using the MOSS server machine key. RSA encryption lets you use public key algorithms, but carries the added overhead of needing appropriate containers for the encryption keys.
For MOSS 2007-and more specifically for the pluggable ASP.NET 2.0 SQL Server authentication provider-you would want to encrypt the <connectionStrings> node in cipher text since it is where the most significant security breach could occur:
<connectionStrings>
<add name="MembershipConnectionString"
     connectionString="connectionString"/>
</connectionStrings>
Using DPAPI encryption is relatively straightforward and the easiest to implement since it uses native machine key encryption for either a virtual directory or a physical directory. There are other ways to implement this programmatically, but using the following commands in a command prompt is the least painful:
aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider

aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider
Since you are primarily concerned only about implementing encryption for the connection strings node, you can just encrypt that specific section by specifying the section parameter:
aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"

aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"
After implementation, the nodes of sensitive information will be replaced by well-formed XML cipher values:
<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>
Like the overall MOSS architecture, this model is pluggable in that you can create your own encryption providers to manage cipher text for relevant MOSS configuration files, such as web.config or machine.config, and, furthermore, you are not limited to RSA or DPAPI encryption.
Using encryption does have some consequences. Because you are using the local machine key for encryption, you can only use this configuration node on the MOSS server it was created on-otherwise the cipher process will fail. If an intruder gained access to the server, they could retrieve the machine key and decrypt the connection string. The decryption process will also cause a minor application performance hit.
4. Alternate Access Mapping and Zones Alternate Access Mapping (AAM) is crucial, especially when setting up more than one entry location for your SharePoint environment. AAM simply enables you to specify different URLs through which users can access a single physical site (see the diagram in Figure 2). AAM can direct users to the same physical path for your MOSS site, but with different authentication providers and Web application security policies. AAM also compensates for using different domains, reverse proxies, and other URL redirection mechanisms. The URL that MOSS will use is already mapped for you by default, but this can be extended to additional URLs that a SharePoint architect explicitly creates to handle different methods of entry. AAM is required to ensure that proper internal and public URL mapping works correctly.
A SQL Server Authentication Provider
Let's walk through the implementation of the pluggable ASP.NET 2.0 SQL Server authentication provider. This provider uses forms-based authentication with encrypted web.config connection strings, a very typical implementation for perimeter (extranet) MOSS deployments.
The first step in enabling the pluggable SQL Server provider is to ensure the database for user credential storage is created on the appropriate SQL Server instance so the service provider will have something to use as the membership data store. To do this, execute the following command from the Run dialog box or a command prompt:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql
This will bring up a SQL Server wizard that allows you to configure the database for storing your member data.
Since most likely you haven't yet set up the membership provider for database storage, configure SQL Server for application services so it will create a new database. If you do have an existing database, you can add the relevant information (if database consolidation is an organizational objective).
The SQL connection string is going to connect to this SQL instance, so you should set up this database to use SQL Server authentication (see Figure A). At this point, I'll use a plain text username and password since, later in the setup process, I'll show you how to use native ASP.NET 2.0 encryption functionality to hide this private connection information in cipher text to prevent possible exploitation.

Creating the Login Form
Forms-based authentication is often used for externally facing sites that are going to reside on a perimeter network and be publicly exposed to all Internet users. With that in mind, when creating an extranet site collection, it is best to choose the Internet presence MOSS template. With this template you won't have to manually create a login form. If you are extending a current site or want to implement a custom login form, it's easy to make one yourself using Microsoft Visual Studio® 2005. Relatively little coding is required.
Start by opening up the site collection physical directory as a Web site through Visual Studio, typically stored in a location like this:
C:\Inetpub\wwwroot\wss\VirtualDirectories\<GUID>
The first step is to add a default.aspx page since this is the default document in the IIS virtual server settings. Use the Add Item command in Solution Explorer, then add a login control to the newly created Web Form surface through the Visual Studio Toolbox.
Figure a Setting Up SQL Server Authentication
Figure a Setting Up SQL Server Authentication
The login form will work with very few changes, so don't worry if you are not a developer or not familiar with coding in a .NET Framework-compliant language. Once the login control is there, you simply have to bring up the Web Administration Tool (WAT) by selecting Administer Web site from the Web Form design surface. Make sure the provider is set to AspNetSqlProvider and the authentication type is set to From the Internet in the WAT. Lastly, you can delete the default.aspx page that you created as a custom login form from your directory since it is now stored in the MOSS database.
Now set up the authentication provider through the Application Management portion of SharePoint Central Administration. Since you are using forms-based authentication, you should choose Forms for the Authentication Type (this is set to Windows by default), and select the "Enable anonymous access" option so that Internet visitors can browse the site after authentication. These options can be found by navigating to Central Administration | Application Management | Authentication Providers | Edit Authentication (see Figure B).
Figure b Choosing Authentication Provider through the Application Management Screen
Figure b Choosing Authentication Provider through the Application Management Screen
On the same page, ensure that the provider being used for authentication in the membership provider section is specified as AspNetSqlMembershipProvider and that Role manager name is AspNetSqlRoleProvider. Specify where you want end users to have anonymous access by navigating to /_layouts/setanon.aspx and selecting either the entire site or the security setting that is most appropriate to your needs.
You'll make the major changes by modifying web.config. Make sure the <authentication> element is set to use the <forms> element. This is usually configured automatically when you switch from Windows authentication to Forms authentication, and it's an important portion of the login process since it will carry the data about the users authentication ticket, which in turn will verify the user credentials on the page postback through ASP.NET 2.0 authentication methods. But web.config is still not aware of the SQL connection to your user store, so you must add the connection string entry to connect to the membership database:
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Server=SQLserver;
Database=aspnetdb;uid=username;
pwd=password;" providerName="System.Data.SqlClient" />
</connectionStrings>
Make the same modifications to the Central Administration site web.config file to promote conformity of authentication types, and to ensure that the PeoplePickerWildCard resolves to the AspNetSqlMembershipProvider so that the lookup controls for adding users will know the correct path to search.
Since you are making changes to back-end XML files, MOSS requires that you reset IIS. Once you're connected to the SQL Server database, you can browse the Web site with ease—except you have no site collection owners to administrator the content. In the WAT, go to the Security tab and add a user, then make this user a site collection administrator by going to SharePoint Site Management and adding the appropriate users under Site Collection Administrators. The name should be correct because of the modifications to the peoplepicker node in web.config made earlier.
Lastly, encrypt the connection strings with DPAPI by opening up the run dialog and executing:
aspnet_regiis.exe -pef "connectionStrings"
"C:\Inetpub\wwwroot\WssVirtual\<GUID> "
—prov "DataProtectionConfigurationProvider"
When the operation completes successfully, you'll receive a dialog confirming this.

Figure 2 URL Mapping and Zones
Figure 2 URL Mapping and Zones
In MOSS, zones are a new feature that allow greater control over the site mapping provided by AAM. Zones let you map different authentication providers to the same physical path and MOSS content depending on the AAM URL mappings through which users are connecting to the content. When specifying AAM URL mappings, although it is not necessary that the zone is bound to an authentication mechanism, it is recommended. An AAM URL mapping to a zone that is not defined in the authentication providers page will use the security setting for the Default zone.
Zones do require some planning since they will heavily impact how people are authenticated and routed through your portal from multiple URL entry points. When extending a new Web application, you can specify the zone you want to use under the Load Balancing URL section of the settings (see Figure 3). It is recommended that you place your most publicly accessible URL (for example, the URL you plan to expose to the Internet) in the Default zone, as this is the URL SharePoint will use if it cannot fully determine which zone you are in.
Figure 3 Configuring MOSS Zones
Figure 3 Configuring MOSS Zones
Within each zone you can bind a global Web application security policy that defines permissions settings for users in the zone. This lets you centrally manage large-scale permissions modifications. Web applications commonly include several sites in various site collections, and permissions management of these sites can become problematic when applications become large and complex. MOSS 2007 allows global security policies that bind policy settings such as full access, full read access, deny-write access, or deny-all access to a specific user or group within the application. These policies can override the granular permission settings provided by MOSS and managed from the SharePoint Central Administration interface, so you'll want to plan your configuration carefully.
Bringing this all together, your externally facing site might have two URLs as defined in your AAM settings: one for your corporate users to enter, and a second for external users. Each has a unique URL-perhaps contoso for internal users, and extranet.contoso.com for trusted external partners. While both of these URLs will map to the same content, each can access the site through its own zone, with its own authentication provider and its own application security policy. Configuring the intranet zone on the internal URL lets internal users resolve to their domain-authenticated Windows identities while external partners log in via Web single sign-on authentication through the extranet zone, which allows them to use their own organization's user credentials. By leveraging the power of binding Web application security policies to zones, it becomes possible to give all trusted external users full-read access, as opposed to manually setting it on an object-by-object basis.
5. Targeted Content for Secure Collaboration Locking down your SharePoint site collections means users will only handle information you authorize them to access. New flexible permission mechanisms allow you greater control over the various types of business information stored in your MOSS environment.
MOSS 2007 gives you the option to bind an identity to a specific object, whether a site collection, an individual site, a document library, a subfolder, a list, or an individual document or list item. This enforces granular access controls and explicit membership to that item, both denying access and adjusting the user interface so that users are unaware of items they don't have access to. This functionality in MOSS is known as Item Level Security (ILS) or Secured Objects (SO). MOSS object permissions are hierarchal in nature, allowing them to scale from individual objects such as list items up to larger items such as a list or document library. Permission inheritance can be implemented, allowing lower-level children objects to optionally inherit permissions from higher-level parent objects. There are 33 unique default permissions that can be given to a user or SharePoint group, each of which can be bound to an object. You can create new permission levels as well.
For example, within a project management site you can allow only developers and project managers access to sensitive development material, such as design specifications and coding techniques built in Microsoft Word documents stored in a document library. The library's permissions by default will inherit from the site permissions, but the permissions can be modified to give access only to developers and project managers, or even so that each Word document can only be seen and accessed by the appropriate project manager and development team. In contrast, non-sensitive material can be made completely public, either at the item, folder, or document-library level.
Permissions can even be specified on event items, such as project due dates in an Events list, so you can ensure that only certain members will see specific events. Furthermore, the ILS functionality extends down to returned search results, which will only return objects that map back to the security context of the person doing the search. All of these controls in effect, will trim the user interface to the exclusive user context.
The permission management architecture has been vastly improved in MOSS 2007. Permissions can be set for both SharePoint groups and domain groups, as well as at the individual level. Several groups are rolled out by default, notably Owners (who get full control), Visitors (who get contributor rights), and Members (who get read rights). Individuals or domain groups can be assigned to these default groups or to custom groups you can create and manage at the site collection level, which can have various unique permission levels.
When creating groups based on roles, you could create "developers" and "project managers" groups. You could then assign granular permissions that would, for example, let developers upload relevant coding documentation, and give read and approval permissions to project managers so that they could evaluate and endorse those documents. Group membership remains consistent throughout the site collection so that the created groups could be reusable across a number of different project sites.
6. Integrating Pluggable Single Sign-On Within a typical computing environment, a user can have access to any number of third-party applications, each with its own authentication criteria, which leads to various security issues and password fatigue. The MOSS SSO service helps to alleviate this problem by providing an encrypted back-end cache of users' credentials for mapping to connected line-of-business systems. This can aid in the retrieval of business-critical information to display through MOSS mechanisms such as the Business Data Catalog (BDC) or SharePoint DataView Web Parts (DVWP).
The MOSS SSO provider, like several of the other application architectural features discussed, is pluggable; you can specify a unique SSO provider outside of the one shipped with MOSS (SpsSsoProvider), though only one SSO provider per line-of-business system can be registered at a time within the environment.
7. Information Rights Management (IRM) Protecting information at the client level even when business information is taken offline is a considerable concern for companies that tend to deal with data of a sensitive nature, especially those that have to deal with legislation such as California Senate Bill No. 1386, Sarbanes-Oxley (SOX Compliance), and the Health Insurance Portability and Accountability Act (HIPAA). Server-side Information Rights Management (IRM) integrates with MOSS repositories to provide a common solution built on the Windows Rights Management (WRM) framework. IRM gives you tight control over business data by imposing access restrictions at the document level, regardless of where the document is stored or who tries to open it. A common IRM implementation lets you allow only authorized viewing or printing, but this can be extended to other scenarios such as requiring user credential verification after a certain time period; not allowing users to upload assets that don't take advantage of IRM; a scheduled expiration tag that will drop the restricting policy; and binding to a global organizational IRM permission policy.
The IRM functionality is provided by a protector, and several are installed with MOSS 2007. A protector is an application that manages the encryption process for a file type; typically all of the files you store within MOSS already have protectors built for them. (Microsoft Office system files are natively supported, along with the OpenXML file formats.) Like other providers within MOSS, however, the application architecture is pluggable so you can implement custom protectors for other file types.
The first step in implementing IRM is to ensure you meet all the requirements in your MOSS environment. You'll need to have WRM Services Client installed on every MOSS front-end Web server, and Microsoft Rights Management Services (RMS) must have connectivity to your MOSS front-end Web servers. Then you must specify the RMS server for MOSS to assimilate through SharePoint Central Administration, either by using the default in Active Directory or by specifying the location.
IRM works directly with SharePoint data store structures such as document libraries to maintain permissions. When a user navigates to an IRM-enabled document library and attempts to download a document, MOSS binds the permissions configured for the document library to the document (see Figure 4). As a result, there's a 1:1 mapping between MOSS and document permissions, translating SharePoint roles related to the document into IRM permission levels on the document itself.
Figure 4 Transition of IRM Premissions from a Document Library
Figure 4 Transition of IRM Premissions from a Document Library
The document is encrypted locally for offline protection and maintained in this state until it is uploaded back into the document library. When the document is uploaded, it is maintained in unencrypted form so the SharePoint gatherer can index its content for full-text searching (though no user account will be able to access the content in unencrypted form).
MOSS 2007 provides a number of new features that can help you implement effective security in your organization without adding a lot of management overhead. Even better, the features are very flexible, allowing a lot of customization that ensures users can access just the information they need. See the sidebar "A SQL Server Authentication Provider" for a simple example.

Adam Robert Buenz is a SharePoint Architect and Developer for ARB Security Solutions LLC (sharepointsecurity.com). He focuses on security-centric collaboration environments. Contact him at adam@sharepointsecurity.com.


 SharePoint: Find It All with SharePoint Enterprise Search
SharePoint Matt Hester

Find It All with SharePoint Enterprise Search
At a Glance:
  • Architecture of an enterprise search solution
  • Indexing and querying business data
  • LOB data and people knowledge

You probably spend a lot of time worrying about things like server uptime and availability, software updates, and security. But even if your infrastructure is running perfectly—every app and
every file available across the network-your users may still be losing productivity. Sure, all the data they need is available, but how long does it take them to find it?
A lot has been done to help people deal with information overload. Desktop search tools have made it easier to find that piece of information hidden among all the other data stored on your system. (See my August 2006 article "Find Anything with Windows Desktop Search". But what about all the data available on portals, stored in shares, and trapped in business applications, let alone the valuable information stored in various employees' heads. This information is vital to your users-they need this data to do their jobs, and they need it quickly for making timely and accurate business decisions. But think about how long it takes one of your users to find and gather data spread across the network. Now think about the potential impact this has on your enterprise's bottom line.
You need to reduce the amount of time it takes your users to track down information stored throughout the enterprise. How can you do this? The answer, quite simply, is by using a search engine that provides enterprise search capabilities.
Enterprise search can find information stored most anywhere in your organization. Whether looking for data stored on the desktop, tucked away on an intranet site, locked in a line of a business (LOB) application, or kept in a person's head, an enterprise search tool can help. (Don't worry, you won't have to implant any chips into your user's brains.)
An enterprise search solution combines desktop search with fast intranet searching capabilities. Ultimately, an enterprise search tool must be able to perform federated searches, ones that can access multiple data sources with a single query. The user has a single interface where he enters the query. However, underneath the covers, the query is sent to several different search engines and then the results are displayed in one aggregated view.
In this article I will discuss how Microsoft® Office SharePoint® Server 2007 (MOSS 2007), the next generation of Microsoft SharePoint solutions, provides a powerful search engine that will help you tear down the silos of information in your organization. MOSS 2007 offers numerous improvements from previous versions, completely redeveloped components, and some brand new features. Here I will discuss some of these key components-such as indexing, propagation, relevancy, and content sources-and how they will help you provide better enterprise search capabilities to your users.

Searching the Enterprise with SharePoint
Enterprise search will be available in four versions with key differences: Microsoft Office SharePoint Server 2007 for Search Standard Edition, Microsoft Office SharePoint Server 2007 for Search Enterprise Edition, Microsoft Office SharePoint Server 2007 Standard, and Microsoft Office SharePoint Server 2007 Enterprise.
The main difference between the two Search Editions and the full SharePoint Server editions is that the two Search Editions do not include the People Search functionality (which also includes the integration with Knowledge Network for MOSS 2007), Business Data Catalog, or the enhanced Search Center with customizable tabs. Figure 1 details the key differences.
Figure 1 Key Differences of the Four Search Offerings (Close Figure 1)

 | Microsoft Office SharePoint Server 2007 for Search Standard Edition | Microsoft Office SharePoint Server 2007 for Search Enterprise Edition | Microsoft Office SharePoint Server 2007 Standard Edition | Microsoft Office SharePoint Server 2007 Enterprise Edition
Indexes | 40 file types out of the box (extensible) | 40 file types out of the box (extensible) | 40 file types out of the box (extensible) | 40 file types out of the box (extensible)
Supports (out of the box) search on file shares, Web sites, SharePoint sites, Exchange Public Folders, Notes database files |  |  |  |
Supports search on third-party document repositories |  |  |  |
Supports search for people and Expertise |  |  |  |
Supports searching on structured data sources |  |  |  |
Provides secure content access control |  |  |  |
Provides enhanced Search Center UI |  |  |  |
Document limit | 400,000 | Unlimited | Unlimited | Unlimited
The UI offers a number of new features, including "Did you mean?" capabilities. A mainstay for Internet search engines, this advises you when you may have misspelled a common search term (see Figure 2). The interface also includes hit highlighting and full support for "best bets". But this only scratches the surface of the new search capabilities.
Figure 2 The New 'Did You mean...' Functionality in SharePoint Searches
Figure 2 The New 'Did You mean...' Functionality in SharePoint Searches

Finding People Knowledge
One of the most interesting new offerings is the ability to search for people with certain knowledge and expertise. This lets users tap into and leverage the knowledge held by employees throughout the organization-an important step in breaking down the silos.
To enable this, indexing and searching can be performed on any Lightweight Directory Access Protocol (LDAP) directory, including Active Directory® distribution lists and SharePoint user groups. In reality, MOSS doesn't search the LDAP directories directly; to enable people search, the LDAP information needs to be imported into MOSS. (Searches can also be performed across the entire enterprise infrastructure.)
Search results can be grouped according to an individual's "social distance"-this refers to the distance from a user's position (a sales assistant probably won't want to give the CFO a call) and common interests. Figure 3 shows the results from a people search.
Figure 3 Finding Colleagues with Relevant Knowledge
Figure 3 Finding Colleagues with Relevant Knowledge

Searching Business Data
SharePoint can also index various types of business data. This includes line of business applications (such as HR applications, CRM, expense reporting, and so on). Traditionally, this sort of data is hard to access outside of the LOB application's normal interface, making it difficult for the majority of employees to discover and use any of this data.
But now MOSS search can retrieve data from any LOB application, such as a relational database or a Lotus Notes database, that is accessible through ADO.NET or Web services. What's special about this is that it does not require custom code to be written. With the Business Data Catalog feature, getting this business data is as easy as accessing any document or Web site. The Business Data Catalog feature can be simply integrated with the property management and customized scopes offered by the Search Center.

Returning Relevancy
Of course, any number of new features would offer little value if they didn't produce accurate results. Fortunately, MOSS has made some dramatic improvements in relevancy. Before I discuss these improvements, however, it's important that you understand how relevancy in the enterprise differs from relevancy on the Internet.
You may wonder why intranet searches can't just rely on the same tools (and thus the same accuracy) as Internet searches. Simply put, these are two very different environments with very different needs and requirements. These differences can be grouped into three main categories: security, structure, and hierarchy.
Security refers to the simple nature of the Internet versus the enterprise. Data on the Internet is commonly accessible anonymously; indexing and searching does not require authentication or security trimming. An enterprise environment, on the other hand, must adhere to a strict security model, including filtering the results to match the searcher's permissions.
The impact of structure has to do with density. The Internet is very rich and deep, with sites linking to other sites to augment their content. But in the enterprise, links are typically used for navigation, and the structure is much less dense.
Loosely related to link structure is the site hierarchy factor. On the Internet, there is typically no hierarchy to the sites and very few top-level sites. An enterprise's intranets, however, are usually planned out and hierarchical in nature. Even when an enterprise has multiple main root levels, there is usually only one main portal for the organization.
These fundamental differences change the way in which an enterprise search solution indexes data and returns results. MOSS 2007 aims to better meet the different needs of the enterprise. It features a new ranking engine, which was developed using existing technology combined with work from Microsoft Research and the MSN® team. Relevancy was increased through the creation of a series of relevance algorithms, which gather both internal and external information about the documents and line of business data being crawled. When enterprise data is indexed, over 200 document types are scanned and algorithms are applied to detect language, extract metadata, and perform text analysis. These new algorithms, which are tuned specifically to meet the needs of enterprise data and LOB applications, dramatically improve the accuracy of results.
Several metadata tags are included in the relevancy calculations. Here are a few of the things considered:
  • Click Distance Browsing distance from authoritative sites (shorter distances tend to be more relevant).
  • Anchor Text Hyperlinks act as annotations on their target. In addition, they tend to be highly descriptive.
  • URL Depth URLs higher in the hierarchy tend to be more relevant.
  • URL Matching Direct matches on text that's in URLs.
  • Metadata Extraction Automatically extracts titles and authors from document text if they are missing.
  • Automatic Language Detection Helps create preference for results in your language.
  • File Type Biasing Certain file types tend to be more relevant (for example, PPT files are often more relevant than XLS files).
  • Text Analysis Traditional text ranking based on such factors as matching terms, term frequencies, and word variants.

How Does the Indexing Work?
MOSS 2007 has made important improvements in how the indexing service works and how content is managed. For starters, you can specify if the content sources are SharePoint servers, Web sites, file shares, Exchange Public Folders, Lotus Notes databases, or LOB apps. The overall indexing administrative experience has been streamlined, letting you freely choose what, how, and when to index across multiple content sources. This is handled through crawling rules, which let you specify paths to be included or excluded. You can even configure how the crawler follows the links of the URL. A built-in log gives a comprehensive view of the number of sites crawled and how they were indexed.
The index is similar to the index technology used in Windows® Desktop Search. Two main components make up the index: a content index and a properties store. This is an extremely efficient way to process the data. The content index includes the actual text contained in files as well as an associated inverted index of words that are in your enterprise index. The property store database is critical to processing the results. The property store database holds all the additional metadata properties (author, date created, document type, and so on) about all the documents in the store. Structurally, the property store consists of a table of properties and their values. Each row in the table corresponds to a separate document in the full-text index. The property store also maintains and enforces document-level security that is gathered when a document is indexed.
The indexing and storage process starts with the index engine, which is responsible for crawling the content source. The engine begins crawling after it has verified it has an appropriate protocol handler to read the content sources. Once the correct protocol handler for the content source has been loaded, the protocol handler and the necessary IFilters extract and filter the items from the content source. An IFilter is an add-in that enables the index engine to open, read, and index the contents of new file types it would not otherwise be able to fully index. IFilters extract the text and the metadata for each document and then pass the stream back to the index engine.
The document properties are then stored in the properties store, and the actual text of the document is placed in the content index. But just before that happens, the index engine removes "noise" words. The engine also processes the information using wordbreakers and stemmers to streamline the data, enabling better query execution. (Wordbreakers break the text into words and phrases. Stemmers generate inflected forms of a given word.)
The index engine uses continuous propagation, which allows the index to be built almost immediately. With continuous propagation, the index continues to be built even as the crawling process moves through the content sources. This enhancement allows for near immediate results-a dramatic improvement over SharePoint Portal Sever 2003, in which large content crawls could take days, and the index was only propagated when the crawl was completed.

How Does Querying Work?
When a user inputs a query or a custom application calls the index, the query engine begins processing the request. It first passes the query into a language-specific wordbreaker. If the language cannot be identified, a neutral wordbreaker is invoked. After the query is broken down, the engine passes the information to a stemmer (if stemming is enabled) for further processing. This two-step process improves the relevance and effectiveness of the results returned by the query.
If the query specifies property information, the content index is checked first for matches paired with documents in the property store, and then the properties in the query are checked again to ensure a match. The query engine does an additional level of filtering to remove results that the user does not have permission to access. The matching results are returned in a list, ordered according to relevance. Figure 4 outlines how all the components of indexing and querying fit together.
Figure 4 Architecture of the MOSS 2007 Enterprise Search Environment
Figure 4 Architecture of the MOSS 2007 Enterprise Search Environment

Enhanced Management
Administrators will find it easier to manage the search environment. An improved set of common tools for end users and administrators help to reduce the complexity introduced by the different connection points into the platform. And the search engine benefits greatly from the new management model in MOSS 2007. (Figure 5 shows the main page used for modifying search settings.)
Figure 5 Configuring Search Settings
Figure 5 Configuring Search Settings
Scopes, which allow you to control the different search capabilities, have also been improved. Scopes let you easily search within a content source, essentially allowing you to manage the index in smaller chunks. In SharePoint Portal Server 2003, scopes are connected to the content sources, making them less flexible and somewhat challenging to manage. In MOSS 2007, scopes are separate from content sources, offering a greater degree of flexibility. You can define scopes based on arbitrary content properties such as URL, type, or author. You can even combine scopes to have multiple rules, for example, all technical documents by a specific author.
Of course, if an administrator wants to improve the performance of the search engine, one of the most important things they can do is understand the current usage of the index. One of best new additions to the administrative toolset is query reporting. Out of the box query reporting functionality lets you quickly find information about query volume trends, top queries, click-through rates, queries with zero results, and so on. The query reporting can provide details at site level and the core service provider levels. Figure 6 shows a sample report. You can export the information to Microsoft Excel® for further analysis and for pivoting on the data.
Figure 6 Query Report in MOSS 2007
Figure 6 Query Report in MOSS 2007

Security and Privileges
As I mentioned earlier, the query engine filters out results so the list that the user sees only includes documents that the user has permission to access. (In SharePoint Portal Server 2003, the user is presented with links that he might not have proper permissions to follow.) One caveat regarding security trimming is that MOSS 2007 does not security trim Web crawls. You cannot trim the Web sites due to the fact that the HTTP protocol has no way to read back the access control info. Additionally MOSS 2007 doesn't let you security trim the Business Data Catalog or People searches.
MOSS 2007 respects the existing access control lists (ACLs), ensuring the security of documents in the index. This is a major differentiator from several other search tools. Unlike some search engines, which require you to use a config file to set permissions on files manually, MOSS 2007 allows you to keep in sync with current permissions.
The index can quickly reflect changes in the ACL for a single document. Say, for example, there is an Excel spreadsheet currently stored in the index and the ACL for the document is changed to be restrictive. An administrator can reindex and crawl just that one document and the security trimming will happen immediately (and, if necessary, the document can be completely removed from the index).
In addition, individual documents can be assigned unique permissions or be set to inherit the permission settings from a document library or parent directory. This makes the process of selecting the groups or individuals that are allowed to view, edit, and save documents much more straightforward.
There have also been enhancements to authentication and sign-on management. The secure credential cache is now extensible, making it possible for MOSS to accept single sign-on credential caching systems from third-party sources and custom-coded add-ons. In addition, the core authentication can now accept third-party systems. These two enhancements build on the new ASP.NET provider model, which allows the use of other directory services.

Customization
In MOSS 2007, you have a number of options for modifying the user interface. The UI can be customized with many of the tools you already use to modify Web sites. There are also new tools, such as the Office SharePoint Designer, which helps you build Master Pages (offering an easy way to build a branded site). Figure 7 shows a search results page being edited.
Figure 7 Customizing the Look of a Search Results Page
Figure 7 Customizing the Look of a Search Results Page
Out of the box, MOSS 2007 provides two tabs for the Search Center interface: All Sites and People. You can simply add additional tabs that reflect the different types of information your users search on most frequently. For example, you can provide a direct entry into any of your enterprise applications, databases, or even directory services. You can even correlate these tabs to scopes. This is handy for creating contextualized search tabs on specific content. Note that the search-only editions do not support this customization of the search tabs.

Wrap-Up
As you've seen, MOSS 2007 provides some pretty compelling new enhancements to enterprise search functionality, allowing your users to be more efficient and more productive. For more info, see Microsoft Office SharePoint Server TechCenter.

Matt Hester is a TechNet presenter on the Microsoft Across America team. To see him present live, please visit www.technetevents.com/mhester. Check out his blog at blogs.technet.com/matthewms.


 SharePoint: Powerful Command Line Administration for SharePoint
SharePoint Todd Klindt

Powerful Command Line Administration for SharePoint
At a Glance:
  • Configuring SharePoint with STSADM
  • Scripting daily administrative tasks
  • Advanced STSADM Operations

Think about how people interact with Windows or Microsoft Office. Some users are avid mousers, using the pointer to navigate menus and toolbars to perform common tasks. Others are comfortable
with the keyboard, quickly executing familiar keystrokes and shortcuts. For any given task, there is almost always several ways to get it done.
The fact is, a graphical interface can be easy to use, but it can be equally cumbersome for tasks that require you to do the same thing repeatedly. Some things are easier to do with the keyboard. If you do any SharePoint® administration, you've probably experienced what it's like to be bogged down in a graphical interface. But SharePoint actually offers a more powerful way to get things done.
The primary interface for managing Windows® SharePoint Services (WSS) and Microsoft® Office SharePoint Server 2007 (MOSS) is the GUI-based SharePoint Central Administration. But SharePoint also includes a command-line tool for more powerful administration. This tool, STSADM.exe, provides all the functionality of SharePoint Central Administration, but with the command-line flexibility many administrators desire. In this article, I will give you a crash course in using STSADM to manage WSS and MOSS. I'll also give you some tips on how to configure your environment and discuss some common STSADM commands. I will even show you some advanced STSADM commands that can make you look like a hero-if the need to use them ever arises.

Getting Started
If you haven't stumbled upon STSADM, it could be because it is somewhat buried. In Windows SharePoint Services 2.0, it's in c:\program files\common files\microsoft shared\web server extensions\60\bin by default. The default location in version 3.0 is c:\program files\common files\microsoft shared\web server extensions\12\bin.
To simplify access to this tool, I use two different approaches. First, I simply add that directory to my PATH environment variable. This way I can use STSADM wherever I am in the file system. This, however, is not always an option. My second approach is to create a shortcut to CMD.EXE and set STSADM's location as the initial directory. Why not just point a shortcut directly to STSADM? This doesn't work since STSADM is not interactive. As a result, if you do point a shortcut directly to STSADM, you will be presented with a quick display of its usage and then it will be gone.
When you run STSADM, you need to be a member of the local Administrators group on the Web server, and you need to execute the app locally. This means you cannot use STSADM to remotely administer a SharePoint server.
To see what operations you can perform with STSADM, type stsadm.exe -help in a command prompt. Be sure to check this list after you apply updates and hotfixes to SharePoint since new operations may be added. There is also a handy guide to stsadm.exe operations available at go.microsoft.com/fwlink/?LinkId=77516.

STSADM Basics
Let's start by looking at some of the commands you might use to tweak your existing SharePoint installation. You can use STSADM to add functionality to SharePoint and to modify configuration settings.
STSADM uses the -o parameter followed by the operation you want to perform. Just typing STSADM -operationname will not work. If, for example, you want to add site templates to your installation, you can use the following command:
Stsadm -o addtemplate -filename <filename of the template>
-title <title of template> -description <description of template>
Or, if you want to add a Web Part Package, you can use this command:
Stsadm -o addwppack -filename <filename of the Web Part Package>
For details on usage for any operation, simply pass the operation with no parameters and STSADM will tell you what it expects for input. STSADM -help operationname will also give you usage info.
When managing templates, you can use the enumtemplates operation to see which templates have been added and deletetemplate to remove any that are installed. Similarly, there are commands to work with Web Part packages. You can use the enumwppacks operation to list the Web Part packages installed on each virtual server or Web application, and deletewppack will let you remove any that have been added.
STSADM also has two operations that deal with SharePoint settings: setproperty and getproperty. Executing either with no parameters will give you a list of the properties you can view or manipulate. Like STSADM itself, this list changes with updates and hotfixes. Nevertheless, there are a few properties that are more useful than others. Figure 1 lists some of the properties you may want set after you get SharePoint installed, including the most common properties I hear SharePoint administrators ask about.
Figure 1 Setting Useful SharePoint Properties (Close Figure 1)

Property | Function
Alerts-enabled | Turns alerts on or off for your virtual server or Web application.
Alerts-limited | Specifies whether users are restricted to setting a certain number of alerts on the virtual server or Web application.
Alerts-maximum | If alert limits are set, this is the maximum number of alerts that a user can set.
Days-to-show-new-icon | This sets how long the "New" icon appears next to items added to the Web site, like announcement posts, for instance.
Job-immediate-alerts | Specifies how often SharePoint looks for immediate alerts to send out. The default for SharePoint 2.0 is five minutes. You can adjust that interval here. Decreasing the time will increase load on your Web and database servers, so keep an eye on it if you change this property.
Job-daily-alerts | Specifies what time the daily alerts are sent out. SharePoint 2.0 defaults to "between 22:00 and 06:00." If you have users who are not in the same time zone as the server, you may want to adjust this property.
Job-weekly-alerts | You probably see the pattern here. This sets the schedule for weekly alerts.
Let's take a quick look at using one of these properties. The following command will have SharePoint send out immediate alerts every 10 minutes:
Stsadm -o setproperty -pn job-immediate-alerts -pv "Every 10 minutes"
Notice I used -pn and -pv instead of -propertyname and -propertyvalue. These are acceptable shortcuts for those times when you don't want to type the entire word. Also note that all the examples and commands I have discussed in this section will work for both versions 2.0 and 3.0 of Windows SharePoint Services.

Daily Administration
Day-to-day SharePoint administration is pretty easy. For most SharePoint administrators, the bulk of daily tasks consist of working with users and sites. STSADM has several operations to streamline these tasks.
I'll start with sites and webs. For purposes of consistency, I will use "site" to refer to site collections and "web" to refer to subsites (also known as subwebs). Some of the terminology is tricky, but if you stay consistent with what STSADM uses, it will be easier to find the command you need.
If you run a large SharePoint installation, you probably spend a lot of time creating new sites for users. I know I find myself repeatedly doing this. Creating new sites can be done quite easily in SharePoint Central Administration. But since I perform this task so often, I find it faster to use STSADM to get the job done.
I use the createsite operation. This is quite simple and takes the following parameters:
  • url <url>
  • ownerlogin <DOMAIN\name>
  • owneremail <someone@example.com>
  • ownername <display name>
  • lcid <language>
  • sitetemplate <site template>
  • title <site title>
  • description <site description>
  • quota <quota template>
You can bring these up at the command prompt by typing stsadm -help createsite (see Figure 2). Of these nine parameters, the only mandatory fields are URL, ownerlogin, and owneremail.
Figure 2 Createsite Parameters
Figure 2 Createsite Parameters
If you have sites that you create on a routine basis, you can go a step further in streamlining the process by writing a wrapper script around STSADM to automate the task. For instance, to automate the creation of personal sites, you can save the following to a text file named createpersonalsite.cmd:
stsadm -o createsite -url http://localhost/users/%1 -ownerlogin contoso\%1
-owneremail %1@contoso.com -sitetemplate usersite.stp
-title "Personal site for %1" -description "Personal site for %1" -quota "500 MB"
And then to create a site for the user jsmith, you could simply execute the following:
createpersonalsite.cmd jsmith
By scripting site creation, you save yourself a lot of typing and can make sure all your newly created sites are consistent. The operation createweb provides the same functionality at the web level.
In Windows SharePoint Services 2.0, the only easy way to get an exhaustive list of the site collections on a particular virtual server is to use STSADM. Enumsites lists in XML format all of the site collections on a specific virtual server or Web application. This can be coupled with a Data View Web Part to easily view a list of site collections. (See the sidebar "Working with a Data View Web Part" for more information.)
STSADM provides a deletesite operation for, as you can guess, removing sites. All you need to do is provide the URL. Optionally, you can pass it -deleteadaccounts to have the accounts deleted in Active Directory®. When working with webs you would use the deleteweb operation.
You can also add, delete, and enumerate the users of a site or web. The associated operations are adduser, deleteuser, and enumusers. These operations are handy if users need to be added to a site in bulk, or if you need to maintain a list of users who have access to a site for auditing purposes.
When working with webs you have access to an additional operation, renameweb, that lets you change the name and URL of a web. For example, to rename a web from "oldname" to "coolnewname," use the following:
Stsadm -o renameweb -url http://localhost/oldname -newname coolnewname
This can be a life saver when project names change or business units are realigned. In Windows SharePoint Services 2.0, this is a big issue, as the only way to migrate webs is with SMIGRATE.exe, which does not maintain any user-related settings like membership or alerts. With Windows SharePoint Services 3.0, this is less of an issue, as STSADM can back up and restore webs and sites.

Backing Up and Restoring
One of the best uses for STSADM is backing up and restoring sites and webs. For small to medium-sized installations, this functionality can be the cornerstone of a disaster recovery plan. The backup operation is self-explanatory and very easy to use. Simply tell STSADM which site to back up and where to write the backup file, like this:
Stsadm -o backup -url http://localhost -filename site.bak
This operation dumps the entire site collection to the file site.bak. It includes all site content, such as webs, document versions, lists, and users. It does not back up any site definitions or changes you've made at the file system level of your servers.
While the backup operation is important, it does have a few snags to keep an eye on. If the site is large enough, the Content Database may be locked during the backup process. This may prevent users from accessing any sites in that database until the backup operation is finished. This issue has been mitigated with service packs, but it is still something to keep an eye on as your sites grow. STSADM also uses the server's temp directory when doing backups and restores, so monitor your drive space.
Working with a Data View Web Part
You can couple the enumsites command with a Data View Web Part to create an easy way to view a list of site collections. Let's see how.
First, create a scheduled task that runs:
stsadm –o enumsites –url http://localhost
>c:\inetpub\wwwroot\excludedsite\sites.xml
Make sure the XML file is being written out to a directory that is published with IIS, but not managed by SharePoint. Then use Microsoft FrontPage® (or the FrontPage successor, Microsoft Office SharePoint Designer 2007) to add a Data View Web Part to a Web Part page and point it at the URL of the XML file.
The Data View Web Part provides functionality like sorting, filtering, and grouping. You can also make the URL field a link to take you directly to the site. If you would like a list of webs instead, the operation enumsubwebs provides an XML output of the subwebs in a site collection or web.

Finally, keep in mind that while STSADM backups work well for small to medium sites, the functionality does not scale particularly well. For very large sites (several gigabytes or more), the backup and restore processes can slow down quite a bit.
Restoring a site is equally simple. STSADM -o restore takes a file created by STSADM -o backup and writes it to a site in SharePoint. You have a lot of flexibility with this command: you can restore a site back to its original location (if, for instance, the site was erroneously deleted), you can restore it as a different site on the same virtual server (perhaps if you want to test a process on a site without the risk of destroying data), or you can restore the site to a completely different server or virtual server.
Restoring to a different site or server makes it a bit easier to do individual document recovery. If you have a site backed up and a user needs a document restored, you do not need to restore the entire site. That would sacrifice all changes made to the site since the backup was stored. Instead, you can just restore the site to a different URL, grab the documents, and save them back to the original site.
In Windows SharePoint Services 2.0, STSADM has one fairly serious limitation. When backing up, it can only deal with sites, not with webs. Administrators made their discontent known and Microsoft responded. In Windows SharePoint Services 3.0, the backup and restore operations can now handle webs. It also adds two new commands: import and export.
To export a web, use the following simple command:
Stsadm -o export -url http://localhost/web -filename backup.dat
Export has handy options, including the -versions switch. This allows you to decide how large your backup files will be by restricting which file versions will be backed up.
To import a web back to the server, use the following command:
Stsadm -o import -url http://localhost/web2 -filename backup.dat
If your site is large enough, the backup file might be in multiple parts. In this case, point STSADM -o import to the first file and it will automatically grab the subsequent files.

Expert Operations
Now that you are comfortable with STSADM, I want to show you a couple of operations you can use to get out of a bind. The first is a newly added operation called migrateuser. Version 2.0 does not sync itself with Active Directory. If an account is renamed, it can no longer log in to SharePoint. In the past, there was also no way to migrate user access from one domain user to another. Before Windows SharePoint Services 2.0 Service Pack 2 (SP2), you had to remove the user from every web and manually add the new account.
SP2 introduced a new API and STSADM takes advantage of it. If the account jsmith is renamed to jjones, you can use the following command:
Stsadm -o migrateuser -oldlogin domain\jsmith -newlogin domain\jjones -ignoresidhistory
Since you're not actually migrating accounts, you can ignore Windows security ID (SID) history. Note that this command does not require a URL. It makes the change throughout the content databases, without regard to sites or webs.
Another operation that can get you out of a bind is unextendvs. If you do not want SharePoint to render a virtual server or Web application, you unextend it. Normally, you would do this from the SharePoint Configuration Analyzer. However, in a Web farm, SharePoint Configuration Analyzer requires that your servers are all at the same patch level. It is possible for a server to be out of sync with the rest of the farm and, therefore, it will not get the unextend option in SharePoint Configuration Analyzer. Using STSADM, though, the following command will unextend your virtual server:
Stsadm -o unextendvs -url http://localhost
Once the server is no longer in the Web farm, you can perform the maintenance you need.
On the subject of Web farms, for ease of administration, you may want all of your servers to have SharePoint Configuration Analyzer on the same port. The port is randomly generated when SharePoint is installed, but STSADM includes an operation to change the port to one you specify:
Stsadm -o setadminport -port 1026
This makes all the necessary database changes, it makes the IIS changes, and it adjusts the shortcut to SharePoint Configuration Analyzer in Administrative Tools.

Conclusion
Windows SharePoint Services is a powerful solution and it requires powerful administration. STSADM provides a way to accomplish SharePoint administration, including the automation of configuration and common day-to-day tasks. In fact, sometimes it is the only way to get the job done.

Todd Klindt is a Systems Analyst at UGS where he plays with SharePoint all day long—and gets paid to do so. He is also a Windows SharePoint Services MVP, and an Aquarius.


 SharePoint: Wiki While You Work
SharePoint Mauro Cardarelli

Wiki While You Work
At a Glance:
  • What's a wiki?
  • Building a wiki in SharePoint
  • Editing and tracking changes

The wiki concept has been around for over 10 years. In its simplest form, a wiki—the Hawaiian term for "quick"—is an online destination where users can freely create or edit Web page content
using only a browser. The goal is to provide a space where members of a virtual community can edit any page with full freedom to introduce, alter, or remove content, including anything created by previous authors. Unlike blogs, which are designed for more structured knowledge exchange and one-to-many communication, wikis enable a more collaborative experience.
Much attention has been given recently to the next generation of online tools, dubbed Web 2.0. The premise is that barriers surrounding content creation will be lowered, allowing users to be producers as well as consumers of online information. This phenomenon is occurring not just in the Internet world but also within corporate firewalls. You should think of it as Enterprise 2.0-tools that make content creation easier for all employees. Technologies like blogs and wikis will go a long way in changing how companies think about, store, and recycle corporate knowledge.
Microsoft is facilitating this next-generation capability with the introduction of Microsoft® Office SharePoint® Server (MOSS) 2007, the third version of the popular SharePoint technology. MOSS 2007 offers extended collaboration and communication functionality, including support for the creation of blogs and wikis. This article discusses how to get started building wikis with MOSS 2007.

Getting Started
If you've worked with SharePoint Portal Server 2003, the use of site templates should be very familiar. Site templates provide a framework for the layout of a particular type of page (a team or meeting or social event, for example) that presets placeholders for specific content. MOSS 2007 extends the use of site templates by introducing a new collection of template types. One of these is for a wiki.
Figure 1 shows the New SharePoint Site page used to create a SharePoint site. Notice that in the template list there's an item for Wiki Site. By selecting this template, you can quickly and easily create your first wiki. Take a look at Figure 2, which is the default rendering of the newly created wiki. The structure of a wiki is such that this default page is your home page. Everything here can be edited. Properly authorized users-your virtual community-can modify this page or create new pages.
Figure 1 Selecting the Wiki Template for a New Site
Figure 1 Selecting the Wiki Template for a New Site
Figure 2 Your New SharePoint Wiki, Waiting to be Edited
Figure 2 Your New SharePoint Wiki, Waiting to be Edited
Before we go any further, let's take a step back and talk about introducing wikis to your users. As I mentioned, wikis have been around on the Internet or through third-party tools for some time. For the most part, however, the use of wikis has been highly specialized and has grown slowly, through word of mouth. MOSS 2007 is poised to change this by offering wiki functionality to all intranet users. This is a very powerful (and potentially scary) proposition! How do you explain the value of a wiki to a non-technical, non-Internet-savvy coworker? What you need to tell them is that wikis are intended to foster creative exchanges of opinions and ideas in an environment free enough to offer all users a voice. They enable content collaboration, but they're actually a lot more. The end result of a wiki is not a document or a chapter, but rather a book-a book that need never be finished, that you can modify whenever necessary.
OK, back to work. For first-time wiki users, online guidance is available via the How to Use This Wiki Site hyperlink. The default wiki template comes with sufficient documentation to get new users comfortable and contributing quickly.

How Wikis Work
On every wiki page, you'll notice action buttons on the upper-right side. If you click on the one labeled Edit, you'll be directed to the page associated with content editing. Figure 3 shows an example. All editing happens in the browser-there is no need to use external tools like Microsoft Word. And the edits take place online and in real time (once saved). Moreover, no Web design or development skills are required. The edit interface allows for full rich text creation (bolding or colors or bullet points or images), all with the use of standard buttons. A user simply opens an existing page in edit mode and adds or modifies content. That's it.
Figure 3 Editing Wiki Content Entirely within the Browser
Figure 3 Editing Wiki Content Entirely within the Browser
In an environment where content is ever evolving, how do you manage the changes? You may not necessarily feel the need to police all contributions, but you probably want some means of tracking changes and maintaining version history. MOSS 2007 lets you do this. Figure 4 shows what a standard page looks like after you click the History button. In the center, you'll notice that all edits to the text have been tracked. On the left, you can see the history of changes, tracked for each time a change was made. The community has full power to review, track, and even roll back changes. This is a powerful concept. As you're building and changing your wiki, MOSS 2007 is tracking that movement.
Figure 4 Tracking Changes to a Wiki Entry over Time
Figure 4 Tracking Changes to a Wiki Entry over Time
As noted, a wiki is not a Web page. It is a collection of limitless pages. As a member of a wiki community, you may decide to introduce a new idea or discussion point. Rather than adding text to an existing page, you may want to branch off onto a new page. MOSS 2007 supports this by allowing easy addition of wiki pages. Simply click New and you've spun off a new wiki page. Start adding content and you're on your way!

Conclusion
MOSS 2007 may not have introduced the concept of a wiki but, given its wide availability, it does make them much more appealing. Wikis can transform the way organizational workers collaborate-they are no longer bound by the limits of a document. Wikis encourage unstructured thinking and broader collaboration, and this integrates nicely into the broader concepts associated with the Enterprise 2.0 philosophy. Wikis are enablers; they allow all users to participate-and not only to follow along but also to head off in new directions.

Mauro Cardarelli is a Managing Partner at Jornata, a Boston-based IT consulting services company. His responsibilities include technology evangelism, architecture design, and software development. He can be reached at mauro.cardarelli@jornata.com.


 From the Editor: Sometimes industries
From The Editor

Sometimes industries undergo seismic changes. This holds true not only for technology, but for politics, fashion, and everything else. I was thinking about this a few weeks ago when I was speaking at the Windows Connection conference in Las Vegas. Five years ago in November I would've been at Comdex—a huge show that served every possible segment of the world's technology buyers and learners. But the show, which had grown steadily for almost two decades, disappeared almost overnight. So instead of attending a huge, widely focused show, I was speaking at a very successful show that was narrowcasted, with an emphasis on a few developer and IT products. I was reaching the same people in the same location, but the scale was more rewarding for all those who attended.
My talk was all about technical writing—how to do it, where to do it, and why. The changes in our industry are reflected not only in the history of Comdex, but in the world of technical communications. Five years ago, I gave a similar session, and it was all about magazines. Back then, few people had heard of blogs. Community sites were just a shadow of what they are now. In the past five years, we have seen a permanent change in how the written word is transmitted, on a scale never seen before.
This is a mixed blessing, of course. Different forms of communication serve different purposes. People can put their thoughts online spontaneously, but having those thoughts appear in a magazine usually means that the words have been edited and technically vetted. You can pull a blog post down, but you can't go to everyone's house and ask them to rip out a section of page 28.
Anyway, there's a reason I'm talking about all this change. In response to the numerous readers who have provided us with feedback on the magazine, we are expanding our lineup of columns. In this issue, we are giving you the first installment of The Cable Guy, a popular TechNet online column that's now making the leap to the printed page. We also heard from all you postmasters, and we know that Exchange Server 2007 is about to become a big story, so we are launching Exchange Queue & A as a regular column. (Stop it, it's a cute name!)
If you'd like to see a Microsoft technology featured in the magazine, please drop us a line. The best way we can serve you is to give you what you need. —Joshua Trupin

Thank you to the following Microsoft technical experts: Puneet Arora, Jeff Bienvenu, Nino Bilic, Eric Broberg, Ramesh Chinta, Matt Cohen, Michael Dalton, George Irimescu, Bryan Jeffries, Dave Kong, Vijay Krishna, Rob Lefferts, Lawrence Liu, Bob Ma, Manu Namboodiri, Joel Oleson, Arpan Shah, Troy Starr, James Sturms, Jim Truher, and Blaine Young.


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

Server Administration
Windows Server 2003 Resource Kit Tools
go.microsoft.com/fwlink/?LinkId=77796
The Microsoft Windows Server 2003 Resource Kit Tools is an invaluable set of over 100 utilities that can help you streamline and automate your administrative tasks. It includes everything from Active Directory® tools to network troubleshooting utilities to CD/DVD image burners.
The Custom Reason Editor (custreasonedit.exe) is a great tool for getting your Shutdown Event Tracker organized. A component of Windows Server® 2003, the Shutdown Event Tracker logs reasons for system shutdowns to the event log. Meanwhile, the Custom Reason Editor tool lets you create a custom list with configurable parameters that will override the built-in reasons that are enabled by default. This tool can make it easy to aggregate and identify troubling processes, applications, or system states that lead to a shutdown by keeping event items logical and organized.
The DNS Resolver Tool, a command-line utility that simulates the SMTP service's execution of DNS resolution, displays messages regarding the status of the DNS query you specify as a command parameter. This utility will run on any Windows Server 2003 host with the SMTP service installed and will return error codes you can use in batch files. CDBurn.exe and DVDburn.exe are command-line utilities that let you create CDs and DVDs from ISO images and provide limited support for RW media with the /Erase switch that will clean the media before applying the new disk image. They can be used, for instance, to automate archival processes in your infrastructure.
Windows Server 2003 Resource Kit
Windows Server 2003 Resource Kit
If you need to verify whether an account has been successfully locked out, the Account Lockout Status tool makes it quick and easy with both a command-line and GUI option. The tool queries every reachable domain controller and checks the status of the target user's account. Perhaps one of the best tools for automation, the Robust File Copy Utility, Robocopy.exe, gives you a variety of options for moving or copying files. This tool lets you use wildcard characters and even file attributes to specify candidates for copying, and copying can be selectively set to be recursive. You can use the tool for synchronization, and set it to delete destination files or directories that have been removed from the source directory.
Another one of my favorite utilities is the simple tool Tail (tail.exe) which, like the Linux/UNIX utility, lets you display the last N number of lines from a file, refreshing the display when new lines are added. This is great way to debug or monitor any task that writes to a log file.
Time It (timeit.exe) lets you time commands and stores the data into its own database file letting you test how long your administrative tasks are really taking.
You should note that the tools have not been localized, having been written and tested in English only, and may "produce unpredictable results" upon execution. Be sure to test on your non-English-based systems before you use one of these utilities in a production environment.
Price: Free download.

Track Problems
ASP.NET Issue Tracker
www.ASP.NET/StarterKits/WhitePapers/Issue%20Tracker%20Whitepaper.htm
There are two things that, in my mind, always make an application better: when it's free and when it's customizable. The ASP.NET Issue Tracker, which is provided through the ASP.NET online developer community, is both of these things. Designed as a Starter Kit for learning to program Web applications under the ASP.NET 1.1 framework, Issue Tracker is a simple, but useful tool for tracking issues related to projects.
The interface is straight forward and lets you create projects, users, and issues with ease. The application supports multiple users with role-based permissions, protecting issues from unwanted eyes. You can also create custom issue categories for each project and custom data fields of various types. Tasks can be assigned a status, a priority, and a milestone, which helps organize your projects.
Another cool feature is that upon project creation, you can specify your own status codes, priorities and milestones for each project and assign an image to represent it. All the code is available in the download, so, if you have a .NET developer on hand, or can work your way through existing code, you can use the starter kit as a basis for any custom functionality you may need.
Price: Free.

Systems Monitoring
NetHealth Sentinel Professional
www.nethealthsys.com
Network and systems monitoring are essential, and I'm always on the lookout for apps that give me insight into machine health from a distance. NetHealth Sentinel Professional, from NetHealth Systems, does just that.
An agent-based solution, Sentinel Professional gives you deep insight into monitored host machines. The application is split into four components: the Admin Server, the Admin Console, the Connection Manager, and the Remote Agent. The Admin Server executes scheduled tasks, stores configuration information, and collects alerts via the Connection Manager.
The Admin Console is the graphical interface to the Admin Server that allows you to view and configure your monitored systems as well as set up any scheduled tasks or events. The Connection Manager gathers all the data from the Remote Agents—host agents that reside on your monitored system. The Remove Agent runs as a Windows service and securely communicates to the Connection Manager via a secure connection. Each Remote Agent can be configured to send alerts to one or more Connection Managers.
NetHealth Sentinel Professional
NetHealth Sentinel Professional
One nice feature is the aggregation of Events from all the machines on a specified monitoring group. The smooth GUI also lets you drag and drop data columns from the Event view to group by item.
The application also offers the Vital Signs panel which gives you a quick overview of whatever statistics you would like to monitor. By default, you can see CPU, disk, and memory utilization, but you can add, via the Monitor tab, counters of your choosing.
NetHealth Sentinel Professional also includes a baselining feature that allows you to set levels for a machine's "normal" operation and then triggers alerts if operation exceeds one of those established baseline values.
Price: $495 for a 10 Client Access License pack.

Data Encryption
TrueCrypt
www.truecrypt.org
TrueCrypt, from TrueCrypt Foundation, is a free, open-source "on the fly" encryption tool that, with the correct password or encryption key, will decrypt information you are trying to read or encrypt data you are trying to write in memory, from and to your encrypted volumes. But don't worry—at no point does your volume exist in a decrypted state. Only if you have a memory dump while the application is decrypting data in memory could an aggressor find what information you are trying to protect. That can easily be avoided by turning off memory dumps on your system, not to mention that only a small portion of your data exists in memory decrypted at any one time.
The application supports both virtual volumes and physical partitions or devices. Virtual volumes, dubbed "file containers" by the authors, can be created with any file extension or have no file extension at all, so to peering eyes your sensitive data will appear to be made up of random data; there is no TrueCrypt "file signature."
TrueCrypt
In addition, you can run TrueCrypt in "traveler mode" which essentially means you can create a file container on a USB key along with the application files and take your encrypted data with you wherever you go without requiring installation of the TrueCrypt application on the host system. But, by the nature of the read/write via memory, you will need administrative privileges on the system you want to use your traveler disk on.
TrueCrypt has a simple wizard to set up your traveler disk as well. This would be a great way to carry around your sys-admin information and not have to worry (as much) about eyes peering into sensitive corporate data.
For another extra level of security, TrueCrypt also lets you create a hidden volume within a file-container, so even if an intruder mounts the outer volume, he won't be able to discover that there is an inner hidden volume on the disk. Every volume is initialized with random data, making the hidden volume that resides in the outer volume "free space" very difficult to detect.
TrueCrypt can use AES, Blowfish, CAST5, Serpent, Triple DES, Twofish, and a few combinations of those algorithms to encrypt your data. The application uses the LRW mode of operation for encryption, which is to become an IEEE standard for sector-based storage encryption. For the header hashing algorithm, you can choose to use Whirlpool, SHA-1, or RIPEME-160, and the application will not store any hash on your system as an added layer of protection. The applica-tion supports FAT12, FAT16, FAT32, and NTFS file systems, but as with other Windows-based sector encryption utilities out there, it doesn't let you encrypt a Windows boot partition.
Price: Free.

Book Review
Hacking Web Services
www.charlesriver.com
Shreeraj Shah's Hacking Web Services (Charles River Media, 2006) is a valuable resource for those involved in development, deployment, or support of Web services. The book is a well-organized general security reference for Web services and their component technologies. And it does a good job of detailing what is involved in defending them in your infrastructure and through your development practices.
The book begins with a relatively in-depth introduction to Web services A case study titled "The Consequences of Procrastination" teaches you about the power of preemptive security procedures and the penalties of reactive systems. The chapter titled "Web Services Scanning and Enumeration" discusses how to use the wsChess, a .NET-based Web service security toolkit from Net-Square (net-square.com/wschess/index.shtml), to profile and footprint Web services.
The book includes a utility CD, which contains a sample .NET-based application called SOAPWall. This shows you how to block injection characters and buffer overflows in your .NET Web services. In addition, the CD provides demos of different types of Web service attacks.
Price: $49.95.
Shreeraj Shah's Hacking Web Services (Charles River Media, 2006) is a valuable resource for those involved in development, deployment, or support of Web services. The book is a well-organized general security reference for Web services and their component technologies. And it does a good job of detailing what is involved in defending them in your infrastructure and through your development practices.
The book begins with a relatively in-depth introduction to Web services A case study titled "The Consequences of Procrastination" teaches you about the power of preemptive security procedures and the penalties of reactive systems. The chapter titled "Web Services Scanning and Enumeration" discusses how to use the wsChess, a .NET-based Web service security toolkit from Net-Square (net-square.com/wschess/index.shtml), to profile and footprint Web services.
The book includes a utility CD, which contains a sample .NET-based application called SOAPWall. This shows you how to block injection characters and buffer overflows in your .NET Web services. In addition, the CD provides demos of different types of Web service attacks.
Price: $49.95.

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

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

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


 Utility Spotlight: Internet Explorer Administration Kit
Utility Spotlight
Internet Explorer Administration Kit
Lance Whitney
Download the code for this article: Utility Spotlight: Internet Explorer Administration Kit 7 (KB)

Your CIO has asked you to install the latest version of Internet Explorer 7 throughout your organization. The deadline is tight, the budget is small, and the requirements are many. You need a customized package that will apply the same features and settings to all your users. You also need to be able to change those settings whenever necessary.
Plus, you need to lock down Internet Explorer® so users can't modify any settings. How can you create and deliver this type of Internet Explorer install quickly and easily?
Here's Microsoft to your rescue with the Internet Explorer Administration Kit, affectionately known as IEAK. This free configuration tool was created to help IT administrators, developers, ISPs, and others create customized installation packages for Internet Explorer. In fact, Yahoo! employed the beta version of IEAK 7 to create a customized Internet Explorer 7 package to download from the Yahoo! Web site.
The Internet Explorer 7 build you create with IEAK needs include only the features and options you specify. You can enable specific security settings and lock out any controls you don't want your users to access.
After Internet Explorer is deployed, those of you with Active Directory® can, of course, use Group Policy to control and update the browser settings. Or, if you like, you can use IEAK to manage the diverse array of Internet Explorer settings.
IEAK 7 is user-friendly, more so than previous versions, providing a simple graphical interface to create your Internet Explorer package. Step-by-step screens guide you along as you select the features and options to incorporate into your build.
The new release of IEAK offers a few changes over prior versions, with some options added and some retired. You now can add default RSS Web feeds to your Internet Explorer build, point to more than one home page and search page, and add support for an anti-phishing filter. You can also set the Microsoft® Windows® Malicious Software Removal Tool to run and update. However, you can no longer customize Outlook® Express and Windows Media® Player with IEAK as those applicationss aren't included with Internet Explorer 7.
You can create an Internet Explorer package for 32-bit or 64-bit platforms-Windows XP with Service Pack 2 (SP2), Windows Server® 2003 with SP1, or Windows Vista™-x86-based, x64-based, or Itanium-based. Before you run IEAK 7, Internet Explorer 7 must be installed on the PC you use to create your package. For compatibility, you should run IEAK on a computer with the same OS as the computers on which you'll apply the build.
In this column, I'll discuss how to use IEAK to create your Internet Explorer 7 installation build and maintain or update your browser settings.

How to Get IEAK 7
You can download the latest version of IEAK 7 for free from microsoft.com/technet/prodtechnol/ie/ieak7. In addition, this page provides documentation and release notes on IEAK, which are worth reading.
When you install IEAK 7 through the downloaded ieak.msi file, you're asked what type of license to use based on your role-ISP, Content Provider or Developer, or via a Corporate Intranet. The screens you see and the type of package you build vary, depending on the role you choose. Thus, if you're creating the build for a business environment, be sure to select the role and license for a Corporate Intranet. After IEAK is installed, a new Program Group called Microsoft IEAK 7 is created on your Start menu containing three items-IEAK Help, IEAK Profile Manager, and Internet Explorer Customization Wizard.
You'll use the Internet Explorer Customization Wizard to build your installation package. Using this wizard is fairly simple as each screen leads you through the process of designing your package. So, what's the catch? Well, knowing how to configure each option requires a clear understanding of the features and controls in Internet Explorer. Fortunately, IEAK 7 can help here too. The tool's built-in help is more detailed and descriptive than in previous versions. A Help button appears on each screen of the Customization Wizard to explain that screen's settings and options. You can access the entire IEAK help file from the IEAK Help shortcut or through the IEAKHelp.chm file in C:\Program Files\Microsoft IEAK 7. I recommend reading the documentation before you create your build to understand each component and plan out the options you require.
The Customization Wizard divides the package creation into the following five distinct stages:
  1. Gathering Information
  2. Specifying Setup Parameters
  3. Customizing the Setup Experience
  4. Customizing the Browser
  5. Additional Customization
Microsoft has streamlined the number of screens you must contend with in IEAK 7, so the process is clearer and cleaner than in prior versions. However, the Customization Wizard still conjures up dozens of screens where you choose the options for your package. As a result, I won't go through every screen in this column-many of them are self-explanatory and I've explained how to access Help for the more intricate ones. Instead, I will provide a brief description of what each stage does and discuss a few of the more important screens.
Stage 1 Gathering Information Here you decide where to store your installation package, what OS and platform it will run on, how you wish to distribute Internet Explorer, and which options to customize. In this stage, you can specify any of three distribution methods for Internet Explorer 7, as displayed in Figure 1-a File installation, which creates a flat directory structure with the files that comprise your build; CD-ROM, which creates an installation disk (handy if you support remote users); and a Configuration-only or Branding-only package, which applies your customized settings to an existing installation of Internet Explorer 7. You might use the last option for Windows Vista if Internet Explorer 7 is already installed, and you want to apply your own customizations to it.
Figure 1 Specifying a Distribution Method
Figure 1 Specifying a Distribution Method
In this stage you also specify which language to use for your build. You can create localized versions of Internet Explorer 7 for each language you need to support.
Stage 2 Specifying Setup Parameters Here you download the latest components and updates for Internet Explorer to build your package.
Stage 3 Customizing the Setup Experience In this stage you choose the installation your users will receive-Interactive (where the user is presented with choices during the installation), Hands-free (where the user can see the installation taking place, but cannot intervene), or Completely Silent (where the installation runs completely in the background without user interaction). If you're building a CD-ROM, this stage will prompt you to create a start page and other elements for the CD.
Stage 4 Customizing the Browser Here you customize the appearance of Internet Explorer; set the URLs for Home Page, Support Page, and Favorites; configure your proxy settings; and establish the privacy and security settings for the browser. In this stage, you can also specify the name and location for an auto-configuration file, or an Internet settings (INS) file, with which you can manage your browser settings if you don't use plan to use Group Policy.
The INS file is a simple text file that contains all the major browser settings, from home page to Favorites to security options to proxy configuration. You store this INS file on an internal Web server. Each PC then points to this file to get its browser settings. If you need to modify any setting in the future, simply edit the INS file, and your users automatically receive that change. You can specify the frequency at which the settings are updated and applied.
Also in this stage is the opportunity to establish your proxy servers, either by manually entering their IP addresses and port numbers or by creating and specifying the name of a JScript® (JS), JavaScript (JVS), or Proxy Auto-Configuration (PAC) file with your proxy information. IEAK Help provides examples of code you can use to create these files.
You can also enable Protected Mode if you're designing an Internet Explorer 7 package in and for Windows Vista. You just simply turn on Protected mode in Internet Explorer 7 on your reference PC and then import that setting into IEAK.
Stage 5 Additional Customization Finally, in this stage, you set user policies and security restrictions for your build. You can selectively lock out individual settings you don't want your users to see or modify. Figure 2 displays the Additional Settings screen with five categories of controls you can enable or disable. The settings on these screens are drawn from five ADM templates for Internet Explorer 7, which are installed after you download the latest browser components in Stage 2 of the wizard. If you use Group Policy, you can bypass this stage. If not, then you can configure the options in the five categories. As these categories come directly from the ADM templates, you can even modify them by editing each ADM file in a text editor to add your own customized controls. The ADM files are located in C:\Program Files\Microsoft IEAK 7\pol-icies under different subdirectories for each Windows operating system and platform. Figure 3 displays the five categories with a brief description of each.
Figure 3 Categories in Additional Settings Screen (Close Figure 3)

Category | Description
Control Management | This category lets you enable or disable certain ActiveX controls. The settings in this category don't apply to Windows Vista, only to Windows XP and Windows Server 2003.
Custom Settings | This category displays security settings. You can enable or disable certain controls and actions by zone (Internet, Intranet, Trusted Sites, or Restricted Sites).
Corporate Settings | In this category, you can set the size and parameters for the browser cache.
Corporate Restrictions | Here you can lock out specific controls and screens in Internet Explorer so that your users can't see them. These settings don't apply to Windows Vista, only to Windows XP and Windows Server 2003.
Internet Settings | This category offers options for AutoComplete, display size, and the advanced settings displayed in the Internet Options menu of Internet Explorer.
Figure 2 Customizing Internet Explorer Features
Figure 2 Customizing Internet Explorer Features

Checking the Build
After you complete the screens in the Customization Wizard, your package is created in the location you specified in Stage 1 or by default in c:\builds. Under this will be the destination directory-IEAK uses the current date for this directory name, for example, 01012007 for January 1, 2007. Under this will be two subdirectory paths, one named INS and the other with the name of the distribution method you chose-FLAT, CD, or BrndOnly.
The INS directory acts as a workspace or repository that keeps track of your customizations as you build your package. A text file in this directory called install.ins stores all the settings you create. If you restart the Customization Wizard, your previous selections are automatically picked up from this file.
The FLAT, CD, or BrndOnly directories store the actual installation files. Under any of these three locations will be a subdirectory named for the OS and platform, such as WIN32 for 32-bit Windows XP or Windows Vista. The final subdirectory is named for the language you used for your package, such as EN for English. As an example, if you created a build on January 1, 2007 using a Flat distribution for 32-bit Windows in English, the directory path of your build would be c:\builds\01012007\FLAT\WIN32\EN.
To find the installation created with a Flat distribution method, drill down through the FLAT directory structure until you see the IE7Setup.exe file in the language subdirectory. This is a self-extracting executable containing all the binaries and configuration files that make up your build. This file is all you need to deploy your Internet Explorer 7 package (the files in the INS directory are not required for installation). You can copy this single file to your distribution server to test your package, and then when ready, deploy it to your users.
If you chose a CD-ROM distribution, you must copy everything from within the CD directory to your CD. This includes an autorun.inf file, which is automatically generated, and a directory with the executable file that installs Internet Explorer from the CD.
If you built a Configuration-only or Branding-only package, drill down through the BrndOnly directory structure until you see the Setup.exe file in the language subdirectory. This is a self-extracting executable, which you can copy to your distribution server for deployment.

Managing Your Settings
Your Internet Explorer 7 package contains all the features and settings you need initially. But what do you do when you need to change an option? You have two choices. If you have Active Directory you can update your browser settings using Group Policy. If not, IEAK provides a tool called Profile Manager to modify the settings. Let's look briefly at Group Policy first.
Using Group Policies Group Policy is the best method for managing Internet Explorer as it supports all browser settings. With past versions of IEAK and Internet Explorer, you'd have to add ADM files and Internet Explorer Maintenance (IEM) files to your Group Policy console to incorporate all of the settings for Internet Explorer. But for Internet Explorer 7, Windows XP SP2 and Windows Vista include all necessary Group Policy settings to maintain and update the browser.
If you open the Group Policy Editor (gpedit.msc), you'll find all the required settings for Internet Explorer 7 under Administrative Templates | Windows Components | Internet Explorer.
Using IEAK Profile Manager With the IEAK Profile Manager you build and create the autoconfiguration, or INS file, to store the settings for Internet Explorer 7. Profile Manager initially requires you to load or create a new INS file. You could start from scratch and create a new INS file with the same settings you configured in the Customization Wizard. But why duplicate work? When you built your package IEAK created the default install.ins file to store the browser settings. Instead of creating a new INS file in Profile Manager, use install.ins. To load this file, browse to the INS path in your builds directory, say c:\builds\01012007\INS. Drill down through the remaining subdirectories until you see the file.
Profile Manager divides its settings into two sections, as you can see in Figure 4. The Wizard Settings cover browser options such as home page, proxy settings, and security zones. These correspond to the settings in Stages 3-5 of the Customization Wizard. The Policies and Restrictions section controls user restrictions and corresponds to the settings in the five categories from Policies and Restrictions in Stage 5 of the Customization Wizard.
Figure 4 Configuring Internet Explorer Using Profile Manager
Figure 4 Configuring Internet Explorer Using Profile Manager
Since you already defined these settings when you built your package, you shouldn't need to modify anything. This is, however, a good opportunity to review all the settings you chose for your package to make sure they're accurate.
After you've verified the settings in Profile Manager, save the install.ins file elsewhere and then copy it to an internal Web server. To do this you'll need to enter the Universal Naming Convention (UNC) path of the server, the same path you specified in the Automatic Configuration screen in Stage 4 of the Customization Wizard. You're also prompted to save a CAB file along with the INS file, displayed in Figure 5. Why? When you modify your Internet Explorer 7 settings with Profile Manager, IEAK often needs to download Registry entries to your Windows clients. These entries are stored in INF files, which are then stored in a CAB file. If the version number of the INS file changes due to new modifications, a new CAB file gets generated for download. Store the CAB file in the same location on your Web server as your INS file.
Figure 5 Saving Your Auto-Configuration Files
Figure 5 Saving Your Auto-Configuration Files
It's a good idea to then make copies of both the INS file and the CAB file and save them to different locations on your Web server. Think of these as both your backup copies and your test copies. When you modify your Internet Explorer settings with Profile Manager in the future, you can load and modify your test INS file to test your changes before you modify the live INS file.
Changing a browser setting or control through Profile Manager is simple. Just select the appropriate category and you can enable or disable any of its options. After you've made your changes, resave the INS file and then copy it back to your server.
One more recommendation: the INS file is a simple text file. You can open it in Notepad to view its settings. Can you also edit the INS file in Notepad? You can, and the settings will take effect. However, using Profile Manager to modify the INS file provides a couple of benefits. Profile Manager automatically generates a CAB file if one is needed, and it also stamps the INS file with a new version number each time it's modified. Therefore, you should always use Profile Manager to modify your INS file.

Wrap-Up
IEAK is an effective tool for creating and customizing your Internet Explorer 7 build quickly and efficiently. The latest version, IEAK 7, boasts several improvements over previous versions (clearer screens, more helpful Help) to work with you to design your installation package. By understanding and using IEAK, you should be able to deliver a reliable Internet Explorer 7 installation to your users and please your CIO at the same time.
Automatic Delivery of Internet Explorer 7
Microsoft plans to distribute Internet Explorer 7 as a high-priority update through Automatic Updates and through the Windows Update and Microsoft Update sites shortly after the final version of Internet Explorer 7 is released. This may pose a problem for you as an administrator, depending on your environment. If your users don't have local admin rights, they won't receive this update. Also, if you manage your environment with Microsoft Systems Management Server (SMS) or Windows Server Update Services (WSUS), then you already control the updates your users receive. If, however, some or all of your users have local admin rights and you have no system to manage updates, then you may need to block the Internet Explorer 7 update. Microsoft has created an Internet Explorer 7 Blocker Toolkit. This Toolkit (available from the Microsoft Download Center) includes both a Group Policy template and a script that sets a registry key to prevent the Internet Explorer 7 update from running.

Lance Whitney is an IT consultant, trainer, and technical writer. He's created and supported installation packages for Internet Explorer since version 4.0. Originally a journalist, he took a blind leap into the IT world about 15 years ago.


 SQL Q&amp;A: Data Archiving, Linked Servers, Measuring Bandwidth, and More
SQL Q+A
Data Archiving, Linked Servers, Measuring Bandwidth, and More
Edited by Nancy Michell

Data Archiving
Q I need a complete data-archiving strategy for my group. My current approach is based on the standard model of backing up data and then running utilities that will purge historical data. If the purged data needs to be retrieved, the environment and database are restored.
I'm looking for an archiving solution that can be done in stages. For stage one, data would be purged from the database but would still be accessible in real time. In other words, the data is removed so the size of production database is manageable, but end users are still able to access the data. In stage two, data would be completely removed and a restore would be required to access it. How can I do this?
A The easiest thing to do would be to restore the archive copy of the database, then modify the application to access the new, trimmed database or the old untrimmed one if the user so requests. As a result, you'll have a copy of the database for each purge period.
If data changes are slow and most of the data does not change between purges, you may end up with a lot of overlap and wasted space. On the other hand, since it is accessed infrequently you can probably get away with placing this archived data on a few large, slower, inexpensive drives (instead of many small, fast, expensive ones). If data gets wholly refreshed each period, this will suit you well. This process should be quite easy to manage and nearly foolproof.
Also, look into the possibility of using database snapshots-they offer a way to create a point-in-time replica before trimming the old database. While snapshots may work well in some scenarios, they also have numerous implications. Database snapshots are "copy on write" and continuously maintain changes between the original database and the point in time when the snapshot is taken. If there are a lot of changes from the original, the snapshot can become quite large.
In some sense the database snapshot is the opposite of backup and restore. The former makes sense when you anticipate only a few changes since it only stores deltas, while the latter is more suitable when you anticipate a lot of changes. In this case, the benefit of "copy on write" space savings evaporates while the difficulty of managing snapshots persists.
Another option is to use table partitioning. It allows you to take particular tables, designate key value ranges as belonging to different partitions, and then place those partitions on different filegroups. Once you have control over which data goes into which filegroup within one table, you can exercise better control over associated costs. You can choose which filegroups to place on which physical drives (see the earlier note about cheap vs. expensive drives) and which filegroups should be backed up and how frequently. If you make those filegroups read-only you can also use partial backups.

Database Quantity
Q My company is looking to implement and host an application that is expected to serve approximately 5,000 of our customers. We would like to implement one database per customer to insure confidentiality. Would the resources of the server be less efficiently used for a given data and index size, number of user connections, and workload if it was 1 database or 5,000?
A No matter how large your staff may be, maintaining the same code base between the databases would be difficult. Fix one bug in the database code and you have to roll it out 5,000 times. In addition, the database recovery times would be horrendous, as would be the time taken to do tasks like backups and database consistency checking. Think about it this way-does a bank have a separate database on their host for each customer who has a checking account?
SQL Server™ can create many, many databases, but that's not always the best approach. Just think of the work required to perform one transaction in each database in the same period of time; each database has its own transaction log. As we all know, one key to online transaction processing (OLTP) performance is maintaining an environment where the transaction log takes advantage of sequential writes to its underlying disk. If you want to perform transactions in these databases rather than just reading from them, don't use this approach.

Querying a Linked Server
Q I am developing a data warehouse on SQL Server 2005 Service Pack 1 (SP1). Our source server is on a partner's domain and the destination server is on our own domain. We are fetching the records from the source through a linked server. When we execute a query from the source with joins between the source tables, the query is executed very quickly. However, whenever we have even a simple join with our destination tables, the query takes forever. Why?
A Avoiding cross-server joins is a best practice, especially across a domain boundary. That said, based on your particular results this issue may occur because your partners trust your domain, but you don't trust the domain of your partners. Try refactoring your query to run it from the source, and then copy the results over to the destination. This may well give you a better outcome.

Measuring Bandwidth
Q Are there any best practices for measuring the bandwidth used for database mirroring? I understand there's a requirement that it has to be about three times the log-generating rate, but if the demand is not heavy, is it possible to do database mirroring over a broadband connection over the Web?
A Besides raw throughput, you need to consider the round-trip message latency (more critical if safety=full) and also the link reliability. Database mirroring is optimized for a reliable network connection so there can be a fair amount of overhead on reconnection. If the broadband connection is unsteady (dropped connections or long delays) you may not be able to maintain a connection. For more help, check out this whitepaper on mirroring performance considerations.
Securing Access to SQL Server
Looking for recommendations for securing access to SQL Server in a production environment? Try the Microsoft patterns & practices Developer Center. Three patterns may be of special interest:
  • Security Engineering Index
  • Security Guidance for Applications Index
  • Threat Modeling Web Applications

Want details on how to set up a complete operational environment? Here are two good references:
  • Windows Server System Reference Architecture
  • Data Services Implementation Guide

Thanks to the following Microsoft IT pros for their technical expertise: Denis Altudov, Jayashree Anand, Gus Apostol, Bhavana Bartholf, Mike Blaszczak, Dibyendu Chakraverty, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Nakul Garg, Phil Hummel, Steve Lindell, Kaloian Manassiev, Al Noel, Ward Pond, Paul Randal, Remus Rusanu, Mike Shelton, Christy Sutton, Kevin Tsai, Peter Ty, Val Wittenberg, Steven Wort, Kalyan Yella, and Frankie Yuen.


 The Cable Guy: TCP Receive Window Auto-Tuning
The Cable Guy
TCP Receive Window Auto-Tuning
Joseph Davies

Welcome to the first installment of The Cable Guy in TechNet Magazine. Fans of the column on the TechNet Web site already know we cover all manner of networking issues, and we'll continue that tradition here each month. If you're new and looking for an archive of previous columns, head over to the Cable Guy site.
Now let's get started with our first topic here-the TCP Receive Window.
Throughput over TCP connections can be limited by sending and receiving applications, sending and receiving implementations of TCP, and the transmission path between the TCP peers. In this column I'll describe the TCP receive window and its impact on TCP throughput, the use of TCP window scaling, and the new Receive Window Auto-Tuning feature in Windows Vista™ that optimizes TCP throughput for received data.

The TCP Receive Window
TCP connections have a number of important characteristics. First, they are a logical point-to-point circuit between two Application Layer protocols. TCP does not supply a one-to-many delivery service, it provides only one-to-one delivery.
Second, TCP connections are connection-oriented. Before data can be transferred, two Application Layer processes must formally negotiate a TCP connection using the TCP connection establishment process. Similarly, TCP connections are formally closed after negotiation using the TCP connection termination process.
Third, reliable data sent on a TCP connection is sequenced and a positive acknowledgment is expected from the receiver. If a positive acknowledgment is not received, the segment is retransmitted. At the receiver, duplicate segments are discarded and segments arriving out of sequence are placed back in the proper order.
Fourth, TCP connections are full-duplex. For each TCP peer, the TCP connection consists of two logical pipes: an outgoing pipe and an incoming pipe. The TCP header contains both the sequence number of the outgoing data and an acknowledgment (ACK) of the incoming data.
In addition, TCP views the data sent over the incoming and outgoing logical pipes as a continuous stream of bytes. The sequence number and acknowledgment number in each TCP header are defined along byte boundaries. TCP is not aware of record or message boundaries within the byte stream. The Application Layer protocol must provide the proper parsing of the incoming byte stream.
To limit the amount of data that can be sent at any one time and to provide receiver-side flow control, TCP peers use a window. The window is the span of data on the byte stream that the receiver permits the sender to send. The sender can send only the bytes of the byte stream that lie within the window. The window slides along the sender's outbound byte stream and the receiver's inbound byte stream.
For a given logical pipe (one direction of the full-duplex TCP connection) the sender maintains a send window and the receiver maintains a receive window. When there are no data or ACK segments in transit, a logical pipe's send and receive windows are matched. In other words, the span of data in the outbound byte stream that the sender is allowed to send is matched to the span of data in the inbound byte stream that the receiver is able to receive. Figure 1 illustrates this send and receive relationship.
Figure 1 Matching Send and Receive Windows
Figure 1 Matching Send and Receive Windows
To indicate the size of the receive window, the TCP header contains a 16-bit Window field. When the receiver gets data, it sends ACKs back to the sender indicating the successfully received bytes. In each ACK, the Window field notes the number of bytes remaining in the receive window. When data is sent, acknowledged, and retrieved by the application, both the send and receive windows slide to the right. The receive window is the window that controls how much unacknowledged data can be in flight from the sender to the receiver.
Because there can be data in the receive window that has not been retrieved by the app and data that has been received but not acknowledged, the TCP receive window has additional structure, as Figure 2 shows.
Figure 2 Types of Data in the TCP Receive Window
Figure 2 Types of Data in the TCP Receive Window
Notice the difference between the maximum and current receive windows. The maximum receive window is a fixed size. The current receive window is of variable size and corresponds to the remaining amount of data that the receiver is allowing the sender to send. The current receive window's size is the value of the Window field advertised in ACKs sent back to the sender, and is the difference between the maximum receive window size and the amount of data that has been received and acknowledged but not retrieved by the application.

The TCP Receive Window and TCP Throughput
To optimize TCP throughput (assuming a reasonably error-free transmission path), the sender should send enough packets to fill the logical pipe between the sender and receiver. The capacity of the logical pipe can be calculated by the following formula:
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
The capacity is known as the bandwidth-delay product (BDP). The pipe can be fat (high bandwidth) or thin (low bandwidth) or short (low RTT) or long (high RTT). Pipes that are fat and long have the highest BDP. Examples of high BDP transmission paths are those across satellites or enterprise wide area networks (WANs) that include intercontinental optical fiber links.
Increasing Sender-Side Performance for High-BDP Transmission
The new Receive Window Auto-Tuning feature provides enhanced performance for receiving data over high-BDP links, but what about sender performance?
The existing algorithms that prevent a sending TCP peer from overwhelming the network are known as slow start and congestion avoidance. These algorithms increase the send window (the number of segments that the sender can send) when initially sending data on the connection and when recovering from a lost segment.
Slow start increases the send window by one full TCP segment for either each acknowledgment segment received (for TCP in Windows XP and Windows Server 2003) or for each segment acknowledged (for TCP in Windows Vista and Windows Server "Longhorn"). Congestion avoidance increases the send window by one full TCP segment for each full window of data that is acknowledged.
These algorithms work well for small BDPs and smaller receive window sizes. However, when you have a TCP connection with a large receive window size and a large BDP, such as replicating data between two servers located across a high-speed WAN link with a 100ms round-trip time, these algorithms do not increase the send window fast enough to fully utilize the bandwidth of the connection.
To better utilize the bandwidth of TCP connections in these situations, the Next Generation TCP/IP stack includes Compound TCP (CTCP). CTCP more aggressively increases the send window for connections with large receive window sizes and BDPs. CTCP attempts to maximize throughput on these types of connections by monitoring delay variations and losses. In addition, CTCP ensures that its behavior does not negatively impact other TCP connections.
In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1Gbps connection with a 50ms RTT. Connections with a larger BDP can have even better performance. CTCP and Receive Window Auto-Tuning work together for increased link utilization and can result in substantial performance gains for connections with large BDPs.
CTCP is enabled by default in computers running Windows Server "Longhorn" and disabled by default in computers running Windows Vista. You can enable CTCP with the "netsh interface tcp set global congestionprovider=ctcp" command. You can disable CTCP with the "netsh interface tcp set global congestionprovider=none" command.

The size of the Window field in the TCP header is 16 bits, allowing a TCP peer to advertise a maximum receive window size of 65,535 bytes. You can calculate the approximate throughput for a given TCP window size from the following formula:
Throughput = TCP maximum receive windowsize / RTT
For example, with a 65,535 byte receive window you can only achieve an approximate throughput of 5.24 megabits per second (Mbps) on a path with a 100ms RTT, regardless of the transmission path's actual bandwidth. With today's high-BDP transmission paths, the originally designed TCP window size, even at its maximum value, becomes a throughput bottleneck.

TCP Window Scaling
For larger window sizes to accommodate high-speed transmission paths, RFC 1323 (ietf.org/rfc/rfc1323.txt) defines window scaling that allows a receiver to advertise a window size larger than 65,535 bytes. A TCP Window Scale option includes a window scaling factor that, when combined with the 16-bit Window field in the TCP header, can increase the receive window size to a maximum of approximately 1GB. The Window Scale option is sent only in synchronize (SYN) segments during the connection establishment process. Both TCP peers can indicate different window scaling factors to use for their receive window sizes. By allowing a sender to send more data on a connection, TCP window scaling allows TCP nodes to better utilize some types of transmission paths with high BDPs.
Although the receive window size is important for TCP throughput, another important factor for determining the optimal TCP throughput is how fast the application retrieves the accumulated data in the receive window (the application retrieve rate). If the application does not retrieve the data, the receive window can begin to fill, causing the receiver to advertise a smaller current window size. In the extreme case, the entire maximum receive window is filled, causing the receiver to advertise a window size of 0 bytes. In this case, the sender must stop sending data until the receive window has been cleared. Therefore, to optimize TCP throughput, the TCP receive window for a connection should be set to a value that reflects both the BDP of the connection's transmission path and the application retrieve rate.
Even if you could correctly determine both the BDP and the application retrieve rate, they can change over time. The BDP rate can vary based on the congestion in the transmission path and the app retrieve rate can vary based on the number of connections on which the app is receiving data.

The Receive Window in Windows XP
For the TCP/IP stack in Windows XP (and Windows Server® 2003), the maximum receive window size has a number of significant attributes. First, the default value is based on the link speed of the sending interface. The actual value automatically adjusts to even increments of the maximum segment size (MSS) negotiated during TCP connection establishment.
Second, the maximum receive window size can be manually configured. The HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize and HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize registry values can be set to a maximum of 65,535 bytes (without window scaling) or 1,073,741,823 (with window scaling).
Third, the maximum receive window size can use window scaling. You can enable window scaling by setting the HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts registry value to 1 or 3. By default, window scaling is only used on a connection if the received SYN segment happens to contain the Window Scale option.
Finally, the maximum receive window size can be specified by an application by using the SO_RCVBUF Windows Sockets option when a connection is initiated. For window scaling, the application must specify a window size larger than 65,535 bytes.
Despite the support for scalable windows, the maximum receive window size in Windows XP can still limit throughput because it is a fixed maximum size for all TCP connections (unless specified by the application), which can increase throughput for some connections and decrease throughput for others. Additionally, the fixed maximum receive window size for a TCP connection does not vary with changes in the application retrieve rate or congestion in the transmission path.

Receive Window Auto-Tuning in Windows Vista
To optimize TCP throughput, especially for transmission paths with a high BDP, the Next Generation TCP/IP stack in Windows Vista (and the next version of Windows Server, code-named "Longhorn") supports Receive Window Auto-Tuning. This feature determines the optimal receive window size by measuring the BDP and the application retrieve rate and adapting the window size for ongoing transmission path and application conditions.
Receive Window Auto-Tuning enables TCP window scaling by default, allowing up to a 16MB maximum receive window size. As the data flows over the connection, the Next Generation TCP/IP stack monitors the connection, measures its current BDP and application retrieve rate, and adjusts the receive window size to optimize throughput. The Next Generation TCP/IP stack no longer uses the TCPWindowSize registry value.
Receive Window Auto-Tuning has a number of benefits. It automatically determines the optimal receive window size on a per-connection basis. In Windows XP, the TCPWindowSize registry value applies to all connections. Applications no longer need to specify TCP window sizes through Windows Sockets options. And IT administrators no longer need to manually configure a TCP receive window size for specific computers.
With Receive Window Auto-Tuning, a Windows Vista-based TCP peer will typically advertise much larger receive window sizes than a Windows XP-based TCP peer. This allows the other TCP peer to fill the pipe to the Windows Vista-based TCP peer by sending more TCP data segments without having to wait for an ACK (subject to TCP congestion control). For typical client-based networking traffic such as Web pages or e-mail, the Web server or e-mail server will be able to send more TCP data more quickly to the client computer, resulting in an overall increase in network performance. The higher the BDP and application retrieve rate for the connection, the better the performance increase.
The impact on the network is that a stream of TCP data packets that would normally be sent out at a lower, measured pace, are sent much faster resulting in a larger spike of network utilization during the data transfer. For Windows XP and Windows Vista-based computers performing the same data transfer over a long, fat pipe, the same amount of data is transferred. However, the data transfer for the Windows Vista-based client computer is faster due to the larger receive window size and the server's ability to fill the pipe from the server to the client.
Because Receive Window Auto-Tuning will increase network utilization of high-BDP transmission paths, the use of Quality of Service (QoS) or application send rate throttling might become important for transmission paths that are operating at or near capacity. To address this possible need, Windows Vista supports Group Policy-based QoS settings that allow you to define throttling rates for sent traffic on an IP address or TCP port basis. For more information, see the resources on policy-based QoS.
Increasing TCP Throughput for High-Loss Networks
High-loss networks can dramatically decrease TCP throughput because of frequent timeouts and retransmissions. Examples of high-loss networks are wireless networks—such as those based on IEEE 802.11, General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS)—that can have high packet losses depending on network conditions, signal attenuation, electromagnetic interference, and the changing location of the computer.
The Next Generation TCP/IP stack supports the following four RFCs in order to optimize throughput in high-loss environments.

RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm
The Fast Recovery algorithm, defined in RFC 2001, is based on the Reno algorithm, which increases the amount of data that a sender can send when a segment is retransmitted due to a fast retransmit event. Although the Reno algorithm works well for single lost segments, it does not perform as well when there are multiple lost segments. The NewReno algorithm provides faster throughput by changing the way that a sender can increase their sending rate during fast recovery when multiple segments in a window of data are lost and the sender receives a partial acknowledgment (an acknowledgment for only part of the data that has been successfully received).

RFC 2883: An Extension to the Selective Acknowledgment (SACK) Option for TCP
SACK, defined in RFC 2018, allows a receiver to indicate up to four noncontiguous blocks of received data by using a SACK TCP option. RFC 2883 defines an additional use of the fields in the SACK TCP option to acknowledge duplicate packets. By doing this the sender is able to determine when it has retransmitted a segment unnecessarily and adjust its behavior to prevent future unnecessary retransmissions. The fewer retransmissions that are sent, the better the overall throughput.

RFC 3517: A Conservative Selective Acknowledgment-based Loss Recovery Algorithm for TCP
The current implementation of TCP/IP in Windows Server 2003 and Windows XP uses SACK information only to determine which TCP segments have not arrived at the destination. RFC 3517 defines a method of using SACK information to perform loss recovery when duplicate acknowledgments have been received, replacing the older fast recovery algorithm when SACK is enabled on a connection. The Next Generation TCP/IP stack keeps track of SACK information on a per-connection basis and monitors incoming acknowledgments as well as duplicate acknowledgments to more quickly recover when multiple segments are not received at the destination.

RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
Spurious retransmissions of TCP segments can occur with a sudden increase in RTT, leading the retransmission timeouts (RTOs) of previously sent segments to begin to expire and TCP to start retransmitting them. If the increase occurs just before sending a full window of data, a sender can retransmit the entire window of data. The F-RTO algorithm prevents spurious retransmission of TCP segments through the following behavior.
When the RTO expires for multiple segments, TCP retransmits just the first segment. When the first acknowledgment is received, TCP begins sending new segments (if allowed by the advertised window size). If the next acknowledgment confirms the other segments that have timed out but have not been retransmitted, TCP determines that the timeout was spurious and does not retransmit the other segments that have timed out.
The result is that for environments with sudden and temporary increases in the RTT, such as when a wireless client roams from one access point to another, F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate. The use of SACK-based loss recovery and F-RTO are best suited for connections that use GPRS links.

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


 Windows PowerShell: Windows PowerShell Constructs
Windows PowerShell
Windows PowerShell Constructs
Don Jones

Last month, I showed you some ways in which Windows PowerShell could be put to immediate use solving administrative tasks—without actually writing any scripts. However, while Windows PowerShell is an excellent interactive shell, you can really take advantage of its capabilities and automate more complex tasks when you start to utilize its powerful-yet simple-scripting language.
First, though, you may be asking yourself: does Microsoft really need another scripting language? After all, Microsoft has brought us KiXtart, a logon script processor, as well as Visual Basic® Scripting Edition (VBScript). The answer, however, is yes. Microsoft really did need another scripting language. I'll explain why.
The Windows PowerShell™ language needed to be simple and intuitive, so administrators could pick it up without a lot of training. It also needed to be pretty flexible, so it could accommodate all the powerful functionality Windows PowerShell itself can provide to users.
Because Windows PowerShell is based on the Microsoft® .NET Framework, its scripting syntax needed to be .NET friendly. In assembling a scripting language for Windows PowerShell, the designers selected a syntax that's essentially a very simplified C# (pronounced C-Sharp, one of the languages that ships with the .NET Framework). Why not stick with a VBScript-like syntax? The Windows PowerShell scripting language isn't actually all that different from VBScript, but by sticking more closely to C# syntax, PowerShell provides a sort of initial stepping stone for learning .NET Framework programming. If you ever decide to move up to Visual Studio® and start writing C# applications, much of your Windows PowerShell scripting syntax will move up with you.
One of the most important things in the Windows PowerShell scripting language-or any scripting language, for that matter-is its constructs. These are special language elements that allow Windows PowerShell to perform logical comparisons and take different actions based on the comparisons' results or that allow it to repeat one or more instructions over and over.

Thinking Logically
Logical comparisons are at the heart of many scripting language constructs, and Windows PowerShell is no exception. A comparison essentially looks at two values or objects and evaluates whether the comparison is True or False. For example, you could ask yourself, "Is this user's password expiration date the same as today's date?" The result will either be True if the dates are the same or False if they are different. Note that I'm capitalizing True and False, because they're terms that have special meaning within Windows PowerShell.
Here's an example of a real logical comparison you could perform within Windows PowerShell:
PS C:\> $a = 1
PS C:\> $b = 2
PS C:\> $a -eq $b
False
I've created a variable named $a and set it to contain the value 1. In Windows PowerShell, variable names always begin with a dollar sign, so they're easy to spot. The = is technically referred to as the assignment operator, because it's used to assign a value. Next, I create a second variable, $b, and assign it the value 2. Then comes the actual logical comparison-I ask Windows PowerShell to compare the contents of $a and $b using the -eq (equality) operator. PowerShell performs the comparison, determines that the two values are not equal, and displays the result: False.
The Windows PowerShell operators are a bit different from other scripting languages you may have seen, and are even different from C#. Most languages will use the = operator to perform equality checks as well as for value assignment; Windows PowerShell avoids confusion by having a dedicated operator for each function. Figure 1 shows the Windows PowerShell comparison operators, along with equivalent operators in other languages (like VBScript) that you may be familiar with already.
Figure 1 PowerShell Comparison Operators (Close Figure 1)

Operator | Name | Description
-eq | Equality | Tests whether values are the same. Other languages may use = or == to test for equality.
-ne | Not Equal | Tests for inequality. Other languages may use <> or != to test for inequality.
-gt | Greater Than | Tests whether one value is larger than another. Other languages may use the > character.
-lt | Less Than | Tests whether one value is smaller than another. Other languages may use the < character.
-ge | Greater Than or Equal To | Tests whether a value is larger than or equal to another value. Similar to >= in VBScript and other languages.
-le | Less Than or Equal To | Tests whether a value is smaller than or equal to another value. Similar to <= in VBScript and other languages.
These comparison operators have another interesting feature. Take a look at this comparison:
PS C:\> $a = "TechNet"
PS C:\> $b = "technet"
PS C:\> $a -eq $b
True
By default, the comparison operators are case-insensitive, meaning the capitalized version of TechNet is seen as equivalent to "technet". That's convenient, because in most administrative tasks you don't care about the case of the letters. However, sometimes you may, and you can ask Windows PowerShell to perform a case-sensitive comparison by prepending the letter c to the comparison operator:
PS C:\> $a -ceq $b
False
Likewise, if you're ever concerned or confused about whether or not Windows PowerShell is going to perform a case-insensitive comparison, you can force it to do so by prepending the letter i:
PS C:\> $a -ieq $b
True
Just remember that logical comparisons always result in one of two values: True or False.

Making Decisions
Now that you know how to write logical comparisons, you can start using them in constructs. The first construct I'll show you allows Windows PowerShell to make decisions based on a comparison. It's called an If construct, and there are a few variations of it. Here's the simplest:
PS C:\> if ($a -eq $b) {
>> Write-Host "They are equal"
>> }
>>
They are equal
There are some interesting things to note here. First, the variables $a and $b still contain the values "TechNet" and "technet", respectively. I started the construct by using the If keyword. Following it, in parentheses, I entered the logical comparison I wanted to perform. Following that is a curly brace, which signals the start of what I'll call the conditional code-the code that Windows PowerShell will execute if the comparison returns a result of True. You know from the earlier example that this comparison does return True, so I'd expect the conditional code to execute. I type my conditional code, Write-Host "They are equal", and press Enter. Finally, I end the conditional code section by typing a closing curly brace, and tapping Enter twice. (The second Enter on a blank line lets the parser know that I'm done writing and ready for it to execute the code.)
Notice that this construct isn't running from a script file. I simply typed it into the Windows PowerShell com-mand line. This is what makes Windows PowerShell unique in the world of Windows scripting: scripts can be created interactively, as well as put into a file for permanent storage.
As soon as I typed the opening curly brace and pressed Enter, Windows PowerShell displayed a >> prompt. That's its way of saying, "I recognize that you're inside a construct, and I'm ready for you to start typing whatever goes inside the construct." After I typed the closing curly brace and tapped Enter twice, Windows PowerShell immediately executed the construct, determined that its logical comparison was True, and executed the conditional code. You can see this because "They are equal" was displayed before PowerShell returned to its normal prompt. Using Windows PowerShell to script interactively allows you to quickly test bits of code before assembling them into a more permanent script, which makes both learning and debugging easier.
I should point out that Windows PowerShell isn't especially picky about things like pressing Enter. For example, this is functionally the same as the previous example:
PS C:\> if ($a -eq $b) { Write-Host "They are equal" }
They are equal
Because I typed this all on one line, Windows PowerShell didn't need to display the special >> prompt; it simply executed the construct when I pressed Enter at the end of the line. How did Windows PowerShell know it was OK to execute the construct? Because it was complete at that point-the closing curly brace had been typed.
I alluded to other variations of the If construct. Here's a full example, presented as it might appear in a PS1 script file, rather than in the shell:
if ($a -eq $b) {
  Write-Host "They are equal"
} elseif ($a -lt $b) {
  Write Host "One is less than the other"
} else {
  Write Host "One is greater than the other"
}
The construct starts out the same, by using the If keyword. However, in the event that the comparison is False, I've provided another comparison by using the Elseif keyword. If that second comparison is also False, then my last keyword, Else, provides a final set of code that will execute.

Repeating Yourself
Windows PowerShell contains a couple of constructs for executing code over and over, until some comparison is either True or False. Programmers call these loop constructs. Even better, one of the most useful loop constructs is capable of enumerating the objects in a collection and executing one or more lines of code for each object. Appropriately enough, the construct is called a foreach construct, and it looks like this:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> Write-Host $name
>> }
>>
don-pc
testbed
I started by asking the Windows PowerShell Get-Content cmdlet to retrieve the contents of the c:\computers.txt file, a file I created myself that contains one computer name per line. Windows PowerShell treats each line as an object, so the file is essentially a collection that contains those objects. The collection winds up in the variable $names. Using the Foreach keyword, I tell Windows PowerShell to enumerate the $names collection, using the variable $name to represent the current object each time the loop executes. The loop code goes inside curly braces. So, for each name in the file, I'll output the name to the command line. And, as you can see from the output following the construct, that's exactly what Windows PowerShell does. You can see how this would provide an obvious benefit in administrative scripting: you could easily construct a list of server names, for example, and have Windows PowerShell retrieve information from each one in turn.

Real-World Constructs
So let's take logical comparisons, the If construct and the foreach construct, and do something useful. I want to quickly check the status of the Messenger service on a set of servers. I expect that the service will be stopped on most of the servers, so I don't want Windows PowerShell to list all the servers where the service is in the state I expect; I only want it to list the servers where the Messenger service is actually started because those are servers I need to do something about.
I know that the Windows PowerShell Get-Service cmdlet can help me retrieve the information I need for the local computer. Unfortunately, however, it can't reach out to a remote computer, which is really my goal. Happily, I can also access the same information via Windows Management Instrumentation (WMI), using the Get-WMIObject cmdlet, which lets me work with a remote computer. So here's the script:
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started -eq $True ) {
    write-host "$name has Messenger running"
  }
}
Notice the ' character on the third line? It tells Windows PowerShell that the next line is a continuation. It's useful in cases like this where the entire line wouldn't fit in the magazine without wrapping. Also notice that my If construct compares $svc.started to $True. The variable $True is a special variable in Windows PowerShell that represents the Boolean True value. (A companion variable, $False, represents Boolean False.) Actually, I could have done a little shortcut there:
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started) {
    write-host "$name has Messenger running"
  }
}
Remember that the If construct's condition simply needs to be True or False. Normally, you get True or False by comparing two values, as I did in the first version of this script. However, because the Started property is either True or False, there's no need to actually compare it to True or False.

One Useful Tool
So there you have it-a simple, useful administrative tool that utilizes constructs to do its job. Whether you type it into Windows PowerShell interactively, or save it in a PS1 file for easy reusability, it's a handy tool to check the status of a service on various computers and a great demonstration of how constructs can help automate administrative tasks.

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


 Hey, Scripting Guy!: Be Careful What You Say
Hey, Scripting Guy!
Be Careful What You Say
The Microsoft Scripting Guys

DURING THE AMERICAN Civil War (at the Battle of Spotsylvania, to be precise), Union General John Sedgwick was dismayed to find his men cowering in the face of the occasional random shot fired in their direction by Confederate snipers. According to legend, Sedgwick told the men: "I'm ashamed of you, dodging that way. They couldn't hit an elephant at this distance." Moments later, Sedgwick became the highest-ranking Union officer killed during the war. Maybe the Confederate snipers couldn't hit an elephant at that distance, but, unfortunately for Sedgwick, they could hit a general.
Of course, it goes without saying that the moral of the story is-well, now that you mention it, "Keep your head down if someone is shooting at you" would be a pretty good moral, wouldn't it? Wow-too bad we didn't think of that. Instead, we came up with the following moral: "Be careful what you say, because someday it might come back to haunt you." It was true for General John Sedgwick, and it's been true for many other people as well. For example, no one remembers Thomas Watson, long-time head of IBM, as one of the great entrepreneurs in American history. Instead, Watson has been immortalized as the man who said, "I think there is a world market for maybe five computers."
Interestingly enough, there's no evidence that Watson ever actually said this; at best he may simply have mentioned someone else's thoughts on the matter. But who cares? After all, the idea that the head of IBM might have said that there was no market for computers makes such a good story that we can't let a silly thing like facts get in the way, can we?
Incidentally, Watson did say "If you want to succeed, double your failure rate." That's advice the Scripting Guys have wholeheartedly embraced.
Well, at least the part about doubling your failure rate.
And then there's this quote: "If you're writing VBScript scripts you don't have access to the .NET Framework." Admittedly, telling people that the Microsoft® .NET Framework is inaccessible to scripters isn't quite as memorable as "They couldn't hit an elephant at this distance" or "I think there is a world market for maybe five computers." However, such a statement is equally far off base. It's true that the .NET Framework was designed with C# and Visual Basic® developers in mind, and it's true that VBScript cannot instantiate native .NET Framework classes. But that doesn't mean the .NET Framework is inaccessible to scripters, at least not all of it.
Yes, you're right: we can't deny that the majority of .NET Framework classes remain off-limits to VBScript. However, there are a reasonably large number of .NET classes that have COM-callable wrappers, which simply means these classes include a COM interface enabling them to be accessed from a scripting language like VBScript. You say you find that hard to believe? Then take a look at the HKEY_CLASSES_ROOT portion of your registry shown in Figure 1; you should see all sorts of classes beginning with System.
Figure 1 System Classes in the Registry
Figure 1 System Classes in the Registry
Most of these are .NET Framework classes, and most of them can be instantiated through VBScript.
Told you!
Of course, as anyone who's ever bought a product advertised on late-night TV can attest, just because you can do something doesn't mean you should do it (there's usually a reason why those items aren't available in stores). Sure, you can create an instance of the System.ContextMarshalException class in a script; we just don't have any idea why you'd want to or what you'd do with it.
But that isn't the case for all .NET Framework classes. For example, one of the great bugaboos in the scripting world is the fact that there's no easy way to sort a list of items. To put a list in alphabetical order requires you to either use a disconnected recordset or create a cryptic sorting function all your own, like the following bubble sort code (those of you with weak stomachs might want to skip on to the next paragraph):
For i = (UBound(arrNames) - 1) to 0 Step -1
    For j= 0 to i
        If UCase(arrNames(j)) >
          UCase(arrNames(j+1)) Then
            strHolder = arrNames(j+1)
            arrNames(j+1) = arrNames(j)
            arrNames(j) = strHolder
        End If
    Next
Next
Don't feel bad: we wrote the code and we aren't totally sure what it all means, either.
So how can the .NET Framework help us in a situation like that? To answer that question, let's take a look at a very simple and straightforward little script:
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()

For Each strItem in DataList
    Wscript.Echo strItem
Next
As you can see, what we're doing here is creating an instance of the .NET Framework class System.Collections.ArrayList. We then use the Add method to add five items to the list. That's all well and good, except for one thing: we added these items in somewhat haphazard fashion (B, C, E, D, A), but we need to display the items in alphabetical order (A, B, C, D, E). Time to haul out the bubble sort code, right?
Wrong. (Sorry to be so blunt, but wrong is wrong.) As it turns out, we don't need to haul out bubble sort code; all we need to do is call the arraylist's Sort method:
DataList.Sort()
That's it. With that one single line of code we can sort all the items in our array list.
Prove it? Wow, tough crowd. That's OK; we expected there to be a Doubting Thomas or two in the audience. That's why the script includes a For Each loop that loops through all the items in the list, echoing the value of each one to the screen:
For Each strItem in DataList
    Wscript.Echo strItem
Next
Now here's a question for you to tackle: what do we get back when we run this script?
Good guess:
A
B
C
D
E
Nice, isn't it?
Hmmm, we see that some of you aren't wholly satisfied. You say that's well and good, but what you really wanted to do was echo back those values in descending order; that is, you wanted a list that ran from Z to A rather than a list that ran from A to Z. If you can't get that, well . . .
Hey, no problem. All you had to do was ask:
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Reverse()

For Each strItem in DataList
    Wscript.Echo strItem
Next
You're right: this does look an awful lot like the script we just showed you, doesn't it? However, there is an important addition. Take a look at the single line of code we added, a line that directly follows the Sort method:
DataList.Reverse()
See that? After sorting the list in ascending order, we called the Reverse method which-surprise, surprise-reverses the order of all the items in the array. What does it give us? It gives us output that looks like this:
E
D
C
B
A
It's hard not to be impressed, isn't it?
But wait! It gets even better. Have you ever tried to remove an item from a VBScript array? No, don't cry; we aren't going to ask you to do that. Instead, we're going to show you how easy it is to remove an item from our .NET Framework arraylist. Don't like the letter D? Get rid of it. Here's a script that creates an array list, sorts it, and then removes the entry for D:
Set DataList = CreateObject _
  ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Remove("D")

For Each strItem in DataList
    Wscript.Echo strItem
Next
Again, you should take a look at the little line of code immediately following the Sort method:
DataList.Remove("D")
Here we've used the Remove method to remove the item equal to D. And here's what we get back when we run the script:
A
B
C
E
Hasta la vista, D!
And don't overlook the best part: we can remove an item without having to resize or redimension the array. Now that's cool. Of course, we were also able to add items to the array without having to resize or redimension things. Try telling us that doesn't make your scripting life easier.
Believe it or not, we've hardly yet scratched the surface of what you can do with the .NET Framework arraylist (for more information, see the arraylist entry in the .NET Framework SDK).
Is the arraylist useful for scripters? Let's put it this way: having seen the .NET Framework arraylist, we're not sure why you'd ever want to use the built-in VBScript array, at least not for simple lists of items like the ones we've used here.
Admittedly, we Scripting Guys haven't exactly made an exhaustive survey of the .NET Framework to find out which classes might be of use to scripters (and which classes might not be). That's something we're working on. In the meantime, feel free to poke around the full .NET Framework SDK. It seems like every time we browse through the SDK we find something new and interesting that script writers can use.
Like what? Well, how about generating random numbers. Want to generate a random number between 1 and 100 using the VBScript random number generator? No problem; just use code similar to this:
Randomize
Wscript.Echo Int((100 - 1 + 1) * Rnd + 1)
Got that formula memorized? If not, don't worry; turns out it's far easier and far more intuitive to use the .NET Framework System.Random class:
Set objRandom = CreateObject("System.Random")
Wscript.Echo objRandom.Next_2(1,100)
Most likely you can figure this out without an explanation. Regardless, we'll give you a brief one, if only because TechNet Magazine has this idea that columnists should actually write something each month. (Beats us why-that's their policy, not ours.)
As you can see, we create an instance of the System.Random class, and then call the Next_2 method, passing the method two parameters:
  • 1, the first number in our range (remember, we're hoping to generate a random number between 1 and 100).
  • 100, the high number in our range.
That's all we have to do.
Looks like we have time for one final question. Yes, you in the green shirt. Who exactly was it who said script writers couldn't access the .NET Framework? Well, to be perfectly honest, when we first started we-oops, looks like we're out of time after all. See you next month!
Good Times, Good Times
February is almost here, which can only mean one thing. No, not Valentine's Day. No, not President's Day, either. Oh, for goodness sakes, Groundhog's Day? No, the closer we get to February the closer we get to the 2007 Winter Scripting Games, the world's foremost (probably the world's only) international scripting competition. This year's Games promises to be bigger and better than ever; this time around we'll have four divisions:
  • Beginners VBScript
  • Advanced VBScript
  • Beginners Windows PowerShell™
  • Advanced Windows PowerShell
Check out the 2007 Winter Scripting Games home page for more information.
What's that? Oh, thanks. And, uh, a Happy Groundhog's Day to you, too.

Download Windows PowerShell Today
Windows PowerShell 1.0 is now available for download. And it's even free! How can you pass up that deal? Download the software and start using it today.

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


 Exchange Queue &amp; A: We Have All the Answers (Because We Made Up the Questions)
Exchange Queue & A
We Have All the Answers (Because We Made Up the Questions)
KC Lemson and Paul Bowden

Hello, and welcome to the first installment of Exchange Queue and A! We're kicking off with a series of questions that, to be honest, we came up with ourselves, so it's probably unfair to position this as a genuine question-and-answer column
because it's only Q&A insofar as the Qs and As happen in an echo chamber. We do, however, believe that these questions may be representative of questions on the minds of Microsoft® Exchange Server customers, and so we claim the moral high ground. In the future, we certainly welcome your questions, so feel free to send them to queuea@microsoft.com.
Our current vision for this column is that it will be a rotating cast of authors (kind of a "throw the writers at the wall and see which ones stick"), but all of us have been involved with Exchange for many years. This month the answers (and questions!) were coauthored by KC Lemson and Paul Bowden, Lead Program Managers in the Exchange product team at Microsoft. Both of us are old-timers in Exchange development. We've moved around quite a bit, but have never been able to get away from messaging.
KC has worked in the Exchange group for the last six years where she's held a variety of roles including a program manager on Microsoft Outlook® Web Access (OWA) and lead program manager in charge of the Exchange pre-release customer program. She is currently the User Experience Manager for Exchange, in charge of product design and customer research. Before joining Exchange, she was a tester in Outlook for three years, and was responsible for the testing of attachments during the era when people thought it was a double-plus-bad thing to block executable attachments in e-mail. KC blogs at blogs.technet.com/kclemson.
Paul has spent the last three years working on that nifty little Exchange Best Practices Analyzer (ExBPA) tool. In fact, he won an award for it a couple of months ago and had his photo taken with Bill Gates. However, with the Exchange Server 2007 project wrapping up, it's time to shuffle the deck. Paul needs to stop dreaming in XML and come back to the real world. He's going to be the Release Manager for the next version of Exchange (the version that we'll start working on just as soon as Exchange Server 2007 has shipped).
By the way, did you enjoy the incredible amount of wit demonstrated in the naming of this column? We, of course, can't even take credit for the name; it was suggested by a reader of KC's blog. (Enjoy the shirt, Tim!) Runner-up suggestions were "Pushing the Envelope" and "When I'm X64", the latter of which KC enjoyed so much that she registered www.whenimx64.com and pointed it to her blog just because she could. If only we could be as empowered about everything in our lives.
Side note: KC first proposed naming this column "The Monthly Queue and A" until our editor aptly pointed out that we are as yet an unknown quantity and our ability to deliver on schedule can't be trusted (he was more polite and less blunt in his response than we are here, but we knew what he was thinking). Along those same lines, we have no idea what the feedback will be from readers of this column, and whether or not it's worth repeating it. Therefore we met in the middle with the name and you'll just have to let us know what you think at queuea@microsoft.com.
And so, without further ado, on to the questions...

Q Why should I be excited about Exchange Server 2007?
A We realize it's risky to open the first column with what is essentially a marketing question, but we are so excited about Exchange Server 2007 that we really want to share it with you. So we will attempt to limit the "market-ecture" in this response and instead just speak to a few of the many technical reasons why an Exchange administrator or user should be excited about Exchange 2007, from one geek to another.

Scalability and Performance Improvements
First off is the obvious one: 64-bit. What's the big deal, you ask? Well, 32-bit Windows® can only support a total of 4GB (232 bytes) of memory, and 2GB are taken by the kernel by default, leaving only 2GB for applications. The current version of Windows supports a /3GB switch in boot.ini that gives applications up to 3GB of memory headroom, but once you've used that the Windows kernel gets a little uncomfortable, and it won't be long until you're having to reboot that server to reclaim resources.
Happily, 64-bit support, along with significant changes to the underlying database engine (JET) in Exchange, solves this problem. Since Exchange servers are traditionally far more bound by disk I/O than by any other system resources (such as CPU), adding memory to the system means that you can significantly reduce the disk I/O by keeping more information in memory instead of having to read the disk. As a result, with Exchange 2007 you can support far larger mailboxes for your users on similarly equipped physical hardware than with Exchange 2003. The mail server I am on at Microsoft, for example, supports 4,000 users with 2GB mailbox quotas, resulting in 6 terabytes (TB) of data. To be clear, just because Exchange 2007 can take advantage of more memory doesn't mean that it needs that much memory-we've tested a box running 32-bit Windows Server® 2003 and Exchange 2003 with 4GB or less of memory, installed 64-bit Windows Server 2003 and Exchange 2007, and saw similar performance.
Exchange 2007 also includes two new ways of improving availability: Clustered Continuous Replication (CCR) and Local Continuous Replication (LCR). These technologies reduce the risk of a storage failure causing serious problems. LCR keeps a local copy of your databases on the same machine, but you can put them on different storage media. CCR can do the same between two machines over a network. CCR, combined with the disk I/O improvements we touched on earlier in this column, opens up new options for storage hardware; if you would like to use direct-attached storage media such as SATA or SCSI drives, it is now a much more cost-effective, performance-improving option.

Administration
Microsoft invested heavily in a new administrative experience in Exchange 2007, which includes the command-line interface shown in Figure 1. It's called the Exchange Management Shell (EMS) and is based on Windows PowerShell™. If you are not a fan of the command line, that's fine-the GUI is still there for you, only now it's called the Exchange Management Console (EMC) and it's a far more intuitive interface than the old System Manager (see Figure 2). If you are already an advocate of command-line interfaces or want to become one, check out the EMS in Exchange 2007.
Figure 1 Storage Group Status in Exchange Management Shell
Figure 1 Storage Group Status in Exchange Management Shell
Figure 2 The Same Status in Exchange Management Console
Figure 2 The Same Status in Exchange Management Console
In Exchange 2003 you may have had to use Windows Management Instrumentation (WMI) scripts to perform some of the more complex administrative tasks, but with EMS these tasks can be done by anyone who sees "CD C:\TEMP" and doesn't think it's an album from a new band (ba dum bump). Although one of us is a former UNIX sysadmin, and therefore our objectivity may be questioned here, we can point you at plenty of unbiased third parties who will vouch for how the shell is incredibly intuitive even if you've never used a command line before (more on that in the next Exchange Queue and A column).
One of the beauties of Windows PowerShell is that it is object-based. When you retrieve information from the server, such as a list of mailboxes or SMTP connectors, the information is automatically stored in an object or variable and streamed to stdout as text for easy reading. That object can then be passed directly to another command and operated on in the pipeline (in which case it passes along the object rather than the text, making it easy to modify the data or operate on parts of it). Here's a simple example:
Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB
The Get-Mailbox command retrieves a list of mailboxes in the system. The | (called the pipe symbol) indicates that the output of the command on the left should be passed to the command on the right. The next part, "Set-Mailbox-ProhibitSendQuota 250MB" means that all of those mailboxes now have a quota such that they can no longer send e-mail after they reach 250MB in size. You could also have set it to 250000000 or 250000KB or .25GB as well-the shell is very flexible in how it handles data.
Another helpful administrative improvement in Exchange 2007 is the ability to create transport rules, using a rules wizard very much like the one in Outlook to apply business logic to messages flowing through your system. Want to block any e-mail that appears to contain Social Security numbers in the body based on a regular expression? Check. Want to set up an ethical wall so that two divisions in your organization can't e-mail each other? Check. Want to add a disclaimer to every e-mail that is going outside your organization? Check.
One last administrative feature that we are very excited about is customizable system messages: out of the box you can now add your own custom text to non-delivery reports as well as (finally!) the message users see when they are over their storage quotas.

Help the Help Desk
One of the biggest expenses for many customers is the help desk costs related to configuring new profiles in Outlook. With Autodiscover in Outlook 2007, just start Outlook and it will automatically look up your e-mail address and retrieve your Exchange server information from Active Directory® using the Service Connection Point. If you're not connected to Active Directory, just enter your e-mail address and password and the Autodiscover lookup can download an XML file from a specified Web server (such as http://autodiscover.contoso.com) that has basic configuration information in it such as the server to use for RPC over HTTP (now called Outlook Anywhere).
Another help desk cost is managing the seemingly inevitable false positives from your anti-spam filter. Users can keep safe lists in Outlook of senders whose messages should not be subjected to content filtering, but until Exchange 2007 those lists only let the messages bypass the Outlook filter. However, because the Exchange filter acts on the messages before Outlook ever sees them, users could still miss e-mail from people they trusted.
Exchange 2007 helps here too: if you use the anti-spam content filter with either the Edge or Hub server role in Exchange 2007, you can configure it to propagate users' safe-sender lists to that server, so that messages from those senders will bypass the spam content filter. Of course, what is spam for one user is a newsletter for another, so the safe-sender aggregation happens on a per-user basis.

End User Delight
With Unified Messaging (UM) in Exchange 2007 you can receive inbound voicemail and faxes in your Inbox. (If you've never had this before, you don't know what you're missing.) You can also call up your Exchange server and tell it to notify every participant of your 8 A.M. meeting that you're running late. Even the smallest of organizations can easily have a customized and branded automated attendant so that when your customers call you, your system can route them in the right direction. In order to use UM, you will need either an IP-based PBX (IP/PBX) or you can hook up your traditional circuit-switch based PBX to a Voice over IP (VoIP) gateway.
Link Access is a new feature in OWA 2007. What if you're on the road without a VPN client installed and you need to view a Microsoft Word document on a file share or a SharePoint® site on the corporate network? No problem-just load OWA 2007, go to the Documents link, and type in the name of the share or SharePoint site (http://mysharepointsite or \\server\share) to browse and open files. Of course there are plenty of security controls for administrators to lock this down however they desire-all servers allowed except a certain list, all servers denied except a certain list, only allow access to the documents if users log in to OWA from private computers, and so on.
OWA also includes WebReady Document Viewing (that's "transcoding" in geek speak) where you can tell Exchange to render certain types of file types into HTML if you don't have the right application installed locally. Exchange 2007 will ship with support for transcoding the following file types by default: DOC, DOT, RTF, WBK, WIZ, XLS, XLK, PPT, PPS, POT, PWS, and PDF. The transcoding engine has a pluggable architecture so that we could add support for new file types in a service pack. There are also administrative options so that you can determine which file types users are permitted to transcode, or to disallow transcoding entirely.
If you have mobile devices that synchronize with Exchange using Exchange ActiveSync®, you'll be happy to know that when you reply to or forward an e-mail thread, the message will no longer be converted to plain text. Your text is added at the top but the HTML body from the rest of the message remains as-is. This works for any device that supports ActiveSync, it does not require functionality in the client.

Q I've heard that Exchange 2007 is "64-bit only for production purposes." What does that mean?
A Exchange 2007 is available in both 32-bit and 64-bit flavors. The 64-bit version is intended for production "live" usage of the core server roles (Mailbox, Hub Transport, Edge Transport, Client Access, Unified Messaging). The 32-bit version is intended for evaluation of the new features of Exchange 2007. The management tools can also be used in 32-bit in production, so that you can manage your 64-bit Exchange 2007 production servers from your 32-bit Windows XP desktop machine. Also note that the Exchange 2007 schema must be installed from a machine in the root domain-Exchange itself does not need to be installed in the root domain, but we require the schema extension to happen in the root domain as a way of ensuring good network connectivity to the schema master. If you don't have a 64-bit server in that domain, you can use the setup.exe from the 32-bit version to extend the schema.
What's wrong with 32-bit servers, I hear you ask? If you've had the pleasure of running thousands of users on a single server, you know it can be quite a balancing act between performance and stability with the memory limitations we described earlier. If you've bought a new computer in the past two years, chances are that it already supports x64 extensions. In fact, it's pretty difficult to buy a new computer that doesn't support 64-bit mode these days. Thus, it may be that the machine already running Exchange in your environment is 64-bit capable; it's just that it's running a 32-bit operating system. Which brings us to a good point-once you've got your new 64-bit-capable computer, remember to install the 64-bit version of Windows Server 2003 SP1.
So why do you see all the warnings in setup about not using 32-bit installs in production? Although it's pretty easy to compile Exchange in multiple flavors, each component is 100 percent optimized and tuned for 64-bit (some of the code paths we've chosen to achieve the improvements in disk I/O on 64-bit systems actually cause a performance degradation in 32-bit environments). In fact, when you're kicking the tires with 32-bit, don't even think about getting it to perform under load (simulated or otherwise); you won't get a realistic picture of how it will perform in a 64-bit system or how many users you can fit on the server.
So we're all clear? You can use the 32-bit version of Exchange 2007 to:
  • Evaluate the new features on a test server with no live user mailboxes on it.
  • Drool over the new administrative console, shell, or OWA interface (mind the drool on the keyboard, though).
  • Administer your Exchange 2007 servers.
  • Extend the schema in your Active Directory forest.
Once you're ready to move mailboxes, you need the servers to be running a 64-bit operating system with 64-bit Exchange 2007. If you don't, you'll have both setup and ExBPA bleating at you (see Figure 3). Paul knows this for a fact-he wrote the code!
Figure 3 Trying to Install 32-Bit Where Only 64-Bit Should Go
Figure 3 Trying to Install 32-Bit Where Only 64-Bit Should Go

Q How much memory do I need to run Exchange 2007?
A Your base install needs at least 1GB of physical RAM. As I mentioned earlier, some of the server roles are on the heavy side. If you're looking to install an all-in-one server (such as Mailbox, Client Access, Hub Transport and Unified Messaging), you'll probably want to start with 2GB of RAM and scale it based on the number and usage of mailboxes. If you're looking to install either the Edge role or a cluster, then those need to be installed on separate machines. A cluster can only have the Mailbox role installed-nothing else.
You'll be excited to hear that you can finally install more than 4GB of RAM in your Exchange server. Many current machines come standard with 6 or 8GB, and it's always a crying shame to take those double data rate (DDR) modules out or use /BurnMemory to get the RAM down to 4GB (unfortunately, Exchange 2003 will perform worse and be less stable if you have more than 4GB-see go.microsoft.com/fwlink/?LinkId=76537 for details).
For your infrastructure servers (Hubs, Client Access, and such) you'll be fine with less than 4GB of RAM, even under the heaviest of loads. Where you want to spend your money is the Mailbox servers. That newly optimized 64-bit JET cache will want to make use of as much memory as you can throw at it. Of course, unlike Exchange 2003, Exchange 2007 supports up to 50 storage groups.
Although each storage group can support multiple databases, this won't really buy you any savings-especially as LCR and CCR (the two forms of database replication we discussed earlier) can only work with storage groups that have a single database. You'll certainly have to power up that extra RAM if you intend to create a bunch of storage groups or live the dream of 2GB+ mailboxes for each user. There's some great detailed information on RAM sizing on the Exchange team blog, but Figures 4 and 5 provide cheat-sheets to get you started.
Figure 5 RAM and Storage Groups (Close Figure 5)

Physical RAM | Maximum Recommended Storage Groups
2GB | 2
4GB | 8
8GB | 24
12GB | 40
16GB+ | 50
Figure 4 RAM by User Type (Close Figure 4)

User Type | Mailbox Role Memory Recommendations
Light | Base 2GB + 2MB per mailbox
Average | Base 2GB + 3.5MB per mailbox
Heavy | Base 2GB + 5MB per mailbox
By the way, Microsoft IT uses a number of storage groups that is a multiple of seven, because they have a rotating backup schedule whereby on any given day, only a few of the storage groups get backed up. We call this schedule "candy cane backups" because of the Excel spreadsheet that describes the backup schedule, where the storage groups getting backed up on any give day are colored red in a cascading way. Hope this was helpful. Please send "real" questions for the next issue.

KC Lemson is a lead program manager on the Exchange Server team. She spends her free time helping safeguard the money of Nigerian royalty.
Paul Bowden is also a lead program manager on the Exchange Server team. He spends much of his free time reconfirming his PayPal account information upon request.


 Security Watch: Services Hardening in Windows Vista
Security Watch
Services Hardening in Windows Vista
Wole Moses

Microsoft announced its Trustworthy Computing Initiative in early 2002, in the aftermath of several high-profile viruses and worms that wreaked havoc on Windows systems, paralyzed IT departments, and cost businesses and consumers enormous sums to remediate. With this initiative, Microsoft issued a
mea culpa regarding its security track record and made a swift course correction and paradigm shift from developing software with an emphasis on rich features and usability to prioritizing around software security and integrity. The Blaster worm struck in August 2003, adding further impetus to the security initiative. (For the Blaster story, see the sidebar "Attack of the Clones.")
The tenets of the trustworthy computing initiative are Secure by Design, which speaks to the secure coding philosophies; Secure by Default, which is about ensuring that components of Windows® default to the most secure setting possible; and Secure in Deployment, which has to do with the creation of tools and prescriptive guidance to help businesses and consumers secure their Windows infrastructure.
Overall the Trustworthy Computing Initiative resulted in major improvements in security; unfortunately, Windows XP could never fully benefit as it was released two years before the initiative took off. (Though Service Pack 2, SP2, made great strides to incorporate these philosophies, Windows XP could not be completely retrofitted into this initiative.)
Thus, Windows Vista™ is the first Microsoft desktop operating system that is fully compliant with the goals of Trustworthy Computing. Windows Vista Services Hardening, a specific implementation of the Trustworthy Computing Secure by Default principle (see Figure 1), is an important new capability that is designed to thwart errant service behavior that much of today's malware can currently perform. Service Hardening helps Microsoft take huge steps in changing the default behavior and security profile of Windows services.
Figure 1 Secure by Default: Windows Services (Close Figure 1)

Feature | Description | Result
Least Privilege | Windows Vista services are configured to use the least privileges necessary to run. | Windows Vista reduces the default security privileges available to Windows services, lessening the potential impact of malware.
Service Isolation | Service SIDs are utilized to allow services to run in low privilege accounts. | Windows Vista can thwart malware by restricting access to its resources based on service SIDs.
Restricted Network Access | Network restrictions are implemented out of the box on all Windows Vista services. | Windows Vista restricts malware from using services to perform improper network activities.
Session 0 Isolation | Session 0 is reserved for services. | Windows Vista restricts malicious applications from hijacking highly privileged services using message-based attacks since they no longer run in the same session.

Risky Services
Windows services, formerly known as NT services, are long-running executable applications that run in their own Windows sessions. Services can be started automatically when the computer boots, can be paused and restarted, generally don't show any user interface, and can run in the security context of an account that is different from either the logged-on user or the default computer account. Windows services are thus a great facility for certain types of application development and for end users who need to use these applications. However, because of their power and flexibility, Windows services have traditionally been vulnerable to exploitation-for several reasons.
First, in the past, Windows services have generally run in highly privileged Windows accounts such as the Local System account. If a service running in the Local System account is compromised by malware, the malware has a great chance of doing absolutely anything it desires on that system. Consider, for example, the remote procedure call (RPC) service in Windows XP. Prior to Windows XP SP2, the RPC service ran under the Local System account, which is what enabled Blaster, Welchia, and other worms to perform administrative tasks once the RPC vulnerability was exploited.
Second, many services are network-facing, which provides an opportunity for malware to exploit them by creating inbound connections to them over the network, and for an infected service to make an outbound connection to infect other systems or perform some other illicit activity such as forwarding monitored keystrokes. Most of today's worms and malware infections occur through some method of network connection.
Finally, services are typically long-running, which is to say that they run from the time a system boots up until it is shut down. This is attractive to malware writers because it means they can probe that service for flaws for as long as the system is up-ultimately providing malware plenty of time to perform its nefarious activities.

Attack of the Clones
It could be his greatest triumph. If everything went according to plan, he might soon control hundreds of thousands of Windows systems around the world, issue virtually any instruction to them, and then kick back and watch them obediently carry out his every command.
Persistent yet elusive in his methods, he started by surreptitiously probing several computer systems, looking for a vulnerable entry point. It didn’t take long to find exactly what he was looking for—an unpatched system suffering from a known vulnerability he knew exactly how to exploit.
What made this particular vulnerability so sinister was that by successfully exploiting it, he could gain full administrative access to the system. He wasn’t taking control of just any account: he was manipulating the most powerful administrative account in Windows. Whatever he did next was limited only by his imagination.
After a few moments of reflection, he tested his rogue code against the unpatched and vulnerable machine—and it worked! As simple as that, he now had unlimited privileges to the computer. He used his administrative access to force the machine to download and install Trojan horse code, make registry modifications, and then reboot, turning the infected system into a surrogate ready and willing to carry out his commands. The registry modification caused the malicious software to run every time the computer restarted.
Now his intentions became clear. Upon infection, any contaminated machine would probe specific network ports of all other machines on the network. If that network port was open, and the machine was vulnerable, the Trojan horse code would be downloaded and installed to this new machine. The same registry modifications would occur. The cycle would recursively repeat itself and thus a swelling army of attack clones was created. By the end of the day, thousands of Windows systems around the planet were part of his sinister clone army, unresponsive to any commands issued by anyone else in the world.
As if that were not enough, he then turned his sights on the Microsoft Windows Update site and instructed all of his clones to perform a Denial of Service Attack on August 15, 2003 in an attempt to prevent any computer anywhere in the world from downloading the vulnerability fix that, interestingly enough, had been available for months.
By now you probably realized that I just described the MS Blaster worm pandemic that, in August 2003, struck Windows computers in every corner of the globe. Blaster was arguably one of the most serious attacks on Windows ever, causing billions of dollars in damage. The irony is that although MS Blaster had enormous power over machines it infected, it was remarkably simple in its implementation.

How Blaster Works
Blaster and its derivatives use a vulnerability in the Windows RPC service to execute a buffer overflow. An attacker who successfully exploits this vulnerability would be able to run code with Local System privileges on an affected system, enabling him to take any action on the system: install programs, view, change, or delete data, and create new accounts with full privileges.
In the case of Blaster, the worm automatically scans networks looking for computers with open TCP port 135. When it finds a victim, Blaster attempts to exploit the RPC vulnerability. If successful, it then connects to port 4444 on the target and instructs the victim computer to launch Trivial File Transfer Protocol (tfpt) and download a copy of the worm, called MSBLAST.EXE, from the infected system. (Tftp is included as part of the operating system in Windows 2000, Windows XP and Windows Server 2003.) The attacking system then instructs the newly infected computer to launch MSBLAST.EXE, and the victim computer becomes a new attacker. Blaster also wrote code to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Run Registry key, enabling itself to run every time the computer started.

Services Hardening
Services have been hardened and secured in Windows Vista in four ways: running services with Least Privilege, Service Isolation, Restricted Network Access, and Session 0 Isolation. I'll discuss each of these in detail.
Running with Least Privilege Many Windows services have previously run in the context of the Local System account-the most powerful account in Windows. The Local System account has user rights and privileges such as the ability to access almost any system object or another user's profile, impersonate users, open sensitive registry keys such as: HKLM\SECURITY, and to present the computer's credentials to remote servers. Since malware writers would love to have this level of access and control of Windows, any service running in the Local System Security context is sure to become a juicy target.
It turns out that although a number of Windows services have been configured to run under the Local System account, many of them need only a small subset of the privileges that are unique to the Local System account. Unfortunately Windows XP and previous versions of Windows operate in an "all or nothing" manner, which is to say they provide no mechanism to pick and choose needed privileges. Thus, many Windows services inevitably end up running with unnecessarily excessive security privileges.
Windows Vista Service Hardening addresses this issue by introducing the concept of least privilege to services configuration. Least privilege enables services to run with the minimum privileges necessary to function, instead of forcing them to run with all of the default privileges assigned to the account they use to log on.
For example, a service may need to be able to act as part of the operating system but doesn't need to be able to create a security token. With least privilege, you can remove the create-token privilege. As a result you lower the damage an attacker could do should that service become vulnerable to an exploit in the future. Developers can use command-line tools such as SC.exe (see Figure 2) or use programmatic methods to define and specify the privileges their particular service needs. Out of the box, Microsoft has applied least privilege to reduce the default privileges on all pre-installed Windows Vista services.
Figure 2 SC Command Options Define Windows Vista Service Privilages
Figure 2 SC Command Options Define Windows Vista Service Privilages
Service Isolation In versions of Windows prior to Windows Vista, when a service needs to access a privileged object (such as a sensitive registry key or file), the services gain access via one of three methods: using the Local System account to access the object; decreasing the security on the registry key or file to enable a lower-privileged service account to gain access; or creating an account specifically for the service and allowing access to the objects only for that account.
While these approaches all work, there are basic problems with each. The first two are inherently risky and the last one introduces the headache of having to manage passwords manually on the new accounts.
Suppose, for example, an antivirus program installs a service that needs access to several sensitive system objects, such as the virus signature file and registry entries pertaining to the antivirus software. If the antivirus service was configured to use the Local System account or, for that matter, any of the other built-in security accounts, to access its objects, this would mean that if any other Windows service that used that account became infected by malware, that malware could potentially access and modify the antivirus signature files, alter registry settings that affect the way the antivirus software works, or simply shut down the antivirus service altogether. As a matter of fact, today's malware uses some of these exact techniques to keep itself hidden and functional.
Windows Vista addresses these security and manageability concerns with service isolation, which enables a service to reserve an object for its exclusive use by securing the resource-such as file or registry key access-with an access-control entry that contains a service Security ID (SID). Thus, the antivirus service described in our example could run in a low-privilege account but would still have access to sensitive signature files or registry keys. To enable this access, the antivirus service (running in this low-privileged account) would have a SID assigned to it by Windows Vista. After the SID was assigned, the antivirus program could then modify the access control lists (ACLs) of its file system and registry objects to give access exclusively to the antivirus service.
Here's another example. Back in 2003 the Welchia worm started taking advantage of an RPC vulnerability to write itself to %System%\Wins\Dllhost.exe. It also added keys to HKLM\SYSTEM\CurrentControlSet\Services in order to install its own services to the infected Windows system. Today, however, Windows Vista could thwart Welchia by restricting access to both locations to specific appropriate services and by using low-privilege accounts to grant those services access.
Restricted Network Access Windows Vista includes a new firewall that builds upon the capabilities delivered in the Windows XP SP2 firewall. Key new capabilities include outbound filtering and IPsec integration. The new firewall also integrates with Windows Vista Services Hardening to make it more difficult for malware running within an exploited Windows service to perform certain improper network activities.
In the Windows Vista firewall, Windows services are assigned network firewall policies that provide limitations and restrictions on service behavior. For example, a service like Plug and Play, which may never need to communicate over a network port, can be assigned a "no network access" restriction. With this restriction in place, an exploit designed to target that particular service could never reach the service via some network-based approach. Any attempt, inbound or outbound, by that restricted service to communicate would be blocked by the firewall. Other services that have legitimate needs to access a network can be configured to use only specific ports. Developers can take advantage of this capability to restrict their service's network access.
The network restrictions combine with Service Hardening to provide a robust defense against potential service based attacks, which is a big improvement over previous versions of Windows. Previously, there was no way for Windows to decide how, where, and which services were allowed to communicate via the network. However, by using the Windows Vista Firewall Network restrictions against the RPC service, we could prevent viruses such as Blaster, Sasser, or Welchia from using infected services to communicate with other machines.
Session 0 Isolation Fast User Switching in Windows XP accommodates simultaneously logged on users by putting each user in a different Windows session. Session 0 is created during startup, with more sessions added as required. Services have always run in Session 0 and, before Windows Vista, user applications have also been able to run in Session 0. However, there are risky security implications to running user applications and Windows services in the same session because services run at elevated privilege and are therefore targets for malicious software looking for a means to elevate its own privilege level.
Windows Vista addresses these security risks by reserving Session 0 exclusively for services, running applications in other sessions, and by making Session 0 noninteractive (which means that a service can't create a user interface, such as a dialog box or prompt, that an end user can access.) Because of these changes, Session 0 Isolation will impact application compatibility for anyone developing Windows services or drivers.

Summary
Windows Vista is the first complete Trustworthy Computing desktop operating system release from Microsoft and includes significant advancements that will go a long way towards protecting Windows users. Computer security is, of course, an evolving discipline and there is no doubt that malware writers are constantly looking, probing, and researching for new ways to exploit Windows. However, the new Service Hardening features in Windows Vista significantly raise the bar by enhancing default security settings and reducing the potential surface area for an attack. See microsoft.com/whdc/system/vista/Vista_Services.mspx for more information on these substantial improvements.

Wole Moses is a Microsoft Regional Windows Lead and an eight-year Microsoft veteran. Currently based in Istanbul, Turkey, Wole works with the largest emerging market customers in the Middle East and Africa to help them envision and design Microsoft-based solutions that optimize their IT infrastructure while maximizing security.


 The Desktop Files: Windows Automated Installation Kit
The Desktop Files
Windows Automated Installation Kit
Wes Miller

Microsoft has historically offered two versions of the deployment tools that the Windows Deployment Team produced. The first version came in the form of the deploy .cab file which has shipped on the Windows CD for years. It included documentation and tools such as Setup Manager for creating unattended setup files, as well as
the Sysprep tool, used to prepare desktops for deployment. The other version of the deployment tools was the OEM Preinstallation Kit (OPK), which was specifically engineered to meet the needs of OEM system manufacturers and was available only to them. This was the original way in which Windows® PE was distributed. There is a new version of the OPK for Windows Vista™, but it will continue to be available to OEMs only.
Fortunately for most other Microsoft customers, some of whom couldn't obtain Windows PE during the Windows XP timeframe, there will be a near analog of the OPK available for them to use, called the Windows Automated Installation Kit (WAIK). The WAIK will be freely available for download from microsoft.com/downloads after Windows Vista ships and will include the following components: Windows PE 2.0, Windows Deployment Services, ImageX, and Windows System Image Manager-a tool I haven't mentioned before that allows for the creation of unattend.xml files to automate setup. Also included is full documentation for all of the tools.
Note that the recommended method for obtaining the WAIK is to download the full Business Desktop Deployment Solution Accelerator (BDD) from microsoft.com/desktopdeployment, which provides not only the WAIK, but the User State Migration Tool (USMT), Application Compatibility Toolkit (ACT). The BDD also includes additional tools and guidance for achieving a successful deployment of Windows Vista.

Windows PE 2.0
I covered Windows PE 2.0 in significant depth in the November 2006 issue of TechNet Magazine, so I won't go into much detail here; suffice it to say that the WAIK will deliver the official release of the new Windows PE build for Windows Vista. It's important to understand Windows PE, since all of the other tools in WAIK either use or work with Windows PE in some manner. You can find my article on Windows PE 2.0 here. .

ImageX
In my last column, I spent a fair amount of time covering the Windows Imaging (WIM) file format. (See microsoft.com/technet/technetmag/issues/2006/12/desktopfiles.) Now I'll look at ImageX, which is a small, yet powerful, command-line tool that makes the built-in imaging of Windows Vista possible. When planning ImageX, we had considered creating a GUI-based tool, but decided to focus on the command line since automation of the imaging process was the critical component. To see the command-line options for ImageX, see Figure 1.
Figure 1 ImageX Command-Line Tool in Action
Figure 1 ImageX Command-Line Tool in Action
Windows Deployment Services (WDS), which I'll describe later, does deliver a lightweight GUI tool that allows for easy capture of images, but it does not deliver the full functionality of ImageX. It's also important to note that ImageX is designed and tested to capture images for deployment under Windows PE. It was not designed to do "live" captures of Windows systems that are actively running.
If you are familiar with any other system imaging tool, you are familiar to a degree with ImageX. It was designed to be simple to use, allowing you to easily capture and apply images, and yet provide critical functionality that's often missing or incomplete in the commonly used deployment tools that came before it. One such example, which I'll cover momentarily, is the ability to easily and transparently mount an image as a part of your local file system so that you can view, modify, or delete files from within an existing image.
ImageX provides the image manipulation switches shown in Figure 2. I'm going to call out a couple of specific commands to describe them in more depth.
Figure 2 Image Manipulation Switches (Close Figure 2)

Switch | Description
IMAGEX /APPEND | Appends a new Volume Image into a WIM file which already contains an existing Volume Image.
IMAGEX /APPLY | Applies a Volume Image to a volume that has been partitioned and formatted.
IMAGEX /CAPTURE | Captures an initial Volume Image into a WIM file.
IMAGEX /DELETE | Permanently deletes the references to a Volume Image from a WIM file. Note that this deletes the metadata. It does not remove the compressed file data—that can be done by using the /export switch to create an entirely new WIM.
IMAGEX /DIR | Displays the directory tree of a specified Volume Image in a WIM file.
IMAGEX /EXPORT | Exports a Volume Image from a WIM file or several Split WIM (SWM) files.
IMAGEX /INFO | Displays the details of a given Volume Image or WIM file—also can set the /boot option for a given Volume Image that contains Windows PE. Only Windows PE can be booted from a WIM file.
IMAGEX /SPLIT | Splits a WIM file into one or more smaller SWM files so that it can be contained on multiple CDs or DVDs.
The Capture command should be relatively clear-the main thing to remember is that you only use capture once per WIM. Since a WIM file is just a file capture, you can capture an entire volume (C:) or even just a directory (C:\Test). Application is the same-you can apply an image to a directory (even if you had captured an entire volume) or, as is more likely the case, the root of a volume. Once a single Volume Image exists in a WIM already, you would use the append command to add to it. Apply is also relatively self-explanatory and only becomes complicated when you are applying multiple WIM files. The delete command is useful if you want to remove the reference to a specific Volume Image-but in order to completely remove the data from that image you must use export to create a new WIM completely free of the data (meaning, if you want to reduce the size of the image by removing the remaining data, you must use export). Think of export as a tool that can act as a defragmenter, or a consolidator, letting you weave a Volume Image into one or more WIM files, or export it to its own completely standalone WIM file. ImageX also provides the following image editing switches: IMAGEX /MOUNT, IMAGEX /MOUNTRW, and IMAGEX /UNMOUNT.
As mentioned, the product team incorporated editing capabilities into the imaging tools and format from the very beginning. By enabling editing, the format and tools would allow customers to copy files in or out, apply service packs, add/remove files or standalone applications, or add/remove other data from the image as needed (even mounting and modifying the registry). Servicing of the image was always a key focus.
You can think of mounting the image as loading the WIM file as a virtual directory. If you're familiar with them, the proper analogy is probably more like a Volume Mount Point, which allows you to mount an entire volume to a directory that exists on another volume (making F: visible as C:\DriveF, for example). Similarly, you may have used the Microsoft® Virtual CD tool or other ISO mounting tools that allow you to mount ISO (CD) images as local drives. In this same manner, ImageX allows you to mount a WIM file as an overlay on top of a directory. You create the directory and then use the mount command to overlay the specified Volume Image on top of the directory, much as if you had applied it there.
Unlike the Virtual CD tool, however, you can mount a WIM image even if it is located across a network share or if it is on removable media. Of course, doing so may limit its editing capability-a WIM on optical media (CD or DVD) will generally be editable in read-only mode. You can also only edit one Volume Image in a WIM at a time if you are editing in read/write mode-this is to allow for proper locking and safe updating of the file when it is unmounted.
You can mount the image read-only (/mount) or read/write (/mountrw). When you use read/write, any modifications you make to the image are temporarily cached (they do not take effect immediately), and when you run the /unmount command with the /commit option, these changes are permanently persisted into the WIM. If you made changes and then decided you really didn't want to persist them, you could also discard rather than commit them when you unmount the image. This is all or nothing-all writes you've made during the time that the WIM file was mounted are either committed or discarded.
Note that there's an important caveat here. Just as with the delete command, when you use the read/write functionality to edit the WIM, the file data in the WIM file itself isn't completely erased or cleaned up-the files are appended to the end of the WIM file, and the earlier reference in the Volume Image is supplanted with the updated data. This means that if you added a new 5MB file, replacing an existing 5MB file, your image will grow by the size of the 5MB file after it has been compressed (that is, 5MB or less, depending on the type of compression used). To remove the old data from the WIM (if you wanted to shrink the image) you would need to use /export to export the Volume Image into an entirely new WIM file.
If you read my discussion of Windows PE 2.0 in the November 2006 issue of TechNet Magazine, you'll remember that it supports booting from a WIM. In order to do this, the WIM file is read using a driver, similar to the way ImageX does it. But the ImageX support was designed to be used at design time, and the WIM boot feature was designed specifically to be read-only and to work just for Windows PE. So although they are similar, the drivers and implementation are different.
In addition to the ImageX tool, Microsoft provides a formally documented API, WIMGAPI, that allows full support for any imaging tool that wants to be able to capture, apply, or modify WIM files. So any third party that wants to add imaging support or replace an existing imaging infrastructure, can do so with WIMGAPI. This API is a part of the WAIK and therefore is distributed with it.

Windows Image-Based Setup
With the imaging format in hand, the new engine for setup was designed. At its core, it is much like the old Mini-Setup or Windows Welcome, asking the basic questions necessary to get the system uniquely set up and configured while also handling disk configuration before installing the image from the install.wim on the Windows setup DVD. The primary goal of the new setup engine was to allow for manual installations of Windows. We envisioned that many OEM and enterprise customers would use ImageX to do their actual deployments.

Remote Installation Services
At this point you may be asking why I haven't discussed Remote Installation Services (RIS). RIS was something I also inherited when I started in the Windows Deployment team. RIS, which shipped first with Windows 2000 and then again in Windows Server® 2003, uses a Pre-boot Execution Environment (PXE) to network boot a computer to the point that a rudimentary wizard can be completed, and Windows installation can occur-all over the network.
The single largest problem with RIS was that it was excruciatingly fragile. The Windows Server 2003 release of RIS, originally only supported with Windows 2000 Professional, expanded support for server versions of Windows. With the incoming rush of Serial ATA (SATA) storage controllers and GB or faster NICs, keeping drivers up to date in RIS was always fraught with peril. Additionally, RIS doesn't support many of the same locales that Windows does, meaning installation of localized versions of Windows with localized keyboards can be difficult, if not impossible. Windows Deployment Services was designed to be the amalgam of Windows setup and RIS-a PXE-initiated boot of Windows PE, which would allow you to deploy a WIM file over the network.
WDS was designed to not only be available in the forthcoming version of Windows Server code-named "Longhorn," but also as an update that would be installable on Windows Server 2003. This meant that WDS would be able to deploy Windows Vista from older versions of Windows Server, and that it would be able to deploy older versions of Windows as well. In fact, WDS not only works with RIS, but it requires an installation of RIS in order to function. This is because it works by updating the RIS infrastructure to be compatible with WDS, while also providing the new WDS infrastructure.
In addition to working as an upgrade from RIS-thereby providing a good migration path for customers continuing to use earlier versions of Windows while beginning deployments of Windows Vista, WDS also provides much better management tools than RIS historically had, allowing for easier addition of new images to the server. It also provides a pluggable PXE framework, meaning that a third-party PXE server can integrate in and specify that it is to answer a specific client's PXE request instead of WDS. This was a request that we often received with RIS that we could not provide at that time.
Initially available as an installable component on Windows Server 2003 to update RIS, WDS will also ship as an integrated component of the Windows Server "Longhorn" products. Microsoft is also currently planning to include WDS functionality in the future versions of SMS (which will be known as System Center Configuration Manager).
WDS works by providing a PXE-booted version of Windows PE 2.0. This image is contained in a WIM (meaning there is reduced data transmitted over the network) and is booted over the network into a RAMDisk. The installation then happens under Windows PE, using a new client application that provides the functionality delivered by the RIS rudimentary OSChooser application in the past.
Though WDS does not support RIS images of Windows XP, Windows 2000, or Windows Server 2003 as-is, it does have the ability to deploy Sysprep images of them. WDS also integrates into Active Directory®, as RIS did historically, but the PXE server can also run without Active Directory if needed. WDS can even be initiated from Windows PE booted from something besides PXE-such as a CD, DVD, or USB Flash Drive (UFD). This is helpful functionality that RIS was not able to provide.
There are effectively three modes WDS can operate in, depending on your existing use of RIS:
Legacy WDS binaries are installed, but OSChooser is the boot mechanism. RISetup and RIPrep, the scripted setup and image-based setup tools for RIS, still function.
Mixed-Mode Both boot mechanisms are available, both sets of imaging tools function, and both sets of management tools function.
Native There is no RIS functionality, only WIM functionality, Windows PE boot, and new management tools are available. Note that this is the only mode scheduled to be available for Windows Server "Longhorn." It will not include any RIS functionality.
WDS also implements a custom client-server communication protocol, and as a result, an OEM or enterprise customer could theoretically build his own deployment application as well.
The process of capturing a WIM image into a WDS server is nearly identical to the Sysprep scenario I walked through. The difference is that the last step will involve booting into the WDS Capture Image, a Windows PE image that exists to help you capture a client system, and capture it to the WDS server.
The core components of WDS are as follows: the WDS Server Service, PXE Server, Image Store, Communication Protocol, File share with Windows PE images (to be booted), WIM images (to be installed), and additional related management files.
WDS was designed to be relatively lightweight and to provide a nearly identical experience (though often faster) than a traditional optical media-based installation of Windows. The implementation of WDS as an update to RIS allows you to gradually replace RIS in a graceful manner while easing into the deployment of Windows Vista in your organization. It also does so in a way that is easier to use and faster than RIS was ever able to deliver with previous versions of Windows.

Windows System Image Manager
The final component of the WAIK is the Windows System Image Manager (SIM). If you are familiar with Setup Manager from previous versions of Windows, then the concept of the Windows SIM should be somewhat familiar to you. This tool allows you to complete several tasks with unattended setup files. You can easily create a new unattended setup file, edit an existing one, or verify the settings in an existing file against a specific image of Windows Vista. The tool can also show you all potential configuration options given a specific WIM with Windows Vista in it-think of the traditional unattended setup options, documented historically in the help files accompanying the deploy.cab. Finally, Windows SIM can help create Distribution Shares and Configuration Sets, which are used to add drivers, applications, and updates to your Windows Vista installations via an unattended setup file.
Windows SIM requires that you be a local administrator on the system you are running it on. When you open Windows SIM, you will see five panes, as illustrated in Figure 3.
Figure 3 Windows System Image Manager
Figure 3 Windows System Image Manager
Distribution Share, on the upper-left, is a pane that displays drivers and other packages that you have added via SIM. By default it does not have a Distribution Share mounted, but you can easily open or create one.
Windows Image pane, below Distribution Share, displays the config options (Components and Packages) in a given Windows Volume Image in a WIM. Note that you mount a single Volume Image of Windows (one SKU on the Windows Vista DVD) at a time.
Answer File, the pane in the center, displays the configuration options in a new or existing Windows Vista unattended setup file, as well as the default settings as defined by the catalogs (the potential settings and configuration) from the WIM Volume Image that you have mounted.
Properties, in the upper-right of the window, is a pane which lets you edit the individual properties of a component from the Answer File pane.
The final pane is Messages, which is located at the bottom and displays more in-depth feedback, including a view of the raw XML in a Windows Vista unattended setup file (always in an XML format) as well as validation output and any messages related to any Configuration Sets you are currently using (the Configuration Set tab only contains data if you have a Configuration Set opened).
As you've seen, the WAIK provides a very powerful set of tools to help you deploy Windows Vista. The Windows Deployment team has done a great job of creating a collection of tools that you'll find make Windows Vista more easily deployable than any version of Windows in the past.

Wes Miller is a Development Manager at Pluck (pluck.com) in Austin, Texas. Previously, he worked at Winternals Software and at Microsoft as a Program Manager and Product Manager for Windows. Wes would like to thank Scott Dickens and John Macintyre, from Microsoft, for their assistance with this column. Wes can be reached at technet@getwired.com.


 Field Notes: Tech Support for In-Laws
Field Notes
Tech Support for In-Laws
James Snell

I GOT MARRIED last year and, in exchange for my beautiful wife, I seem to have signed a tech-support agreement with her entire family. Recently I got the dreaded "You know about computers, don't you?" call from my mother-in-law, and off I went to find her Windows® XP machine suffering under a ton of the usual spyware, adware, toolbars, and so on.
If you're an IT pro, chances are you're used to fixing computers. But doing it for a relative isn't as easy. The fastest way to deal with an infected machine is to format the hard disk and reinstall Windows. Unfortunately, most people reject that option because they don't want to lose all their data. That usually means you have a lengthy clean-up ahead of you. But what if you can't even get on the machine, or can't get to the Internet?
What you need to do is to put together a toolkit on a 512MB USB key, including antivirus, antispyware, and personal firewall software. Keep that toolkit up to date, and keep it handy.
You'll also want to put Windows XP Service Pack 2 (SP2) on the USB drive. Although Windows XP now comes with SP2 in the box, my mother-in-law's version predates that edition. You can download the Windows XP SP2 installation from microsoft.com/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx. (You want the version for multiple computers; the one for single computer installation uses Windows Update.) At 266MB, it's hardly a quick download, but you only need to do it once.
So, let's say you've spent the afternoon either formatting and installing the OS or laboriously removing viruses and spyware, followed by, in either case, installing the necessary software updates to Windows, plus firewall, updating antivirus definitions, and so on. What now? You surely don't want to spend every weekend doing this. There are several steps you can take to make that scenario less likely.

Banish Junkware
My mother-in-law's system was filled with software-installed mainly by friends-ranging from the almost useful to utter junk. To prevent this from recurring, I locked out the admin account with a strong password and set her up as a standard user-she doesn't need to use the admin account very often. Next time someone tries to install something for her, he'll need to login as admin to continue and that's usually enough of a deterrent. That, plus a little user education, should keep the junk down. (Get Safe Online, getsafeonline.org, has some great tips for users on keeping a PC safe.)
Her security needs are different with regard to passwords. I left the password off the user account to encourage her to use it. Besides, I figure anyone with ill intent and physical access to the machine is more likely to be removing the box from the house than the data from the box.
It may seem silly then that I put a sticky note on the inside of a door on the front of the machine. But I'm not worried about her getting at the admin password without me knowing-after all, it's her machine. While these wouldn't be accepted best practices in an enterprise, my mother-in-law doesn't store any sensitive data, and she's not concerned about other people using her machine. The goal here is to make her life as a user easy, and-more importantly-my life as her tech support engineer easier!

Repel Boarders!
The next step was to provide a bit of extra protection. I like the fact that a firewall is integrated into Windows and that third-party firewalls exist. However, I don't trust just one firewall alone. For added safety, my mother-in-law now has an ADSL router with an integrated firewall. Yes, this is an extra expense and an extra piece of gear to configure and run, but it does add some degree of additional protection. Plus, it's a box with flashing lights-how impressive it that?
But don't assume that the router's initial configuration is secure. I've picked up a couple that, by default, had the Web and telnet interfaces enabled on the public side. Take a minute to check the advanced options.
Software firewalls cannot load up before the networking components have gone live. The built-in Windows firewall is the only protection you have during the early stages of boot up (another reason to have Windows SP2 installed before you connect the machine to the Internet). When you disable Windows firewall, you are still protected by it until your chosen firewall has a chance to start. Plus, with the router firewall in place, I no longer have to worry that something may turn it off because it's a separate device; if it's not on, she isn't connected. Also I see it in the same way as double-keying data. For an attack to succeed, both the router and the software firewall must fail at the same time. It's not impossible, but it is less likely.

Annoy and Protect
Think how much easier the whole process would have been with a good backup. I have no patience for anyone who says they can't back up at least their most important information. DVD recorders and media aren't terribly expensive and Windows comes with backup software included. The problem is so many people just don't use it. For my mother-in-law, my solution was to do the usual backup of the My Documents folder on a schedule and to save the file straight into the CD-burning folder (%userprofile%\Local Settings\Application Data\Microsoft\CD Burning). For this to work, you have to tweak the scheduled task to run only when the user is logged on. So the CD burning wizard now gives regular (and irritating) prompts until she inserts a blank disk, and that's all I want.

Keep in Touch
By setting up Windows Live™ Messenger, you can configure desktop sharing. This means once you get home, if anything else needs setting up then you can see what's going on without making another visit (always a good thing). Incidentally, I can also confirm that taking control of a remote machine (which requires permission, of course) and being watched as you control the mouse is even more impressive than the flashy lights on the router!

James Snell is a former Microsoft Support Specialist based in the U.K. He has worked with home users and with some of the largest global accounts at Microsoft. James is currently working on a new skill—fatherhood. You can reach him at James.Snell@lineone.net.


 Windows Confidential: Getting Out of DLL Hell
Windows Confidential
Getting Out of DLL Hell
Raymond Chen

DLL HELL. A problem so insidious it has its own pejorative nickname. You install one program and suddenly some seemingly unrelated program stops working. This is because, unknown to you, the two programs are connected via a shared DLL file. The two programs might have different ideas of what version of the MSVCRT.DLL file should be in the system directory. Or the first program may upgrade an ActiveX® control that the second program uses-an upgrade that the second program is not entirely compatible with.
If both programs are essential to your company's day-to-day operations, it doesn't really matter which program is to blame. The important thing is that you need to get them up and running. There isn't much difference between "We're losing money" and "We're losing money because of Bob." Either way, your company is losing money and it's your job to fix the problem right away.
It used to be that you had to choose which program won and which program lost. Starting with Windows® 2000, bandages were made available to help you patch over these conflicts. These bandages, however, are only temporary solutions, allowing you to get your system back on its feet while you investigate a more permanent resolution to the conflict.
Windows 2000 implemented a rudimentary version of what now goes by the fancy name of Dynamic-Link Library Redirection. To enable DLL redirection, create a file with the same name as the program whose DLLs you wish to redirect, but with .local appended to the name. For example, to apply redirection to C:\Program Files\Litware Inc\Invoice.exe, create the file C:\Program Files\Litware Inc\Invoice .exe.local. The contents of the file aren't important; what's important is that the file exists.
Once you've enabled redirection for a program, all attempts by that program to load a DLL will first look in the directory that contains the program before the usual search locations. Therefore, in the case of the conflicting MSVCRT.DLL file, you can enable redirection in each program and put a private copy of MSVCRT.DLL into each program's installation directory. Each program then receives its own version of MSVCRT.DLL-the version of the DLL with which the program was tested.
The magic of this technique is that it works even if the program uses a full path to load the DLL. For example, suppose the program tries to load C:\Program Files\Common Files\Proseware Inc\taxplugin.dll. After upgrading to Proseware 2.0, you discover that its tax plug-in is incompatible with your invoice program. What you can do is copy an old version of the tax plug-in to C:\Program Files\Litware Inc\taxplugin.dll. Even though the program uses a full path to load the tax plug-in, DLL redirection will still look in the current directory and use the local override instead of the one in the Proseware Inc directory.
In Windows XP and Windows Vista™, the rules for DLL redirection are a little different, but the general principle remains the same. In addition to creating a .local file, you can also create a .local directory. In that case, the .local directory is searched rather than the program's install directory. This allows you to apply redirection to multiple programs in the same directory without conflict.
Note that you cannot apply redirection to programs that contain an application manifest, and so-called known DLLs are also exempt from redirection. (For further details, see "Dynamic-Link Library Redirection".)
DLL redirection won't entirely get you out of DLL Hell, but at least it gives you some first-aid techniques for tending the wound while you sort out the problem.
Figure 1

Raymond Chen writes about both Windows history and Win32 programming on his Web site, The Old New Thing, as well as in his new book also titled The Old New Thing (Addison-Wesley, 2007). He does not, however, have a pet cat named The Old New Thing.