In-Depth

Take It Easy... Let Windows 2000 IntelliMirror Do the Work

We know you're skeptical about how much time you'll truly save moving your organization to Windows 2000. But some of these management tools really can help you get home on time for a change.

• By Jeremy Moskowitz
• 12/01/2000

Your boss wants you to dedicate more time to strategy and planning for the future of your organization. Your users want you to figure out a way to let them keep working on their documents at 30,000 feet. You want users to save documents on the network you provide for them, not their local hard drives.

Heck, you’d settle for just going home on time for a change.

Can the new features in Windows 2000 come to your rescue? In this article, we’re going to explore some of the new tools Win2K offers to make your administrative duties more effective. Before you know it, you can be pleasing everybody—users, the boss, and even yourself. First, I’ll discuss a little history of Windows administration, then move on to describe the most compelling new features of Win2K. After brief descriptions, I’ll offer up an example of actually implementing that feature—so you can immediately begin making your users happy.

For the sake of simplicity, I’ll be presenting everything on one fictitious Win2K server named W2kserver1. If you’d like to follow along on a test server and try the examples, you should install Win2K Server (or Advanced Server) in the first partition (C:\), and create another free partition (D:\) to house user data files. Finally, create another free partition of at least 1G called R:\ (for RIS).

Next, run DCPROMO.EXE to make it the first domain controller in the domain. My example domain will be corp.com, but you can use anything you like. You should also load and configure Active Directory Integrated DNS and DHCP Server (the latter is required for Remote Installation Services). You’ll also want a desktop machine or two, preferably with a PXE Boot Rom Network Interface Card (which I’ll discuss later), which you’ve joined to the domain to test each new feature after you set it up.

Terms and Conditions

Before we get started on our journey, let’s define our terms. Just what the heck is IntelliMirror, anyway? For one thing, you can’t run down to CompUSA and buy a shrink-wrapped copy of “Microsoft IntelliMirror for Windows 2000;” rather, IntelliMirror is a collection of Win2K features designed to reduce overall administration.

Keeping with the TCO vein, each IntelliMirror feature tries to chip away at each of the sore points in administrating your network by implementing specific technologies. Table 1 shows how Microsoft envisions the Change and Configuration Management initiative, the IntelliMirror features, and the specific technologies therein.

Table 1. Windows 2000 improves desktop management. Here's Microsoft's view of Change and Configuration Management and IntelliMirror.

Features	Benefits	Technologies
Software Installation and Maintenance	Centrally manage software “My software follows me!”	Active Directory Group Policy Windows Installer Add/Remove Programs
User Data Management	Data protection and availability “My data and docs follow me!”	Active Directory Group Policy Off-line folders Synch manager Disk Quotas
User Settings Management	Centrally define environment “My settings follow me!”	Active Directory Group Policy Off-line folders Roaming Profiles
Remote OS Installation	Fast system configuration “Get Windows 2000 working on this machine!”	Active Directory DNS DHCP Remote Installer Service

IntelliMirror implementation isn’t an all or nothing proposition, as it was with Zero Administration for Windows (see “TCO-Whoa!”). Administrators can pick and choose the features and functionality they want to deploy, and when they want to deploy them. While some of IntelliMirror’s features (which I’ll describe in detail in this article) are available when you’re using only Win2K Professional (like Offline Files), most (like Redirected Folders) are available only when you marry Win2K at the server and Win2K at the desktop.

