Poor Man's SU Utility
\[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 Bemowski 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.\]
While logged on to a workstation with a user account, you might need to access that machine's drives as an administrative user. For example, on a user's workstation, you might need to modify files that the user account can't access. You can use the Microsoft Windows NT Workstation 4.0 Resource Kit SU utility to run a process as another user, but this utility can be unwieldy to set up and use. (For information about SU, see Mark Minasi, "SU," January 1998.)
An alternative is to use the NET USE command to connect to a network resource (such as a share), even if that resource is on your current machine. For example, you can connect to your machine's C drive as an administrator by typing the command
net use W: \\mymachine\c$ /user:administrator
This command maps the W drive to the C drive of mymachine. If you access the drive as W, you have administrative permissions. If you access it through C, you have the user account's permissions. If you open a window for W and another for C, you have side-by-side windows that have different privileges.
The NET USE command doesn't limit you to becoming another administrative user. You can become any user if you know that person's password. This flexibility can be useful. For example, you can test a program as a user to make sure the program's access control lists (ACLs) are set up correctly. To become another user, specify that person's user account in the NET USE command. However, user accounts cannot access administrative shares, so you must set up shares manually if you want to access them as non-administrative users.
When you complete your task, discontinue the mapping. Type the command
net use w: /delete
Adapted Template Prevents Potential Side Effect
In "Implement SPE Changes with Custom Template" (Reader to Reader, March 1998), Alex Zarenin shared a system policy template for controlling browser service parameters. The template lets you define systems as Not a Browser, Potential Browsers, or Preferred Browsers, and hide systems from the browser.
I realized that the template might cause a side effect that I encountered implementing a similar policy on my Windows NT systems. The problem occurs when you configure a system as Not a Browser (MaintainServerList=No). This setting causes the browser service to fail when a user tries to start an NT system. The Service Control Manager generates a message box and event log entry for the error. Although benign, such a message can alarm users.
You can fix this problem by revising the system policy template to control the Startup Type value for the browser service. The revised template sets the Browser Service Startup Type to disabled when you configure a system to function as Not a Browser, preventing unwanted error messages from disturbing users. You can download this template from http://www.winntmag.com/magazine.
Use SPE to Customize Your Logon Information
After reading Steve Thomas' article "Uncovering New Settings in the Registry" (March 1998), I decided to customize the Begin Logon, Logon Information, Workstation Locked, and Unlock Workstation dialog boxes in my Windows NT system. I wanted to configure these dialog boxes to include a company greeting, like that shown in Screen 1, page 48.
I wrote a custom template, logonmsg.adm, to change the necessary Registry settings. Listing 1, page 48, contains this template. Rather than using the standard Registry editing tools to implement this template on the many workstations in my company, I used NT's System Policy Editor (SPE) because SPE is easier to use and more efficient. Screen 2 shows how SPE looks now that I've added the template.
If you want to use logonmsg.adm but are an SPE novice, Microsoft's Zero Administration Kit (ZAK) is a good place to start. You can download ZAK for free at http://www.microsoft.com/windows/platform/info/zakdemo.htm. (For more information on ZAK, see Darren Mar-Elia, "Zero Administration Kit: The Answer to Your TCO Woes?" January 1998.)
In the Reader to Reader tip, "Hosting Multiple DNS Names with One IP Address Is as Easy as 1, 2, 3" (January 1998), Paul Noeldner explained how you can use the Active Server Pages (ASP) variable, Request.ServerVariables("HTTP_host"), to redirect incoming requests from Web users. However, the tip didn't mention an important detail.
Because the client, not the server, supplies ASP request object variables, the Domain Name System (DNS) names are not case sensitive--but Visual Basic (VB) string comparisons are. So, in your ASP code, you must use the LCase() VBscript function on the server name. Otherwise, whatever the user types in is exactly what is passed into that variable. So, if a Web user types in http://another.DNS.COM instead of http://another.dns.com, the tip won't work. In addition, you need to use OR clauses in your IF statement to handle users who are connecting by IP address or by LAN broadcast-resolved NetBIOS names.
Alternatively, you can use Request.ServerVariables("HTTP_host") as a dynamic configuration variable to get your ASP applications to automatically configure. For example, my company has several ASP applications on development, testing, and production servers. I can run the same ASP code on all the servers by using Request.ServerVariables("HTTP_host") to set pagewide or sessionwide variables.
Listing 2, page 50, is an example of ASP code. The CASE statements use a comma-delimited list to let you use server name variations. This capability is useful if you have a machine that goes by several DNS names. For example, the code in Listing 2 will send all of these URLs to the same place:
Maintaining NT in the Lab Environment
In my Windows NT lab, I frequently make simple changes (e.g., changing the Registry and adding and modifying files) to each machine. I found that utilities such as Ghost Software's GHOST are wonderful for initial installations but are not suitable for daily administration tasks. A better-suited tool for maintaining large numbers of identical NT machines is Pyzzo Software's PC-Rdist (http://www.pyzzo.com).
PC-Rdist maintains a standard set of files and settings on multiple computers across a network. PC-Rdist runs on the client machines and compares files and settings on the local computer to master copies on a server. To change or add a file, you just change the master image. PC-Rdist also moves files that users add to a temporary directory or deletes these files, replaces files missing on users' PCs, updates the local Registry, and restores system settings. You can configure the clients to regularly check and update files.
This tool will not set up the machines from scratch, however. You still need a utility such as Ghost for the first pass. After that pass, PC-Rdist greatly simplifies your daily administration tasks.
Workaround Needed for Toshiba Laptop
I use a Toshiba Tecra 750CDT laptop computer daily as a domain administrator for AT&T. I configured the laptop to run Windows NT 4.0, Service Pack 3 (SP3). I loaded all the Toshiba drivers from its Web site, including NT subsystem drivers and hardware utilities and Toshiba's Advanced Power Management (APM) utilities and drivers. I now receive error messages when I start the machine and when I run 16-bit applications. The messages always involve the scivdd.dll file, which the Toshiba drivers installed.
I made several calls to Toshiba for a fix. The representatives said they had never heard of this problem, but assured me that they would "escalate the issue to the next level." After about 5 weeks, a technician asked for information so that he could reproduce the error in Toshiba's lab. He generated the same problem and passed the error data to the next level.
Meanwhile, I have found Knowledge Base article Q155726, "Scivdd.dll Generates Error Messages at Windows NT Startup" on Microsoft's Web site (http://support.microsoft.com/support/kb/articles/q155/7/26.asp), which discusses this problem. The article states that Toshiba's scivdd.dll file, which runs the laptop's APM features, doesn't run in NT 4.0. To solve this problem, the article tells you to install NT 4.0 to a clean folder and contact Toshiba for more information.
I can't be the only person running NT on a Toshiba laptop. Does anyone have a workaround to this problem?
Use a .bat or .cmd File to Simulate Single-User Mode
I'm a systems administrator at EDS. People ask me whether Windows NT has the equivalent of UNIX's init 1 command to take an NT system into single-user mode. You can use a .bat or .cmd file to simulate single-user and multi-user modes. You can even name the file init.cmd and accept arguments of 1 and 3 to shut down and start up all networking services. Listing 3 contains an example of init.cmd. You can enhance this file to add more error handling if needed.
During installation of a Windows NT network, I encountered two problems. The first occurred when I was using Ghost Software's GHOST to duplicate workstations (http://www.ghostsoft.com/main.htm). After I made a copy of the master workstation to serve as a template, I renamed that workstation, rebooted, and created a new domain account. I thought this process was generating a new security ID (SID). (For more information about SIDs, see Mark Russinovich, "Windows NT Security, Part 1," May 1998.)
At two NT sites, the network seemed to be OK. But when I tried to use logon scripts to control users' drive mappings at the third site, the logon scripts worked on only one workstation. Using GHOST Walker, I found that all the workstation SIDs were identical. After I changed the SIDs, the logon scripts worked.
I had thought SIDs had to be unique to connect to a server. However, many NT network functions can run on workstations with identical SIDs. At one point, I had about 30 workstations with identical SIDs operating without problems.
I encountered another installation problem when I tried to use Traveling Software's LapLink for Windows NT to remotely control the server consoles and to replicate directories between servers
(http://220.127.116.11/products/travelling/index.htm). The scheduler in LapLink for Windows NT doesn't work. I called Traveling Software's support, only to hear that no workaround exists. After experimenting, I was able to use WinAt to schedule the LapLink transfers.
Three Suggestions for Microsoft
I want to run Internet Information Server (IIS) 4.0 on my network. Although I have Internet Explorer (IE) 3.02, IIS 4.0 requires IE 4.0. I have tried many times to install IE 4.0 on my Alpha-based (Digital Server Model 800) server running Windows NT Server 4.0, Service Pack 3 (SP3), but to no avail. The install goes to about 3 percent, then skips to the end, showing red Xs instead of blue check marks. I consistently get the error message: The install didn't work. Reboot and try again. If that doesn't work, try redownloading the software. Based on this experience, I have three suggestions for Microsoft:
- Create error messages that state why an install failed. Otherwise, these messages are useless.
- Create error messages that use the correct terminology. The term redownloading doesn't make sense. It means "to download the software again," but if the install fails, you haven't downloaded the software in the first place. So how can you install it again?
- Remove IIS 4.0's requirement to have IE 4.0 installed. This requirement has no reason to exist. Microsoft is obviously attempting to force people to use IE 4.0. In addition, if customers want to install IE 4.0, they should be able to install it where they want. (I usually don't manage servers from my console, so I don't want to install IE 4.0 on my server.)
I'm venting my frustration. However, I also want to warn Alpha users who are considering implementing IIS 4.0.
Microsoft Is Stressing Its Non-Disclosure Agreement
Sean Daily's excellent article, "The Value of the MCSE Credential" (March 1998), addressed the controversy of paper Microsoft Certified Systems Engineers (MCSEs). The article commented on the fact that certification preparation has evolved from classroom courses and self-study guides to crash courses and cheat sheets.
Apparently, Microsoft is attempting to nip paper MCSEs in the bud by stressing its Non-Disclosure Agreement (NDA) for exams. I recently became aware of this NDA when I was preparing to take another Microsoft exam. The person registering me asked whether I had read and agreed to Microsoft's NDA policy. I was not aware of this policy, so I investigated and found the following disclaimer online (http://www.microsoft.com/mcp/articles/nda.htm):
"This exam is Microsoft confidential and is protected by trade secret law. It is made available to you, the examinee, solely for the purpose of becoming certified in the technical area referenced in the title of this exam. You are expressly prohibited from disclosing, publishing, reproducing, or transmitting this exam, in whole or in part, in any form or by any means, verbal or written, electronic or mechanical, for any purpose, without the prior express written permission of Microsoft Corporation."
Perhaps Microsoft has learned from Novell's mistake with the Certified NetWare Engineer (CNE) program and is trying to solve the problem before MCSE loses its stature. Although stressing the NDA probably won't stop companies from providing crash courses and cheat sheets, at least it's a stance for integrity.