Preparing for Microsoft Office 2000 Distribution
One key to reducing total cost of ownership (TCO) is efficient, cost-effective software
distribution. To plan an effective distribution of Office 2000, you must first inventory
essential software and hardware. This chapter explains how to accomplish this task with
Microsoft Systems Management Server.
Requirements and Considerations for a Successful
Inventory
To distribute software in complex networked environments, you must have a clear
picture of the current network setup. This setup includes network infrastructure, server
and workstation operating systems, application environment, and user needs. You also
need to consider physical factors such as geographical constraints or remote-user needs.
The more information you can compile, the easier it will be for you to create an effective
distribution plan with an efficient workflow. The first diagram below shows how
recommended deployment decisions are influenced by software and the second diagram
illustrates the same information for hardware.
Exchange
Consider deploying
Off ice 2000 w ithout
Outlook 2000
initially, then
launching as
accelerated an
Outlook 2000
deployment
schedule as
possible
Determine
E-Mail Client Sof tw are
and Version
Inventory
Workstation
Softw are
E-Mail
Determine
Microsoft Off ice
Version
Off ice
Off ice 95
Educate users as
to the diff erences
betw een Off ice
2000 binary f ormat
and Off ice 95
Off ice 97
Outlook (97 or 98)
No additional
planning is
necessary
Standard
Remove all Of fice
97 applications in
CIW.
Standard or
Professional?
Converter
Professional
Decide on f ile
Dual-Save
format strategy
OS
No
Leave Access 97 in
place; this option
can be set in CIW.
You can choose to
deploy Access
2000 later.
Win95
Type of
Operating System
Win95 Service
Pack or
Higher?***w hat is
required?***
NT
Win98
Assess cost of
converting the important
Access 97 Databases. Can
it be budgeted and planned
bef ore deployment?
Off ice 95
solution:
deploy Of fice
97converters
Off ice 2000
solution:
training and
dual-save
formats
Deploy
converters to
all Off ice 95
users via EMail or scripts
Edit MST to
def ault to
dual-save,
implement
policies to
maintain
setting
Yes
Add conversion to
timeline, plan for
completion bef ore
deployment.
Remove Access 97
in CIW.
Win98 Service
Pack 1 or Higher?
*** w hat is
required?***
No
No
Plan for deployment
of NT Service
Packs previous to
the Of fice
deployment
schedule
NT Service Pack
3 or Higher?
Yes
If SP3, consider
upgrading to SP4; if
this is not possible,
consider deploying
addtl hotf ixes
Leave Access 95
in place; this option
can be set in CIW.
You can choose to
deploy Access
2000 later if you
w ish to save disk
space.
Assess cost of
converting the important
Access 95 Databases. Can
it be budgeted and planned
bef ore deployment?
Yes
Add conversion to
timeline, plan for
completion bef ore
deployment.
Remove Access 95
in CIW.
Figure 6.1 Assessing workstation software.
The software inventory should determine:

Operating system (including service pack level). For example, if you are using
Windows NT, Service Pack 4 is considered a basic requirement for Office features
such as the Office Server Extensions. You can also use Windows NT infrastructure
for security and configuration.

E-mail client type. For example, you should migrate Exchange clients early, and you
often have to perform a few more steps to take care of Personal Address Books and
Schedule+ data.

Current installed version of Office. For example: this can drive coexistence
requirements, which can in turn drive viewer and converter deployment, selection of
default File Save settings, and so on.
Here is how recommended deployment decisions are influenced by hardware:
Enough
Hard Disk Space avail for
Installation?
Yes
Enough
Hard Disk Space to allow
Rollback?
No
No
Consider asking
users to clear
space on the hard
disk, otherwise
upgrade
Put in place
recovery plans and
warn users
rollbacks will not be
available; check
whether mission
critical applications
exist
Yes
Memory meets or exceeds
req'd configuration?
Yes
No
Upgrade Memory
Is the Processor
Pentium or Higher?
No
Replace the
system, or consider
a Terminal Server
solution for
numerous lower
end clients
Figure 6.2 Assessing whether workstation hardware can sustain the upgrade.
The hardware inventory should determine:

Amount of memory. The available memory can determine which Office components
you will install, your rollback options, and so on.

Remaining hard disk space on the system disk. For example,

