\[Editor's Note:Share your NT discoveries, comments, experiences with products, problems, and solutions and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to Karen Bemowski at email@example.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
When rolling out system policies in a large network environment, having a plan that details who will manage the policies and how to manage them is helpful. When you are creating this plan, keep in mind eight tips.
Tip 1. Back up ntconfig.pol (Windows NT) or config.pol (Windows 95). Always keep the last .pol file as a backup in case the users' local Registry corrupts. Using the existing .pol file to fix the problem might not work because that file might have caused the corruption. When you use the backup .pol, you might need to re-create user profiles.
Tip 2. Always use the same templates. If you have five templates loaded in the System Policy Editor (SPE), make sure you have the same five templates loaded when editing the .pol file. If you reconfigure an existing .pol file but neglect to include a previously loaded template, that file will lose the existing configurations that the previous template created.
Tip 3. Set the options properly. Make sure you have selected the system policies options you want. If you decide not to set a particular option, make sure the check box is gray, so that the domain controller uses the previous configuration for that option. If the check box is clear, you will inadvertently change the previous configuration of the system policies file.
Tip 4. Keep it simple. Minimize the number of specific user and specific computer entries in the system policies. An effective minimization approach is to first create one standard system policies file for all users by editing the default settings, and then create settings for specific users on an exception basis.
Tip 5. Don't copy a .pol file into %systemroot%\system32\repl\import\scripts on the domain controller until you're certain it works correctly. The workstation automatically searches for .pol files in the Netlogon share, so once you copy a .pol file into %systemroot%\system32\repl\import\scripts, the file is live, ready or not.
Tip 6. Label your global groups. Edit the description to all global groups in the system policies file to include \[POLICY\] as the prefix. This way, administrators will immediately know the groups in that system policies file.
Tip 7. Print a document containing the group priorities for each .pol file for easy reference. If you have more than one .pol file, label each list in every file.
Tip 8. Allow only network administrators access to SPE. To avoid unauthorized access, do not install SPE on users' computers. In addition, to prevent users from installing SPE, restrict their access to source files.
If you run into problems after planning and implementing your system policies, don't despair. Microsoft's Zero Administration Kit (ZAK) documentation has a helpful section on troubleshooting system policies. (For more information about ZAK, go to Microsoft's Web site, http://www.microsoft.com/windows/zak/default.htm.) Before you start the troubleshooting process, go through the following checklist.
1. Check to see whether you used the right SPE. You must use only the Win95 SPE to create the config.pol file and only the NT SPE to create the ntconfig.pol file. Otherwise, unpredictable results can occur.
2. Check for user policies. The settings in users' policies override the corresponding settings in groups' policies.
3. Check for multiple system policies for the same Registry key. When multiple templates configure the same Registry setting, multiple policies can result. When multiple policies exist, the system policies file listed last in SPE is the one that the domain controller will follow.
4. Check for binary keys. System policies can't configure information stored in a binary key. If an application stores data in a binary key, you cannot configure that data through SPE.
5. Check the replicated .pol files. In a large network with multiple domain controllers, NT spreads the load over all the controllers. When NT spreads a load, it replicates ntconfig.pol to the logon shares of the domain controllers. If you have multiple domain controllers, check the Microsoft Windows NT Server 4.0 Resource Kit to see whether you properly set up the directory replication function.
Consistency is the key to successful system policies. If you keep accurate records of your configurations and have a solid change control process in place, system policies are powerful and much safer to use than editing the Registry manually.
Resetting User Settings
In "Modify Windows NT Script to Work with NetWare Clients" (Reader to Reader, March 1998), Lenny Zeltser provides an alternative script to the script Steve Hong presented in "Tip for NT Administrators" (Reader to Reader, October 1997). Steve's script changed the username back to the user's logon after a systems administrator had logged on to the machine to perform administrative tasks. Lenny's script modifies the appropriate Registry key so that Steve's script works when there's a Novell NetWare client on the workstation.
I ran into a different problem with Steve's script when trying to implement it on a NetWare network. The systems administrators at my company must log on to the local workstation as Administrator. (They don't have Administrator privileges on the domain.) When they log off, the workstation is not ready for the user to log on to the domain. Listing 1 contains my solution to this problem. I place this script on the network in a location where all users have it in their PATH statement. That way, before the systems administrators log off,they just go to the Run command and enter setuser and the string for input.
Bug in HP Print Servers
Several models of external HP print servers contain a firmware bug that prevents them from printing large documents in a Windows NT network using the IPX/SPX protocol and Service Pack 2 (SP2) or SP3. This bug affects HP JetDirect 150EX, HP JetDirect High Performance, and possibly other models.
HP internally refers to the bug as the 20-page plus problem because it appears to affect documents that have more than 20 pages. In reality, the printer's limit is about 1MB of output, regardless of the number of pages.
When you send a print job 1MB or larger to an affected print server, the printer will print the first few pages, stall, then reprint the first few pages two or three more times. This problem also occurs when you send several smaller print jobs to the print server at about the same time.
You can work around the problem by configuring the print server to use the TCP/IP or Data Link Control (DLC) protocol instead of the IPX/SPX protocol. However, HP JetDirect 150EX doesn't support TCP/IP and DLC, rendering the 150EX useless to NT users with SP2 or SP3.
Installing DLC on NT automatically installs print server support for the HP JetDirect High Performance print server. To use TCP/IP printing support, you need to install the software that HP ships with the print server. (HP also ships TCP/IP in case you haven't already installed it on your network.) Both protocols work, but I found DLC to be more stable than TCP/IP.
My experience with HP printing software (for both NT and Windows 95) has taught me to stick with drivers included with the operating system (OS) if possible. Even if HP wrote the native drivers, the software that ships with the OS is typically more reliable because Microsoft performs compatibility testing.
HP's first-level technical support staff isn't well informed about the 20-page plus problem, so you'll likely need to talk with a second-level technical support staff member. HP admits that the 20-page plus problem exists but doesn't currently have a firmware update. However, HP let me replace the 150EX models with the High Performance models.
Magazine Needs a Hotfix Column
In "NT in Hackers' Crosshairs" (NT News Analysis, June 1998), Craig Barth raised an important point: As Windows NT 4.0 is maturing, Microsoft is generating an increasing number of hotfixes. One aspect of the hotfixes is worrisome. Some fixes correct problems, but Microsoft posts them with the disclaimer that, because the hotfixes aren't fully tested, you might want to wait for the next service pack. However, years can pass between service pack releases.
The inclusion of a hotfix column in Windows NT Magazine would be extremely useful in the interim between service packs. A column similar to Mark Minasi's "This Old Resource Kit" could provide insight into available hotfixes, what problems they correct, and any prerequisites or other important information you need to know before you apply them.
An Easy Connection
In my company's Windows NT environment, users log on to the network with a regular user ID to get to their home directories on the server. This ID doesn't give them administrative privileges to the server hosting their home directories. Certain users, however, need to connect to an administrative share (e.g., c$) on that server. Typically, these users first have to disconnect the existing mapping to the home directories on that server and then make a Uniform Naming Convention (UNC) connection to the administrative share using an administrator account and password. If they don't disconnect first, they get the error message The credentials supplied conflict with an existing set of credentials.
I recently found an easier way to connect to an administrative share without having to disconnect the existing connection: Use the server's IP address (e.g., 184.108.40.206) instead of the UNC path (e.g., \\myserver\c$). The users simply type \\220.127.116.11\c$ to connect to the server's c$ share without having to disconnect first.
Customize Your Screen Savers
While I was working as an MCSE and systems engineer for Sarcom, a user at a client site requested that I set up a screen saver on every desktop. (Users did not have access to Display in Control Panel.) I wrote a system policies template to implement a standard screen saver. Listing 2 contains an excerpt from this template. (You can find the entire script on Windows NT Magazine's Web site at http://www.winntmag.com. Enter 3799 in the instaNT Doc text box.)
This template lets you select and customize any standard Windows NT screen saver. The interface is simple. The Screen Saver tab in Display provides options for setting up the screen saver. You select the screen saver you want to run (under Settings, you can customize each screen saver), timeout period, whether to make the screen saver active, and whether to make it secure. I recommend that you try the screen saver on a desktop before you implement the policy settings.
More on FOR
After reading Shawn Bayern's tip on how to use the FOR command to "Automate Repetitive Tasks in NT" ("Reader to Reader," April 1998), I want to share a trick I often use. Between Windows NT 3.51 and NT 4.0, Microsoft added many features to the FOR command. One new feature is the command's ability to read in lines from a delimited file and use the various fields to populate a command-line program's arguments. I often use this feature when I must add many new user accounts.
For example, Listing 3 contains a delimited file (users.txt) that uses a comma (,) as a delimiter. This file lists the user IDs, usernames, locations, and passwords of several users. You can simultaneously create user accounts for these users with the users.txt file and this command script:
FOR /F "delims=, tokens=1,2,4" %I in (users.txt) do net user %K password add /fullname:"%I,%J"
This script reads in the users.txt file line by line and populates the variables %I, %J, and %K with the values from the first, second, and fourth fields, respectively. If you want to include the location information in the comments field of the user accounts, you can use this command script:
FOR /F "delims=, tokens=1-4" %I in (users.txt) do net user %L password add /fullname:"%I,%J" /comment:"%K"
Because this script uses all four fields, the variables %I, %J, %K, and %L will get the first, second, third, and fourth fields, respectively. You can create home directories for these users and modify the access control lists (ACLs) on those directories using a similar command script:
FOR /F "delims=, tokens=4" %I in (users.txt) do mkdir \\server\homes\%I
NT 4.0's FOR command is a powerful tool. These examples illustrate only a few of the many ways you can use this command. FOR is a tool that many people tend to overlook.
A Good Tool Could Be Made Better
TechNet is an important tool in my work as an MCSE because it often has solutions to the operating system (OS) problems I encounter. However, Microsoft has not integrated all the great TechNet support information into its OSs. After viewing an error in the Event Viewer, I have to open up the TechNet CD-ROM application, perform a keyword search, and wade through the references the search produces.
This situation reminds me of when word processors and spell checkers weren't integrated. To find and correct spelling errors, you had to run a separate spell checker program. Eventually, vendors integrated the spell checker program into their word processing applications.
Microsoft should follow suit by integrating the TechNet CD-ROM application into its OSs. Then, for example, you could directly access related TechNet support information while viewing an error in the Event Viewer. This integration would reduce downtime for customers and reduce technical support costs for Microsoft.