TC-Whoa! Each day you’re on the job costs your company money. Your salary, the percentage of rent your desk takes up, the software that’s bought to run the business—it all costs money. Some costs are a bit harder to put into hard and fast numbers, like fixing a user’s computer when he or she inadvertently sets the background color, the foreground color, and the font color to black and hits the “Apply” button. These tangible and intangible costs to run the computing environment often need to be quantifiably brought under control—that’s accounting for you and me, folks. To solve these accounting quandaries, GartnerGroup in the early 1990s rode in like the cavalry with its brave new “TCO,” or Total Cost of Ownership Model. This model (or philosophy, some might say) tries to take the voodoo out of accounting for computing services. Simply tally up every nickel you spend on hardware, software, maintenance, support, and the like, and Voila! Instant Accounting! You can find more on GartnerGroup’s TCO model at http://gartner4.gartnerweb.com/ bp/static/tcomanhome.html. Microsoft first took a stab at embracing the TCO method in early 1997 with the debut of a new philosophy called Zero Administration for Windows initiative, or ZAW. The first major technology based on ZAW was NT 4.0’s Zero Administration for Windows Kit, or ZAK. ZAK was a great idea on the surface. Most organizations have two types of users: those who work on one application only, and those who use a few apps, but seem to never stop playing with their desktops. With those types of users in mind, ZAK could be run in two modes: “Taskstation,” in which the users were restricted to running a single application, and “Appstation,” in which users could move among a handful of selected applications. ZAK had a noble goal—reducing the amount of exposure the user has to the operating system, thereby reducing the administrative support required to clean up user messes. While Microsoft’s ZAK was a decent first effort, only a few organizations really embraced it, due to intricacy in implementation and some lack of flexibility. Microsoft still supports ZAK, which is available for free download at www.microsoft.com/windows/zak/getzak.htm. With Win2K, Microsoft could fashion a new paradigm of how administrators manage users and their desktops. Enter the Win2K’s version of ZAW—which was, remember, a philosophy rather than a technology. In Win2K, Microsoft advances the ZAW philosophy of managing user desktops with both Change and Configuration Management (CCM) and IntelliMirror.

Let’s explore IntelliMirror’s features and see where each can be used in your environment.

User Settings Management
(Roaming Profiles)

User Settings Management is a fancy way of saying “Profiles.” Fundamentally, Win2K’s implementation of profiles hasn’t changed much from Windows NT 4.0. Therefore, if you’re already familiar with implementing NT profiles, you’re 99 percent of the way there. For completeness, let’s do a quick review of the profile types found in NT and Win2K.

First, there’s the local profile. A new local profile is generated whenever a new user logs on to an NT or Win2K computer (usually a workstation, but sometimes a server). This profile houses all sorts of “look and feel” settings, including screen settings, Start menu items, and other preferences. Local profiles are great; whenever a user logs back onto that workstation, all the previously used settings appear to be restored for the user. Local profiles start to lose their usefulness, however, when users jump from machine to machine. Their settings won’t follow them—unless you implement roaming profiles using your network.

Roaming profiles enable the restoration of user settings to whatever workstation the user logs on to. Simply point the user’s profile information to an NT or Win2K sharepoint, and Voila! Users retain their settings when they jump from machine to machine.

The last profile type is the mandatory profile. These enable administrators to lock down users’ setting and prevent them from changing anything on the desktop.

As I said earlier, the general theory and execution surrounding NT and Win2K profiles remain the same. There are two significant differences, however, between the two: the location of where the local profile is held and the extra baggage it contains.

When NT profiles are downloaded (or generated), they’re found under %windir%\profiles\%username%. Win2K profiles, in contrast, are found under %systemroot%:\documents and settings\%username%. This change enables administrators to easily find and move the contents if necessary.

By extra baggage I mean that certain settings, including the popular “My Documents” folder, are now maintained within the profile. This can have serious ramifications for your network. Once users start using the My Documents folder, they generally don’t want to stop. But if they start putting their 10 megs of PowerPoint files, 30 megs of Word documents, and 20 megs of Visio files into My Documents and then roam to another workstation, they’ve just moved 60M of data across the network at logon time! Ouch! (Fortunately, you can alleviate this pain with another IntelliMirror feature—“Redirected Folders,” which we’ll explore next.)

Implementing roaming profiles is a simple process. First, create a sharepoint on the Win2K (or NT) server for profile storage and point the user’s profile information to the sharepoint. To create and share a directory to store roaming profiles:

1. Log on as Administrator.
2. From the desktop, double-click My Computer.
3. Find a place to create a Users directory. In this example, we’ll use D:\Profiles. Double-click on D: to open the drive. Right-click in the free area and select the Folder command from the New menu; then type in Users as the name.
4. Right-click over the newly created Profiles directory and select the Sharing command from the context menu.
5. Click “Share This Folder,” keep the rest of the defaults, and click OK.

Normally, you shouldn’t expose file shares as Full Control, but for the sake of this testing example, it’s OK.