Processor type. This can determine performance to varying degrees. In client-server
applications, processors on servers and in workstations affect performance.
How effectively you deal with these factors depends heavily on how accurately
you inventory and understand the target system.
Planning the Assessment
Inventory, analysis of the results, report creation, and testing in the laboratory
form the bulk of the work performed before schedules are created and planning is
finalized. Typically, this pre-deployment work should take anywhere from 60 percent to
80 percent of the entire deployment schedule. If this work is done properly, then a
successful deployment can be completed relatively quickly. The following sections
describe the kinds of information that need to be gathered. Keep in mind that your
inventory will have to determine which previous versions of Office will be upgraded, as
the upgrade prerequisites vary. In particular, keep a clear distinction between Office 95
installations and Office 97 installations.
Initial Preparations
During the inventory process, you should be prepared to expect the unexpected. For
example, MCS reviewed early reports (before the site visit) and conducted in-depth
interviews with users to determine the operating systems that were in place. These
sources indicated that MCS would find only Office 95 and Windows 95 in the field. A
thorough inventory process revealed that a wide range of operating systems and software
were actually in use.
Testing performed in the laboratory had to be adjusted as MCS discovered the
true situation. For instance, while the group deploying Office 2000 had a limited number
of Macintosh machines, a significant percentage of the rest of the company used
Macintoshes, Microsoft Office 98 for the Macintosh, and Eudora Pro. Consequently,
testing had to take into account how compatible the new Office 2000 configurations
might be with the customer’s Macintosh population.
In short, allowances for preparation time should be flexible. You must be
prepared to reorganize based on new information—and that new information may arrive
daily. Do not hesitate to refocus testing plans to accommodate new discoveries made
during this period.
Accurate Inventory of Hardware and Software
The success of any deployment greatly depends on the administrator’s ability to
anticipate potential problems. Gathering accurate data on user’s software and hardware is
critical when determining priorities for time-intensive tasks such as upgrading RAM,
hard disks, or replacing a CPU in anticipation of the new environment.
Unfortunately, it is quite common to have little or no inventory data available.
When it is available, users’ systems often change too rapidly to get a reliable snapshot.
Administrators frequently have to scramble to get an accurate and timely picture.
This customer used Microsoft’s very powerful Systems Management Server
(SMS) to gather inventory data. However, one issue was that SMS relies on users logging
in before inventories are conducted. Some users wait for days before cycling power or
exiting their sessions.
Once hardware data was gathered, it appeared that roughly 40 machines were not
being captured in the inventory—probably due to problems with the KixStart script
interfering with the new SMS client. What was captured though was accurate and useful
raw data on the hardware side. This usefulness of this data proved that is was worthwhile
to configure SMS.
Obtaining accurate information on the wide range of installed software (and the
various versions of that software) on users’ systems proved very challenging. Classic
SMS software inventory required building a file, AUDIT.RUL, that compared CRC
checks of particular files to a list that mapped the results back to particular software
names and version numbers. This meant MCS had to know precisely what was being
searched for—taking into account all the possible patches and upgrades to both operating
systems and applications software. Given the fact that even Windows NT users had local
administrator privileges, there was little hope for truly consistent configurations across
the board. A matrix of all the possibilities confirmed that at least twenty-five possible
variations could exist—and the actual number was probably higher. In the end, since
even a relatively targeted scan of over 50 applications was known to occasionally slow
down logons, the customer’s administrators were reluctant to use it.
Because most companies update and patch software on a regular basis, conducting
centralized software inventories is a major challenge. Administrators need to be careful
that their software inventory requests are not so complicated that they impact workstation
performance. Yet, if they target the query too narrowly, they risk missing slight variations
to the original software they intended to document. This was the problem that MCS
encountered. To make matters worse, conducting an unobtrusive software inventory was
difficult because of the customer’s low-grade hardware (there were still several 486
systems) and many different types of software installed.
Accordingly, MCS began experimenting during this period with other ways to
capture critical-software information. Some methods were used at previous sites and
some were developed for this particular deployment. The key to this process was
prioritizing what was most important, and narrowing down the requirements. The
sections below explain what information was regarded as important to gather, and why.
When applicable, the methods MCS used in this case are described. Briefly summaries of
early attempts follow:

First, MCS built a custom package to obtain software inventory via relatively
lightweight queries to the users’ registries—a method that also could be counted on to
capture more information than the usual IDX file. The package could be sent as part
of the logon script if SMS was not available for some reason—a good side benefit for
future customers who lack the SMS infrastructure.
Second, MCS focused on extracting the versions of the logged on e-mail clients from the
Exchange server logon window. This is described more detail later in this chapter.