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.
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.
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.
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 networkin particular the domain controllersto 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:
Specify the name of the computer account to create.
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.
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.
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:
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.
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:
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:
To promote a BDC to a PDC, follow these steps:
All network connections to the existing PDC and the machine begin promoted to PDC will be closed.
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.
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.
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.
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:
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.
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."
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.
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:
The Server Manager can be used to see which resources a user is attached to.
The Server Manager can be used to see which users are attached to a particular share.
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.
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:
The Directory Replication window can also be used to specify the location of you logon scripts.
NOTE: When you configure the replication service to start, it creates a special share, called REPL$, based on the directory you specify as the logon script path. Generally, this is %SystemRoot%\System32\REPL\Export.
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.
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.
The Manage Export Directories window is used specify subdirectories to export, as well as monitor replication locks.
For each subdirectory entry, you can see some status information by looking at the following columns:
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.
This process is quite similar to exporting a directory tree. From the Directory Replication dialog box, follow these steps:
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.
The Manage Import Directories windows is used to specify subdirectories to import, as well as monitor locks.
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.
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:
The Alerts section of the Server Manager is used to specify administrators who should be notified when something goes wrong.
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.
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.
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.
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. |
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:
Event filtering is useful for finding desired items.
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.
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.
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:
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.
To install the Repair Disk Utility, follow these steps:
The All Users profile contains a Programs icon, which contains common Start menu items for all users on the system.
The Administrative Tools folder contains shortcuts to many of the NT administration tools.
RDISK now appears with all the other administrative tools in the Start menu, as shown in Figure 15.21.
The shortcut to the RDISK utility now appears with the rest of the shortcuts in the Start menu.
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.
The RDISK utility is used to create and update the ERD.
The Repair Disk Utility dialog box has four buttons:
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.
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 doesnt 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.
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 post office is an easy task, but keep the following considerations in mind:
To create your workgroup post office, follow these steps:
Use the Microsoft Mail Postoffice Control Panel applet to create a workgroup post office.
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.
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 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:
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.
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:
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 cant 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 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.
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.
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:
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.
ATTRIB +h +s IO.SYS
ATTRIB +h +s MS-DOS.SYS
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:
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.
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:
You must enter information about each Remoteboot workstation.
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.
To create a new workstation record automatically, follow these steps:
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.
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 usemaybe 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:
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:
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.
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.