IntelliMirror Adds Manageability

WINDOWS 2000 WORKSTATION MANAGEMENT FEATURES

What's the biggest challenge you face in the maintenance of your enterprise Windows NT infrastructure? Is the answer

(a) software distribution
(b) configuration management
(c) easy OS installation
(d) roaming users
(e) all the above

If you answered e, then you're among the majority of Windows administrators. The arrival of Windows 2000 (Win2K) is just around the corner, and with Win2K comes technology that might revolutionize software distribution, configuration management, OS installation, and roaming user profiles. I can hear you skeptics saying, "Revolutionize?" Administrators have waited a long time for Win2K's improved manageability. Although these improvements are only the beginning, in this article I explain how these improvements represent a revolution in the ideas surrounding Windows management.

Over the past year, Microsoft has used various terms to refer to management technology, including Zero Administration for Windows (ZAW), Change and Configuration Management, and IntelliMirror. IntelliMirror is a subset of the Change and Configuration Management solution within Win2K. What is IntelliMirror? To answer this question, I'll examine the features that make up IntelliMirror, explain why these features are important for getting control of your Windows infrastructure, and show you how to set up these features in your Win2K environment.

The name IntelliMirror hints at this technology's purpose to intelligently mirror the user experience regardless of computer choice or network connectivity status. Underlying the mirroring of the user experience are three important categories of management: user document management, user settings management, and software installation. Spanning these categories and enabling the management features are two key Win2K technologies—Active Directory (AD) and Group Policy. As I examine each IntelliMirror management category, I'll explain how AD and Group Policy help you manage your environment.

User Document Management
IntelliMirror's user document management technology lets documents follow users. The keystone to this technology is the offline-folders feature—previously known as client-side caching. Offline folders let users store server-based files, server-based folders, and Web content locally on a Win2K workstation so that users can continue to use or view content without a network connection. If you're familiar with NT 4.0's My Briefcase, think of offline folders as a more intelligent and integrated My Briefcase.

Let's look at an example of how offline folders work. Suppose a user's home directory resides on a network server and maps to the H drive. The user can simply right-click on the home directory folder and choose the Make Available Offline property from the context menu to tell Win2K to cache the contents of the home folder to a laptop. After the user disconnects the laptop and logs on again, the home folder will be available on the laptop without a network connection. If the user was working on a document in Microsoft Word, he or she can continue editing this file as if the laptop is still connected to the network. The next time the user connects to the network, Win2K will perform a file-level synchronization of all changes the user made to the laptop version of the home folder with the server. Offline folders perform only whole-file synchronization, not bit-level synchronization. Therefore, if a user changes one byte in a cached file, Win2K will copy the whole file back to the server when the user reconnects to the network. If two people are working on the same server-based file offline, Win2K will use the last-writer-wins approach (i.e., the most recently saved copy) when synchronizing the files with the network.

An administrator can specify that a client always cache the contents of a given share or folder. Alternatively, an administrator can restrict caching to only documents or only application files. From the client, a user can pin (i.e., select) a file or folder, such as the home folder, to make the folder continuously available offline.

To manage synchronization in Win2K, Microsoft provided the Windows Synchronization Manager tool. From the Start menu, choose Programs, Accessories, then Synchronize. You can set up offline-folder synchronization on a per-network-adapter basis, which lets you modify synchronization behavior depending on whether a network connection is via dial-up or LAN. For each network connection that you define, you can specify whether to perform synchronization at logon or logoff, when the computer is idle, or on a scheduled basis.

To control offline-folder behavior for Win2K users, you can use AD-based Group Policy Administrative Templates, which are similar to NT 4.0 system policies. Screen 1 shows some of the offline-folder policy options that you have at your disposal if you use Administrative Templates.

IntelliMirror's user document management also includes the My Documents folder feature. The My Documents folder is part of a Win2K user profile that will replace NT 4.0's personal folder. When you use roaming profiles, Win2K lets you redirect a user's My Documents folder location to prevent caching a large My Documents folder each time a user logs on to a new Win2K machine. Screen 2 shows how to use the My Documents Properties page's Target tab to move the default location for My Documents to another location on your network, such as a home folder.

Finally, user document management includes the new disk quota feature in Win2K. You can define disk quotas on a per-volume and per-user basis. You can use Win2K disk quotas to track user disk usage and limit the number of bytes a user owns. Additionally, Group Policy Administrative Templates let you enforce a quota policy for the Win2K machines' local drives.