Now you need to specify which network user accounts can use roaming profiles. In this example, I’ll choose just one of my users: Martin Wier. To modify accounts to use roaming profiles:

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.
2. Double-click on Martin Wier’s account and click his Profile tab.
3. In the Profile Path text box, specify the server, sharename, and directory you want to use, such as \\w2kserver1\profiles\%username% (as shown in Figure 1). Leave all other fields blank and click OK.

Figure 1. Implementing roaming profiles is a simple process. Here you type in the \\SERVERNAME\SHARENAME\%username% in the Profile path.

Note: If you use the %username% variable, the result (in this case mwier for Martin Wier) gets evaluated upon first use, the directory is automatically created, and NTFS permissions automatically assigned.

You can make sure roaming profiles are working by logging into the domain as Martin Wier from a workstation that’s a member in your domain. In the My Documents directory, create FILE1.TXT and save some dummy data inside. Before logging off, also change the Display Appearance Scheme to something different, like “Pumpkin Large,” and log off. Then, log on to another workstation as Martin Wier and make sure the FILE1.TXT was properly downloaded from the server and the background has changed as well.

Right-click over FILE1.TXT, click Properties, and take a note of where the file actually is residing. You can compare that file’s location now (the local hard drive) with the file’s location after the next section is completed (on the server, we hope).

User Data Management
(Redirected Folders)

Thanks to the change in roaming profile contents, your users are theoretically passing countless megabytes of data across the wire each time they log on! That is, unless you set up redirected folders.

Redirected Folders allows you, the administrator, to redirect certain desktop locations and make them act as if they were network drives. This feature counteracts the roaming profile problem described above. If you redirect the My Documents directory, it no longer travels along with the profile as users roam. Rather, it’s planted on servers—either on one share or across shares based on security group membership.

Redirected Folders have the added benefit of releasing your users from a dependency on networked drive letters. Some organizations like to use certain drive letters as mnemonics to help users remember where their data goes. Some like to use the H: drive for [H]ome drive or U: drive for [U]ser directories. With redirected folders, this whole concept of drive letters (which is generally confusing for users) goes right out the window. You can just inform your users to save their files in the “My Documents” directory—secure in the knowledge that their data is secretly being stored and backed up on the server.

You can feel free to let your users get hooked on using the “My Documents” folder with no penalty, even though it’s part of the roaming profile. That’s because, with redirected folders, you can make the My Documents folder actually “stay put” on another sharepoint on the server, safe with the knowledge that the data is being backed up.

Goodbye, home drives; hello, simplicity.

To implement folder redirection, first, create another sharepoint as you did above. In this example, I’ve created d:\DATA.

After you’ve created the d:\DATA sharepoint, you’re ready to create your group policy object (GPO). You implement each of these changes via the Group Policy editor, which can be started within the Active Directory Users and Computers MMC snap-in. In this example, I’ll be changing the “Default Domain Policy,” which is guaranteed to affect all users in my domain. But you can create a new GPO at any level you want.

To redirect users’ My Documents settings by changing the default domain-wide group policy:

1. Log in as the Administrator of the domain.
2. Start the Active Directory Users and Computers MMC snap-in by clicking Start | Programs | Administrative Tools | Active Directory Users and Computers. The Active Directory Users and Computers MMC appears.
3. Right-click the domain (corp.com) and select the Properties command. The domain Properties box appears as shown in Figure 2. Click the Group Policy tab.
4. A default domain policy exists for the domain. Select it and click Edit. The Group Policy editor appears.
5. The group policy for the domain appears. Drill down to Folder Redirection by clicking on User Configuration | Windows Settings | Folder Redirection.
6. Right-click My Documents and select Properties. The My Documents Properties dialog box appears.
7. Use the Setting pull-down list box and select Basic—Redirect Everyone’s Folder to the Same Location.
8. Type \\W2kSERVER1\ data\%username% in the Target Folder Location text box, as shown in Figure 3. Click OK. By default, users have exclusive NTFS permissions to their directories, and the contents of their My Documents folders are automatically moved to the new directory. You can change this behavior by clicking on the Settings tab.
9. Close the Group Policy screen.
10. To verify that folder redirection works, log on to the workstation as Martin and right-click over the FILE1.TXT you created; select Properties. Notice the new location of the file (it should be on the server). By default, once Folder Redirection is turned on, all files in the My Documents folder automatically get moved to the server. You can change this behavior if you want by clicking on the Settings tab shown in Figure 4.

