Reader to Reader - October 1998 - 01 Oct 1998

[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 protected]. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll get $100.]

For an unknown reason, TCP/IP commands on my Windows NT server were taking a long time to execute. For example, ping 127.0.0.1 took from 70 seconds to 100 seconds to get going.

I tried shutting down as many system components as possible, but it made no difference. I tried reinstalling TCP/IP and then the network adapter, but to no avail. I then installed both Service Pack 3 (SP3) and the Roll-Up hotfix, with no improvement in performance. At that point, I began wondering whether Internet Explorer (IE) 4.0 was causing the problem. I decided to investigate, although I wasn't too hopeful because I had installed IE 4.0 on other servers and they weren't experiencing the problem.

In my investigation, I first used the Dependency Walker utility (depends.exe) from the Microsoft Windows NT Server 4.0 Resource Kit to get a list of .dll files that ping uses. I then used the resource kit's File and Directory Comparison utility (windiff.exe) to compare the System32 directory contents of the server in question with the System32 directory contents of another server that ran IE 4.0 but didn't have the problem. I filtered the Comparison utility's output to show only those .dll files that were different. Finally, I produced a list of .dll files that were common to the outputs of both utilities. The list of .dll files that were common to both utilities contained only three .dll files.

One at a time, I ran the three .dll files from the normal server on a second installation of NT (always a good idea, especially if you can install the software on a different controller, drive, or partition). By comparing the results of these tests with the results of the Dependency Walker utility, I tracked the offending file: wsock32.dll. The tests identified the normal server's .dll file as 4.00 and the slow server's .dll file as 1.0. The 1.0 .dll file was rws32.dll in disguise and claimed to be part of Proxy Server. I don't know how this .dll file got on the server.

My experience has taught me an important lesson: If you have a resource kit, take the time to find out what's in it. In the long run, this time investment will pay off.

—David Barnes
[email protected]

Another Way to Connect to a Network Resource
Shawn Bayern's tip "Poor Man's SU Utility" (Reader to Reader, July 1998) describes how you can use the NET USE command to connect to a network resource. However, this approach is useful only for tasks that require file access. Another approach is to connect to a remote machine's IPC$ share as an administrative user. This approach gives you administrative permissions so that you can remotely perform tasks, such as editing the Registry or using Server Manager.

For example, after I removed software from a client PC, the PC didn't display the desktop after I logged back on. I couldn't do anything locally on the machine to fix the problem because the GUI was inaccessible. So from another desktop, I connected to the PC's IPC$ share with an administrator account, then used regedt32 to remove the fault service entry. After I rebooted, the PC worked fine.

—Troy Bruder
[email protected]

Use the LSA to Control NT Services
You can configure Windows NT so that an NT service runs as a Local System service or as a specific user. Most NT systems administrators run NT services as Local System services. However, many of these administrators don't understand the privilege status of a Local System service because the documentation is unclear about whether a Local System service has administrator or guest account privileges.

When you run NT services as a specific user, there is no ambiguity about privileges because you control the NT service's privilege status. To change an NT service's privileges, you simply change the user's privileges. You can use the Local Security Authority (LSA) to programmatically make changes, such as adding user privileges. User privileges you might add include Act As Part of Operating System and Log On As Service.

LSA is a protected subsystem that maintains information about a system's local security policy. In addition to housing policy information, the LSA provides various services for translations between names and identifiers. For example, LSA translates names to security IDs (SIDs), SIDs to names, privilege programmable names to logon user IDs (LUIDs), privilege LUIDs to programmable names, and privilege programmable names to displayable names.

Adding privileges programmatically with LSA can be a bit tricky because you are giving the user a new privilege rather than enabling a privilege that already exists. So you need to be careful about where you add privileges. For example, suppose you have an NT domain in which you installed an NT service under a particular user in the Security Accounts Manager (SAM) domain. You added the user credentials and the user, ournewuser. Now you want to add the Log On As Service privilege to the user. Although ournewuser is in the SAM domain, you can't add the privilege to the Primary Domain Controller (PDC). You must add the privilege to the LSA of the local machine (i.e., the machine that is running the service) because the privilege belongs to the user and the machine. If you don't add the privilege to the member server's LSA, the locally installed service won't be able to log on.