User Settings Management
The cornerstone of IntelliMirror's user settings management is the enhanced roaming user profiles available in Win2K. Roaming user profiles have been available since the early days of NT. In NT 4.0, Microsoft added files and folders to roaming profiles, which already included Registry settings, and the addition made using roaming user profiles more complicated. Microsoft has made several significant changes in the behavior of roaming user profiles in Win2K to improve usability.

The first change you might notice is cosmetic. On a workstation with a new Win2K installation (i.e., not an upgrade), the user's profile that is cached on the local workstation resides outside the system folder. (NT 4.0 holds the user's profile in the folder %systemroot%profiles. If you upgrade an NT 4.0 system to Win2K, the profiles cached on that system will remain in %systemroot%profiles.) The new location is off the root of the system drive in the C:Documents and Settings folder. In this folder, you'll find all the usual NT 4.0 folders, including All Users and Default User.

Microsoft called this folder Documents and Settings because a user profile contains documents and settings. Microsoft moved profiles out of %systemroot% to make securing the system folder from prying users easier. Unfortunately, instead of simply calling the new profile folder Profiles, Microsoft sought to make the folder more obvious to users browsing the file system.

With Win2K's roaming profiles, you can also make parts of a user profile nonroaming. Screen 3 shows the Local Settings folder under the user profile. The Local Settings folder prevents the OS from copying anything inside the folder to the profile server when the user logs off. This copy protection is ideal for data that you don't want to roam with the user and that would take up unnecessary space on a profile server. For example, as Screen 3 shows, Internet Explorer (IE) keeps temporary cache files in Local Settings to prevent the OS from copying the files when a user roams. Using Group Policy, you can exclude other folders from roaming. This extended copy protection gives you flexibility to let your users roam with their desktop preferences without incurring large wait times while 50MB of profile information copies at logon.

Another Win2K feature related to roaming-profile performance is the ability to administratively limit the size of a user's profile. Through Group Policy, you can set up for users a profile disk quota that limits the size of their profile. After a user's profile reaches a certain size, you can warn the user to clean up the profile.

The best part of Win2K's roaming user profiles is the improvement in exception handling. If you manage large roaming-profile environments in NT 4.0, you know the kind of damage that can occur if a user chooses the wrong profile option at logon, after receiving the confusing message about the server profile being unavailable or only available over a slow link. Users can easily blow away their stored profile with a default profile, which wreaks Help-desk havoc because the users lose all their documents and settings. In Win2K, Group Policy gives you much better control of the roaming user profile when the profile is either unavailable from the server or available only across a slow link.

In the case of an unavailable server profile, you have the option to simply log the user off or let the user log on with a temporary profile. Win2K will use a locally cached version of the profile when available. Otherwise, users get a temporary profile to use for that logon session. If the server profile is available when the user next logs on, Win2K discards the temporary profile and copies the server-based profile as usual. To facilitate this control, Win2K has two significant server profile improvements. First, users don't need to answer a prompt or even know whether their server profile is unavailable. Second, with temporary profiles, you no longer have to deal with users overwriting server profiles with a locally cached version.

Also, Microsoft improved the slow-link behavior of profiles. Using Group Policy, you can set parameters, such as a time period in milliseconds or a connection speed value, to determine when a server connection is via a slow link. You can preset the profile behavior to always use the local profile or to always download the server-based profile when detecting a slow link, so the user doesn't have to make a decision. Presetting profile-download behavior benefits mobile users who dial up to networks over slow modem lines. These users aren't likely to want to download their server profile when they have a locally cached profile available.

Software Installation
In my June 1999 article "Windows Installer Takes Control," I explained how the Windows installer technology will play a key role in configuration management of Win2K and NT 4.0. The Windows installer technology is an important part of IntelliMirror because users need continuous access to applications regardless of whether the applications are server-based or locally installed. To provide availability, Win2K relies on AD and Group Policy. Using Windows installer, Group Policy can present an application for installation to a user or machine by publishing or assigning. When you're ready to add an application to a Group Policy within AD, you need to decide which presentation mode you want to use. Group Policy presents published and assigned applications to the user's desktop in different ways.