Figure 2. To implement folder redirection, you work through the Group Policy editor. Here, we’re modifying an entire domain’s default policy, which will affect all users in the domain.

Figure 3. Enter the \\SERVERNAME\SHARENAME\%USERNAME% to redirect the My Documents directory.

Figure 4. Turn on caching by right-clicking the My Documents folder and clicking Make Available Offline.

User Data Management (Offline Files)

When executives dream about laptops, what do they imagine? First, they want a battery life that can last from New York to L.A. Second is the ability to keep working at 30,000 feet as if they were still on the network. With Offline Files, you can deliver the goods.

Often, Offline Files is compared to the Windows 95 Briefcase—except that it works as advertised. Like the Briefcase, certain files or directories can be earmarked, or pinned, so they can be worked on offline. When the user goes off the network (or even if the network just suddenly disappears), the files are accessed as if they were still on the network. When the network reappears (when the user reconnects to the docking station, or power is restored, or whatever) the Offline Files engine kicks into gear and compares the document that’s actually on the network with the one on the hard drive. Whichever is the most recently changed wins.

If for some reason both files have changed, a rudimentary conflict resolution engine pops up and asks the user which copy to keep: hard drive, network, or copy the hard drive copy to the network with a new file name, which in effect preserves all copies.

As a network administrator, you have three ways to accomplish this task: teach users how to manually pin files, set up the network share to cache files automatically, or use GPOs to specify specific files that are always in the cache.

Now that the users’ My Documents directories are centralized, you can instruct users to turn on this great new feature. In this example, Martin will log on to his PC and turn on the client-side caching:

1. Log on to the workstation again as mwier.
2. Right-click My Documents and click Make Available Offline as shown in Figure 4.
3. The Confirm Offline Subfolders dialog box appears. You can select either this folder alone or this folder and all subfolders, and click OK. The Synchronization Wizard will synchronize the files, then disappear.
4. The Confirm Offline Subfolders dialog box appears. Keep the default to propagate to all subfolders and click the OK button.

On-going synchronization occurs without any further interaction. Users may, however, adjust their synchronization settings from their Win2K Professional workstations by selecting the Synchronize icon off the Accessories menu.

Note that an administrator can also force a client to automatically synchronize files with specific shares. When setting up a share point, simply click the new Caching button and choose a setting in the setting drop-down box: Automatic Caching for Documents, Automatic Caching for Programs, and Manual Caching for Documents (Figure 5).

Figure 5. In Offline folders you can set up either manual or automatic caching for documents or programs. (Click image to view larger version.)

Once either of the “Automatic” settings are enabled, 10 percent of the client workstation is used to continually cache networking documents. If the Automatic Caching for Documents is chosen, the system looks at the network before it looks locally for an updated file. The reverse happens when Automatic Caching for Programs is chosen.

Additionally the administrator can use Group Policy settings to manually specify settings that force specific files and folders in the cache. In the Group Policy Object, drill down to administratively assigned offline files by clicking on User Configuration | Administrative Templates | Network | Offline Files and selecting Administratively assigned offline files.

Software Distribution and Maintenance
(Windows Installer)

Since IntelliMirror’s primary goal is to reduce the amount of time you have to run around to the computers on your network, it fortunately includes a basic software distribution mechanism. I said basic, but it’s still powerful—though not as powerful as its big brother Microsoft Systems Management Server (SMS). The Software Distribution feature built into Win2K’s IntelliMirror isn’t meant to supplant SMS in the enterprise. Instead, think of it as an “on demand” way to get certain applications to your users.

For instance, when you send someone in your organization a .PDF file via an email attachment, and he or she clicks on it, what happens? If the user has Adobe Acrobat Reader loaded on the workstation, the reader pops up and imports the document. If it isn’t loaded, the user gets the dialog box similar to Figure 6.

Figure 6. A familiar problem for our users (and sometimes for us!).

