Monthly and Annual Windows 2000 Activities Chapter 10 In This Chapter

advertisement
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 385
Chapter 10
Monthly and Annual Windows
2000 Activities
In This Chapter
Auditing your network
Reviewing security
Performance benchmarking and monitoring
The monthly reboot
Managing disk space on servers
Disaster recovery simulation
Implementing operating system service packs and hotfixes
Implementing network application upgrades
Creating month-end or quarterly archives
Annual budgeting for your network
Setting up an active technology committee
Evaluating systems on the horizon
The annual planning retreat
Y
ou’re proud of your Windows 2000 Server network. You spent a lot of
time during planning and setup, configuring every aspect of your
systems to your specifications, conducting stress testing, developing
foolproof daily and weekly maintenance plans, and migrating the users onto
the new system. Your network runs smoothly, and the users are happy with
its performance. However, even in a network as trouble-free as yours (which
most of us can only wish for), certain administrative tasks require attention
each month and every year. This chapter will introduce you to many of the
tasks I’ve seen during my time as a network administrator. These tasks are
conveniently shown in Table 10-1 as a checklist. Hopefully this baker’s dozen
checklist will enable you to integrate some of these tasks into your own
network management approach. You won’t see step-by-step instructions on
how to delete users; instead, I’ll talk about some good habits to get into that
will make your day-to-day job easier and also enable you to more easily train
new network administrators as they come on board. After all, you’d like to
be sitting in the CIO’s leather chair someday, wouldn’t you?
4620-1 ch10.f.qc
386
10/28/99
12:27 PM
Page 386
Part III: Windows 2000 Server Administration
■
■
Table 10-1 The Monthly/Annual Checklist
Item
Description
1
Auditing your network
2
Reviewing security
3
Baselining and monitoring performance
4
The monthly reboot
5
Managing disk space on servers
6
Disaster recovery simulation
7
Implementing service packs and hotfixes
8
Upgrading and removing applications
9
Creating month-end or quarterly archives
10
Annual budgeting
11
Technology committee formation and meetings
12
Evaluating new systems
13
Annual planning retreat
Comments
Completed
Auditing Your Network
In a working day-to-day Windows 2000 network, new users, directories, and
shares are created daily; in a large, growing enterprise, administrators in
various locations may create hundreds of these objects in a busy week. Much
of that discussion was covered in Chapter 9. How in the world does a Windows
2000 Server professional keep track of all this, and more important, how can
you ensure that users, shares, and such are deleted properly when someone
leaves the business? A well thought out checklist for adding and deleting users
is a very good start, but some auditing will always be necessary because steps
will be missed and some tasks might fall through the cracks.
Here are the steps I use when deleting a user account:
1. Require an account deletion form. This is useful for two reasons; first,
it assures that you have the CYA factor, and second, you can file these
forms away for review at the end of the month. Without these forms,
it’s difficult to remember whom you’ve deleted during the month,
especially in a large organization.
2. On the date specified on the deletion form, change the account password
and disable the account. Do not delete the account at this point, in case
the user’s replacement is coming on board soon (in which case you can
just rename the original user account to the new account name) or if the
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 387
Chapter 10: Monthly and Annual Windows 2000 Activities
387
■
■
user comes back to the organization for some reason. At the same time,
inform your end user support group of your action, so they will not
accidentally re-enable the account if the former employee calls in.
3. Determine if the user’s manager needs access to the user’s old e-mail. If
not, go ahead and delete the e-mail account if it is not likely that the user
will return soon, as some temporary employees do, for example.
4. If necessary, give the manager permission to access the user’s home
directory, so he or she may get to documents as needed. Give the
managers a set amount of time (usually until the end of the current
month) to move any documents they might need before deleting the
directory itself.
5. At the end of the month, go through all accounts that have been disabled
during the month. If they are still not needed, delete the accounts from
the Windows 2000 Server Active Directory, and also delete the user’s
home directory and any network shares specific to that user. If your
system logon scripts have references for individual users (and they
shouldn’t, if you can avoid it) check to see if the deleted accounts were
referenced in those scripts. If so, modify the scripts as necessary.
In addition to reviewing user deletions, you also will want to take a look at how
your network has changed over the month. For example, let’s say a specific
application on your network required the creation of several network shares
on your main server. During the last month, that application was replaced with
another vendor’s product. As part of your end-of-month audit, you’ll want to
make sure that the shares created for the old application are deleted; not only
will this clean up your users’ views in My Network Places, it might improve
your network performance.
Reviewing Security
Documenting your network’s security is an essential part of maintaining
your Windows 2000 Server network. During daily operations, NT File System
(NTFS) and network share security settings will be changed, added, and
deleted. Without proper monitoring and auditing each month, these settings
can get out of control and you won’t know which folders and shares have the
proper security.
Consider two alternate ways to test your security, ways that will expose
your greatest weaknesses. First, download the SATAN tool from any of the
numerous shareware sites (www.winfiles.com, www.shareware.com).
SATAN is a tool that you may configure to test the security of your system
against outside intruders. It does have a learning curve, so allow yourself a
few weeks to master it and achieve the end results you seek — a more secure
Windows 2000 Server!
Second, hire the enemy. Have you ever noticed that successful hackers are
often offered jobs by the very firms that they hacked into? It is true and
probably happens more often than the media reports. In your case, I’d
4620-1 ch10.f.qc
388
10/28/99
12:27 PM
Page 388
Part III: Windows 2000 Server Administration
■
■
recommend that you consider hiring a high school or college kid and let the
kid take a “controlled” run at your system to test your security. Many hackers
come from this socioeconomic group, so why not hire the enemy and get ‘em
on your side?
Establishing and maintaining security settings on your Windows 2000 Server
network isn’t difficult, provided you stay on top of changes as they happen
each day, week, or month. Here are three steps that will help you keep your
network secure:
1. Set up and implement a plan. Implementing an initial security plan is
the first step toward a well-maintained network security setup. Every
responsible Windows 2000 Server professional should create a
spreadsheet, database, or other document outlining their network’s
security setup when the network is installed. This type of document
should be maintained in your network notebook. Before you turn users
loose onto the network, make sure that the actual security on shares,
files, and directories is as you intended it, and as you documented it.
2. Document changes as they occur. Any security document is a “living
document” and must be updated and changed to reflect changes made to
the network each day, week, month, or whenever. A security document,
be it a database, spreadsheet, or text, must be your security template
and reflect the network as it should be.
3. Audit security regularly. Once a month, or more often if your
environment requires it, compare the security settings in the template
with actual security on the network. Are they different? Do you know
why they’re different? If so, update the security template to reflect the
changes, and scold yourself or the administrator responsible for not
updating the template when the settings were changed.
If you find inconsistencies or mistakes in your network security, change
the permissions back to their intended settings. Make sure that you are
satisfied with your audit before moving on to other monthly tasks; security
maintenance is one of the most important parts of a Windows 2000 Server
professional’s job. If you doubt this, just wait until the CEO’s personal
documents are e-mailed throughout the company.
Baselining and Monitoring Performance
Windows 2000 Server’s Performance Monitor tool is extremely useful in
helping you tune your Windows 2000 network. However, for any monitoring
data to be useful, you must first generate benchmark measurements so that
you have a baseline to compare against. This matter is discussed at length in
Part V, “Optimizing Windows 2000 Server,” but it’s worth mentioning here.
And it should certainly be on your monthly/annual list of activities!
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 389
Chapter 10: Monthly and Annual Windows 2000 Activities
389
■
■
In a growing network, Windows 2000 Server’s performance baseline may
change significantly each month or every few months, as new users, services,
and applications are added to the system. Because of this, that Performance
Monitor baseline you recorded back in February may be far from accurate
in August.
In my current network, I usually do a performance benchmark every three
months or so, and more frequently if there is a major user conversion going
on. My coworkers and I save these files for future use and refer to them for
comparison when trying to troubleshoot a server problem using
Performance Monitor.
Performance baselining and monitoring will be discussed in detail later in the
book, but I wanted to mention it in this chapter because accurate baselines are
a crucial part of understanding whether your Windows 2000 Server network is
humming along happily or whether it’s headed for a screeching halt.
The Monthly Reboot
All operating systems use and release primary memory, or RAM, as needed.
This is normal and occurs constantly. In fact, one way to monitor the RAM
usage on your Windows 2000 Server is to run Task Manager (selected from the
taskbar properties on your Windows 2000 Server desktop). Task Manager is
discussed at length in Chapter 20. The Performance tab on Task Manager
enables you to see, on the lower right of the screen, the memory consumed
over the memory available on you system (see “Mem Usage:”), as seen in
Figure 10-1. Another good memory indicator is the memory chart in the middle
of the Performance tab that shows a memory consumption histogram view on
the left and a memory consumption time line or time series at the middle right.
Figure 10-1: The Task Manager Performance tab
4620-1 ch10.f.qc
390
10/28/99
12:27 PM
Page 390
Part III: Windows 2000 Server Administration
■
■
Under the best of circumstances, the memory consumption information
displayed in Figure 10-1 would increase over the course of a month because
Windows 2000 Server, in the process of using and releasing RAM, will slightly
fragment this primary memory. That is, not all of the RAM used will be
returned properly and counted again as unused. In English, Windows 2000
Server doesn’t give back all of the RAM it uses when it is done with it. And I
haven’t even started to discuss how applications affect RAM. It has been my
experience that Microsoft Exchange Server can be a poor server citizen when
it comes to releasing unused RAM. Microsoft SQL Server can be trained to be
a good server citizen because you can specify how much and in what ways
SQL Server will use RAM (this is done via the server property sheet in SQL
Server’s Enterprise Manager).
Third-party applications are what may just cause your Windows 2000 Server
machine fits when it comes to releasing RAM. I’ve already seen offenders
(including the backup engine service of a well-known third-party backup
application) that not only fail to release all of the RAM used when the
application was open but sometimes, in a badly behaved way, cause the
Windows 2000 Server to consume all available memory. That is, some poorly
written applications will cause the memory histogram and time line shown
in Figure 10-1 to “max” at the top of the chart. Perhaps you’ve experienced
this, and would know that your server slows down so much that it is difficult
to launch another application at the server or sometimes even move the
mouse on the server machine.
Enter the monthly reboot to “reset” and form contiguous RAM space. By
rebooting your Windows 2000 Server, you flush and defragment RAM and
get a fresh start. This will certainly solve the slow buildup of memory
consumption from the operating system and applications not returning all
consumed RAM. To see for yourself, consider the following experiment.
STEPS:
To monitor RAM consumption and defragmentation
Step 1.
Launch Task Manager from the taskbar properties of Windows
2000 Server.
Step 2.
Observe and record the Mem Usage value on the lower right of the
Performance Tab sheet.
Step 3.
Launch one or two server-based applications such as Microsoft
Exchange Server or Oracle.
Step 4.
Observe and record the Mem Usage value again (as in Step 2) after
launching the server-based applications.
Step 5.
Let both Task Manager and the applications launched previously
(Step 3) run for several days. Continue to use your network
as usual.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 391
Chapter 10: Monthly and Annual Windows 2000 Activities
391
■
■
Step 6.
Several days later, observe and record the Mem Usage value again
and terminate the applications you launched in Step 3.
Step 7.
Now observe and record the Mem Usage value with the
applications successfully terminated.
Step 8.
You will now compare the different Mem Usage values over the
past few days. Ideally, if there were no RAM leaks, the Mem Usage
values in Step 2 and Step 7 would be the same. But most likely
these values are not the same, reflecting the fact that not all RAM
was returned to available memory once the applications were
terminated. Indeed, the Mem Usage value in Step 7 should be
larger than the Mem Usage value in Step 2, all other things
being equal.
You can also perform the preceding experiment where you simply run Task
Manager for several days or weeks without explicitly launching and terminating
server-based applications just to observe what level of RAM fragmentation may
be attributed to the underlying Windows 2000 Server operating system. And
above all, perform that monthly reboot to flush and reset your RAM to battle
this form of memory fragmentation. You might also be interested to know that I
like to use the monthly reboot to test the bulletproof nature of my Windows
2000 Server machine. It is my goal to have networks in place that I can reboot
with confidence each month. If I’m afraid to reboot a Windows 2000 Server
machine each month because I’m afraid it won’t restart and come back up, I
probably have larger, more serious underlying problems with my network than
simple RAM fragmentation.
I’m very comfortable providing the preceding advice regarding the monthly
reboot to those of you working on small- and medium-sized Windows 2000
Server networks. However, I am reluctant to advise you to override strict and
necessary system management policies at the enterprise level. Be sure to
check with your Windows 2000 Server network stakeholders (including your
boss) before rebooting your Windows 2000 Server each month. At the
enterprise level, accept my advice as something to consider.
Managing Disk Space on Servers
In Chapter 9, I mentioned disk space monitoring as an important task that
Windows 2000 Server professionals should do at least weekly. On a monthly
basis, I recommend going one step further and monitoring the growth of
individual directories on your servers and running a disk defragmentation
utility. A weekly look at total free disk space is fine, but once a month, a more
detailed look is called for. While this seems like (and is) a lot of work, it’s also
essential; if you don’t know which directories are growing out of control, you
can’t stop a problem before the server runs out of disk space.
4620-1 ch10.f.qc
392
10/28/99
12:27 PM
Page 392
Part III: Windows 2000 Server Administration
■
■
Disk quotas
The manual method for managing disk space on Windows 2000 Server
networks is to impose storage quotas on a per-user basis. This is a great
new feature in Windows 2000 Server, one that was clearly long overdue.
Implementing disk quotas is very easy. Simply configure the Quota tab sheet
from any hard disk’s Properties sheet. Disk quota entries may be made on a
default, group, or individual user basis.
Automatic management
A blast from the past. This Windows NT Server story applies equally well to
Windows 2000 Server today. After spending a few months manually recording
each folder’s size on our NT server, my fellow administrators at work and I
decided there must be a better way to determine which directories are
growing the fastest. We started looking into third-party utilities and settled
on Storage Resource Manager from Highground Systems (www.highground.
com). While this tool was written as a user space quota utility, it works very
well for our needs; we can generate database reports indicating which
directories on our servers are biggest, and which are growing at alarming
rates. Using this information, we can stop any out-of-control growth before it
takes out our server’s free disk space.
A real-world war story
One of my clients, an online research firm, found that it didn’t know exactly
where its mission-critical data was located on the network. Of course this
discovery was made during a hard disk failure when it was time to perform
data restoration. From that experience, a table such as the one shown in
Table 10-2 was devised to better map out how the disk space on the network
was being utilized. I’ve created one example for your benefit. The intent is to
have you fill in the blanks with your own information as part of the data
location exercise.
Table 10-2 Data Location
Data
Size
Alaska 12MB
Drive
Letter
Physical Based
Location Location
Server1
c:\data\ak
UNC
Location
\\server
1\ak
ARC
Path
Location
multi(0)
disk(0)rdisk
(1)partition(2)
Comments
Is backed up
nightly.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 393
Chapter 10: Monthly and Annual Windows 2000 Activities
393
■
■
Closely related to disk space calculations is the topic of disk fragmentation.
Contrary to popular belief, NTFS partitions do indeed suffer fragmentation
from the ins and outs of daily Windows 2000 Server activity. This of course
isn’t news at the desktop level with FAT and FAT32 in the traditional end user
Windows environment. Windows 98 performs disk maintenance activities for
you with ease.
Windows 2000 Server provides defragmentation support right out of the
box. This is a big improvement on Windows NT Server 4.0, where you had
to purchase third-party utilities. To defragment your disks in Windows 2000
Server, simply select the Defragment Now button on the Tools tab sheet of
any volume’s Properties sheet.
Before running a disk utility to “recombine” your fragmented secondary
storage space, make sure that you’ve made bona fide and verified tape
backups of your data. Just in case!
Dynamic disks
Be advised that Windows 2000 Server emphasizes the concept of dynamic
disks as the primary storage type. Contrast that with the old paradigm of
basic disks. What’s the difference? The basic file system has the partition
view, whereby you could have either four primary partitions or three primary
partitions and one extended partition. But the dynamic disk view essentially
does away with those partition limitations and just defines everything as
volumes.
You can only convert disks from basic to dynamic using the Disk
Management MMC. You cannot convert disks from dynamic to basic.
Likewise, you can only create volumes on dynamic disks in Windows 2000.
The dynamic disk volume types include the following:
■ Simple volume. This is disk space on a single disk.
■ Spanned volume. This is disk space combined from two or more disks.
■ Mirrored volume. This is an identical copy of a simple volume.
■ Striped volume. Similar to stripe sets in Windows NT Server 4.0.
■ RAID-5 volumes. This is comparable to the stripe steps with parity RAID-5
volumes in Windows NT Server 4.0.
I recommend you implement RAID-5 at the hardware level, not the
Windows 2000 Server software level. This is because hardware-based
RAID-5 implementations use the processing capability of the RAID
controller card and don’t significantly add operational overhead to
your Windows 2000 Server machine.
Another way to understand the concept of dynamic disks is to look at it
from a logical viewpoint. Dynamic disks de-emphasize the physical view of
partitions and emphasize the logical view of volumes.
4620-1 ch10.f.qc
394
10/28/99
12:27 PM
Page 394
Part III: Windows 2000 Server Administration
■
■
Distributed file systems (Dfs)
Extending the logical view of storage is distributed file systems (Dfs). Dfs
is a view of storage across the entire enterprise network whereby disparate
storage media and geographically diverse locations may be viewed as a
single storage resource. You may also create a hierarchical tree of storage
resources in the enterprise with Dfs. This is accomplished by selecting
Distributed File System from the Administrative Tools program group. This
will launch the Distributed File System MMC, which will allow you to create
a Dfs storage structure.
The first time you run the Distributed File System MMC, you will need to
run the Create New Dfs Root Wizard to create a “root” container. This is
accomplished by selecting the New Dfs Root Volume menu option from the
Action menu.
Recovering from Disaster
First and foremost, update your Emergency Repair Disk (ERD) each and every
month, even if you don’t believe significant system activity has occurred that
might warrant such action. Never underestimate the passing of time and its
effects on a Windows 2000 Server. Sure, you may not have added any users in
the past month, but with a default password change duration of 42 days in
Windows Server, it’s likely that user accounts have been updated in the past
month, with or without your knowledge. This immediate example is only one
of several “background” system update possibilities that warrant the monthly
ERD creation process. The ERD is discussed in more detail in Chapter 21.
Because the ERD resides on a floppy disk, I suggest that each month you
create a new ERD and save the old one. I’d hate to see you get in the habit of
overwriting the ERD each month and ultimately suffer a floppy disk media
failure. Also, note the ERD isn’t created with the RDISK command any more.
In Windows 2000 Server, the ERD is created via the Backup tool in the
Accessories, System Tools program group.
You and I both can learn a lot from the mainframers of yesteryear,
specifically, in the area of disaster recovery. The client/server networking
community has done a very poor job of addressing disaster recovery. Novell
took the lead years ago with its NetWare SFT III specifications, wherein hot
“mirrored” servers were kept online some distance away from the main
production NetWare servers. Microsoft is, to be quite candid, just arriving at
the disaster recovery party with its Windows 2000 Server clustering solution
(see the online help system under clustering for a more detailed discussion).
So how can you address the disaster recovery issue in Windows 2000 Server
today? There are several ways.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 395
Chapter 10: Monthly and Annual Windows 2000 Activities
395
■
■
Native clustering
Clustering in Windows 2000 Server is managed and implemented via the
Cluster Administrator. This tool is part of Windows 2000 Administration
Tools. Windows Clustering provides three clustering technologies:
■ Network load balancing clusters
■ Server clusters
■ Component load balancing clusters
These clustering technologies, used alone or together, provide scalability
and high networking availability, never before seen in a Microsoft-based
networking solution. They provide a total clustering and load balancing
solution for all application architectures. You may also manage remote
clusters via the Cluster Administrator.
Third-party solutions
Larger Windows 2000 Server sites will initially look at third-party solutions
ranging from robust optical-based backup systems to clustering applications
until viable and tested Microsoft solutions, such as native clustering, are
deployed. One notable third-party clustering solution in the Windows 2000
Server environment is Vinci (which was recently acquired by Legato).
Identical spare servers
Consider implementing this approach from the old Windows NT Server 4.0
days. Here, two of my Windows NT Server clients purchased identical servers
(down to the network adapter card). One acts as the production server, the
other is a spare (see Figure 10-2). The idea is that if the production server
crashes or fails, the hard disks can be moved to the identical spare server
and the organization will have its network up and running again within one
business day. An alternative approach is to restore from backup tape to
the spare server.
Believe it or not, this spare server approach will actually work in a Windows
2000 Server environment. I have only performed this in a medium-sized
environment, and clearly, at the enterprise level a more robust solution such
as clustering would be used instead.
One lesson I learned from using the spare server approach was how long it
took to get back online. Early on I thought I could have an organization back
online within one or two hours. Wrong! For whatever reasons (glitches,
unexpected issues), the spare server approach takes a full business day
to implement. With this fact in mind, I can now manage everyone’s
expectations appropriately.
4620-1 ch10.f.qc
396
10/28/99
12:27 PM
Page 396
Part III: Windows 2000 Server Administration
■
■
Production Server
Windows 2000 Server
256 MB RAM
10 GIG HD
Dell PowerEdge 2300
Spare Server
Windows 2000 Server
256 MB RAM
10 GIG HD
Dell PowerEdge 2300
Identical Windows 2000 Server
server machines
Figure 10-2: Using a spare server
If you haven’t already done so, take a few minutes to assess how you are
managing the downtime expectations for the stakeholders on your Windows
2000 Server network. Have you communicated that server-related downtime
might be measured in hours, if not days (but rarely minutes)? If necessary,
take a moment to jot down a few ideas on how you might better manage
expectations (perhaps an e-mail message to everyone in the office advising
people to have alternative work processes ready in case the server is down
for a day).
Although the spare server solution will work, you must plan for how you will
handle the “different” SID value on the backup server, assuming you use the
same server and domain naming conventions. If you are using Windows
95/98, this is not a serious problem, as these desktop operating systems
don’t bind the SID to their logon process. But if you are using Windows 2000
Professional or Windows NT Workstation at the desktop, you’ve got major
problems. That is because the spare server’s SID numbers (machine and
domain) will be different from the original networked environment. In all
likelihood, you will need to use a SID changer, an application found at
popular shareware sites (www.winfiles.com, www.shareware.com).
Reciprocity agreements/hot sites
Our firm occasionally offers its spare training PCs as potential “rescue”
computers for our smaller clients in a crisis. By that I mean that if the
property management firm calls with a crashed server, we can trot over
with a bare-bones spare Windows 2000 Server and have the ten users printing
from Microsoft Word by lunch. Not a perfect solution, but one that works
in a crisis.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 397
Chapter 10: Monthly and Annual Windows 2000 Activities
397
■
■
Larger enterprises contract with hot sites to address possible failures. These
are the airlines, hospitals, and large corporations of the Windows 2000 Server
community. Although this approach is expensive, when properly configured,
the enterprise customer’s network can limit downtime to minutes, not hours
or days.
Why bother?
Wouldn’t it just be easier to do nothing and wait for the problems at
your site to work themselves out instead of following all of the preceding
approaches to disaster recovery? Well, you know what the answer is: Of
course not, for at least one reason — the cost of downtime. Even small
organizations can calculate the cost of downtime in the range of several
thousands of dollars per hour. Such high costs make a spare server or
third-party disaster recovery solution seem cheap.
Annual drill
Regrettably, too many of us in the networking community don’t perform an
annual disaster recovery exercise. The customers I have that do this typically
perform this activity in response to some form of EDP audit or at the request
of government regulators (if they are in a regulated business).
The annual disaster recovery drill can take many formats. It can be as simple
as the CIO pulling a drive out of a RAID array chassis unannounced (after
making sure the evening backup tapes were successful — wink wink). A client
of mine that runs an online research service performed that exercise, and it
was an eye-opener, to say the least.
Another disaster recovery exercise is to have your IT consulting firm arrive
unannounced, grab last evening’s backup tape and several IT staff members,
and have said staff perform a complete and successful system restore —
within one business day. Again, such an exercise is a real eye-opener.
Implementing Service Packs and Hotfixes
In every operating system, bugs and shortcomings are bound to appear.
Because of this, operating system vendors periodically release bug fixes
for system administrators to apply to their servers. Microsoft’s method
for large-scale updates of Windows 2000 Server systems involves groups of
enhancements and bug fixes they call service packs. No surprise here.
This is what Microsoft did back in the NT days too! While service packs
are generally safe, many problems have cropped up as a result of applying
them, so it’s extremely important for administrators to know exactly
what they’re doing before attempting to update a production system.
In my experience, it’s very important to have the following questions
answered before applying any service pack:
4620-1 ch10.f.qc
398
10/28/99
12:27 PM
Page 398
Part III: Windows 2000 Server Administration
■
■
1. Why is this necessary? Do you have a compelling reason for installing the
service pack, or are you just trying to keep your servers up to date? This
phenomenon of riding the latest versions or upgrades is often called the
“bleeding edge,” and with good reason. No matter how much Microsoft or
other vendors test their products, some instabilities or incompatibilities
will always come up. Remember; if it ain’t broke, don’t fix it. If the server
crashes and you have to restore it from backups, you’d better have a
good explanation when the CIO asks you why you were messing with the
production environment.
2. Do you have a back out plan? What if something does go wrong? While
Murphy’s Law does not always apply in the world of Windows 2000 Server
networks, you’d better be ready for anything when doing any sort of
operating system upgrade. In all cases, update your servers’ Emergency
Repair Disks and use the “Create an Uninstall Directory” option when
applying a service pack. Also spend some time planning what you would
do if the server refused to boot after the upgrade; do you have a reliable
method for restoring it from “bare metal” if you have to format the drives
to correct the problem?
3. Have you tested the service pack in your environment? Do you really
know how the new files will interact with your production systems? On
occasion, third-party or homegrown applications do not respond well to
changes made by a service pack and may either refuse to run or behave
strangely. Make sure you thoroughly test how the service pack will affect
your production environment.
4. Have you properly researched the upgrade and its possible side effects?
When you’re thinking about applying a service pack or performing an
application upgrade, Windows 2000 Server user groups on the Internet can
be invaluable. Before we applied Service Pack 2 to our Microsoft Exchange
5.0 server, I spent a few days on the Net, gathering information from the MS
Exchange support forum (www.msexchange.org) and other sources. It’s
well worth your time to take advantage of these resources and enlighten
yourself about the possible consequences of the upgrade.
5. Have you scheduled an appropriate time window for the work?
Because service pack installations require a server reboot and may
require additional downtime, they obviously should not be performed
during production hours. In a smaller shop where users work from 8 to
5, this is fairly easy; you can schedule the work for any weeknight after
everyone has gone home. In a 24/7 shop, scheduling downtime is not
quite as easy. Choose a period of time when the system will be under
minimal use, such as the middle of the night. These “O’ Dark Thirty”
projects may not be fun for you, but this scheduling is necessary to
minimize user impact. Also, make sure you give yourself some “cushion”
time, in case something goes wrong. Estimate your downtime as
accurately as possible, and schedule an hour and a half of downtime,
even if you think the work will only take an hour. If you have the system
back up and running early, you’ll be a hero. If it’s late, you’ll have some
explaining to do the next day.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 399
Chapter 10: Monthly and Annual Windows 2000 Activities
399
■
■
Hotfixes
While service packs replace many files and sometimes add new features,
hotfixes are “quick-fix” solutions to urgent problems that come up. Hotfixes
replace only a few files at a time and are not as thoroughly tested as service
packs are. As with service packs, caution is advised when applying hotfixes;
if you are not experiencing the specific problem described in a hotfix Readme
file, then don’t apply the fix.
Hotfixes are also tricky in that they often must be installed (and removed!)
in a specific order, or they won’t work properly. As such, it’s important that
administrators take advantage of all information available about the hotfix
they’re thinking of installing. Hotfixes also usually require a server reboot,
so be sure to schedule some downtime.
Be conservative
The recommendations in this section may sound overly conservative, and
this type of caution is definitely not necessary for all environments. However,
it is absolutely required in larger enterprises and is a very good idea even in
the smallest of shops. If you run your small 25-node, single-server network as
you would run that of a huge conglomerate, your colleagues and users will
respect your professionalism and concern for their interests, and this will
pay off later on, believe me.
Upgrading and Removing Applications
Be sure to honor the upgrade cycle of your software vendors. With certainty,
you can anticipate upgrading your mission-critical applications every 18
months if not sooner. And many software vendors will release interim
upgrades monthly and quarterly. Your challenge as a Windows 2000 Server
professional is to implement these application upgrades in a noninvasive
manner. That’s a kind of way of saying you’ll first test each application
upgrade on a test server to make sure it works. Then you’ll install the
application upgrade on the production servers on the weekends when no
one is around. Heck, you didn’t want to use those weekends for skiing or
fishing anyway. Regarding the “how” of installing an application upgrade,
you will recall this was discussed in Chapter 9.
Creating Backup Archives
In many businesses, it’s necessary to create special archives that can be
shipped to an offsite storage facility for long-term safekeeping. Some companies
are required to do this by governmental regulations, and others keep data as a
safety net in case of litigation or other unforeseen circumstances. Many offices
are governed by state regulations and must keep all business data for seven
years. At the end of each month, these sites do a special data export from their
backup system and ship them to an offsite storage area. You may not be
4620-1 ch10.f.qc
400
10/28/99
12:27 PM
Page 400
Part III: Windows 2000 Server Administration
■
■
required to perform this action for your network, but if so, make sure you
develop a consistent plan and schedule, and stick to it. It’s easy to miss an
archive window, especially if it is supposed to happen during a busy time,
such as the holiday season.
Budgeting for Your Network
Like it or not, a lot of what you accomplish as a Windows 2000 Server
professional centers on the budget you have to work with. Part of your
monthly and annual activities include paying attention to the financial side of
Windows 2000 Server networking. Here are several approaches to addressing
the budget issues, including zero-based budgeting, linear percent growth,
percent of revenue, and Windows 2000 Server on $5 a day.
Zero-based budgeting
This is my favorite. Here, as part of the budgeting exercise, you start with
a blank spreadsheet. Each and every expenditure category is critically
reviewed. By that I mean each item, down to the network adapter cards you
keep on hand, is evaluated for usefulness. Questions to ask are as follows:
■ Why do you have so many computer parts in inventory?
■ Do you need to add staff? How can you justify such an addition?
■ If you’re planning to add two more servers, what else would be needed?
Here the idea is that adding a server results in other additions, such as a
printer or a modem. Each of these additions would be listed as a line
item under the new server, as shown in Figure 10-3.
Zero-based budgeting is similar to designing a bill of materials (BOM)
system in manufacturing. You build up the budget from the lowest levels.
If you want to learn more about zero-based budgeting, consider learning it
the way I did: from a management consultant. If you have consulting funds
available, hire a nontechnical management consultant who specializes in
business practices such as zero-based budgeting. After you work closely
with such an individual once, in all likelihood you will be able to create
your own zero-based budget in later years.
Linear percent growth
This is the simplest and most popular way to create your IT budget. Here,
you simply apply a growth factor to last year’s budget. For example, you
might say that you’ll increase this year’s IT budget by five percent across
the board. This means that each expense category will simply grow by five
percent. Call it overly simplistic, but it works, and this method is used
extensively.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 401
Chapter 10: Monthly and Annual Windows 2000 Activities
■
401
■
Figure 10-3: A zero-based budgeting example
Percent of revenue
This is how the accountants in your organization think. That is because
industry ratios comparing IT expenses as a percentage of total revenues are
widely published. For example, many believe that IT as a whole shouldn’t
exceed two percent of the firm’s total revenue.
To use this method, first you would agree on a percent-of-revenue value.
This consensus might be arrived at via the technology committee (I speak of
technology committees in the next section) or the board of directors. Once
that value is selected, simply create a spreadsheet similar to Figure 10-4 and
enter the Percent of Revenue.
Industry ratios that may be useful for your budgeting purposes are
indeed widely reported. One of the best sources for this information is
Computerworld, a weekly trade newspaper. Another great source is
CIO magazine.
4620-1 ch10.f.qc
402
10/28/99
12:27 PM
Page 402
Part III: Windows 2000 Server Administration
■
■
Figure 10-4: Budgeting via Percent of Revenue
Windows 2000 Server on $5 a day
Closely related to the Windows 2000 Server network budgeting process is the
“Windows 2000 Server on $5 a day,” or marginal budgeting approach. Believe
it or not, it is highly likely that you already understand this approach well.
Remember the last time you purchased the car you drive? Did the salesperson
attempt to “up-sell” you into getting a better car stereo or seat warmers? Was
the argument made that these extra features would only cost an additional
$1.00 per day over the life of the car? (And wouldn’t you enjoy that high-end
stereo much more in traffic jams, all for just a $1/day?) The good news is you
can apply the same reasoning to your Windows 2000 Server network!
Let’s assume that you plan to amortize, or recover the cost, of your network
software and hardware over 36 months, a reasonable recovery period. This is
approximately 1,095 days. Now suppose you are considering the purchase of
a Dell PowerEdge server that is dual-processor-capable. You are currently
unsure if you should add a second processor to the server now or purchase
one a few years down the road. You do realize that a second processor would
provide immediate and significant benefits to the overall performance of your
network. Consider the following.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 403
Chapter 10: Monthly and Annual Windows 2000 Activities
403
■
■
A second server-class processor is approximately $1,000. And you expect
to keep the server for three years (or approximately 1,095 days). This
second processor effectively will cost you $1,000/1095 days = $0.92 per
day (rounded up). That’s 92 cents a day to keep everyone happier on
your network! Seems like a good investment. And imagine how much
more performance and reliability you could add to your network if you
were willing to spend an additional (or marginal) $5.00 per day. Depending
on your situation, perhaps that extra $5 a day would enable you to have a
mirrored RAID array, something that is highly desirable in a production
SQL Server environment.
Creating a Technology Committee
Early on in the life of your Windows 2000 Server network, it is essential that you
create a technology committee, populated with key network stakeholders, that
meets on a regular basis. I’ve enjoyed assisting many firms with the process,
and establish a monthly meeting rather than a quarterly one (this area moves
too quickly for a quarterly meeting). Stakeholders that sit on your technology
committee include
■ Executives. This group, at the C-level (CEO, CIO, CFO, COO), has the
ability to make valuable contributions about how technology fits into
the mission of the overall organization. They also control the IT budget
(something that shouldn’t be lost on you).
■ Line managers. This group is critical. It is from this group that your
applications needs will be best identified, including new features that
would make the organization run more efficiently. Line managers are
typically experts in their processes, knowing more than you or I do about
what they need out of the computer system.
■ End users. Another critical group. These technology committee
members can offer you insights on how the network is performing on a
day-to-day basis. Can they print when they need to? Do they receive
prompt attention from you or the help desk when problems occur? Do
they trust the network? A great group of people with lots of important
feedback for you.
■ Outside IT consultant. An outside presence is a very meaningful addition
to the technology committee. An outsider is typically innocent of the
political shenanigans that occur internally in an organization. Outsiders
offer that distant view so appreciated by senior management, plus
expertise gathered at other sites that can benefit you.
■ You. Don’t forget the role you have as the firm’s Windows 2000 Server
professional. Welcome to the table!
Consider having the outside IT consultant serve as the coordinator for the
technology committee. When I’ve seen this process managed by in-house
staff, it tends to fade and fall off the radar screen after several months.
However, an outside IT consultant brings both the freshness and the
4620-1 ch10.f.qc
404
10/28/99
12:27 PM
Page 404
Part III: Windows 2000 Server Administration
■
■
motivation to keep the committee alive. The “motivation” I speak of means
the hours that the outside IT consultant will bill to coordinate and serve on
the technology committee. For an IT consultant, there is perhaps no greater
motivation than the prospect of billable hours.
Because a picture is worth a thousand words, perhaps Figure 10-5 will enable
you to understand the technology committee better. Our roles as Windows
2000 Server professionals don’t just encompass hardware and software issues,
but also communication with our stakeholders every step of the way.
C-level Executives
CEO, CFO. CIO, COO
Line Managers
Windows 2000 Server
Computer Network
You
(Windows 2000 Server professional)
End Users
Outside IT Consultant
Figure 10-5: Technology committee membership
Issues addressed by the technology committee include, but are not limited
to, the following:
■ Budget versus actual expenditures
■ Implementation schedules
■ IT hiring decisions (in-house staff, consultants)
■ Vendor selection (services, products, presentations)
■ Network performance review (end user satisfaction surveys, network
uptime reports, performance monitoring charts and analysis)
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 405
Chapter 10: Monthly and Annual Windows 2000 Activities
405
■
■
Evaluating Systems on the Horizon
One of the biggest frustrations of working with modern information technology
is the constant barrage of upgrades and enhancements that seem to come down
the pike. Talk to anybody at a Windows 2000 Server conference, and they’ll all
say the same thing: Once you finally have that new office suite or e-mail system
rolled out to your 10,000-user environment, there’s no time to rest before you
have to start working on integrating the product’s next version. If you let it get
to you, this frantic upgrade schedule can cause untold stress and grief. So
what’s a frazzled administrator to do?
The answer is simple: Exercise moderation. The reasons software vendors
hit us with endless upgrades is the incredible competition they face and
the perceived huge demand for these new versions. Who generates this
perceived demand? Us! So stand up to them; go to your 2000 conference
hotel room window, lean out, and shout, “We’re mad as hell and we’re not
going to take it any more!” Seriously, the upgrade frenzy won’t stop until
the IT world in general learns to relax a bit and capitalize on their current
systems. This phenomenon has already started taking root, thankfully, and
should continue through the next couple of years.
Two real-world examples
Mind an old war story? Some time ago, at my office, we completed
migration from Microsoft Mail to an Exchange Server based e-mail and
groupware system. Our primary reason for doing this was that the text-based
and decentralized nature of MS Mail post offices created an administrative
nightmare for us, and our users were clamoring for the new features available
in Exchange Server. When we began the project, the current version of
Exchange Server was 5.0, so that’s the system we went with. Now that all the
users are on the system and things are running smoothly, we are beginning to
evaluate the move to version 5.5. At this point, we haven’t seen anything that
would really push us over the edge as far as undertaking (and paying for!) an
upgrade. Sure, there are many new and useful features in 5.5, plus a better
back-end database, but at this point we haven’t found any “gotta have it”
features that would apply to our network. We also want to see what’s coming
down the pike in Exchange Server 6; we don’t want to be upgrading our e-mail
system more than once every couple of years. So we’re going to play it cool
for a while, keeping our existing Exchange Server 5.0 system on the latest
service pack, and enjoying the calm between the migration storms.
At the same time that we were doing the Exchange migration, our threeperson network administration group was moving our 175 users from nine
NetWare 3.12 servers to one central Windows NT 4.0 server. When that
migration was completed, users worked along every day, basically oblivious
to the system that manages all of their files and printers. After a year of client
and server conversions, we enjoyed the lull, believe me. We were also very
4620-1 ch10.f.qc
406
10/28/99
12:27 PM
Page 406
Part III: Windows 2000 Server Administration
■
■
conservative about messing with our production systems; we didn’t put
Service Pack 4 on a single production box right away, but waited and
watched the Internet forums carefully to see what kinds of problems might
await us. We didn’t have an urgent need to move to SP4, so we were being
rather conservative about it and waited for the first round of hotfixes to
come out before proceeding. Consideration should be given to learning
Windows 2000 Server and what effects it will have on your network before
deploying it on production servers. In other words, deploy Windows 2000
Server on test servers as soon as you can, but also think about a reasonable
delay (for learning and testing) before deploying Windows 2000 Server on
your production servers.
What do these examples have to do with your network? I’m hoping to convey
that you don’t have to jump on the latest operating system or application
upgrade in order to have a successful, well-maintained system. Be aware of
what’s coming and start thinking about how to integrate it, but don’t rush it.
Unless the new system is ripe with features your users absolutely can’t live
without, they won’t care what version they’re on, as long as they can log on
and work each day. Life on the bleeding edge can be fun and exciting, but it
can also be painful for you and your users. So be open to the possibility of
delaying upgrades for a while. Take a few months, optimize your current
systems so that they hum along perfectly, and enjoy the silence.
Looking inward
Don’t forget to look inward at Windows 2000 Server when you’ve got your
forward-thinking strategic planning hat on. By that I mean you may consider
implementing additional features in Windows 2000 Server that may not have
made the most sense in year one (the first year you implemented Windows
2000 Server in your organization). One such feature that many firms can take
advantage of is the built-in Terminal Services. In the past Windows NT Server
4.0 era, terminal-like functionality was provided by a separate Windows NT
product called Terminal Server. In Windows 2000 Server, terminal
functionality is provided out-of-the-box as Terminal Services.
You implement Terminal Services just like Terminal Server by installing the
Terminal Services client component on the workstations, after Terminal
Services has been loaded on your Windows 2000 Server. These workstations
can then launch a session to connect to the Terminal Services running on the
Windows 2000 Server. You may recall this session is typically a large session
window on the monitor of the existing workstation. You may also attach “thin
clients,” which are similar to dumb terminals, to your network. You will find
the greatest use of Terminal Services for remote users who dial in or VPN
(virtual private network) into the corporate network, users who regularly
destroy their local desktops and benefit from the “roving” profile nature of
Terminal Services, and strategically deployed thin-clients.
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 407
Chapter 10: Monthly and Annual Windows 2000 Activities
407
■
■
Remembering the Annual Planning Retreat
My favorite! But seriously folks, there are valid reasons for getting away each
year for an annual planning retreat. It is critical that this be held off-site so
that participants aren’t distracted by the telephone, e-mail, pagers, and the
like. It is here that budgets are made and better friendships between the
business staff and the IT department are cultivated. It is here that the
strategic vision for technology is cast.
Use the annual planning retreat to hear from your main technology vendors.
Vendors such as Microsoft, Cisco, Oracle, Novell, and others will be happy to
send a sales engineer to your retreat, for free, to educate you on their
existing and forthcoming solutions. To arrange for such presentations, just
call your account representative at the vendor of your choice.
And don’t forget that the annual retreat is a chance for you to both show off
your successes and receive accolades for a job well done as a Windows 2000
Server professional.
Summary
In addition to daily administration, Windows 2000 networks require monthly
and annual attention to continue running smoothly and to keep up with the
technology that users demand. In this chapter, I covered some of these monthly
and yearly tasks:
Auditing your network
Reviewing security
Performance benchmarking and monitoring
The monthly reboot
Managing disk space on servers
Disaster recovery simulation
Implementing operating system service packs and hotfixes
Creating monthly or quarterly archives
Implementing network application upgrades
Annual budgeting for your network
Setting up an active technology committee
Evaluating systems on the horizon
The annual planning retreat
4620-1 ch10.f.qc
10/28/99
12:27 PM
Page 408
Download