To add the Log On As Service privilege to ournewuser, you need to download code from the Windows NT Magazine Web site (http://www.winntmag.com). Listing 1 contains an excerpt from this script. The LSA code determines the type of server you're using and obtains the user SID and a Local Policy Object in the form of a standard Windows Handle for the machine. The user SID and Local Policy Object are necessary to add the privilege via the LsaAddAccountRights API. The code demonstrates some LSA programming techniques, such as how to make an LSA_UNICODE_STRING structure from a string and how to obtain the Local Policy Object's Windows Handle.

When you use the LSA code, you might encounter problems. For example, you can activate some privileges instantly (e.g., Log On As Service). But for other privileges (e.g., Act As Part of Operating System), you must log off and log on before the service is active. If you run into problems, you can refer to the online Help in the Win32 software development kit (SDK). The lsasamp sample application and documentation are especially useful.

—Mark Stretch
[email protected]

Use the FOR Command with an /F Parameter
In "Automate Repetitive Tasks in NT" (Reader to Reader, April 1998), Shawn Bayern provides a task automation script that uses the FOR command with a list of devices in parentheses. We have developed a similar script, task.cmd, that calls a file, server.lst, containing the list of devices. The advantage of keeping the list of devices in a separate file is that you need to maintain only one list of devices instead of maintaining the list in each script.

As Listing 2 (page 54) shows, the task.cmd script uses the FOR command with an /F parameter. This parameter lets the command access the server.lst file in Listing 3 (page 54). The script then calls a subroutine to perform the task on all the devices listed in the server.lst file. The subroutine displays the device it is working on, performs a dir command on a directory, and sends the results to a file. The script keeps looping through the server.lst file, applying the task to each device listed, until it gets to the end-of-file (EOF). For explanations of the command and parameters used in this script, you can type

FOR /?

at the command prompt.

When using the FOR command with the /F parameter, you can accomplish a lot of work in a short amount of time. The scripts we've developed help us support hundreds of servers.

—Lavon Fischer
[email protected]
Terry Acker
[email protected]

An Unlikely Cause of Blue-Screen Errors
I recently experienced a rash of blue screens of death on my Windows NT Workstation 4.0 machine. My machine started up without incident, but after an hour (sometimes less), I received blue-screen errors, such as IRQL_NOT_LESS_OR_EQUAL and PAGE_FAULT_IN_NONPAGED_AREA. When I turned off the machine for a while, it started and ran again without incident for about an hour.

I spent 3 days trying to find a cause for these blue-screen errors. I searched Microsoft's Web site, checked all my manuals, and searched past issues of Windows NT Magazine. Eventually, I discovered the problem: My CPU fan had become detached from the chip. Now my problem made sense. My machine worked until the CPU heated up, causing the blue-screen errors. When I turned off the computer, the CPU cooled, and the machine worked the next time I started it.

This problem caused me not only mental stress and strain, but also many lost hours of productivity. By sharing my experience, maybe I can save at least one fellow administrator from going through the same ordeal.

—Dianne M. Daniels
[email protected]

Logging Share Permissions
At a client site, I've occasionally needed to reproduce share permissions because of an accidental deletion or hardware failure. Unlike NTFS file and directory permissions, share permissions are easy to inadvertently change. One wrong click of the mouse can leave users without access permissions at the share level.

Although inadvertently changing permissions is easy, reconstructing the permissions is not. The task of reconstructing permissions becomes even more challenging when systems administrators make undocumented permissions changes.

To help with this task, I wrote a script, logshares.bat, that logs share permissions. Listing 4 (page 54) contains this script. Now reproducing permissions is straightforward. I hope the script saves you as much work as it has me.

—Douglas L. Gillett
[email protected]

Bye Bye Big Blue
My small company has a directly routed connection to the Internet, complete with Domain Name System (DNS). Fifteen employees are regular road warriors. When on the road, they use a long-distance dial-up service to receive Post Office Protocol (POP)-based mail from the company's Internet Service Provider (ISP). Unsurprisingly, my phone bills are high.

To reduce costs, I decided to find an international provider that could supply local dial access numbers for these 15 road warriors. I contacted IBM about its IBM Internet Connection Services. I discovered that this service doesn't support small businesses. Therefore, I had only two options: personal accounts and corporate accounts. Because the corporate accounts have all the bells and whistles (e.g., Web hosting), the cost was much more than I cared to spend. So I decided to go with the personal accounts. Little did I know that I would go through a lengthy registration process for each of the 15 road warriors.

The last straw was when I learned that IBM wouldn't let the road warriors connect to IBM's POP servers when they were working at the office on the company's routed LAN. IBM expects these 15 users to manually edit their POP/Simple Mail Transfer Protocol (SMTP) properties every time they leave and return to the office.

That's just not going to happen. Bye bye, IBM. You blew it.

—Elliot Ross
[email protected]

Another Trick of the NT Trade
In "A Trick of the NT Trade" (Reader to Reader, June 1998), Jeremy Brandt describes how to use the SUBST command to map a drive letter to a share's subdirectory. You can use this technique to map home drives. Another workaround is to share out the individual user directories and then update the Uniform Naming Convention (UNC) path in User Manager for a particular home drive (i.e., \servernameusername). When users log on to a Windows NT workstation, they will get the home drive you specified.

If you use logon scripts for Windows 95, Windows for Workgroups (WFW), or DOS clients, you can use the command

'NET USE H: /home'

to map the H drive. If your company's policy is to not have all user directories displayed in a browse list, you can create a share name and append the $ character to it.

—Larry Dragich
[email protected]