| Downloads |
|---|
| 7665.zip |
\[Editor's Note: Share your NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
SQL Server 7.0 Backup Log
One of the differences between Microsoft SQL Server 7.0 and SQL Server 6.5 is that in SQL Server 7.0 you must be able to access the primary data file to execute a transaction log backup with the no_truncate option. If this file is corrupt, you can't perform a log backup to save the active transaction log. To minimize the risk of losing data, set up a user file group as the default file group. In this scenario, the primary data file contains only system objects. This tip is based on the assumption that the fewer I/O operations you perform on a file, the less likely you are to corrupt the file.
NT Print Server Fix
My company recently had a problem running Windows NT Server 4.0 on a print server for a site with more than 100 printers. We were using TCP/IP, and the printers were attached with internal NICs. Users reported that their print jobs were taking forever.
We investigated the problem and learned that Line Print Remote (LPR) in NT Server 4.0 Service Pack 3 (SP3) uses only 11 TCP ports (721 through 731), unlike SP2, which uses 512 TCP ports (512 through 1023). To fix the slow-printing problem, you need to change a Registry entry to let LPR use the high TCP ports (above 1024). Start regedt32, and go to the Registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LPDSVC\lpr for the print server you want to change. Set the value to 1 to use available TCP ports above 1024. (If the value is 0, the printer uses only TCP ports 721 through 731.) For more information about this fix, see the Microsoft article "Printing to LPD Printer Is Slow or Fails with Windows NT" (http://support.microsoft.com/support/kb/articles/q141/7/08.asp).
FTP vs. HTTP
Microsoft needs to reconsider its decision to stop providing access to service packs on its FTP site. Novice users might prefer to download service packs and hotfixes from Web pages, but FTP is a better method for experienced users. First, you can configure most FTP clients to automatically retry after logon failures (which are common at busy sites) so that you can continue working. Second, many FTP clients can download an entire directory structure as one operation, letting you focus on other tasks while you download service packs and associated hotfixes. Third, some FTP clients let you mirror an FTP site, so only changes on the FTP site transfer. This process saves time and conserves bandwidth. Finally, FTP is a more efficient protocol than HTTP and yields faster transfers and lower CPU and network-bandwidth utilization.
Those of us who use the Internet as a tool for information access look for the quickest methods to find and acquire the information we need. Although HTTP is sometimes the right tool, FTP is often quicker and more efficient.
LinkPro Red Alert
A few months ago, I purchased a copy of LinkPro Technology's PowerSync and paid $89 for an unlock code. The code worked when I initially installed the product. However, I tried to reinstall the software later, and I spent nearly 4 hours trying to figure out why the product wouldn't accept my code. I finally called the company and learned that you must obtain a new code every time you reinstall the software. You can load and use PowerSync without an unlock code for 30 days, but the product isn't completely functional until you obtain a new code.
I'm not an unreasonable person: I pay for all my software—even the $10 shareware programs. I have no problem paying $900 for StatSoft's STATISTICA. But I won't let LinkPro waste my time with its ridiculous unlock-code policy.
I called LinkPro and was finally able to obtain a copy of PowerSync (for a nominal fee) that didn't require an unlock code. Apparently, LinkPro requires unlock codes only for products that you download from its Web site—not for products the company ships to you.
Prevent Users from Closing the Command Window During Logon
If you have trouble with users not waiting for their logon scripts to end, you need a method to position the command window outside the visible screen and to minimize the window. The Windows NT .adm policy RunLogonScriptSync won't perform these actions because it simply waits until the logon script ends, then starts the shell. The Registry value that specifies the command window's position on the monitor typically doesn't appear. This value is an 8-byte hexadecimal value. The first 4 bytes represent the vertical position of the window, and the last 4 bytes represent the horizontal position of the window. The Registry value that specifies the size of the command window is also an 8-byte hex value. The first 4 bytes represent the number of characters that appear on each line, and the last 4 bytes represent the number of text lines on the screen.
I created a policy template (.adm file), which Listing 1 shows, that lets you hide the command window outside the visible screen and minimize the window. After the commands in the logon script execute, you can use the command regedit /s command-window.reg to reset the WindowPosition and WindowSize values to the defaults. The file command-window.reg contains the lines that store the Registry values for WindowPosition and WindowSize. If you want to prevent users from using Task Manager to cancel cmd.exe, you need to use the Windows NT .adm policy DisableTaskMgr.
Netlogon Network Traffic
Regarding Richard Adams' article about tuning Registry settings to cut network traffic ("Registry Tweaks to Tune Your Network," May 1999), I'd like to point out that a partial sync isn't always smaller than a full sync. I've often seen partial syncs in which the amount of transferred data is larger than the size of the SAM. This situation can occur because of the way the Netlogon service uses the change log.
A change log entry isn't the changed data but rather a pointer to the changed SAM object. When you add one user to a large group, the change log points to the group object and the whole group replicates to the BDCs. If you add several new users to existing groups, multiple entries for the same groups appear in the change log as you create the users. This occurrence causes the large groups to replicate multiple times during a partial sync.
The best way to avoid this traffic duplication is to create all the users first, then make the additions to each group in turn. This process makes the change log entries for each group consecutive. Netlogon will detect multiple consecutive entries for an object and will send the group membership only once.
Improved Exploring
If you try to use the command \\computername\drive$ from the Start, Run option to explore a drive on a network computer, you'll see only a collection of folders. Use the following .cmd file to improve you search. Create a *.cmd file (e.g., e.cmd), and fill it with the following string:
start explorer /e,/root,%1
Place the e.cmd file in your \winnt\system32 directory. Then click Start, Run, and type
e \\\drive$
WINS and LMHOSTS Again
I read both of Mark Minasi's articles about LMHOSTS ("Pick Users' Domain Controller," February 1999, and "More LMHOSTS Tips," June 1999), and I'd like to point out that LMHOSTS is only one way (and probably not the best way) to force a workstation to log on to a domain controller. Microsoft developed a tool called setprfdc.exe that does what the preferred server statement did in Novell NetWare net.cfg files for binary mode. When workstations log on to a domain controller across the WAN because the local domain controller is busy, setprfdc.exe forces connection to the local domain controller.
In my previous position with Microsoft Premier Support, I never created or modified a HOSTS or LMHOSTS file for a workstation. Instead, I used logon scripts to push the files from the domain controllers. The LMHOSTS file listed only the servers, in the order that I wanted the workstation to test for the servers' availability. I used WINS for most name resolution, but in a shop that runs Korean Windows 95 (i.e., Samsung), WINS gets corrupted frequently because of the nonroman characters in the NetBIOS names. Having an LMHOSTS file was necessary in this environment. In addition, logging on to the correct domain controller was mandatory because our domain was spread across the WAN.
To see which workstation OS is running, then copy the HOSTS and LMHOSTS files to the correct directory, use a logon script such as the one in Listing 2. I used logon scripts similar to this one to distribute antivirus software, Microsoft Office 95 and Office 97, Microsoft Outlook, and other applications. RAS users hated me because I tested to see whether they were using the company's standard antivirus software, and if not, installed the software on their home computers across the telephone line. But the company's network, not remote users' convenience, was my priority.
Response to "DMZ with Proxy Server 2.0"
Svyatoslav Pidgorny's advice in "DMZ with Proxy Server 2.0" (Reader to Reader, June 1999) is disastrous from a security standpoint. The purpose of isolating exposed machines on a network segment (i.e., demilitarized zone—DMZ) is to ensure that if one of the machines becomes compromised, an attacker can't use it as a staging ground for accessing internal workstations and servers. Svyatoslav's suggestion to eliminate the third network card and place the exposed DMZ machines behind a proxy server negates any security advantages a DMZ might offer. An attacker can easily change a compromised machine's routing tables to talk directly to the local network, bypassing any additional security the proxy server might try to impose.
In addition, although switched media (e.g., Ethernet) have performance advantages, they're no defense against network sniffing attacks. A determined attacker can fairly easily overload the switch's media access control (MAC) tables and cause the switch to start misdirecting or even broadcasting traffic.
Take Advantage of Administrative Shares
My organization frequently updates its proprietary software, and we need to distribute these updates to users' workstations. Instead of going to each workstation to download the updates, I created a batch file that takes advantage of the hidden administrative shares that install by default. I use this batch file, which Listing 3 shows, when I need to distribute files or folders to individual workstations. I put the paths in quotes so that I can use long filenames and folder names. To use the batch file in your environment, log on with administrative privileges and change the paths accordingly.
MFT Placement
In "Optimizing NTFS" (March 1999), Sean Daily stresses the importance of placing the Master File Table (MFT) at the beginning of your hard disk. You can use Symantec's Norton Ghost (the full or evaluation version) to quickly and easily accomplish this task. Make an image of your hard disk on tape or on a second physical hard disk. Then place the image back on the original hard disk. When you reboot, the MFT will be at the beginning of your hard disk. To verify the MFT's location, use a tool such as Executive Software's Diskeeper.
Terminal Server Solution
In "Novell Rescues NT Thin-Client Environment" (Reader to Reader, May 1999), Ken Mejias asked for a solution to the 2048 open file handles on Windows NT Server 4.0, Terminal Server Edition. WTS originally included Service Pack 3 (SP3), which doesn't provide a solution. But WTS SP4 includes a feature that lets client connections maintain 2048 open files instead of the combined 2048 limitation.
Ken needs to ensure that the server has SP4 or later installed. Then, start regedt32 from the server and go to the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Rdr\Parameters Registry key. Select Edit, Add Value, and add the value name MultipleUsersOnConnection, the data type REG_DWORD, and the data value 0.
For more information about this fix, see the Microsoft article "Terminal Server and the 2048 Open File Limitation" (http://support.microsoft.com/support/kb/ articles/q190/1/62.asp). Ken should also contact Citrix to see whether a similar fix exists for WinFrame products.
Corrections to this Article:- Listing 2 in Reader to Reader: "WINS and LMHOSTS Again" contains a script that includes the EXISTS command. The correct command is EXIST.
