|
17Remote AdministrationSo far, you have seen a number of wonderful administration tools that you can use from the Windows NT 4.0 server's desktop. The problem in most environments, however, is that you are not always sitting at the server console. In fact, in many environments, the server is located in a computer room in another location. While these rooms provide security and air conditioning for the computers, they are not the best place for most system administrators to work in. The cooling fans tend to make a lot of noise. Operators usually are located in control rooms that are isolated from the noise (and often are kept a little bit warmer than the normally chilly equipment areas). Also, as a system administrator, your users usually will want to be able to come see you. While the usually secure computer room environment may be a nice place for you to hide when you are tired of answering questions, it is not a place that promotes interaction with your users. Therefore, many system administrators are assigned a desk in an office area. With that in mind, how do you administer your NT server(s)? In the UNIX world, most old-time system administrators would just use Telnet to log into the various servers that they were maintaining from their desktop, and issue all those commands and edit the files from the command line. A few of the more graphically oriented individuals would use X-terminal connectivity to allow them to log in to remote servers and still utilize a graphical user interface. This often caused a large amount of network traffic due to the fact that signals were being transmitted every time you moved the mouse. Windows NT has taken a different approach to administration of remote machines. I like of think of it as a very client-server oriented approach that keeps traffic levels down. With NT 4.0, many of the tools for remote administration that used to be add-on products you purchased with the Windows NT Resource kit or downloaded off the Microsoft Web page now are part of the basic product. The NT 4.0 CD even distributes client-side remote administration software for NT workstations and Windows 95 workstations on the Windows NT 4.0 CD-ROM. This can be a real time-saver when you are looking for one place to find all the files with which you need to work. This chapter covers some of the tools that are currently out that I would consider to be part of a remote administration scheme. While most of the tools come as remote versions of the Windows NT administration tools that you would use on your server (such as User Manager for Domains), there are other considerations. For example, I sometimes set up scripts that run as scheduled jobs when I am not in the building. You also can activate scripts from another workstation using remote procedure calls. Finally, there are a number of system management tools (such as Microsoft's Systems Management Server or SMS) that fall into the category of remote administration tool. While this chapter cannot cover each topic in detail (there is a manual on just SMS), it should give you a feel for what is available and what these tools can do for you. Introduction to Remote AdministrationFor purposes of my discussion here, I group the various forms of remote administration into three general categories (see Figure 17.1):
Three categories of remote administration. Remote LoginThe first category is what I call remote login. In this situation, you use a communications package for a command line interface to another computer. Based on your logon privileges, you can execute commands, modify configuration files, and so on, as necessary to perform remote system administration. This is how I have performed most of the UNIX system administration work in my past life. As mentioned in the introduction to this chapter, this can be extended to include a graphical interface (such as X-Windows), but this can take a fair amount of network bandwidth. Client/Server ProcessingIn client-server processing, you run a program on your local computer, which sends signals to a remote computer that has a server utility (such as Windows NT service). The server utility performs actions based on the orders transmitted to it. The use of intelligent agents at both ends reduces the network traffic required to accomplish the task. For example, you might need to transmit a small amount of information about the current state of the remote machine, perform analysis, get user input, and then transmit only the final instructions for actions taken on the remote system. Another advantage of this architecture is that you can make the client application more friendly because you are not limited by command-line interfaces or a lack of knowledge about the remote system. Automated System ManagementThe final alternative starts out with client-server processing, but goes a bit further. In this case, you have intelligent agents on a server and a number of clients. You can instruct these agents to download new software packages, back up files from the client to the server, and so on. These actions can take place at night or during low system activity. The key difference between these methods is the level of intelligence and automation provided by these tools. You can even check the current state of a client before deciding the actions you want to take. Most packages also provide intelligent inventory agents that collect data on the hardware and software that is currently loaded on the clients to make it easier for you to determine the best actions to take. The basic Windows NT remote administration scheme is based on the client-server model. You run a full-fledged version of tools, such as User Manager for Domains or Event Viewer on your local workstation. You select a remote computer (or the domain server in the case of domain maintenance) to work with and then process everything as if you were on the remote computer's system console. This method provides advantages in that you can work from almost anywhere in the building in which these remote administration tools are installed, as in the case when your office is not located in the same building as the server. It also enables you to spawn multiple windows to monitor events on multiple remote computers at the same time (for example, you can have a whole series of Performance Monitor graphs running if your computer and network are up to the task). You must think about important security considerations when you allow remote administration. Basically, it comes down to trusting the person issuing the commands. In the Windows networking environment, trust usually boils down to domain security. This is the environment in which security tokens are exchanged and your account is validated against a central, secure database to validate that you are able to log onto the domain. Therefore, while you can use remote administration tools read the event log on a remote computer if you are in a Workgroup configuration, you need to be in a domain configuration to be able to perform useful administrative functions or issue security-related changes, such as adding new users. Do you ever get the feeling that Microsoft is nudging you (sometimes not too gently) into using domains for your Microsoft networks? If you have any doubts on this subject, wait until you get to Chapter 26, Microsoft BackOffice and other Microsoft Products, to find out that the Exchange Server electronic mail product now is designed to work in the domain environment. For more information about NT security, refer to Chapter 25. Remote Administration ToolsWhat are the tools at your disposal to perform the remote administrative functions under Windows NT? Several months ago, Microsoft first made Windows 95 versions of their basic NT domain administrative tools available on their Web site. Now, these same basic tools are provided in the client subdirectory on the Windows NT 4.0 server CD-ROM, along with a version that upgrades the tools on Windows NT workstations to make them domain capable. Following are the tools you will find in this directory:
Let me start with the installation process for these utilities. I discuss the Windows 95 version in that it is similar to that used for Windows NT workstations, but perhaps a little more difficult for people who come from the Windows NT environment. In this case, go into Control Panel and select the Add/Remove Programs icon. Add/Remove Programs is designed for operating system programs and not your common applications which typically come with a setup utility. Choose the Windows Setup tab (see Figure 17.2). The Add/Remove Programs utility.
First, you select the Have Disk option, which indicates that you want to install an item that is not on the list. This utility is designed to look for a .INF file, in this case the SRVTOOLS.INF file provided on the Windows NT 4.0 Server CD-ROM. Second, you are prompted to tell the system where the files are located (see Fig. 17.3). In this case, it is the \CLIENTS\SRVTOOLS\WIN95 subdirectory on the CD-ROM drive (in my case it was G:\CLIENTS\SRVTOOLS\WIN95). Windows then loads the product descriptive information from the .INF file Specifying the location of the remote admin software.
The third step in the configuration process involves clicking the checkbox next to the Windows NT Server Tools prompt and then clicking the Install button (sere Figure 17.4). The new tools will be installed. You might think that you got away with installing a system utility that did not require a reboot of the operating system. Unfortunately, if you read the documentation, you must insert manually the C:\SRVTOOLS directory into the path variable in your AUTOEXEC.BAT file and then reboot to have this change take effect. Final installation screen for remote admin software.
After you complete the installation, file configuration, and reboot, you are ready to use the remote administration tools. First ensure that your workstation is configured to participate in the domain on which you plan to administer. You can choose a domain after you start the tools. This is useful when you are working on multiple domains. I, however, prefer to have my default settings configured so that in the long run they minimize my labor. The first thing that you have to find is the location of the new software you installed. Figure 17.5 shows the location of the applications on my menu system. Running the remote admin tools. Remote User ManagerThe first tool, User Manager for Domains, is a key point in Chapter 16, User Administration. If you are reading this guide straight through, it should be fresh in your mind. Look at Figure 17.6 to see whether you can find all the differences between this version of the User Manager tool and the one you are used to using on the Windows NT Server console. What impressed me most about this is that it is the same as you would use on your console. There were no changes made to adapt User Manager to the remote computer's environment. Of course, if you are accessing this tool from Windows NT 3.51 workstations, you will get the old look and feel of the Program Manager environment, but the appearance does not affect the basic functionality of the tool itself. User Manager tool.
A key concept when working with User Manager tools is the capability to select a domain. Figure 17.7 shows the Select Domain menu option in the far left menu of these utilities. This actually enables you to control one or more entire domains from your personal desktop computer. Remember however, that you will be validated by user ID and password in all domains, so security is still preserved, even when you move around. Selecting the domain.
For those of you who have forgotten the basic functions of the User Manager, following is a summary of the functions of User Manager:
Remote Event ViewerNext on the list of remote administration tools is the Event Viewer. Unlike User Manager, which focuses on the Domain level, the Event Viewer is targeted at specific computers within the domain. The Event Viewer is a tool that enables you to probe the log files of remote systems. These log files contain a wealth of information on both normal operations and problems. Figure 17.8 shows an example of the log that monitors activities for the operating system itself. The Event Viewer.
The Event Viewer is a good candidate for being the first tool you look at when you have a problem with your system. Chapter 30, Auditing Windows NT Server, discusses in greater detail functions available in the Event Viewer; however, the following brief summary should stimulate your interest in this tool:
Remote Server ManagerThe third tool provided as part of the remote administration package on the Windows NT 4.0 CD is the Server Manager (see Figure 17.9). Like the Event Viewer, it also focuses on the individual computer system level. Its job is to show you what is going on with a particular computer (not just events that are logged). In addition, it displays alerts, which are events that should attract the interest of administrators who do not want to wade through a large number of routine events in the system log files. Server Manager.
The Server Manager provides the following useful displays for the remote system administrator:
Remote Performance MonitorThe Performance Monitor is another tool that comes with Windows NT and does not require special configuration or additional software to provide services for multiple computers. The Performance Monitor is built to enable the administrator to select not only the system resource that is to be monitored, but the actual computer system on which the monitoring is to occur. This is useful in that you can have graphs of key actions, such as processor utilization, disk transfer rates, and memory usage running on your personal workstation while you are working on other tasks. Figure 17.10 shows the Add to Alert dialog box you use to select the parameters you want to monitor. The first field in this dialog box is the Computer system name. Performance Monitor Add to Alert dialog box.
The Performance Monitor tool provides a number of monitoring options. It is a highly flexible and customizable tool that is described in greater detail in Chapter 19, Performance Tuning and Optimization. For now, look at the following list, which summarizes the actions this tool can perform:
So far, the discussion of tools in this chapter has focused on administration of user accounts (and the associated privileges) and monitoring the usage of system resources. Another common administrative task involves altering the other half of the security picture, which consists of the privileges needed to access the various resources. If you install the server tools just described, you get an amazing side benefit that is integrated into the tools with which you are already familiar. Something appeals to me about a capability that integrates with the rest of your environment in a way that you almost might not even notice (as opposed to the developers who build a monstrous system every time a new requirement surfaces. Remote Directory and Printer ControlsThe feature that I am referring to relates to directories and printers that are available on remote computers. If you use your Explorer interface to highlight a shared directory or printer and right-click with your mouse, you can select Properties from the pop-up menu. The resulting Properties dialog box offers number of options, including the Security tab. You can use this tab to set up the desired access permissions for this resource. This section has taken on the task of describing the various tools available in the Microsoft network environment that enable you to maintain computers located throughout your network from any Windows NT or Windows 95 computer. The client-server model used by these tools not only minimizes network traffic, but also enables you to have a powerful graphical-user interface when performing daily chores. These features are well-integrated within the environment, and in many cases, use tools that are already available on the local workstation. I know that I do not want to sit in a cold, noisy data center ever again. I also am certain that I do not want to share my cubicle with a dozen servers. They may keep you warm in the winter, but they tend to ruin the decor of the office. The tools discussed in this section make it practical to administrator remote Windows NT computers. Scripts and Remote AdministrationBatch files (sometimes called scripts for ex-UNIX types) enable you to perform a number of routine system functions. Batch file programs basically take the commands that you enter at the DOS command line and store them in an ASCII text file which usually ends with the .BAT or .CMD extension. You then can execute these files from the command line. You usually can put together batch files quickly, making it easy for you to automate common administrative tasks. You may even want to create a directory of your common scripts that has some form of protection (ownership and access privileges for only administrators, for example). While you can use a remote procedure call to execute these scripts on an as-needed basis, there is more interesting use for your administrative batch files. The best form of remote processing is that which takes place automatically, without your involvement. To accomplish this, create a script and store it in a batch file. Following is a portion of a script that would stop an Oracle database, stop its services, and perform a backup of the C drive. net stop "OracleServiceORCL" >> c:\scripts\backup.log ntbackup backup c: /d"Daily Backup" /b /l"C:\daily_bk.log" /tape:0 net start "OracleServiceORCL" >> c:\scripts\backup.log Using the preceding code, you have saved the complete listing of the script in a file called BACKUP.BAT, which is located in the protected C:\SCRIPTS directory. Suppose that you also want to perform your nightly backups at 2 a.m. every morning of the week. (Hopefully, someone else will come in and change the tape that is in the tape drive on weekends.) To schedule a job to run at a time you specify (either once or on a recurring basis), use the at command. In this command, you specify the time and then the script to run. It is similar in concept to the UNIX cron utility. To set up your backups, at the DOS command prompt, type the following: at 2:00 "c:\scripts\backup.bat" The graphical administrative tools provided in Windows NT are easier to deal with than batch programs. Batch files, however, provide a tool that enables you to perform tasks that graphical tools cannot. You can use batch programs rather than GUI tools to more easily meet special needs or perform simple tasks. For example, I have as simple batch file on my computer at work that copies the contents of my six data-holding directories to my directory on the server drive about an hour before the nightly backup kicks off. This way, my workstation (which lacks a tape drive) has its user data backed up nightly. While I could set up the server to back up my local hard disk through the network as part of its backup job, I like to do it this way because if I mess up a file, all I need to do is copy the file down from my server, without restoring from tape. You might be surprised at the number of NT command-line applications that allow you to specify a remote computer name for execution. One of the biggest would probably be the shutdown command. You use the UNC name for the computer to specify which computer is to be shut down. An example of this command (for shutdown and reboot) would be: shutdown \\joe /R Before moving on from this section, I want to mention another option. There is a utility in the Windows NT Resource Kit that enables you to convert almost any executable file into a Windows NT service using SRVANY. Batch files are executable so they, too, can be turned into a service. One of the things that I miss from the UNIX world is the startup scripts directories that contain custom scripts that are executed when the system starts up. A common task is to run a database startup utility such are Oracle's SQL*DBA with an Oracle command file that issues a series of commands. For example, Oracle has a series of services you can start automatically, but you must issue a command to open the database for business. The approach I like to take is to create a script called STARTUP.BAT in my SCRIPTS directory and then turn the script into a service using the srvany utility from the Resource Kit. This STARTUP.BAT file can hold all the commands needed when you start up your system, or it can call other batch and executable files. To avoid assumptions about environmental variables such at PATH, be careful when writing these scripts and always fully qualify your filenames. Scripts that execute as services are another means of getting your server to do what you want done even when you are not there. Distributed System Management ToolsThe final set of tools mentioned in this chapter are the distributed system management tools that are starting to appear on the market. Microsoft has its Systems Management Server, which is a part of BackOffice (discussed in greater detail in Chapter 26, Microsoft BackOffice and other Microsoft Products). Oracle and other vendors also are marketing similar products. These products enable you to not only to perform maintenance on your server remotely, but also on the many client workstations that you might be asked to support. You should be aware of some of the features that the distributed system management products offer. Be sure, however, to test them thoroughly before committing to them as a key part of your architecture. The distributed system management products are fairly new and may not be fully ready for prime time. Some of the features that these tools offer for remote administration include the following:
SummaryThis chapter has provided an overview of the tools that are available to provide remote administrative services in the Windows NT environment. One of the first uses of these tools is to enable administrators to perform routine maintenance tasks from their desk as opposed to the server console. You also can extend these tools to enable a single administrator to maintain multiple computers, and even computers that are widely dispersed geographically. With just the tools provided on the Windows NT 4.0 Server CD, you can configure Windows 95 and Windows NT workstations to serve as administrative consoles located anywhere on your network.
|
