15
Administering the Server
As a network administrator, your primary duties consist of constantly adding new computers and users, or modifying existing user accounts, configuring both server and client workstations and troubleshooting all sorts of problems.
In this chapter we look at many of the features NT Server provides for administering the local server. Of primary importance here is the Server Manager application. We also look at how to use this application to perform administrative functions such as creating computer domain accounts and synchronizing the domain controllers. We then discuss managing services and shares on the server.
We then move to a discussion of how and why to use the Directory Replication service and configuring the server to alert you if there are problems. This is followed by a look at how to use the Event Viewer to troubleshoot problems, as well as a method of simply monitoring what is going on your server.
This chapter also looks at the Repair Disk utility (RDISK.EXE) and how to use it to help recover the server in the event of a system failure.
A section on using the workgroup version of the Microsoft Mail service explores how to use NT Server out of the box as a basic electronic mail server for small workgroups. Finally, we look at using the Remote Boot Service, which enables you to boot Windows 3.x and Windows 95 workstations from the network.
Interspersed throughout this chapter are command-line alternatives to managing your network in case you prefer to use the command line for your day-to-day activities.
Using Server Manager
Server Manager is a wonderful administrative tool. It encapsulates the manipulation of a remote computer's resource management into a single application. With it, you can manage your network client (Windows NT only) computer's shared resources and even determine which shared resources your other network clients are using. You can also use this tool to create computer accounts and to synchronize your backup domain controller's database with your primary domain controller. And you can perform all this from your own server or workstation.
NOTE:To enable a Windows NT Workstation, Windows 95, or Windows 3.x client to perform these tasks, first you must install the software. You can find this software in the \CLIENTS\SRVTOOLS directory on the Windows NT Server CD-ROM. You also can install the software from a network share. You can create this share and copy the installation software by using the Network Client Administrator, as explained in chapter 21, Network Client Administrator. For more information on using other machines to administer your server, see chapter 17, Remote Administration.
NOTE:For purposes of this discussion, we assume that you are using the local domain for your administration. If you want to administer a different domain, just choose Select Domain from the Computer menu, and then choose the domain to administer in the Select Domain dialog box.
The Server Manager is installed in the Administrative Tools program group by default. The main Server Manager window, shown in Figure 15.1, lists all the computer accounts created in the domain.
Figure 15.1
The Server Manager lists all computer accounts in the domain.
Each entry listed in the Server Manager is associated with an icon that lets you know at a glance what role the computer plays in the domain structure. The three icons are for the primary domain controller (PDC), the backup domain controller (BDC) and a workstation.
In addition, some icons might appear grayed out. This occurs when a computer is turned off, or otherwise inaccessible.
Creating Computer Accounts
In a Windows NT domain structure, one of the most important tasks of Server Management is the creation of computer accounts. A computer account must be the same as the computer name of a client computer. A client can be a Windows NT Server backup domain controller (BDC), a Windows NT Server configured as a member server, or a Windows NT Workstation, for example. This component is used to establish the trusted connection between your domain controller and your client. This trusted connection is the beginning of the network authentication process for domain members.
NOTE:This idea of creating an account for both the computer and the user is new to the world of Microsoft networking. Before Windows NT, the user account was the only real means of authentication. Now the identity of the workstation or server itself can also be authenticated. This allows you to control what computer a user is allowed to use to log onto the network, but more importantly it allows the NT network—in particular the domain controllers—to trust the identity of an individual computer.
NOTE:You only need to create computer accounts for NT Workstations and NT Servers in the domain. You should not create computer accounts for other systems on the network, such as Windows 95, Windows 3.x, and Macintosh computers. Because these other clients will not take advantage of this computer account, someone could bring up an NT Workstation or NT Server configured as a domain controller, and make use of that computer account.
For a Windows NT Workstation or Server to join an existing domain, it must have a computer account. Furthermore, the creation of this account requires administrative permissions in the domain. This prevents an average user from bringing up an NT system in your domain without your permission.
There are two ways in which you can create the computer account: either from the Server Manager, or during the installation process of an NT Workstation or NT Server.
The major benefit of creating the computer account with Server Manager is that by precreating the computer account, you also can specify the computer name on the client. This can enable you to regulate the naming convention of client workstations on your network. So instead of having names like FRODO, SUPERMAN, and JUNGLE_JIM, you can have responsible and descriptive names like FRED_WARD, ACCOUNTING, or MARKETING. Using Server Manager provides another important benefit: You don't have to give out an administrative password (which you would have to change afterward) to a user, and you don't have to physically go to the location of the client computer and enter your administrative account and password in the Control Panel Network applet's Domain/Workgroup Settings dialog box.
When an NT Workstation, or NT Server configured as a member server, joins a domain, the Domain Admins global user group is added to the client computer's Administrators local group. This provides you, the domain Administrator, with administrative capabilities on the client machine locally or remotely. Also, the Domain Users global group is added to the client's local Users group.
WARNING:On a network with two-way trust relationships, if you do not have a computer account, you are not a trusted member of the domain, and you have no access to a domain controller. This means that even if you have a user account on the domain controller, without a computer account, you cannot be authenticated at the user level. And if you cannot be authenticated, you cannot access network resources. On a network with no trust relationships or with a one-way trust relationship, a user account can be mapped to a user account on the remote computer. This local user account-to-remote user account mapping provides limited access to network resources.
You can also use computer accounts to restrict a user's ability to access your network to a specific set of workstations. This possibility is discussed in User Manager for Domains and the creation of user accounts in Chapter 16.
To create a computer account, follow these steps:
- Open the Server Manager from the Administrative Tools program group.
- Choose Add to Domain from the Computer menu. The Add Computer to Domain dialog box appears, as shown in Figure 15.2.
Figure 15.2
Specify the name of the computer account to create.
- Select the computer type. A computer type can be a Windows NT Workstation or Windows NT Server configured as a member server, or a Windows NT backup domain controller. Enter the computer name in the Computer Name field.
- Click the Add button.
- Repeat steps 2 through 4 for each computer account you want to create. Then click the Close button.
Deleting a computer account with Server Manager is as simple as selecting the computer account and pressing the Delete key. Alternatively, you can choose the Remove from Domain command from the Computer menu. Before the computer account is deleted, you will be warned and asked to confirm the action, as shown in Figure 15.3.
Figure 15.3
Removing computer accounts deletes the associated security identified.
WARNING:Computer accounts have unique security identifiers (SIDs). If you delete an account and then re-create it, the client computer user must rejoin the domain. If you move a computer from one domain to another and then attempt to rejoin the original domain using the original computer account, the attempt will fail. If you change the client computer's configuration from a domain to a workgroup and then attempt to rejoin the domain using the original computer account, the attempt will fail. If you change the computer's name without creating an account for the new computer name, the attempt will also fail. The moral of this story is that whenever you change a computer's domain or name, you must create a new account for it.
TIP:Adding or deleting computer accounts from the command line is an easy task. As with most network-related commands, it begins with the NET command.
This version of the NET command is available only on Windows NT Server computers:
NET COMPUTER \\ComputerName /ADD /DEL
Explanations of the syntax follow:
\\ComputerName: Name of the computer account you want to create.
/ADD: Specifies that you want to create the computer account and add the computer to the domain.
/DEL: Specifies that you want to delete the computer account and remove the computer from the domain.
Synchronizing the Domain Database
The master domain database, which includes your computer and user accounts, physically resides on the primary domain controller (PDC). Changes to this database are replicated to your BDCs at periodic intervals, as defined by a setting in the Registry. Sometimes this replication process fails due to a poor network connection or other problems. You can use Server Manager to force an immediate replication of this database to all BDCs in the domain, or only to a specific BDC.
To synchronize all the BDCs with the PDC, follow these steps:
- Open the Server Manager from the Administrative Tools program group.
- Select the PDC in the main window of Server Manager.
- Choose Synchronize Entire Domain from the Computer menu.
You receive a message indicating that the process may take several minutes to complete, as shown in Figure 15.4. Click Yes to continue.
Figure 15.4
Synchronizing the domain takes a few minutes.
You receive this message because synchronizing the account database can use quite a bit of network bandwidth and can affect your network performance. So you should use this command only if you absolutely must during peak network usage hours, particularly if you have a large number of accounts and users to replicate to the BDC.
- Click the OK button to proceed.
- Next you are informed that you should check the event log of the PDC and BDC to make sure that the replication process succeeded. The idea here is to make sure that the PDC and the BDC sent and received the same number of accounts. This information is contained in the system event log Net Logon.
If you have a number of backup domain controllers, you might only need to synchronize a particular one. This occurs most often when the BDCs and the PDCs are geographically dispersed and connected by wide-area-network (WAN) lines. To synchronize a specific BDC with the PDC, follow these steps:
- Select the BDC in the Server Manager main window.
- Choose Synchronize with Primary Domain Controller from the Computer menu. You will see a message that the process may take several minutes to complete. Click the OK button to proceed.
- Next you are informed that you should check the event log of the PDC and BDC to make sure that the replication process succeeded.
Because all computer accounts and user accounts must be created on the PDC's database, if the PDC fails and goes off line, you cannot make any account modifications. If this occurs, you can promote a BDC to a PDC temporarily to make account modifications. After you solve the problem with the PDC, you can bring it back online. There are several items to consider when a failed PDC is restored or when promoting a BDC to a PDC:
- When you promote a BDC to a PDC, all client connections on both domain controllers are terminated. This could cause a loss of data for your network users. Because of this possibility, you should warn your users to disconnect prior to promoting a BDC.
- You will not be able to synchronize a domain if you are attached to the network through an NT RAS server running on a domain controller of the domain you wish to synchronize. This is because when you synchronize the domain, the RAS connection will be terminated before the role change is completed. When you loose connection to the network, NT terminates the synchronization request, which is then rolled back and the backup domain controller is not promoted.
- If you promote a BDC to a PDC and you bring a failed PDC back online and a, you now have two PDCs on the domain. This prevents you from making any changes to the account database. To correct the situation, you must demote one of the PDCs to a BDC.
- Before you bring your PDC back online, you should keep a few considerations in mind. Never use a domain controller that has stale data as a synchronization source. To prevent this from occurring, demote your failed PDC to a BDC. Then force the synchronization of the BDC with the current PDC. Then you can promote the BDC (the original PDC) back to a PDC and return to your original configuration. Synchronizing the database first ensures that the account database update will be successful (because you can check the event logs to make sure) and that any changes you made while the original PDC was down will be maintained. If you fail to synchronize the database prior to demoting the current PDC, you might overwrite your user databases on the backup controllers with an older copy (the one on your failed PDC) and lose any account modifications that occurred while the original PDC was down.
To promote a BDC to a PDC, follow these steps:
- Select the BDC in the Server Manager main window.
- Choose Promote to Primary Domain Controller from the Computer menu. You see a message telling you that the process may take several minutes to complete and warning you that all connections to the existing PDC and the BDC you are promoting, will be closed. This warning is shown in Figure 15.5. Click the OK button to proceed.
- After the account synchronization completes, the BDC is displayed as a PDC, and the old PDC is displayed as a BDC in the main window, as shown in Figure 15.6, where you’ll notice the icon and the description on the old PDC, called TESTPDC, and on the new PDC, called BDC1, have changed.
Figure 15.5
All network connections to the existing PDC and the machine begin promoted to PDC will be closed.
Figure 15.6
Promoting a BDC to PDC demotes the existing PDC.
TIP:You can synchronize the entire domain account database by running the following command from a command prompt:
NET ACCOUNTS /SYNC /DOMAIN
Descriptions of this syntax follow:
/SYNC: Synchronizes the entire domain if it is executed on a PDC, or just the BDC with the PDC if it is running on a BDC.
/DOMAIN: Synchronizes the entire domain regardless of where the application is executed. Normally, this switch is used only when the command is executed on a Windows NT Workstation or Windows NT Server running as a member server.
Managing Remote Computer Resources
You can use Server Manager to manage your local or remote computer resources. I find this capability to manage remote computer resources highly useful in my day-to-day administrative activities because I do not have to leave my desk. With Server Manager, you can stop, start, pause, continue, or configure system services on a remote computer running Windows NT Workstation or NT Server. You can also use it to create new shares or modify or delete existing shares. You can use it to determine who is connected to the remote computer, or even to determine which shares are available on the remote computer.
Managing Services
One method of controlling services on a Windows NT computer is to use the local computer's Control Panel Services applet. With this tool, you can stop, start, pause, or continue the execution of a service. You can also use it to specify if the service should be automatically started at boot time and to configure which user account privileges the service uses to do its job.
You can use Server Manager to perform these same tasks by selecting the computer in the Server Manager's main window and then choosing Services from the Computer menu. The Services on PRIMUS dialog box appears, as shown in Figure 15.7.
Figure 15.7
The Server Manager can be used to control services on an NT system.
TIP:Before you stop a service that a client may be using, you should pause it. This prevents any new clients from connecting to this service. You can then send a message (by choosing Send Message from the Computer menu) to the connected users to inform them of your intention to shut down the service. The clients then have the opportunity to save their data before you shut down the service.
The buttons you can click to perform selected functions follow:
- Start: Starts a service that is not executing. Any command-line parameters entered in the Startup Parameters field are passed onto the service when it starts executing.
- Stop: Stops a service that is currently running.
- Pause: Prevents new connections to a service (if it is a network-aware service, such as the Server service), while still providing support to currently connected users.
- Continue: Continues the operation of a paused service.
- Startup: Changes the start-up characteristics for a service. The available options provided in the Services dialog box are the Startup Type and Log On As fields. The Startup Type entry can be Automatic, Manual, or Disabled. Log On As can specify that the service should use the default system account or a user account that you created with User Manager for Domains. If you specify a user account, then you must also specify a user password.
Managing Shares
Just as you can manipulate a remote computer's service control manager database with Server Manager, you can also manipulate a remote computer's network shares.
First, select the computer in the Server Manager main window to highlight it. Then choose Shared Directories from the Computer menu. The Shared Directories dialog box appears, as shown in Figure 15.8.
Figure 15.8
The Server Manager can be used to view the current shares on an NT system.
You can create a new network share by clicking the New Share button. The New Share dialog box appears, asking you to specify the share name, path, comment, and number of users that can connect to the share. By clicking the Permissions button, you can specify the share level permissions.
You can modify an existing share by highlighting a shared directory and then clicking the Properties button. The Shared Directory dialog box appears, which is similar to the New Share dialog box.
To remove an existing network share, highlight the shared directory and click the Stop Sharing button.
WARNING: Clicking the Stop Sharing button in the Shared Directories dialog box immediately stops sharing the directory. There is no confirmation message. Before you do this, check to see who is using the share. This is discussed in the next section, "Performing Resource Accounting."
Performing Resource Accounting
To determine which users are connected to a computer, the network shares available on a computer, or the shares in use on a remote computer, you can do so by double-clicking a specific computer listed in the Server Manager's main window, or selecting a computer in the main window and then choosing Properties from the Computer menu. The Properties dialog box appears, as shown in Figure 15.9. This is the same dialog box displayed in the Control Panel Server applet.
Figure 15.9
The Server Manager can be used to view how many users are logged on and how many resources are being accessed.
The Properties dialog box enables you to access the following functions:
- Usage Summary: This lists the number of sessions, file locks, open files, and named pipes in use on a computer. The number of sessions actually reflects the number of users connected to the computer because each connected computer uses one session.
- Users: This displays the User Sessions dialog box, shown in Figure 15.10, and determines which users are connected to the computer and what resources they are using. The upper box lists the connected users, the name of the computer they are connected from, the number of open files, the total connection time, the total idle time, and whether the users have connected with guest privileges. The lower box lists the resources the selected user is connected to, the number of files in the resource opened by the selected user, and total amount of time the user has been connected. To disconnect a specific user, highlight the user and click the Disconnect button. To disconnect all users from all resources, just click the Disconnect All button.
Figure 15.10
The Server Manager can be used to see which resources a user is attached to.
- Shares: This performs an action similar to the Users button. After you click this button, the Shared Resources dialog box appears, as shown in Figure 15.11. The emphasis here is on the shares. The upper box lists the shares by name, number of connections, and physical path of the shared directory. The lower box lists the connected users, total connection time, and whether the connection currently is active. To disconnect all users from a specific share, highlight the share and click the Disconnect button. To disconnect all users from all resources, just click the Disconnect All button.
Figure 15.11
The Server Manager can be used to see which users are attached to a particular share.
- In Use: Clicking In Use displays the Open Resources dialog box, as shown in Figure 15.12. This lists the resources that currently are open, such as files, named pipe connections, print jobs, and links to LAN Manager communication devices. It also includes information about the user who has opened the resource, the permission granted when the resource was opened, any locks, and the pathname to the open resource. To disconnect all users from a specific resource, highlight the resource and click the Close Resource button. To disconnect all users from all resources, just click the Close All Resources button.
Figure 15.12
The Server Manager can be used to display a list of all resources that are currently open.
NOTE:Replication and alerts are discussed later in this chapter in the sections titled "Configuring the Directory Replicator Service" and "Configuring Alerts."
CAUTION:If you disconnect a user, any files that have been opened by the user will not be closed properly and the user may lose data. Disconnecting a user in this fashion also does not prevent him from reconnecting. If the user or the user's application attempts a reconnect, it will be granted, unless you paused the Server service, as discussed earlier in the Managing Services section of this chapter.
Configuring the Directory Replicator Service
Use the Directory Replicator Service to copy directories and files from a Windows NT Server to another server or workstation. The service consists of an export component specifying the root directory to export and an import component used to specify directories and files to copy from the export server. The export server is limited to a single directory tree, which consists of the root directory and a maximum of 32 nested subdirectories. To configure the replication service, you must perform the following tasks:
Configuring the Export Server
To configure your Directory Replicator Service to export a directory tree, use Server Manager. Just double-click the name of the server to display the Properties dialog box, and then click the Replication button to display the Directory Replication dialog box. Then follow these steps:
NOTE:Windows NT Servers can be configured as both import and export servers. Windows NT Workstations can only be configured as import servers. Also, Windows NT Workstation cannot change the default replication path from %SystemRoot%\System32\Repl\Import\Scripts.
- Enable the replication service by enabling the Export Directories radio button.
- Add computers to replicate to in the To List box by clicking the Add button at the bottom left of the screen. The Select Domain dialog box appears.
- Select the individual domains and computers to which you want to export. Then click the OK button. You are returned to the Directory Replication dialog box. To add more computers, repeat steps 2 and 3.
NOTE:By default, the local domain is always included as an export partner, unless you add an entry in the To List box. If you do add an entry, the local domain no longer is automatically included. To continue to export to the local domain, add the domain name to the To List box.
- Specify the export path (if the default is not acceptable, although in most cases you will not need to change this entry) in the From Path field. Generally, this is the %SystemRoot%\System32\Repl\Export directory.
- Add the subdirectories from the root export directory. Click the From Path Manage button, which displays the Manage Exported Directories dialog box (see Figure 15.14).
Figure 15.14
The Manage Export Directories window is used specify subdirectories to export, as well as monitor replication locks.
- Specify the subdirectories to export by clicking the Add button. The Add Subdirectory dialog box appears, in which you can specify the subdirectories of the root export path to export. For each subdirectory you select, you must specify whether you want to wait until the files in the directory have been stable (no changes have been made for 2 minutes) by enabling or disabling the Wait Until Stabilized checkbox, and whether you want any subdirectories to be copied by enabling or disabling the Entire Subtree checkbox. Remember that you must repeat this step for each subdirectory you want to export.
For each subdirectory entry, you can see some status information by looking at the following columns:
- Locks: Specifies the number of active locks on the subdirectory.
- Stabilize: Indicates whether the files must be idle for 2 minutes before replication can occur (which can prevent partial replication changes if the files are very active).
- Subtree: Indicates that all subdirectories are to be replicated.
- Locked Since: Indicates that a subdirectory has been locked since a specific date/time.
TIP:If you are going to be making a lot of changes to a subdirectory you have marked for export, use the Add Lock button to lock the directory. This prevents the directory from being replicated until all the locks are released.
Configuring the Import Server
This process is quite similar to exporting a directory tree. From the Directory Replication dialog box, follow these steps:
- Enable the replication service by enabling the Import Directories radio button.
- Add computers to replicate to in the From List box by clicking the Add button at the bottom right of the screen. The Select Domain dialog box appears.
NOTE:By default, the local domain is always included as an import partner unless you add an entry in the From List field. If you do add an entry, the local domain is no longer automatically included. To continue to import from the local domain, you must add the domain name in the From List field.
- Select the individual domains and computers to which you want to import. Then click the OK button. You are returned to the Directory Replication dialog box. To add more computers, repeat steps 2 and 3.
- Add the subdirectories from the root import directory. Click the To Path Manage button, which displays the Manage Imported Directories dialog box. (See Figure 15.15.)
Figure 15.15
The Manage Import Directories windows is used to specify subdirectories to import, as well as monitor locks.
- The only difference in the Manage Imported Directories dialog box is that the status information for each entry consists of the number of locks on the directory, the status (OK, which indicates that the directory is receiving regular updates; No Master, which indicates that no updates are being received; No Sync, which indicates that the directory has received updates, but the current data is outdated; and a blank entry, which indicates that replication has never occurred), the date/time the last update occurred, and the date/time of the oldest lock on the directory.
TIP:To prevent an import directory from being updated, just select it and click the Add Lock button. An import directory with a lock will not be updated.
CAUTION:If you are importing directories from a domain or server located on the other side of a WAN connection, the import may fail from the local domain. To ensure that this does not occur, manually add the domain or computer name in the From field of the Manage Imported Directories dialog box.
Configuring Alerts
Use alerts to notify an administrator of a serious problem that has occurred on a Windows NT computer. You can choose to send an alert to a particular domain user or a specific computer monitored by several Administrators or support personnel.
To guarantee that the alert will be sent, you should also modify the system to start the Alert and Messenger services at system startup. This ensures that the services are functioning and available to send administrative alerts. If the services are left in their default start-up setting of Manual, then the services will attempt to send the alert but may fail due to unforeseen circumstances. If they fail, the alert will not be sent. A Windows NT Server computer has a default start-up setting of Automatic and does not have to be reconfigured. To receive an administrative alert, the messenger service must be running.
To configure the Alert service, use Server Manager. Just double-click the name of the server to display the Properties dialog box. Then follow these steps:
- Click the Alerts button in the Server dialog box. The Alerts dialog box shown in Figure 15.16 appears.
Figure 15.16
The Alerts section of the Server Manager is used to specify administrators who should be notified when something goes wrong.
- To add a new computer or user to be notified, enter the computer or user name in the New Computer or Username field and then click the Add button. The computer or user name then is moved to the Send Administrative Alerts To box.
- To remove a computer or user, select the computer or user name in the Send Administrative Alerts To box and click the Remove button. This moves the computer or user name to the New Computer or Username field.
NOTE:You do not have to include the double backslashes (\\) for a computer name, as you do for just about every other usage involving a computer name. If you do, the double backslashes are dropped when the name is moved.
- To add or remove more computers or users, repeat step 2 or 3.
- When you finish entering or removing computer and user names, click the OK button to return to the Server Manager main window.
Using the Event Viewer
Use the Event Viewer to display status events that occur on your computer. These events are divided into three categories. Each category is contained in a specific log. The system log includes events related to running the operating system, the application log includes application-specific events, and the security log includes auditing events. These events are further divided into types that have specific icons associated with them.
NOTE:Use the Event Viewer to view your logs daily for your file servers, and at least weekly for workstations. If you do not review your logs in this time frame, you might be unaware of system errors that could result in a system failure, and you will not be aware of possible attempts to violate the security of your network.
Viewing Events
To view the events that have occurred on your system, first select the log to view. Access this information from the Log menu. You can select the application, security, or system log to view. Each event in a log is broken down into components that describe the event. Table 15.1 summarizes these event components. To get the details of an event, just double-click one and the Event Detail dialog box appears, as shown in Figure 15.17. What is important to note here is that the description contains a textual message in the Description box that describes the error condition, and if the event has any associated data with it, this is included in the Data box. This data list often contains information that you or Microsoft technical support can use to isolate and solve the problem.
Figure 15.17
All events contain certain informational components.
Table 15.1. The event components.
| Component | Description |
| Icon | A quick indicator to the type of event. |
| Date | The date the event occurred. |
| Time | The time the event occurred. |
| Source | The name of the application, system service, or device driver that reported the event. |
| Category | A general classification of an event type. In most cases, categories are used only in the security log. |
| Event ID | An event number specific to the event source and associated with a specific error message. |
| User | An event can be associated with a specific user that triggered the event. In most cases, this is used only in the security log. |
| Computer | An event can be associated with a specific computer that triggered the event. In most cases, this is the name of the host (the computer where the log resides) computer. |
Filtering Events
One of the problems you will notice over time is that so many events occur on your system that finding the trouble spots can be quite time consuming. And if it takes too much of your time, then you probably will stop checking for these problems. Eventually, a problem will grow into a system-related failure that could cause you to lose your job. And I would like to help you avoid that possibility. The easiest way to minimize the amount of data overload is to use the Event Viewer's filtering capabilities.
Follow these steps:
- Choose Filter Events from the View menu to display the Filter dialog box shown in Figure 15.18.
Figure 15.18
Event filtering is useful for finding desired items.
- In the View From section, select the Events On radio button. Then specify a date and time.
- In the View Through section, select the Events On radio button. Then specify a date and time.
- In the Types section, select the type of event to report. For a quick look, I suggest only looking for warning and error conditions.
- In the Source drop-down list box, select the event source to view. This is useful for limiting the report to a specific application, system service, or device driver to determine how often the error has occurred.
- In the Category drop-down list box, select the event categories to view. In most systems, there will be only security-related categories, or possibly no subcategories. If you have categories, you can further limit the report to a particular category by selecting it from the list.
- In the User field, enter the user account you want to use to further limit the report. This can be useful when you are checking events in the security log and have noticed a potential violation. By limiting the report to just this user, you can determine how often the user has attempted to violate your system security.
- Enter the computer name in the Computer field to further limit events to just events that have occurred on the specific computer.
- If you are looking for a specific event, enter the event number in the Event ID field. This can be useful to determine how often a specific event has occurred in the past.
NOTE:This is most useful when you already know the event ID you want to locate, such as when you want to find previous occurrences of an event you just found in the Event Viewer.
- After you finish entering all your filtering characteristics, click the OK button to engage the filter. When a filter has been engaged, the title bar of the Event Viewer changes to include the word Filtered.
NOTE:After a filter has been specified, it remains in effect until you change it. If you enabled the Save Settings on Exit option, the next time you launch Event Viewer, the filter also remains in effect.
To remove a filter that you have created using these steps, just choose the View | All Events menu option, and all the events are displayed in the logs.
Archiving Events
Instead of just throwing away the events in your event logs when you fill them up, you should archive them. Then you can load them at a later date for comparison with current logs to isolate any potential problems. You also can use these logs with Excel or any database that can import a comma-separated value or ASCII text file. You can use this imported data to spot trends that can indicate a potential network trouble spot or hardware-related failure.
TIP:You can set the maximum size of the log by choosing the Log | Log Settings menu option to display the Log Settings dialog box. In this dialog box, you also can specify that you want the log to automatically wrap and overwrite events on an as-needed basis, to overwrite events after a specific number of days, or to manually clear the log to free space for further events.
To archive a log, follow these steps:
- Choose Log Type from the Log menu, where Log Type is the Application, Security, or System log.
- Choose Save As from the Log menu to display the Save As dialog box. In the Save File As Type field, select Event Log Files (*.EVT) to save the event file as a binary file that can be reloaded later into the Event Viewer. Or, select Text Files (*.TXT), which is a standard ASCII text file, or Comma Delim Text (*.TXT), which is a comma-separated value text file.
- Enter a filename in the File Name field and click the OK button. If the drive or directory is not the one you want, change it before clicking the OK button.
Using the Repair Disk Utility
The Repair Disk Utility (RDISK.EXE) is used for creating and updating your system's Emergency Repair Disk (ERD). An icon is not automatically created for this utility when you install Windows NT. However, I find this tool to be so useful that I immediately create an icon for it whenever I install Windows NT Workstation or Windows NT Server, and I suggest that you do so as well. The ERD includes contents from your %SystemRoot%\Repair subdirectory, as well as copies of the NTLDR, NTDETECT.COM, and BOOT.INI files from your system. If you were unable to create a repair disk during the installation process, you should use this utility to create the ERD. Also, you should run RDISK regularly to update the ERD. The ERD is the most effective method of recovering your system in the event of a system failure.
NOTE:The ERD is not a bootable disk; instead, it is intended to be used with the three Windows NT installation disks that came with your copy of NT.
The ERD is also useful for restoring the Registry (which is what the repair information includes) when you make a mistake with the Registry Editor or install some software that prevents your system from functioning properly. If you have a recent copy of the repair disk, you can back out of the changes to your system just by running through the repair process and be up and running in minutes.
TIP:You can create the three boot disks by running WINNT32.EXE /OX from the CD-ROM in the \I386 directory. /OX specifies that you want to create the three installation disks that use floppy disks or the CD-ROM as the installation source medium. You can use /O instead of /OX to create the three boot floppy disks, which use the temporary copy of the installation directory ($WIN_NT$.~LS) that was copied to your hard disk from a WINNT.EXE (MS-DOS based) installation. The /S:SourcePath should be a UNC name (such as \\SRV\CD-ROM\I386) or a local device name (such as E:\I386) for the installation media.
WARNING:Before you make any system modifications, you should use the Repair Disk Utility to back up your Registry. At the very least, you should update the local repair information, although I recommend that you also make a new repair disk. In fact, you should keep at least three repair disks so that you will always have one you can use to restore your configuration. Much as you have multiple backup sets, if you have multiple repair disks, you can restore your system to a known good state. At least one of these repair disks should contain a valid Registry to restore your Registry configuration.
Installing the Repair Disk Utility
To install the Repair Disk Utility, follow these steps:
- Right-click the Start button and choose Open All Users. An Explorer windows appears.
- Double-click the Programs icon in the Explorer window, shown in Figure 15.19. This brings up another Explorer window.
Figure 15.19
The All Users profile contains a Programs icon, which contains common Start menu items for all users on the system.
- Double-click the Administrative Tools icon. This brings up an Explorer window that shows existing shortcuts to many of the NT administrative tools, shown in Figure 15.20.
Figure 15.20
The Administrative Tools folder contains shortcuts to many of the NT administration tools.
- From the File menu, choose New, then choose Shortcut. The Create Shortcut window appears.
- Type RDISK into the Command Line box, then click the Next button. Click the Finish button.
- Close all the Explorer windows.
RDISK now appears with all the other administrative tools in the Start menu, as shown in Figure 15.21.
Figure 15.21
The shortcut to the RDISK utility now appears with the rest of the shortcuts in the Start menu.
Using the Repair Disk Utility
After you create the program item for the Repair Disk Utility, it is a good idea to run it and back up your system configuration. When you run the application, the Repair Disk Utility dialog box appears, as shown in Figure 15.22.
Figure 15.22
The RDISK utility is used to create and update the ERD.
The Repair Disk Utility dialog box has four buttons:
- Update Repair Info: This button updates the Registry information contained in the %SystemRoot%\Repair directory. After you click this button, you are asked whether you want to create a new repair disk.
- Create Repair Disk: This button formats a high-density floppy disk and copies the same repair information as described for the Update Repair Info button. This repair disk is used by the repair process to restore your Registry.
TIP:If you have a 2.88MB floppy drive and experience problems creating a repair disk, insert a 1.44MB floppy and use this to create your repair disk.
- Exit: This button exits the application.
- Help: This button displays brief descriptions of the Repair Disk Utility buttons' actions.
The information contained in the %SystemRoot%\Repair directory consists of uncompressed copies of your AUTOEXEC.NT and CONFIG.NT files and the compressed files listed in Table 15.2.
TIP:If you have COMPRESS.EXE, which is included with several of the Microsoft SDKs and development platforms, as well as the NT Resource kit utilities, you can compress the files in a format that is compatible with the Microsoft expansion program. EXPAND.EXE is included with Windows NT and is used to manually decompress these files. You might want to use the same format because you will have this program (EXPAND.EXE) on every system you use.
Table 15.2. Key components of the Registry.
| Filename | Registry Key | Description |
| default._ | HKEY_USERS\DEFAULT | The default system profile |
| sam._ | HKEY_LOCAL_MACHINE\SAM | Your Security Account Manager |
| security._ | HKEY_LOCAL_MACHINE\Security | The security database |
| software._ | HKEY_LOCAL_MACHINE\Software | The software configurable settings |
| system._ | HKEY_LOCAL_MACHINE\System | System-specific configuration settings |
You will see one additional file not mentioned in the %SystemRoot%\Repair directory if you enable the Show Hidden/System Files option in the NT Explorer. This file is called setup.log, and it should never be deleted. This file is used by the Setup program during an upgrade. If the Setup program cannot find enough free space during the upgrade, it prompts you to delete some files from your current installation. The files listed in setup.log are the files that will be deleted to make room for the upgrade. If this file is missing and you have insufficient disk space, the Setup program can continue only if you reformat your hard disk. This is rarely an acceptable solution and could be quite dangerous to your continued health if this installation is your only domain controller (which contains all your account information), has critical data files, or contains similar nonrecoverable components. If this file doesn’t exist or is unable to clear enough disk space to perform the installation, you will have to exit the upgrade process and manually delete enough files, then rerun the upgrade program.
Working with a Workgroup Post Office
Windows NT Server and Windows NT Workstation can act as a workgroup electronic mail post office. When you run this post office service, any Windows 3.x, Windows NT 3.x, or DOS workstation running the Microsoft Mail client can connect to the post office. Windows 95 and NT 4.0 also include the Exchange client software, which comes with the Microsoft Mail connector. You can use this to connect to the NT 4.0 post office.
It does not offer all the functionality of the full-blown Microsoft Mail 3.5 or Exchange 4.0 mail servers, but if all you need is rudimentary e-mail services, it may be just the ticket for you.
Creating a Workgroup Post Office
Creating a post office is an easy task, but keep the following considerations in mind:
- Only the creator of the post office can administer it.
- A workgroup post office can display only personal or shared folders one at a time—not both simultaneously.
- If you have more than ten users, do not install the post office on a Windows NT Workstation computer because a Windows NT Workstation is limited to ten simultaneous connections.
To create your workgroup post office, follow these steps:
- From the Control Panel, open the Microsoft Mail Postoffice applet. This will bring up the Microsoft Workgroup Postoffice Admin window.
- Select the option to Create a New Workgroup Postoffice, as shown in Figure 15.23. There should be only one workgroup post office in your workgroup/domain. If you create more than one post office, the two post offices cannot exchange e-mails. You need the complete Microsoft Mail or Exchange package in order to support multiple post offices.
Figure 15.23
Use the Microsoft Mail Postoffice Control Panel applet to create a workgroup post office.
- The next dialog box prompts you for the location of the WGPO (Work Group post office) directory.
NOTE:You can only choose to install the WGPO into an existing directory, so you might have to use the NT Explorer to create a directory for the post office.
The post office should be installed on a partition with sufficient free space to handle all your client's mail data if you store the MMF (Microsoft Mail File) file on the server. If you will have ten clients with a maximum of 10MB of mail per user, for example, you will need at least a 100MB partition.
WARNING:If you install your post office to a compressed NTFS volume, you may gain a bit of additional storage space, but you will decrease the performance of your mail server. This occurs because Microsoft Mail Files (MMFs) are already compressed. The overhead of trying to compress an already compressed file, or to uncompress these files as they are used, is rarely worth the effort.
- After the WGPO directory is created, you are prompted to enter your Administrator account detail information, as shown in Figure 15.24. In this dialog box, enter a name (such as Mail Administrator), a mailbox name (such as Admin) with a maximum length of 10 characters, a password with a maximum length of 8 characters, and miscellaneous information (such as your phone numbers, office, department, and notes). Then click the OK button to create your account.
Figure 15.24
An administrative user is created by default when you create a new post office.
NOTE:If you create an account and do not assign a password, the default is PASSWORD.
A confirmation dialog box appears, informing you of the location where the post office was created and reminding you to share the directory you just created.
And that's all there is to it. In addition to using File Manager to share the post office directory, be sure to create the share with at least Change permission, or the users cannot use their mail clients without errors.
TIP:I prefer to create the share with Full Control permissions for the Everyone group and then to set directory and file-level permissions with File Manager. This way, I can set Change permissions for the Domain Users group, Read for Domain Guests (which provides limited functionality and does prevent them from deleting the entire directory), and Full Control for Domain Admins, which gives the Administrators the capability to run mail utility programs.
Managing Your Workgroup Post Office
Managing your workgroup post office does not involve very many options. In fact, the primary option you will use is to just create mailboxes for your network clients. This is accomplished by opening the Microsoft Mail Postoffice Control Panel icon and choosing the Administer and Existing Workgroup Postoffice option. The Postoffice Manager dialog box appears, which you can use to display the details of a mailbox (click the Details button), create new mailboxes (click the Add User button), delete a mailbox (click the Remove User button), and look at the shared folders' usage summary (click the Shared Folders button).
Whenever you add a user, you must supply a mailbox name with a maximum length of 10 characters, a password with a maximum length of 8 characters, and miscellaneous information (such as the phone numbers, office, department, and notes). This procedure is just like the one you followed when you created your own account earlier. If you do not create the accounts, the individual users can create their own accounts the first time they run the 32-bit Microsoft mail client.
There are a few ways that you can make your post office a little safer:
- You can specify that the user's MMF file be located locally on his computer or remotely on the server. To place the file on the server, each user must choose Options from the Mail menu. The Options dialog box appears. Click the Server button. The Server dialog box appears, in which the user can specify in the storage group in which the MMF file should be placed in the post office or locally on the user's computer. If you store all your MMF files on the server, backing up these files becomes a relatively easy task.
TIP:You also can use the Options dialog box to specify that the inbox (where new messages are stored) be copied to the user's local MMF file when the user connects through remote access.
- If the MMF is stored locally, the individual users must back up their own MMF files by choosing Backup from the Mail menu.
- You can choose Export from the File menu to back up a single folder to a file, and you can choose Import from the File menu to restore a folder from a file.
- To create shared folders, which enable your mail users to share a single folder, you can choose New Folder from the File menu to create a shared folder. Shared folders can be limited to Read, Write, or Delete privileges for your connected users. By using a shared folder, you can save space in your workgroup post office. You can also use this command to create a new personal folder.
Using the Remoteboot Service
The Remoteboot Service is used to support your network clients who boot their operating system from the server rather than from a local disk drive. This process uses a Remote Program Load (RPL) ROM located in the network adapter to load a boot block from the server. The boot block is the actual start-up code for the operating system. After this boot block is loaded, the rest of the operating system is loaded. Most of these network clients do not contain a floppy drive or a hard disk and are referred to as diskless workstations.
NOTE:To take advantage of the Remoteboot service in Windows NT Server, your clients must have Ethernet cards that support remoteboot and have a RPL chip installed. This usually must be purchased separately, and not all Ethernet cards support it.
A diskless workstation can offer a few advantages for you and your enterprise:
- Diskless workstations can prevent the spreading of viruses because there is no mechanism to introduce them. Most viruses are spread from a bootable floppy disk inserted into a local disk drive on a user's computer.
- You can control the distribution of information and software on your network. This is because the network client does not have the capability to change its configuration for it cannot save any settings to the shared software installation. It can execute only the software you permit or save its configuration in a home directory that you provide. But as an Administrator, you can control these options.
- Software upgrades are easier to perform because you only have to update the central configuration. The users automatically benefit from these changes.
- Computers without local floppy drives or hard disk drives are less expensive.
Of course, there are a few disadvantages to diskless workstations as well. They increase the traffic on the network because every user is accessing the same files. Windows performance suffers because any paging must be performed on the networked drive, and the loading of dynamic link libraries must be performed from this shared installation. You can offset some of these disadvantages by using a local hard disk. This hard disk can be used to create the paging file, and it contains the user's data files (and applications, if desired), while still giving you the benefits of easy operating system upgrades and the prevention of virus introductions.
NOTE:You can only remoteboot DOS, Windows 3.1, and Windows 95 clients. You cannot remoteboot Windows for Workgroups 3.11 or Windows NT clients.
NOTE:People often wonder why you can’t remoteboot NT. There are a couple of reasons, but the most understated, yet most important has to do with NT security.
Each time you run setup to install NT, it creates a unique security identifier (SID). This SID is supposed to be unique through all time and space, and is used to set up trust relationships with other computers and domains. This SID is created during the NT setup process and gets coded into many of the services, particularly the network related ones. If you were to take an NT image and copy it file-for-file to another machine, you would end up with two machines with the same SID, and you would be begging for real big problems.
Likewise, if you were to permit multiple machines to run Windows NT from the same image (set of files), each machine would have the same SID, which cannot be permitted.
Installing the Remoteboot Service
Installing the Remoteboot Service is a multi-part process. First, you must install the service. Then you must copy the operating systems to the RPL root directories. And finally, you must use the Remoteboot Manager to set the security on these files and check the configurations. All this before you can create a profile. A profile contains the user configuration. You might have a profile for MS-DOS 5.0 or MS-DOS 6.x, for example, with both of them being able to run Windows 3.x from the shared installation.
NOTE:Before you install the Remoteboot Service, you should be aware of two points: First, your server name cannot contain any spaces or your MS-DOS clients will not be able to connect to it; and second, you should install the Remoteboot files to an NTFS directory because the FAT file system cannot support more than 100 Remoteboot clients and so that you can specify the correct permissions on the shared files.
NOTE:You must have the NetBEUI and DLC protocols installed before you can install the Remoteboot Service.
To install the DLC and NetBEUI Protocols, follow these steps:
NOTE:You must be logged on as a member of the Administrators group to install the DLC and NetBEUI protocols.
- Open the Control Panel Network applet. The Network dialog box appears.
- Click the Protocols tab.
- Click the Add button to display a list of installable protocols.
- Select DLC Protocol and click OK.
- Specify the path to the NT distribution files, such as F:\i386.
When NT is finished copying the necessary files, it returns you to the Network Control Panel. You should see DLC Protocol in the list of installed protocols.
- If necessary, repeat steps 3-5 to install the NetBEUI protocol.
NOTE:After installing DLC and NetBEUI, you do not need to reboot before installing the Remoteboot Service.
To install the Remoteboot Service, follow these steps:
NOTE:You must be logged on as a member of the Administrators group to install the Remoteboot Service.
- Open the Control Panel Network applet. The Network dialog box appears.
- Click the Services tab, then click the Add button to display a list of installable services.
- Select the Remoteboot Service and click the Continue button.
- When prompted, enter a path to specify where you want to install the Remoteboot files. This should be an NTFS partition.
- When prompted, enter a path to the location of the Remoteboot client files. These are stored in the \CLIENTS\RPL directory on your CD-ROM.
- Click the OK button to exit the Network Control Panel window.
- Click Close to exit the Network Control Panel.
- Reboot when prompted.
The next step is copying the client files to your Remoteboot directory that you created in step 4 to install the Remoteboot Service so that you can create a client profile. You can copy the MS-DOS system files and Windows 3.x system files to support an MS-DOS client and allow it to run the shared copy of Windows 3.x, for example.
To set up a client, follow these steps:
- Find a copy of the version of MS-DOS you want to support. On the client workstation, log on to the network, and then connect to the Remoteboot shared directory (NET USE X: \\ServerName\RPLFILES, where ServerName is the name of your server and X is the drive letter you choose to use for the mapped drive).
- Remove the attributes on the MS-DOS boot files. These files are IO.SYS and MS-DOS.SYS. Use these commands:
ATTRIB -h -s IO.SYS
ATTRIB -h -s MS-DOS.SYS
- Copy these files to the appropriate subdirectory. If you are copying an MS-DOS 5.0 installation, copy these files to the BINFILES\DOS500 subdirectory, for example:
COPY IO.SYS X:\BINFILES\DOS500
COPY MS-DOS.SYS X:\BINFILES\DOS500
COPY COMMAND.COM X:\BINFILES\DOS500
NOTE:Do not create any additional subdirectories in the BINFILES root directory. If you are installing any version of MS-DOS 6.2x, for example, it must be placed in the BINFILES\622 subdirectory. This means that you can support only one version of MS-DOS in a particular directory. You cannot install MS-DOS 6.2, 6.21, and 6.22 in the same directory.
NOTE:If you are copying files from an IBM version of PC-DOS, rename the files on the server from IBMDOS.COM to MSDOS.SYS and from IBMIO.COM to IO.SYS.
- Replace the attributes on the MS-DOS boot files. These files are IO.SYS and MS-DOS.SYS. Use these commands:
ATTRIB +h +s IO.SYS
ATTRIB +h +s MS-DOS.SYS
- Repeat steps 1-4 for each version of MS-DOS that you want to support.
The next step requires that you choose the Configure | Fix Security and Configure | Check Configurations menu options to set the appropriate permissions on the files and to verify that all the required boot files are present, including BOOTSECT.COM, IO.SYS, MS-DOS.SYS, and COMMAND.COM. If any of these files are missing, you cannot create a profile.
To create a profile, follow these steps:
- Choose New Profile from the Remoteboot menu. The New Profile dialog box appears.
- In the Profile Name field, enter a unique name containing up to 16 characters. This name cannot contain any spaces or backslashes (\).
- In the Configuration field, select the operating system and network adapter. Select DOS 6.22 3Com Etherlink III to support clients with Etherlink III network adapters and to provide MS-DOS 6.22 as the operating system, for example.
- In the Description field, enter a description for this profile if the default is not acceptable.
NOTE:If you enter a description before selecting the configuration, your description is overwritten with the default description. The default description is the same as the configuration you choose.
- Click the OK button and your profile is displayed in the Profile Name field.
- Repeat these steps for each profile you want to create.
Managing Your Remoteboot Clients
Now that you have created your profiles, it is time to add workstations to the Remoteboot Service. This is accomplished with the Remoteboot Manager. There are two ways to create a new workstation record: You can do it manually, or you can automate the process a bit.
NOTE:You must have the network client for which you want to create a workstation record turned on and available to be queried by the Remoteboot Manager. Otherwise, the process will fail.
To create a new workstation record manually, follow these steps:
- Choose New Workstation from the Remoteboot menu. The New Remoteboot Workstation dialog box appears, as shown in Figure 15.25.
- In the Adapter ID field, enter the 12-digit hexadecimal adapter identification number of the network adapter. If you do not know this number, use the automatic installation procedure.
Figure 15.25
You must enter information about each Remoteboot workstation.
- In the Wksta Name field, enter the computer name of the workstation.
- In the Description field, enter a comment for the workstation.
- In the Password field, enter a password.
NOTE:This password is not the user account password you created with User Manager for Domains. Instead, it is used by the Remoteboot Service to authenticate the workstation and to enable users to set the permissions for the user configuration maintained by the Remoteboot Service. In fact, a user account is created on the basis of the workstation name you supply, and the password for this account is the password you supplied in the Password field in the New Remoteboot Workstation dialog box.
- Select a Configuration type option. This can be Shared or Personal. A shared configuration can be accessed by multiple users, although they cannot make any changes. A personal configuration is user specific and can have user-customizable settings.
- From the Wksta In Profile drop-down list box, select a profile for the account. This is one of the profiles you just created in steps 1 through 6..
- If you are using TCP/IP as your network protocol, select TCP/IP DHCP to use your DHCP server to provide an IP address (the preferred method). Or, to manually assign an IP address, a subnet mask, and a gateway address, enable the TCP/IP Settings option instead.
- Click the Add button to add the workstation record.
- Repeat these steps for each new workstation record.
To create a new workstation record automatically, follow these steps:
- Boot the workstation client. When the workstation starts, it attempts to find an RPL server that will create an adapter record.
NOTE:An adapter record appears just like a workstation record in the Remoteboot Manager main window, but it doesn't have a workstation name associated with it. Instead, it has the 12-digit hexadecimal adapter identification number listed.
- Select the adapter record. Then choose Convert Adapters from the Remoteboot menu. The New Remoteboot Workstation dialog box appears.
- Repeat steps 3-10 of the preceding procedure to create a new workstation record manually.
TIP:To convert multiple adapter records one at a time, select each adapter record while pressing and holding down the Control key. Then choose Remoteboot | Convert Adapters. To convert all adapter records, just choose Remoteboot | Convert Adapters.
Now that you have created these configuration programs, you probably will want to install some software for them to use—maybe Windows 3.x or Microsoft Office.
First, you must install the application files on the server. For this example, use Windows 3.x. Follow these steps:
- Boot the client workstation and sign on with an Administrator account.
- Insert the Windows installation disk (or other application disk) and run the network version of the setup program. To run the Windows network installation program, for example, type setup /a.
- When prompted for an installation directory, specify C:\WIN. This copies the expanded files into the RPLFILES\BINFILES\WIN subdirectory. For an application, specify C:\WIN\AppName, where AppName is a unique name.
TIP:If you are installing an application that is already expanded and does not require any network-configurable parameters, you can just copy the files without running through the network installation process.
Second, you must install the files in the client profile configuration. This configuration can be a shared configuration profile, in which case all users of the configuration profile benefit, or a personal configuration profile, which is unique to that individual. Follow these steps:
- Boot the client workstation and sign on with an Administrator account.
- Change to the Windows directory (type CD C:\WIN).
- Type setup /n and press Enter to run the network client installation. Do not upgrade the installation; instead, just choose the Express installation.
- Install Windows in the C:\WINDOWS directory.
- Copy all the files in the C:\WINDOWS directory to the C:\WKSTA.PRO\WIN directory by using the following command:
XCOPY C:\WINDOWS C:\WKSTA.PRO\WIN /E
This copies the files to the configuration profile and enables all users of this profile to run the application.
TIP:To install additional applications, perform the same steps, but install to a subdirectory of the C:\WINDOWS directory. If you performed a network setup for Microsoft Office to the C:\WIN\OFFICE directory, for example, when you run Setup, specify C:\WINDOWS\OFFICE as the destination directory. Then copy the OFFICE subdirectory files to the C:\WKSTA.PRO\WIN\OFFICE subdirectory.
Summary
This chapter covered many of the administrative duties you are required to carry out on a day-to-day basis. You first learned about Server Manager, which you use to create your computer accounts, synchronize the domain account database, perform remote management of your network clients' shared directories, perform remote service configuration (which includes enabling the Directory Replicator Service to copy your logon scripts to other servers), and perform remote resource accounting of your network clients.
You then learned about using the Event Viewer to keep track of system events that have occurred on your server. This chapter discussed the basic usage of this tool and provides a means for you to archive the data for future reference.
This chapter discussed the Repair Disk Utility, which is used to create and update the Emergency Repair Disk necessary for repairing failed NT installations.
Your final stop was a look at managing your workgroup post office, and using the Remoteboot Service to support your diskless workstations.
| About us | Categories | New Releases | Most Popular | Web Tutorial | Free Download | Drivers |
|