Then what happens? The user gets nowhere fast, and a call is generated to—you guessed it—the help desk or (heaven forbid) to you directly.

The Software Distribution features of IntelliMirror actually use an underlying technology called the Windows Installer (see “What is MSI Anyway?”). The Windows Installer allows administrators to publish or assign applications to the users. When you publish an application, it becomes available to the user via the Add/ Remove Programs applet in the Control Panel. When you assign an application, its icon is automatically added to the Start menu. Upon first use, the application is automatically downloaded and installed.

Moreover, applications deployed via the Windows Installer can be designed to be self-healing. That is, every time the application is launched, it can be set to check for the existence of critical .DLL or .EXE files (or any files for that matter). If any are missing, the application can be set to re-install the missing pieces to get it back to its working state—without any user interaction whatsoever.

Applications can also be deployed based on extension type. Therefore, when a user receives a .PDF file via an email attachment and double-clicks on it, the Adobe Acrobat Reader can instantly be downloaded from the server, loaded on the workstation, and automatically fired up, allowing the user to read the document.

You can create your own basic .MSI packages via the supplied WinInstall LE (found in the valueadd\3rdparty\mgmt\winstle directory of the Win2K Server CD.) WinInstall LE essentially takes a snapshot before and after you load some software, does a quick comparison, and dumps the resultant files out to an .MSI package file. (See “Creating your own .MSI files with WinInstall LE”).

If you don’t want to go through the effort of creating your own .MSI package for this demonstration, Win2K comes with one (very useful) .MSI package: adminpak.msi. This .MSI package contains all the files necessary to administer a Win2K enterprise.

In this example, we’ll publish the adminpak.msi to ourselves—the administrators! This way, whenever you travel to a new desktop, you’ll always have the server administration tools at your fingertips!

To do this, you’ll have to perform the following tasks:

1. Create a New OU for your administrators (say, AdminsOU).
2. Move the administrator accounts into that OU.
3. Create and share a directory (say, d:\share) to house the .MSI application with at least read-only privileges.
4. Copy the .MSI application (in this case, adminpak.msi) from the source (c:\winnt\system32\adminpak.msi) to the sharepoint \\w2kserver1\share\.
5. You must create and edit a new GPO for the OU (say, DeliverAdminPak).

Now you’re ready to drill down into User Configuration | Software Settings, then right-click over the Software Installation settings and select New.

When the file dialog box appears, type in the full network path to the file, such as \\w2kserver1\share\adminpak.msi and select Open.

Don’t type in or select local file paths (such as c:\share\adminpak.msi); these wouldn’t be readable across the network. Enter only sharepoints (such as \\w2kserver1\share\adminpak.msi).

It’s here that you can decide to publish or assign applications. Because this package has lots of icons, I find it works best when published (though you could choose to assign it as well). Select Published and wait a few moments until it has finished loading (Figure 7).

Figure 7. The process of creating a new installation package first involves creating a new GPO for the Organizational Unit, then selecting a sharepoint, and finally designating whether to assign or publish applications.

You can now test your software deployment by logging in at a Win2K Professional machine as an administrative user whom you’ve placed under the OU where you’ve set up the group policy to deliver this package.

If you’ve assigned the package, you’ll have an icon group called Administrative Tools. If you click on any of the icons, you’ll see the Windows Installer load the required files to run the individually selected tool.

If you’ve published the package, you’ll have to traverse to the Add/Remove Programs applet in the Control Panel and select Add New Programs. Under the “Add Programs from your Network” heading you should have listed “Windows 2000 Administration Tools.” If you click Add, the entire package and all required files will be loaded at once.

Remote OS Installation
(Remote Installation Services)

All of the previously mentioned technologies are terrific for managing the user’s data, but what about the PC? What happens if it blows up? The last piece of the puzzle actually comes under the Change and Configuration Management heading, which technically isn’t under the IntelliMirror umbrella.

Remote Installation Services (RIS) can hurl a new Win2K installation plus any pre-defined applications onto a user’s desktop. It does this through the marriage of several technologies—some hardware, some software.

On the hardware side, the PC’s network card is required to use the new PXE boot ROM architecture. The PXE boot ROM enables the computer to attach to the network at boot time in order to grab an image from a server in waiting. The process is simple: Request an IP address via DHCP, find out what RIS server is available to answer the request, see what images are available for download, and download an entire image via the TFTP protocol.

