[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 kbemowski@winntmag.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.
—Larry Dragich
dragich@mich.com
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.
—Dan Bohman
dan.bohman@crown.com
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.
Prev. page
[1]
2
next page 
