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.
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:
- Log on as Administrator.
- From the desktop, double-click My Computer.
- 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.
- Right-click over the newly created Profiles
directory and select the Sharing command from
the context menu.
- 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:
- Click Start | Programs | Administrative Tools
| Active Directory Users and Computers.
- Double-click on Martin Wier’s account and
click his Profile tab.
- 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:
- Log in as the Administrator of the domain.
- 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.
- 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.
- A default domain policy exists for the domain.
Select it and click Edit. The Group Policy editor
appears.
- The group policy for the domain appears.
Drill down to Folder Redirection by clicking
on User Configuration | Windows Settings | Folder
Redirection.
- Right-click My Documents and select Properties.
The My Documents Properties dialog box appears.
- Use the Setting pull-down list box and select
Basic—Redirect Everyone’s Folder to the Same
Location.
- 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.
- Close the Group Policy screen.
- 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:
- Log on to the workstation again as mwier.
- Right-click My Documents and click Make Available
Offline as shown in Figure 4.
- 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.
- 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:
- Create a New OU for your administrators (say,
AdminsOU).
- Move the administrator accounts into that
OU.
- Create and share a directory (say, d:\share)
to house the .MSI application with at least
read-only privileges.
- Copy the .MSI application (in this case,
adminpak.msi) from the source (c:\winnt\system32\adminpak.msi)
to the sharepoint \\w2kserver1\share\.
- 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:
- Click Start | Settings | Control Panel. Double-click
the Add/Remove Programs applet. The Add/Remove
Programs dialog box appears.
- 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.
- 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.
- Click Next, and then the Remove Installation
Folder Location screen appears.
- 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.
- 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.
- 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.
- 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.
- The Friendly Description and Help Text screen
appears. Change these if you want to give special
instructions to the people installing the workstations.
- The Review Settings screen appears. Make
sure the values are what you want and click
Finish.
- 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.