But RIS goes one step further: the most common applications can be pre-loaded into an image. This means that when a new image is required, all the applications are loaded along with the image with almost no additional post-loading configuration time (see “The Remote Installation Prep Tool”).

First, let’s install RIS:

1. Click Start | Settings | Control Panel. Double-click the Add/Remove Programs applet. The Add/Remove Programs dialog box appears.
2. Click the Add/Remove Windows Components button, select the Remote Installation Services option and then click Next to install RIS. You’ll need to reboot your server at this point.
3. When the server is rebooted, come back to this point by clicking Start | Settings | Control Panel. Double-click the Add/Remove Programs applet, select the Add/Remove Windows Components button again, and then select the new “Configure Remote Installation Services” button. The Remote Installation Setup Services Setup Wizard appears.
4. Click Next, and then the Remove Installation Folder Location screen appears.
5. Choose a directory on an NTFS volume that isn’t the system drive. Because W2KSERVER1’s system is on C, you should choose R:\RemoteInstall and click Next. The Initial Settings screen appears. The RIS server must be turned on to accept client connections.
6. Click the Respond to Client Computers Requesting Service check box. For this example, don’t choose Do Not Respond to Unknown Client Computers. Click Next.
7. The Initial Source Files Location screen appears. Type the path of the Win2K Professional CD’s i386 directory in the Path box. In this case, the directory is in F:\I386. Click Next. Note that you could use “slipstreamed” installations, which already have the service pack installed.
8. The Windows Installation Image Folder Name screen appears. Enter the name of the directory to create on the server. Keep the defaults as win2000.pro, if desired. Click Next.
9. The Friendly Description and Help Text screen appears. Change these if you want to give special instructions to the people installing the workstations.
10. The Review Settings screen appears. Make sure the values are what you want and click Finish.
11. The Remote Services Setup Installation Wizard continues, as shown in Figure 8. It takes a while to copy all the files and create the initial directory. When the installation is finished, the Cancel button turns into Done. Click Done.

Figure 8. RIS loads all the Windows 2000 Professional files.

You’ll manage RIS by using Active Directory Users and Computers, right-clicking over the computer running RIS (in this case, W2kserver1) and clicking Properties. You’ll now have a “Remote Install” tab that can be used to refine RIS’ settings.

You’re almost ready to start rolling out your clients. You can either use the PXE boot-ROM already on your PC (usually, it’s enabled by whacking F12 right after reboot), or you can create a boot disk that emulates the PXE boot ROM if your network card lacks an actual PXE ROM. Note, though, that your network card must support the PXE architecture.

Create the boot disk by running the RBFG.EXE program from the \Admin\i386 directory where you installed the RIS service. Click Start | Run and type R:\RemoteInstall\Admin\i386\rbfg in the Open dialog box.

Put a blank disk in the floppy drive and click the Create Disk button to start the boot disk generation.

When ready, pop the boot disk into your workstation, reboot, and press F12 when prompted (and it goes by really fast!). The Client Installation Wizard Logon screen appears. Enter a valid username, password, and domain. In this case, you can enter the username and password of the administrator of the corp domain. Follow the prompts to get a fully deployed RIS image in about as much time as it would take to load it from the CD or across the network. If you want additional images that have your favorite applications pre-embedded, refer to “The Remote Installation Prep Tool.”