A published application is an optional application. Publishing an application makes an application available to users, but users decide whether to install the application. As Screen 4 shows, Win2K and NT make a published application available to users from Control Panel's Add/Remove Programs applet.

Assigning an application differs from publishing in that when you assign an application, you also take a step toward installing that application on a machine or designating that application for a user. When you assign an application, you give the application a presence in the user's environment and within the Windows Explorer shell. Microsoft calls this presence an advertisement. An icon will display on the user's Start menu or desktop for that application. This icon is a special type of shortcut that interacts with the Win2K shell. When the user clicks the icon, the shortcut communicates with AD to find out where the application installation package resides. After locating the package, the installer service running on the workstation executes the package to install the application. Screen 5 shows an assigned application shortcut. The Target type field indicates that the application will install on first use.

Group Policy also lets you designate software installations for a machine or a user. If you want to designate applications for a machine, you need to assign the applications. When you assign an application to a machine, the application package will run at system startup. To designate an application for a user, you can either assign or publish the application. During installation of a published or assigned application, if the installation fails for any reason, the application will roll back to the preinstall state (i.e., uninstall).

To take advantage of the software installation features in Win2K, you must first choose an application that has the Windows installer packaging format (i.e., .msi). Next, you need to define an AD Group Policy Object (GPO) on a domain, organizational unit (OU), or site. (You can't install software on a local GPO.) To assign or publish a new application, start the Group Policy Editor (GPE) snap-in tool (i.e., gpedit.msc) for an AD domain, OU, or site from the Microsoft Management Console (MMC). You can also assign or publish applications from the AD Users and Computers snap-in tool. Select the Software Settings option and right-click Software Installation. From the context menu, choose New, then Package. The path you enter to the .msi package that you want to publish or assign must be an absolute path. Specifically, don't enter a path to a mapped drive. Instead, use a Uniform Naming Convention (UNC) path such as \myserver.mycompany.commsisharemyapp.msi. Because users produce drive mappings when they log on, if you enter a path to a drive mapping for an .msi package with a machine assignment, the drive mapping will be meaningless.

After you select the .msi package, you can decide whether to assign or publish the application. You can also modify the package or configure package properties, such as setting the application to uninstall when the GPO no longer applies to that user or computer, or applying a transform. Screen 6 shows Word 97 with an assignment to a user-specific deployment within the GPE. Before an assignment displays on a user's shell, the user needs to log off and log back on. Published applications work the same way and will appear on the Add/Remove Programs applet after users log off and log back on.

Another software installation technology in Win2K is Dfs services. Microsoft first introduced Dfs in NT 4.0. Dfs provides a way to abstract physical file system resources from a logical directory structure. In NT 4.0, you can create a Dfs root on a file server called \serveradfsroot. Under that root, you can create junctions to any number of server shares. A user needs to map only one drive letter to \serveradfsroot to gain access to all the associated server shares under the root (provided the user has sufficient security privileges). In NT 4.0, if a server goes down, the root and all associated shares become unavailable. Win2K gives Dfs the ability to create fault-tolerant roots within an AD domain because the root is part of AD. You refer to a root by domain name (e.g., \my.company.comdfsroot) rather than server name. Therefore, you can have any number of replica servers with identical data that provide the services to the fault-tolerant root.

Dfs plays an important role in software installation and distribution. When you assign an application to a domain or OU, the users might be dispersed geographically. Ideally, you want the users to receive the .msi package from the network server nearest to them. You can have a Dfs structure that stores all .msi packages, then creates replicas of those packages on multiple servers spread across your network. In Win2K, when a client connects to a fault-tolerant Dfs root that has replica servers, the client will always try to connect to a replica server within its local site. Remember that AD sites, like Exchange Server sites, are high-bandwidth network groupings. Assigning applications using the path to a Dfs root easily distributes the packaged installation to servers local to the client. Therefore, Dfs lets you distribute software without having to use complex software-distribution tools.

Tools for Easing the User Experience
Microsoft developed the IntelliMirror set of technologies to provide a painless experience for users. Offline folders ensure that user and application data is available regardless of users' network connection status. Roaming user profiles let users retain desktop preferences regardless of the machines they log on to. Dfs and the software installation feature make applications available to users, no matter where the applications reside. AD and Group Policy are the technologies that enable these Win2K management features. IntelliMirror's powerful tools let you take the first step toward achieving ZAW.