Some of the main topics in this chapter are
These days, many organizations find themselves using Windows NT Servers for a wide variety of purposes. Due to their relatively low cost, these servers can even be deployed at small sites or be set up by departments for only one purpose per server. For these reasons, an organization can find itself with tens or hundreds of Windows NT Servers. Deployment of so many servers raises various issues, which this chapter considers. In particular, you will consider ways to successfully deploy, manage, and update many servers.
A strongly related set of issues arises from the fact that if you have many Windows NT Servers, you probably have some deployed at sites that are a considerable distance from any system administrator. Such servers are almost always accessible only via relatively slow-speed network links.
Possibly the biggest favor you can do for your organization and yourself is to do some planning before you deploy your Windows NT servers. This might sound obvious, but it's easy for this important step to be lost in the shuffle. You set up a few NT servers as a pilot test. Someone else sets one up as a Web server. The human resources department uses one as an Oracle server. Before you know it, you've got dozens of Windows NT servers deployed, with no policies, procedures, or standards in place. So take the time to do the planning and ensure that the plan is followed from here on out.
Planning for Windows NT on a large scale in your organization involves looking at several sets of issues, as follows.
Decide on your Windows NT domain model. Figure out whether you are going to have user accounts in a single domain only or in multiple domains. Determine where you are going to place backup domain controllers for your user account domains in order to provide efficient user logon authentication or redundancy. Decide whether you are going to place your Windows NT member servers (a server that is not a domain controller but is participating in a domain) into a resource domain. There are some very real limits on the number of user accounts and machines within a domain, and if your organization is very large, you must consider those limits.
This topic is well covered in many places, and you should review this thoroughly. The most important thing to remember is that changing the domain model after the fact is extremely difficult. Not only do you have to set up new domain controllers and move servers accordingly, but you also have to adjust your clients that do domain logons, which could be all of them. You will also have to re-permit shares accordingly. Therefore, you might have thousands of machines that have to be changed and hundreds of shares to re-permit.
Each of your Windows NT Servers can fulfill a particular role or roles in addition to fulfilling one of the standard NT Server domain roles such as primary domain controller, backup domain controller, or member server. It could be a server for a custom application that you use in your organization or perhaps it is a file and print server or both. If you have the luxury of being able to acquire identical hardware for all the machines fulfilling a particular role, the advantages in a large-scale environment cannot be overstated. You will not only see benefits during installation but also when supporting the machines long afterward. During installation, the more you can reduce the number of hardware-specific customizations required from one machine to the next, the easier it is to automate the installation process. After the NT Servers are up and running, the use of equivalent hardware means that software and driver updates can be applied to all of your machines with very few surprises.
You could also standardize hardware for things such as disk drives, tape drives, SCSI controllers, and other significant components. This enables you to ensure that the best hardware is used and minimizes the issues related to device drivers. It also makes it more practical to have spares available to swap into place if anything breaks. Finally, with standardized tape drives, you will have a standard for tapes. Therefore, data can be backed up on one machine and restored on another, or tapes can be shared among sites.
Each of your Windows NT Servers will have to have a unique name and network address assigned to it and so will all of the workstations that connect to those servers. Several things can really help:
Use a Naming Convention. Before installing your Windows NT Servers, decide on a naming convention for them. In a large-scale NT Server environment in which you have lots of servers to administer, name your servers consistently. Consider reflecting the role of the server, or perhaps its geographic location in your naming convention. Publish the naming convention for all of the NT Server administrators in your organization to use.
A useful naming convention enables you to quickly remember what a computer is doing when you see its name. For instance, if you saw a computer called "NYC_SQLSERVER," you would know that this is a server in New York City that is providing SQL Server databases. Therefore, when you're using Server Manager and you see NYC_SQLSERVER (among 300 other servers) grayed out during the middle of a work day, you know immediately that you should do some further investigating. If, instead, this machine were called "MYBABY" or "GRUMPY" or "NEWMACHINE," you would have no idea whether this machine's being offline was significant.
When designing your naming convention, try to anticipate future needs. If you're going to have 120 sites, but you reserve 2 characters in the computer names for site codes, then you're going to have to resort to pretty cryptic site codes for some of the sites. This will then force administrators to refer to tables to translate site codes to site names, which is what you're trying to avoid by introducing a naming convention.
Minimize Network Protocols. You should consider minimizing the number of network protocols that you support. Each will have its own addressing scheme and thus complicate the naming convention and network address tracking problem. Protocols also have network overhead of their own, to update browsing tables, transfer routing information, keep connections alive, and to keep track of computers. Therefore, the fewer protocols you have, the less network overhead you'll have. This will free up network capacity for productive work.
You might want to consider using TCP/IP as your primary protocol. It is an efficient protocol for both LAN and WAN activity but also enables connection to the Internet, and many tools and facilities are available for use with TCP/IP.
Having a second protocol available is also a good idea. Any given protocol can break at any time, for various reasons. Duplicate addresses can occur, files can become corrupted, routers can break, and so on. By having a second protocol, problems caused by failures might not effect the second protocol. Therefore, you can use the second protocol to get to the server to make changes remotely or use it from the server to get to files that are available on the network that enable you to fix the problem. For much the same reason, many administrators of large-scale environments also like to have a modem connected to their servers, with TCP/IP configured to use it. That way, if there are problems with a server's networking, you might be able to dial into it and make the necessary changes.
DHCP. TCP/IP is now the most popular networking protocol, for various reasons. Fortunately, one of TCP/IP's strengths is that it has a good mechanism for automatically managing addresses--DHCP. Although DHCP eliminates that manual burden, even in small NT Server environments, it is an even greater boon in a large-scale NT Server environment, where you can have dozens or hundreds of servers, and probably hundreds, or perhaps thousands of workstations. Don't waste countless hours trying to maintain all those addresses manually. Use the DHCP server included with NT Server 4.0. Its easy to use, it can be administered from anywhere, and it works well.
Not only will DHCP provide your servers and clients with TCP/IP addresses, but also related information, such as subnet masks, routers, DNS servers, WINS servers, and so on. This is beneficial to you not only in the sense of reducing the setup task on each machine, but also in terms of giving you flexibility to adjust your environment. If you add a secondary WINS server, you only have to change the DHCP scopes accordingly. You don't have to go to every machine to make this change effective. Similarly, you can be confident that the correct value is used on every machine, because you've specified the correct value in your DHCP scopes--there will be no human errors.
The other traditional reason to use DHCP is for mobile workers, who can move their laptop between sites. This is especially likely to be true in your large-scale environment, in which you have many users and likely have multiple sites.
The only times you won't want to use DHCP is for machines that shouldn't change their TCP/IP addresses dynamically. This would be true of the DHCP servers themselves, or servers that have clients that cannot use WINS, and thus use DNS or hosts files for name to address resolution. Such clients would include UNIX workstations or Macintoshes. However, this issue can be mitigated by integrating WINS and DNS.
WINS. If you are using DHCP to dynamically provide TCP/IP addresses to the machines in your organization, then you really should use WINS to have a current list of TCP/IP addresses associated with each of the computer names. DHCP and WINS work hand- in-hand quite nicely. In large-scale NT Server environments, in which sites are often located across wide-area network links, and you have dynamic addressing at each site, there really is no other viable way to maintain a centrally accessible list. In addition, with NT Server 4.0, if you are using the bundled DNS server, then you can configure it to query the WINS database to resolve names that aren't otherwise found in the DNS namespace. That means that any machine or operating system capable of performing a DNS lookup can resolve the names of machines in the WINS database, as long as that machine is configured to use the NT DNS server as its name server.
Don't use too many WINS servers initially. Use two WINS servers to start out with. That way, one server can be the primary WINS server, and it can be configured to replicate its data to the other, secondary, WINS server, providing some redundancy. If you have some very slow links in your organization, you might give some thought to placing another WINS server on the far side of a slow network link and configuring the machines on the far side of the link to use the WINS server closest to them. The data can be replicated between the WINS servers during non-peak hours if desired. The thing to keep in mind is that the more WINS server you have, the less current the data will be on each one. Each machine only registers and de-registers itself with a single WINS server, the one that the machine considers its primary. The other WINS servers only have the updated information after replication has taken place. Additional WINS servers will also mean additional network activity when the replications occur, which can be quite significant in a large environment.
Establishing software standards will also help to make it practical to manage many Windows NT Servers. The tighter these standards are, the fewer the variables with which you have to deal. However, other system administrators and the users themselves might wish for changes faster than you can accommodate them. Therefore, compromises are inevitable.
You will particularly want to standardize on which versions of Windows NT itself you are prepared to support, including which service packs. Each version, and sometimes service packs, will have its own issues. Ideally, when a new version becomes available, you will test it thoroughly, document any relevant changes, and communicate those to the appropriate individuals. Only then will it be deployed to your servers. This way you won't be introducing changes that will cause problems on production machines that users depend on. You also won't have any surprise phone calls in the middle of the night, asking you to fix problems on a configuration that you've never seen before.
In addition to the versions of the operating system, you might also want to set standards in terms of configuration. Which servers should offer FTP services, considering the security concerns that FTP introduces? Which servers should offer WWW services, considering the network load this can introduce? Standards can also be appropriate for issues such as which disks are used for data, how directories are named, and so on. Such standards ensure consistency in administration. That way, no matter who makes changes on a machine, they will be understandable by everyone else who might work on the machine at other times.
You might also consider setting standards in terms of what utilities are available on each server. When you go to work on any of your many NT Servers, you might find that you'll need certain software tools to do your job. If they aren't available, you'll have to waste time making arrangements.
With so many servers, workstations, and users involved in your environment, you will have some serious issues to deal with. Security, reliability, backups, and so forth must all be done in a professional manner. Otherwise, the wrong people might see information or data or it may be lost due to disk failures or users might be unable to use their applications for hours or days. Downtimes can be very expensive, considering that many users can be effected. Considering that each user might typically be paid 10 to 40 dollars per hour, if you have even 200 unproductive users, this will cause 2,000 to 8,000 dollars per hour, up to 64,000 dollars per day.
To run things in a professional manner, you should define policies on all significant issues, and document procedures that are consistent with those policies. Ideally, levels of management with sufficient authority should support policies to ensure that they are followed. However, you should also work with all the effected parties, so that you don't miss any issues, and also so that there is some level of consensus. Your coworkers are much more likely to follow the policies and procedures if they had a hand in developing them.
The issues that policies should be set on will vary by organization. The requirements for security, the manpower available, the size, and even the culture of an organization will impact how willing it is to invest in defining policies, and then how well it will follow them. However, here are a few examples of issues to consider setting policies for:
Procedures go hand-in-hand with policies. Standardized procedures ensure that everyone does all steps involved in important tasks that are done on the servers. For instance, it is easy enough to back up all disks on a server to tape, but it is important to label the tapes in a meaningful fashion for everyone, and to put them in a place where everyone can find them. That way, if the person that did a backup goes on vacation, the right tapes can be found and used to do a restore while he is gone.
One procedure that you might want to standardize is keeping a change log for each server. A change log is used to record all changes to the machine. It can then be referred to by anyone who might later investigate issues at that machine. If the change log is kept in electronic form (as a text file at the top of drive C:, for instance), then it can even be referred to remotely. Change logs are important in a large environment because it is likely that you will not only have many servers but also many administrators. Therefore, different administrators will make changes to any given server at various times. Sometimes it is important to know what changes have occurred in the past. By referring to the change log, you can always find out what has happened in the past.
In a large-scale Windows NT Server environment, the sheer number of NT Servers raises two issues related to setting them up. The first issue is the significant amount of time and effort involved in setting up a large number of servers. The second issue is the need to maintain consistency among each of the machines that will be fulfilling the same role, to avoid support issues later on. Automating the installation process as much as possible helps resolve both issues.
You can use answer files to provide consistent answers to many of the NT Server installation questions. You can use answer files for domain controllers, member servers, and for workgroup members, but you will need different answer files for each.
Another option for automating NT Server upgrades is Microsoft's Systems Management Server (SMS). If you have SMS available, you can use it in conjunction with an answer file to upgrade your NT Servers to a new version. SMS provides the most flexibility when it comes to automated installations but requires that the SMS infrastructure be in place. Refer to Chapter 25, "Administering an Enterprise with SMS," for more information about these possibilities.
When you receive a bunch of computers to set up as servers, you need to unpack them, physically set them up, and then boot them up to enable the installation process to be done. As a seasoned Windows NT professional, you certainly know how to set up machines and Windows NT itself. However, when you receive 30 machines all at once, the job is a big one, easily taking days.
You can minimize this activity by only unpacking the computers themselves (the monitors, keyboards, and so on are all the same). Once the computers are booted, you will start the setup process. By using an "answer file," you can reduce the amount of work you have to do, especially if you also use "Uniqueness Database Files" to specify the details that make one machine different from another.
Using an Answer File. Windows NT Server 4.0 enables you to specify an answer file to use when beginning the installation process. You can do that by specifying the /u:answer.txt switch on the command line for WINNT32.EXE (for an upgrade), or WINNT.EXE (for a new install). As the name implies, an answer file provides answers to questions that would normally be asked during the NT Server installation process. The use of an answer file enables the setup process to run unattended.
An answer file is just a text file, so you can create one from scratch, but it is much easier if you have one to use as a template. If you have the NT Server 4.0 Resource Kit, it provides a utility called "Setup Manager" that will enable you to specify most of the answers interactively, and then it will generate an answer file for you.
Listing 8.1 shows a sample answer file called myanswer.txt. This is for a backup domain controller called MACH1 on a domain called XYZDOMAIN. It specifies that the network card should be auto-detected.
[Unattended] OemPreinstall = yes NoWaitAfterTextMode = 0 NoWaitAfterGUIMode = 0 FileSystem = LeaveAlone ExtendOEMPartition = 0 ConfirmHardware = no NtUpgrade = no Win31Upgrade = no TargetPath = WINNT OverwriteOemFilesOnUpgrade = no [UserData] FullName = ěHumpty Dumptyî OrgName = ěAnswerfiles Incî ComputerName = MACH1 ProductId = ěXXXXXX-XXXXî [GuiUnattended] OemSkipWelcome = 0 OEMBlankAdminPassword = 0 TimeZone = ě(GMT-05:00) Eastern Time (US & Canada)î AdvServerType = LANSECNT [LicenseFilePrintData] AutoMode = PerServer AutoUsers = 200 [Display] ConfigureAtLogon = 0 BitsPerPel = 8 XResolution = 640 YResolution = 480 VRefresh = 60 AutoConfirm = 1 [Network] DetectAdapters = ěî InstallProtocols = ProtocolsSection InstallInternetServer = InternetParamSection InstallDC = XYZDOMAIN CreateComputerAccount = HUMPTY, DUMPTY [ProtocolsSection] TC = TCParamSection [TCParamSection] DHCP = no IPAddress = 123.123.123.123 Subnet = 255.255.255.0 Gateway = 123.123.123.1 DNSServer = 123.123.123.2, 123.123.123.3 WINSPrimary = 123.123.123.2 WINSSecondary = 123.123.123.3 DNSName = humpty [InternetParamSection] InstallDir = C:\Inetsrv InstallINETSTP = 1 InstallWWW = 1 WWWRoot = C:\Inetsrv\WWWRoot InstallGOPHER = 1 GopherRoot = C:\Inetsrv\GopherRoot InstallFTP = 1 FTPRoot = C:\Inetsrv\FTPRoot InstallADMIN = 1 InstallW3SAMP = 1 InstallHTMLA = 1
Uniqueness Database File (UDF). If you were to use the exact same answer file on all of your NT Servers, you would end up with completely identical machines, which is not usually what you want. That is why NT Server 4.0 also provides a way to use an answer file, yet override some of the answers in that answer file. The overrides are accom- plished by specifying the name of a Uniqueness Database File (UDF) with the /udf:unique_id,udf_file option on the WINNT.EXE or WINNT32.EXE command line.
Listing 8.2 is a sample UDF file named C:\SAMPLE.UDF. When setting up the MACH2 machine, you would specify the answer file above by placing /u:myanswer.txt on the WINNT.EXE or WINNT32.EXE command line. You would also specify /udf:mothergoose,C:\SAMPLE.UDF. In this particular case, the Unique ID mothergoose is used, and parts of the [UserData] and [TCParamSection] sections are overridden.
[UniqueIds] mothergoose = UserData,TCParamSection [mothergoose:UserData] FullName = ěMother Gooseî OrgName = ěAnswerfiles Incî ComputerName = MACH2 ProductId = ěXXXXXX-XXXXî [mothergoose:TCParamSection] IPAddress = 123.123.123.124 WINSSecondary =
Not all the TCP parameters from the answer file are overridden in this example--just IPAddress and WINSSecondary. Because WINSSecondary has no value specified to the right of the equal sign in the UDF, the default setup value is used, not the value specified in the answer file. You can effectively disable a setting in the answer file this way, without having to provide a replacement value in the UDF.
Note that even though this sample only has one Unique ID in it called mothergoose, a single UDF can have many Unique IDs and corresponding replacement sections.
You might benefit installing from a customized installation of NT when you have a large number of NT Servers. A customized installation is one in which you add the installation of additional components to the NT Server installation process. This ensures that the components will be available on all of your NT Servers, without the possibility of forgetting to add them afterward. In addition to being useful for including additional utilities on all of your NT Servers, it can also be used to include third-party or updated drivers for hardware that is not already supported by the standard NT Server installation process. There is a fair bit of preparatory work and testing involved in customizing the installation, so you should weigh the alternatives carefully before proceeding. For third-party or updated hardware drivers you might not have any alternative, but for rolling out additional software components, nothing can really compare with SMS. SMS gives you more control over the process than any other method. See Chapter 25, "Administering an Enterprise with SMS," for more information.
If you want to add components to the NT Server installation process, you must place the NT Distribution tree for your hardware platforms onto a disk to which you have write access. After you do that, you can configure a special directory, called $OEM$, as appropriate for your needs. It will have various possible components to specify particular details.
You will need a file called $OEM$\Cmdlines.txt, containing a series of command lines that will be executed in sequence during the NT Server installation. Each of the commands should be enclosed in quotation marks and placed below an opening "[Commands]" section marker.
Files in the $OEM$\$$ directory will go into the %SYSTEMROOT% directory tree. Not only can you use this directory to add your own files into the %SYSTEMROOT% subdirectories, you can also replace NT Distribution files with new versions by placing the new versions into the appropriate subdirectory of $OEM$\$$.
One example of a possible use for this subdirectory is for the depositing of an LMHOSTS file onto the installed NT Server system. You need to create the dir0ectory tree $OEM$\ $$\SYSTEM32\DRIVERS\ETC and place an LMHOSTS file into it. After installation, a copy of the LMHOSTS file would reside in %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC.
Use single-letter subdirectory names, as in $OEM$\drive, to store files that need to be copied to a particular directory on a particular drive during the installation process. For example, if you want to ensure that each of your servers includes a file called C:\POLICIES.TXT, you should create $OEM$\C and place a copy of POLICIES.TXT into it. Executable files can be placed into this tree also, but if the installation of the executable file requires that a command-line utility be invoked, you need to place the command line for that installation utility into $OEM$\Cmdlines.txt file.
A subdirectory called $OEM$\NET can contain subdirectories for each network component you want to include in the installation process.
The NT Server installation process can be started from NT Server by using WINNT32.EXE or from MSDOS by using WINNT.EXE, so all file names must follow the 8.3 naming convention. The files can be automatically renamed with long file names after arriving at their destination, however, by including a file called $$RENAME.TXT in each subdirectory of $OEM$ that requires files to be renamed. The $$RENAME.TXT file lists the long name equivalent for each short name that requires renaming.
A $OEM$\Textmode directory can be used for any components that must be in place in order for the system to be able to boot into the graphical mode setup. You need to use this directory only if your hardware requires a special device driver that is not included in the NT distribution, in order for the setup to proceed. The use of this directory for driver files also requires that an accompanying TXTSETUP.OEM file be included. For Intel architecture NT Server machines, you must place a reference to TXTSETUP.OEM into the [OEMBootFiles] section of your answer file. You must also place a reference for each file listed in TXTSETUP.OEM into the [OEMBootFiles] section of your answer file, as well.
If you have multiple hard disk drives in your Windows NT Server machine, you should consider having your Windows NT 4.0 installation reside on a different disk than that containing your machine's Master Boot Record. In addition, install a second, redundant copy of Windows NT Server onto the disk that does contain the Master Boot Record so that you can quickly get a copy of NT Server booted in an emergency. That can really pay off in terms of reliability and quickly getting a server running following a hard disk failure, because it enables you to perform a restore from backup without having to reinstall NT Server. Consider Figure 8.1 for a moment.
This is the disk layout for optimum reliability
A disk layout such as that shown in Figure 8.1 can be a real advantage in a large-scale NT Server environment for several reasons:
Create an NT Boot Floppy. You can use a boot floppy to start a Windows NT Server computer and load a copy of Windows NT server that is already resident on one of your hard disk drives. This can be useful in returning the machine to a functional state if the bootable hard disk fails to boot for any of a number of reasons. Use the following steps to create an NT Boot floppy disk:
2. Determine the device driver for your hard disk drive. This can be done by checking the Scsi Port 0 Driver value in the Registry key HKEY_LOCAL_MACHINE\ HARDWARE\DeviceMap\Scsi. Append .SYS to the name to get the complete file name.
3. Copy the device driver determined in Step 2 from %SystemRoot%\SYSTEM32\ DRIVERS to the root directory of the floppy disk, and rename it Ntbootdd.sys there.
4. Copy NTLDR., Boot.ini, Ntdetect.com, and Bootsect.dos from the root of your hard disk drive to the floppy disk.
TIP: You will occasionally install new software or a driver for a new piece of hardware and find yourself prompted for the location of the NT Server 4.0 distribution files. It is quite useful to have these files available to your server at all times, without having to track down the CD-ROM. If you have enough disk space to spare, place a copy of the appropriate Windows NT Server 4.0 distribution directory tree for your hardware platform right into a subdirectory on one of your hard disks. If disk space is lacking, place a copy onto one of your servers and offer it as a network share, making it available to all servers at that location. You will be able to add NT Server components and drivers later on just by specifying the location of the distribution files.If you do place a copy of the distribution onto a hard disk, also place a copy of the latest NT Server 4.0 service pack that you have applied there, too. That's because service packs should always be re-applied after adding any NT Server components or drivers from the original NT Server distribution.
If you are setting up multiple Windows NT servers, consider speeding the process by duplicating disks. As discussed in the previous sections, you might want to partition each disk in a particular fashion, set up a FAT partition, have a source of Windows NT's installation files available for future changes or re-installs, and even have a source of other installation files (device drivers, resource kits, other applications, and so on) available. You could even start the Windows NT installation up to the point at which it reboots into the graphical mode. After all this is set up, you can then copy the disk as it exists at this state to other disks, to be used in the other servers. Copying the whole disks will be much faster than doing all this set up, and you won't have to worry about missing a step.
The most popular way to make disk copies of this sort is to use a program named Ghost, available from http://www.ghostsoft.com. Ghost copies the whole disk, including partition information. You can also easily set it up to work from a diskette that is used to boot the destination server onto the network, and then the copy can be done from a network share on another server.
It would be ideal to set the whole server up, and then use Ghost to replicate it to other servers. However, Windows NT complicates this process by having unique security identifiers (SIDs) for each machine. Duplicating the whole system would also duplicate the SIDs, which does not work. Therefore, the final parts of the set up must be done in the usual fashion.
Sooner or later, it will be necessary to perform administrative tasks on your NT Servers, even though they might be scattered throughout many locations. Fortunately, Windows NT was designed with this capability in mind. Many of the standard administration tools provided with Windows NT Server use remote procedure calls (RPC) to split their work between the machine where the tool is being used and the machine upon which the tool is acting.
In a large-scale Windows NT Server environment, remote administration is a tremendous because you can execute the management tool on any NT Server 4.0 server or workstation and use it to administer a server located any place that is reachable over the network. If you have many NT Servers at your site, that means that you can easily administer each of them from a single machine, including your own NT Workstation. If you have many sites in your organization, the capability to administer remote NT Servers can mean real savings in travel time and costs any time that a trip to the site can be avoided. Even if an NT Server is not directly reachable over the network (by design or by an outage), with a little advance preparation, you can configure it with a dial-up line, modem, and remote access services (RAS) to perform remote administration. Mind you, over a WAN link, or especially a RAS link, the administration tools will be significantly slower than usual, but with a little patience you will find them quite reasonable.
Many of the vendors of server hardware take their business very seriously. For this reason, they not only build their servers to maximize throughput but also to be as reliable as possible. On a small scale, you might be able to use any old desktop machine as a Windows NT server. On a large scale, it is much more likely that you'll need large servers. And because you'll have many users, they must be very reliable. Therefore, one of these serious (although more expensive) servers might be appropriate.
Server machines from serious vendors come with management tools to maximize their reliability. Such tools alert you to impending failures of disks and prevent similar problems.
Similarly, third-party vendors of backup programs take their jobs very seriously, and their products provide facilities that you will find very valuable as an administrator of a large-scale Windows NT environment. In particular, you will be able to back up all servers at a site to one server, without having to waste disk space on that server for intermediate storage. You will also be able to easily monitor the backups at all local and remote servers. Considering the significance of backups, such products are well worth investigating.
Application management in a large environment varies according to the application. BackOffice applications such as SQL Server or SMS have administration tools that are specifically designed for managing multiple servers, even at a distance. Other tools might or might not have such tools. If not, you may have to rely on remote control facilities, discussed later in this chapter, to administer these applications. However, for true client/server applications, it is usually academic whether the server is remote or not - the tools work equally well either way (possibly just a little slower).
You can use Server Manager to start, or stop services on any NT Server. Choose Computer, Select Domain to select a domain or particular NT Server to administer. To administer a particular NT Server that is not part of your domain, specify the machine name, preceded by the usual two back-slashes that are used to denote a machine name. Highlight the appropriate machine in the list, and choose Computer/Services. You can stop, pause, or start the service. You can also specify a particular user account for the service to execute under.
You also can use Server Manager to create, or delete file shares on any NT Server. Choose the Select Domain item from the Computer menu to select a domain or particular NT Server to administer. To administer a particular NT Server that is not part of your domain, specify the machine name, preceded by the usual two back-slashes that are used to denote a machine name. Highlight the appropriate machine in the list, and choose Computer, Shared Directories. Select New Share to add a share, Stop Sharing to remove a share, or choose Properties to modify an existing share.
If the path for a new share does not already exist, you can create it from a command prompt or Explorer by using a share that already exists and that contains the directory tree in question. Hidden shares are created for all disks by Windows NT by default, and they point to the top-level directory on each of those disks. Therefore, you can use them to create any directory. For instance, you could enter MKDIR Error! Bookmark not defined., and then offer NEWDIR as a share by using Server Manager.
User Manager for Domains can be used to create, modify, or delete user accounts or groups on any NT Server or domain. Choose User, Select Domain to select a domain or machine to administer. To administer a particular NT Server, precede the machine name with the usual two back-slashes that are used to denote a machine name. To administer a domain, just enter the domain name, and the utility will attempt to connect to the primary domain controller for the domain.
You might want to create users or groups on a particular server (as opposed to the whole domain) to allow people to have special rights on that server. This might be appropriate if the server is bought by a particular department or only used by a small group of power users. Letting them administer the server saves you from doing it, but you won't want to give them privileges for all servers.
In a large environment, you'll come to have a huge number of user accounts and a large number of groups. As people move on, change names, and so forth, you'll have many orphaned accounts (in other words, accounts that no one ever uses any more). They should be identified and deleted, if only to keep your systems manageable. To readily identify accounts for this or other reasons, you need the capability to generate reports on old accounts and similar details. A shareware program, called DumpACL, is available for this purpose at http://www.somarsoft.com.
Occasionally you will find it necessary to reboot a remote server. The base distribution of NT Server does not provide a utility for remotely shutting down another server, but the Windows NT Server Resource Kit does provide SHUTDOWN.EXE. As in the following example, you can provide the machine name, tell it whether to reboot afterward, how long to delay prior to shutting down, and confirm that you really do mean it.
SHUTDOWN Error! Bookmark not defined. /R /T:20 /Y
The resource kit also includes a graphical version of this utility, called SHUTGUI.EXE.
DHCP, WINS, RAS, Services for Macintosh, Policies, and Licensing are all things that are usually set up at the time the servers are set up and then forgotten. You need to make changes on occasion, however, or check them to ensure that they're working properly. The standard tools for each of these are intended to be used with multiple servers, including remote servers.
On servers, these tools will be set up if you install the corresponding services. On Windows NT workstations, you can use the appropriate setup program in the Clients directory of the Windows NT Server CD to set up tools for these services, along with the more traditional tools, such as User Manager. The only tool not provided is the License Manager. The License Manager tool must be manually set up on Windows NT Workstations by copying LLSMGR.HLP, LLSMGR.EXE, and LLSRPC.DLL from a Windows NT Server.
The Windows NT Resource Kit also includes DHCP and WINS command-line tools so that you can work with them by using batch files, if need be.
One of the more dramatic changes with version 4.0 of Windows NT is the inclusion of the user interface from Windows 95. This includes the changes to the interface for managing printers. Instead of having a separate Print Manager program, Windows NT 4.0 has a Printers folder.
The Printers folder on your local server or workstation cannot be used to control remote servers. However, if you browse to the remote server, by whatever means you like, you will find that it has a shared Printers pseudo-folder available. For instance, you can use the Start menu's Run option and enter \\server_name. When the window of the servers shares appears, there will be a folder for Printers, which you can double-click to see the currently existing printers, or to add a printer. You can do any of the operations you might require, except for managing ports. If you need to manage ports on the remote server, you will have to either visit the site or use a remote control program, such as the one included with SMS.
NOTE: The remote Printers folder is not a true shared folder. Therefore, you cannot enter \\server_name\Printers at the Run prompt.
The Windows NT registry is intended as the central repository of configuration information. Therefore, if you need to change a server or its applications, you might be able to do so by making a change to its registry. This might be appropriate for obscure values that can't be changed by any of the programs that are provided. It might also be appropriate if the programs used to change values do not have a remote option. However, there might be multiple changes required (to registry entries or elsewhere) with any given change, and so by manually making changes to registry entries, you might be missing necessary related changes.
The REGEDT32.EXE utility that comes with the base NT Server 4.0 product can be used with a remote NT Server to change values in the remote registry. Choose Registry/Select Computer to specify the name of the machine. As always, be careful!
If a change is required on many servers, you might want to consider writing a console-mode C program to change the registry appropriately. That way, you can submit the program to all the servers and have the change done automatically and simultaneously on all servers. Programs to change registry entries can be tricky, especially for values that do not have constant keys. Networking protocols, for instance, have most of their registry entries under registry keys that will have different names, depending on which LANA is assigned to the protocol. Therefore, appropriate checks must be done by the program, and you must test the program thoroughly to ensure that the change is always done correctly.
The NT Server AT command can be used to schedule a command line to execute at specific times on local or remote NT Servers. You can schedule a command to run once at a specific time or to recur. There is also a variation in the NT Server Resource Kit called WINAT.EXE that provides a graphical interface to similar functionality. Both make use of the Schedule service on the remote NT Server. The AT command requires that the Schedule service already be started on the NT Server. The WINAT utility enables you to start the service if it is not already running. You can also use Server Manager.
NOTE: By default, Windows NT services, including the Schedule service, log on by using the built-in account named System. The System account does not have access to the network, so if you want to execute commands that rely on network connectivity, you must change the Schedule service to run under a domain account. Refer to the preceding "Service Administration" section to change the service account on a remote computer.
When remotely executing commands with the Schedule service, you will want to be able to specify the time that the job runs, confident that your idea of the time is the same as the server's. It's easy for time to get out of synch by minutes between servers, but they could also be mistakenly set to be off by hours or days. This issue can also be important to services that work across multiple services, such as SQL Server replication.
The most efficient way to keep the time synchronized on all of your NT servers is to use a time service on each one. The time service synchronizes the time on each NT Server with that of another machine of your choosing. There is a time service included with the NT Server Resource Kit. For example, to set up automatic synchronization with the PDC named primdc:
2. In the [TimeServ] section of %SYSTEMROOT%\TIMESERV.INI, change type to equal PRIMARY, set PrimarySource to equal the name of the server supplying the time, Error! Bookmark not defined. in this example, and set timesource to equal "yes."
3. At the command prompt, issue this command:
timeserv -automatic
TIP: To administer a machine or domain by using many of the tools discussed previously, you must have a set of valid credentials on the machine or domain controller. If the machine you want to administer is not part of the domain that you're currently logged on to or is not part of a domain that trusts your logon domain, you might need to establish a set of credentials on the machine. That can be done by logging on to a share on the machine by using the machine's Administrator account.NET USE Error! Bookmark not defined. /user:machine\Administrator password
Once completed successfully, subsequent connections and communications with that particular machine will use those credentials until that session is terminated.
There can be occasions in which you need to do something on an NT Server, and there just isn't any sort of remote administration tool to accomplish the task. The task requires that you respond to a series of graphical prompts, so using the Schedule service and the AT command is not an option. You might be able to create a package for the task with SMS and use that to roll it out, but that is often overkill and requires too much preparation time for the little one-shot tweaks. For those "last resort" situations, there are remote control utilities on the market. SMS includes one, and there are several third-party products, as well. Remote control utilities send a copy of the screen display of a target machine into a window on another viewing machine and enable keyboard and mouse input from the viewing machine to be sent to the target machine. You can take over the target machine and control it just as if you were there, although the screen refreshes much more slowly. There are very few tasks that you can't do with a remote control utility. Some of the remote control utilities require that you dial-up the target server via a modem, and others work over a TCP/IP network. Either way, a remote control utility might be just what you need to accomplish something remotely, that would otherwise require a site-visit (see Figure 8.2).
This is SMS Remote Control of an NT Server.
Remote control is not necessarily something that you plan on doing on a regular basis. Screen updates require a lot of bandwidth, and during the day most of your bandwidth may already be consumed by production applications. In an emergency, however, remote control can be well worthwhile. If bandwidth is an issue, you can plan on doing your remote control tasks after hours, or at least at lunch time. If most of the bandwidth is available, a 56Kbps WAN link provides reasonable remote control responsiveness, and a 19.2 link is functional.
You need to be able to ensure that your Windows NT Servers are up and running, that they have ample disk space available, and that the hardware on them is functioning correctly. As anyone that has worked with NT Server can attest to, NT has very detailed event recording capability built right into the base operating system. The Event Viewer tool enables you to review the event logs on any server, from anywhere on the network (see Figure 8.3).
This is the NT Event Viewer--System Event.
When you're responsible for administration on a significant number of NT Servers, however, you might find it much too time-consuming to check the event logs on each server on a regular basis.
In large-scale NT Server environments, you will find it advantageous for the machines to tell you when things are not quite right, whenever possible. Alerts are a standard feature of Windows NT Server. The alert facility requires two services to be running on the NT Server that is initiating the alert: the Alerter service, and the Messenger service. You can specify a list of names that should receive alerts for each NT Server, and you should add a messaging name for the appropriate, responsible individuals to the list on each one. The messaging name can be the NT username (which is automatically added during a successful logon), the machine name (which is added when the machine starts up), or any name registered by using NET NAME xxxxx after, or during, logon (see Figure 8.4).
Add a new name to the list of Alert recipients.
2. Double-click the target server in the list.
3. Click the Alerts button, and add names to the list.
NOTE: Alerts will only work over a WAN link if you're using a WINS server for all of your computers or have added special entries to the LMHOSTS file on each NT Server from which you want to receive alerts.
The Windows NT Performance Monitor is a great tool for monitoring a huge variety of system and application statistics. It also works with remote servers. It will even monitor multiple servers at the same time. If the servers are remote (over slow WAN links, for instance) then you might want to consider decreasing the speed at which updates are displayed to decrease the impact on the WAN.
One of the quickest and simplest tools in your arsenal for testing whether a particular NT Server is running is to try a simple TCP/IP ping test to the server. If you are unsuccessful in getting your ping to succeed, try to ping the default gateway (router) for the site. If you can't ping that either, then chances are pretty good that some sort of network problem is to blame. The problem could be at the machine from which you are executing the ping, but that possibility can be eliminated if you are able to successfully ping machines at other locations.
A freeware program is available that routinely pings any servers you tell it to and provides a nice graphical display of the results. It's called Big Brother, and is available at http://www.klever.net. By using this tool, you can readily see servers that are not available. It also makes it clear which servers are at the end of unreliable or swamped network links. The display makes it obvious if all pings are not getting through. The fact that any get through means that the server is up, but if some pings are failing, then there is probably a problem with the network link.
Once again, SMS might be the ultimate management tool. By using its inventory and reporting capabilities, you can keep track of how much disk space is being consumed on your machines, what software has been installed, and lots of other bits of information that an NT Server administrator might find useful. See Chapter 25, "Administering an Enterprise with SMS," for more information.
There are several useful tools in the NT Server Resource Kit that can help you monitor your servers. One of the most useful is DOMMON.EXE, which monitors your domain to ensure that your primary and backup domain controllers are reachable and synchronizing correctly. Another is NETWATCH.EXE, which dynamically displays connections between workstations and specified NT Servers.
Occasionally you will need to install a new software package or update an existing package on most or all of your many Windows NT Servers. You will also need to update the NT Server operating system itself or apply a service pack to it to correct a problem that you encounter.
Before initiating a software update on dozens or hundreds of machines, take a moment to consider the value of doing so. Weigh the expected new functionality carefully against the amount of preparation time, rollout time, and bandwidth consumption involved in implementing the update. Consider saving several small updates, so that you only need to go through the motions once.
After you determine the need to do an update, you should then test, test, and test again. When you have many NT Servers, the need to thoroughly test each blanket update becomes even more important. There is no joy in attempting to uninstall something on several dozen or several hundred servers. If the problems caused by an update are serious enough to render the servers unreachable, you could be faced with the prospect of having someone visit each server to rectify the situation. If that means a lot of travel time, the costs can skyrocket, without even taking the loss of service into consideration. That is a situation that no administrator wants to find himself in, and jobs have been lost for less.
You might consider staging the update so that you don't do all servers at the same time. This might not be possible, if the software must cooperate among all the servers and the different versions are not compatible with each other. If it is possible, however, there are several advantages. For one thing, the first installs can serve as the next level of testing, to ensure that you didn't miss anything in your earlier testing. If you did miss anything, then you're only fixing problems on a few servers. And you're only tying up a few WAN links and servers, if the update has a large impact on them.
Even if the updates must be done on all servers at once, you might be able to at least stage parts of the process, distribute the installation software over the previous weeks, and make some of the related changes at your convenience. Ultimately, the important thing is to plan ahead as much as possible.
Here are the general steps necessary to accomplish any massive update, regardless of the tools that you use to do so:
These steps closely describe what SMS package delivery is all about. If you have SMS in your organization, use it to accomplish your updates, and you likely won't regret it.
If you don't have SMS, you need an alternative method. Creating the update package is where most of your effort will probably go. Your goal is to try and find a way to get to the point that the installation can be started by a single command line and require no further input after that. Some products provide an easy way to do that, but many don't, and you might have to get creative.
After you have an unattended installation method figured out, you need to copy the installation package to each of the holding locations that you have decided on so that the installation can begin on the NT Servers. Copying the files is a matter of perseverance and network bandwidth. Here are a few suggestions to help you:
Initiating the Install. After you have an unattended installation method, and you have the packages in place, you will want to schedule the installation, you can use the NT Server AT command to trigger it. You can copy a BAT file with the necessary commands onto the target machine and specify the exact time that the installation is to commence.
AT \\machine 18:00 /interactive "doinstal.bat"
If you want the installation to begin the next time someone interactively logs on to the machine, then you can add the command to the appropriate user's logon script.
No matter which method you use, the commands contained within the .BAT file can be redirected to an appropriate log file so that you can see the results of each one. Redirect the first command in the file with >, and all subsequent commands with >> so that all output is appended to the end of the file.
Monitoring the Install. You will want to verify that the installs start when they should, and that they are proceeding smoothly. This is especially true with the first installs. You can monitor the install by using Performance Manager or by watching for changes (such as directories being created, services being installed, and so on). When the install seems to be complete, the ultimate test is to try to actually use the updated software to ensure that it is working properly.
If you're updating software on many servers, you might want to get the installs to do a final step to send an acknowledgement to you that the job is complete. This can be an automatically sent e-mail, or copying a log file or even a scratch file to a known directory on a central server or workstation. As long as each acknowledgment is clearly marked as to its originating server, it will be clear which installs have probably succeeded. It might also be clear which ones have failed. If you're updating 50 servers, and you receive 49 acknowledgements, you can scan through them to find the problematic one.
© Copyright, Macmillan Computer Publishing. All rights reserved.