What is .MSI Anyway? Microsoft is constantly developing new products. Sometimes its internal product groups combine forces when one generates a particular technology the other was lacking. Recently this happened between the Microsoft Office 2000 group and the Microsoft Windows 2000 group. The Microsoft Office 2000 group needed a way for its customers to fine-tune how much of Office 2000 to distribute to client machines. The Win2K group needed a way for its customers to receive discrete “packages” of software that could easily be installed or de-installed at will for easy management. This marriage between the two groups was the Microsoft Installer Files format, or .MSI. Indeed, if you’ve ever installed Office 2000, you’ll notice that the “style” of installation is radically different from previous offerings from Microsoft (which used the “ACME” installer.) The old “ACME” style installer in Office 97. Office 2000’s new installation screen. (Click images to view larger versions.) ACME-style installations were fine—if you enjoyed editing .STF, .LST, and .INF files until you got the installation just so. .MSI files were created with the same goals as the previous ACME-style installations; that is, to have a generalized way of getting the files onto the desktop. On the surface, .MSI files appear to act as self-expanding distribution files, like the familiar self-executing .ZIP files. The main difference between ACME-style installations and .MSI files is that the former use a text-editable .STF file, which is essentially a database of what file goes where. .MSI files are the database and may contain either pointers to the files or all the files rolled up into one .MSI file. Additionally, .MSI files have the ability to “tier” the installation (for instance, don’t bother loading the spell checker in Word if I only want Excel). Sounds simple, but it’s revolutionary. Moreover, because .MSI files themselves are a database, there’s an added feature. The creator of the .MSI package (or sometimes the user) can designate which components are loaded to the hard drive on initial installation, which components are loaded to the hard drive the first time they’re used, which components are run from the CD-ROM or distribution point, and which components are never loaded. This lets administrators pare down installations to make efficient use of both disk space and network bandwidth.

Creating Your Own .MSI File with Windows Installer LE .MSI files might come on the CDs from software manufacturers or you can create them yourself. Win2K ships with a scaled-down version of Seagate Technology's popular WinINSTALL product. Called WinINSTALL LE, it allows you to take existing applications, capture their setup actions, and repackage those actions and installed files into one giant .MSI file. Then you can deploy the .MSI package, either through assigning or publishing (see the main article). WinINSTALL works because it's active when you run your application's SETUP.EXE (or similar program). It then scours the hard drive for all the changes (executables, .DLLs, registry changes, and so forth) it can find. But WinINSTALL works best when there's little to encumber its "scouring" process. For instance, imagine you want to repackage an application, called DogFoodMaker 5.0. DogFoodMaker 5.0 has a required .DLL called RUFF.DLL which gets put in the winnt\system32 directory. But say you've already installed an earlier version, DogFoodMaker 4.2, which put its required RUFF.DLL v4.2 in the windows\system32 directory. When WinINSTALL performs its search for the changes after you run DogFoodMaker 5.0's setup program, it may not find the newly updated RUFF.DLL v5.0 file. In other words, your newly created .MSI package may not work. Indeed, Microsoft recommends that you don't even install the WinINSTALL LE program on your "clean" machine. Rather, you should map a network drive over to where WinINSTALL is housed (for instance, a share on a file server) and run it from there. But the .MSI file and its format are simply the package itself. The delivery method to the clients is another animal entirely. In order to deliver the .MSI files to the client, a service needs to be running on the client-the Windows Installer Service. It's a neat little process: .MSI files are "delivered" to the desktop-either published or assigned. Nothing other than the .MSI database and optional start-menu icons is loaded on the client. When the user clicks the icons to launch the application or requests a file with an association, the Windows Installer service looks at the downloaded .MSI database, seeks the necessary components, installs them from the source location (usually the file server), and runs the application. At installation time, the Windows Installer service opens up the package file for the product in question and uses the information therein to determine all of the installation operations that must be done for that product. If you're familiar with the previous install technology used by Microsoft Office, note that the package file functionally replaces the .stf, .inf, and .lst files.

