| Downloads |
|---|
| 3012.zip |
\[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 (under 400 words) to Karen Forster at [email protected]. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.\]
The new HP Vectra VL Series 6 computers (generally 266MHz Pentium II) arrive configured with Windows NT 4.0 and either Service Pack 1 (SP1) or SP2. They also feature the Soft PowerDown Utility, which shuts the PC power off when the user selects Shut Down from the Start menu. If you install SP3, however, this utility might disappear. In some cases, when you select Shut Down, the HP Vectra restarts and then doesn't give you an option to shut down.
Although the Soft PowerDown Utility documentation states that you can use this utility with only SP1 or SP2, I have discovered a workaround for SP3. You need to use the file hal.dll dated October 21, 1996. After you install SP3, you will find the hal.dll file in the uninstall directory. (The file was originally part of the SP1 and SP2 upgrade.) Copy this file into the Winnt/System32 directory, and rename the original file in the uninstall directory. Then open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon in the Registry, and set the PowerdownAfterShutdown value to 1.
Now when you boot, NT startup will show the presence of SP3, hal.dll 2.0, and the Soft PowerDown Utility. When you select Shut Down from the Start menu, the PC will close NT and power down the CPU.
Enable the Shut Down Key
In Windows NT Workstation, the Shut Down button is available in the Welcome screen after you press Ctrl+Alt+Del to log on. However, in NT Server, the Shut Down button is not available by default.
You can display the Shut Down button by configuring the Registry. Follow these steps:
- Run a Registry editor (regedt32.exe).
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon.
- Double-click ShutdownWithoutLogon.
- Change the value of the string to 1 to make the Shut Down button available. (The value 0 disables the key.)
This tip works for NT Workstation and NT Server 4.0, 3.51, and 3.5.
A Windows NT Snob's Opinion
I read Kent Dahlgren's "A UNIX Snob's Opinion of NT" (Reader to Reader, October 1997) and couldn't believe that his gripes about Windows NT are still so petty. What happened to comparing operating systems based on their power and capabilities? NT has a long way to go before it surpasses UNIX in the ability to handle massive amounts of data and users, so why use the worst feature of any operating system (the command line) or the lack of certain utilities (such as the Telnet daemon) as a basis for comparison?
People who gripe that NT's command line stinks or that NT doesn't have a Telnet utility need to wake up. The tools available to most network administrators are GUI-based. Although the command line can do tasks that the GUI can't, the GUI makes my life easier. I can always use the Microsoft Windows NT Server Resource Kit tools or find a Telnet utility on the Internet, where I can find many commercial, shareware, and freeware tools to download.
I'm not telling anyone who uses UNIX to abandon ship. UNIX is a great operating system, so if you like it, keep using it. Just don't tell me that NT stinks because you don't feel comfortable with its command line or because it's missing a Telnet utility.
Map Your Drives with Policies
Many ways exist to map network drives. You can use User Profiles to map static drives, but you must set up the profiles manually. You can use Roaming Profiles, but you must set up and regularly maintain them. You can use the templates in Microsoft's Zero Administration Kit (ZAK), but none address network drive mappings--an area in which I had many questions. (For more information on ZAK, see Darren Mar-Elia, "Zero Administration Kit: The Answer to Your TCO Woes?" January 1998.)
Then I read "Guide to MS Windows NT 4.0 Profiles and Policies" (TechNet, November 1997). This excellent article answered most of my questions on the subject, except for one: Can I use policies to map network drives? Douglas S. Frisk's October 1997 article, "Using System Policy Templates" answered this question and inspired me to write a custom template, DriveMap.adm. Listing 1 contains this template. (You can download the template from the Windows NT Magazine Web site at http://www.winntmag.com.)
I have used the custom template to map three drives with defined network shares: Application, Public, and Shared. Screen 1, page 44, shows how this template looks now that I've added it to the System Policy Editor.
You can adapt this template to map your drives with defined network shares. Just use your favorite text editor to create a similar file, and add as many drive letters as you like.
Implement SPE Changes with Custom Template
After reading Sean Daily's article, "Set Sail for Uncharted NT Performance" (September 1997), I decided to create a policy template to implement several changes throughout the System Policy Editor (SPE). This template includes some of Daily's entries and others that I've found useful. (You can download this template and an overview of what it does from the Windows NT Magazine Web site at http://www.winntmag.com.)
This policy template requires instantiation for different machines on the network. My company uses a default machine (which represents all the workstations in the domain) and individual computer templates for domain controllers and member servers. I hid the default machine from the browser (Browsing Client category) and set the machine as Not a Browser (Browsing Server category). For the domain controllers and member servers, I created individual policies, which make them visible to the browser (Browsing Client category), and set domain controllers as Preferred Browsers and member servers as Potential Browsers (Browsing Server category). You control the Browsing Server category through the drop down list. Similarly, you control the system cache through the drop down list.
In the USER class, this template defines a category, Persistent Drive Mappings, to manage users' drive mappings on a per-user or per-group basis through the policies. This innovative, policy-based approach provides significant advantages over the standard approach to controlling drive mappings through the logon script.
As with any process involving modifying the Registry, make sure you back up the Registry before making any modifications. If you're uncomfortable manually creating policy templates, you can use Simac Software Products' Policy Template Editor (http://www.tools4nt.com) to create customer system policy templates.
Check the Connectivity and the Responsiveness of Your Network
I enjoyed Michael Otey's November 1997 VB Solutions column, "Building an Automated Mass Ping Utility." However, pinging machines to determine availability doesn't tell you whether the machine is responsive. A successful ping tells you only that physical connectivity to the machine exists. If the machine hangs, it might ping but not be accessible to your users. Only when a user calls will you discover that the machine isn't working.
I encountered this problem at a client site, so I developed a crude but effective batch file utility. By mapping to the drives on five target computers and running the batch file (which uses an IF EXIST test), you can check both connectivity and responsiveness of the mapped drives and directories. If a failure occurs, the utility uses a NET SEND command to inform the appropriate administrators. You select which machine to send the failure notifications to. (For information about NET SEND, see Mark Minasi, "Knowing the Angles of NetBIOS Suffixes," February 1997.) The utility also creates a log file (fail_log.txt) that details which target failed and when it failed. When you reset and restart the utility, it saves the log file for future reference under a new name (old_log.txt).
You can download the batch file utility from the Windows NT Magazine Web site (http://www.winntmag.com). This utility will test up to five targets, but you can modify the batch file to test more machines. However, you don't need to modify the batch file if your targets change, because information on the notification and test targets is passed to the batch file as parameters.
The batch file uses the sleep.exe utility from the Microsoft Windows NT Server Resource Kit to pause activity for 1 minute between tests, but you can change this interval. If you want the batch file to run in the background, you can create a shortcut to the utility and add the shortcut to your startup group, as Screen 2, page 46, shows.
Modify Windows NT Script to Work with NetWare Clients
In "Tip for NT Administrators" (Reader to Reader, October 1997), Steve Hong offered a script to solve a common problem for administrators: getting calls from users because they can't log on to their computers after an administrator logs on to those machines, performs administrative tasks, and then logs off. Although the fix is simple (users need to change the username back to their logon), you can use Hong's script to prevent this problem. The script changes the username back to that of the user.
Hong's script works well with the standard Windows NT Graphical Identification and Authentication DLL (GINA). But if you have a Novell NetWare client on the workstation, you need to modify the Registry key for the script to work. Listing 2 contains the modified script. (You can download the template from the Windows NT Magazine Web site at http://www.winntmag.com.)
You need to put this script into a public, shared area. Then when you log on to a user's computer, note the username. After logging on, enter SETUSER <username> from Program Manager, File Run, in NT 3.51 (or Start, Run, in NT 4.0). Finally, change the tmpfile to a local temporary file. Make sure regedit.exe is available in your path.
Install Identical Applications Quickly and Easily
Installing a third-party application on multiple Windows NT workstations can be time consuming, especially if you can't use a script to configure and execute identical copies on every machine. But you can speed the process by creating a standalone, portable .exe file that you can place on a shared drive. When this executable runs, it places the application's required files in the correct directories (creating the directories, if needed), creates the application's groups and icons, and updates the Registry. All you need to do is purchase the required number of licenses.
To create the .exe file, you need two software programs: Seagate Technology's Seagate WinINSTALL (http://www.seagatesoftware.com/wininstall) and Great Lakes Business Solutions' WISE Install for NT, Windows 3.x, and Windows 95 (http://www.glbs.com). I prefer WinINSTALL and WISE to other products because these two include Wizards and are fairly simple to use.
Suppose you want to install an application, DEMO1, on your NT workstations. You need to perform the following procedures one application at a time, with a clean install of NT Workstation each time:
- Build an NT workstation with no added applications (i.e., a clean system). Be sure to install the latest service pack if it is a desktop standard.
- Install WinINSTALL, and reboot to update the Registry.
- Open WinINSTALL, and run the Snapshot option. Snapshot records the clean workstation's hard disk and Registry.
- When WinINSTALL prompts you, specify a directory where you want to store Snapshot information. The best location is on a server that all desktops can access. Do not place this directory on the local machine.
- Install and configure the DEMO1 application. Make sure you configured the application correctly, because this configuration becomes the template for installing DEMO1 on the other workstations. Reboot the machine if necessary.
- Open WinINSTALL again, and choose the Discover option. Discover compares the current setup of the workstation's hard disk and Registry with the record captured previously with Snapshot. Discover then places copies of any new files (in this case, all DEMO1 files) in the directory you specified in step 4. Discover also adds a .reg file (which contains the Registry updates) and a .dat file (which is a log of all files, icons, and Registry changes).
- Install WISE. This program lets you create a self-extracting executable.
- Open WISE. When WISE prompts you, use WISE's scripting language to specify the location of DEMO1's files (by way of the share path), the group names and icons created by DEMO1 and where they point, the location of regedit.exe (i.e., the path on the machine where DEMO1 is to be installed on the workstations), and the .reg file that WinINSTALL created.
- Compile the script into a demo1.exe that anyone with administrator privileges on a workstation (local or domain) can run. Debugging messages will prompt you if you have syntax errors.
WISE offers numerous bells and whistles that you can use to fine-tune the .exe file. For example, you can provide installation standards (such as text and graphics windows) that pop up as the installation progresses, or you can add a percentage-completed bar that shows how far the installation has come along.