The Remote Installation Prep Tool In the article I describe how the Windows Installer can be used to assign applications to users or PCs. But you can alternatively choose to stock a machine full of applications and settings, then use RIS in your machine deployment. To do this, Win2K Server also comes with the Remote Installation Prep Tool or RIPREP. After you load a Win2K Professional machine full of client software just the way you like it, you can simply run RIPREP and create another image on the server. You can load any applications you like, such as Microsoft Office, Boutell.com’s Morning Paper, or anything else that you want to preload on an image. The only caveat is that you must load the software on a machine that you created with the RIS process. Since you just used the RIS process to create your first workstation, you’re ready to continue. In this example, you’ll create a special image for the Sales group, which automatically has Microsoft Office and Boutell.com’s Morning Paper loaded. To create additional RIS images: Create your first client as detailed in the preceding exercise. Log on to the client with the local Administrator account and load the software desired. Since you’re logged in as the local Administrator, configuration changes such as icons affect only the Administrator account. In order for the changes to take effect for every user, you’ll need to copy the Administrator’s profile to the Default User’s profile. Right-click My Computer and select Properties. Click User Profiles | Administrator | Copy To. In the Copy Profile To dialog box, enter the path for the Default User folder, usually C:\Documents and Settings\Default User. Click the Change button, and select the Everyone group to be able to use the profile. Click OK to close the Copy To dialog box, and OK again to close the System Properties dialog box. Run RIPREP from the RIS server. Do this by clicking Start | Run and then typing \\w2kserver1\remoteinstall\admin\i386\riprep in the shared RIS directory. The RIPREP Wizard starts. Click Next. The Server Name screen appears. By default, the server you used to create this image appears in the Server Name box. Leave the defaults and click Next. The Folder Name screen appears. You can give a somewhat descriptive name for how this image will be used. In this case, target it for the Sales group. Type in the name desired and click Next. The Friendly Description and Help Text screen appears. You can elaborate on what this machine has loaded and click Next. The Programs or Services Are Running screen appears next. You should close all running programs and stop the running services to get the cleanest image possible. Click Next. The Review Settings screen appears. Verify that the information is correct and click Next. One additional information screen appears, stating that this process can be repeated if desired. Click Next to continue. The modified image is loaded on the server. A unique mechanism called Single Instance Store, or SIS, prevents multiple copies of the same system files from eating up your disk space. Each time you create new images, only one copy of each system file will be saved. The next time you use F12 in conjunction with the PXE boot ROM or boot disk load client images, a new menu selection will be available, asking which image is to be loaded.

Putting It All Together

All of these features unite to bring you, the administrator, fewer headaches on a daily basis. Let’s examine what these features combined can bring to you. We’ll go right to the grand finale and start with the hardest case: The PC blows up. In the old days (before Win2K, that is), you’d have to find the installation disks, CD-ROM, the backpack-CD drive (if you had one), device drivers, customized network card boot disk or whatever your organization used, and manually load the OS or use a third-party imaging tool (which wasn’t sanctioned by Microsoft, I might add) to load the OS.

Next, you’d have to re-create the users’ desktop settings exactly as they were. That includes displaying the bitmap of the user’s daughter at summer camp at the center of the screen and configuring display settings to “Windows Classic (extra large)” and the screen saver to “Curves and Colors.” If anything (even an icon) is out of place or missing on the desktop, you know what that means—another call for a desktop visit.

You’d then have to manually load each application or wait until your automated software deployment mechanism kicked off its cycle (usually at 2 a.m.) and loaded the applications onto the PC. Good luck getting back the Office 97 tool bar settings. Then you’d have to explain to the user that the files saved to the local hard drive were irrevocably lost because he or she didn’t use the network home drive to save those most important documents. Somehow the user will find a way to blame you for this.

Additional Information You’ll find a multitude of documentation on Windows 2000’s management services at www.microsoft.com/windows2000/guide/ server/ features/managementsvcs.asp. Microsoft offers several audio and PowerPoint presentations on aspects of IntelliMirror. The home page for SeminarOnline resides at www.microsoft.com/seminar/1033. Especially useful: Group Policy: The Foundation Of IntelliMirror Offline Folders Microsoft Windows 2000 Deployment Methods Software Deployment with Windows 2000 IntelliMirror and SMS

At any rate, you end up looking like a zero to the user. With Win2K’s Change and Configuration Management paired up with IntelliMirror, this is a walk in the park. Let’s repeat that scenario: The PC blows up. You boot with the PXE boot ROM, download the new image with all the corporate applications pre-loaded and configured.

The user logs on. The profile is automatically re-downloaded. The bitmap of the user’s daughter appears—centered on the screen, display settings set to “Windows Classic (extra large)” and the screen saver set to “Curves and Colors.” Every icon is exactly where it was left.

Because this user is Assigned Adobe Acrobat reader, its icon is automatically placed on the Start menu for future use. All the files the user placed into the desktop My Documents folder are still magically in the My Documents folder (which is secretly being redirected to on the server.)

Everything is returned exactly as it was when the PC blew up. You’re a hero to the user—in about a tenth of the time—thanks to IntelliMirror.