[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 r2r@winntmag.com. 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.
—Larry Lai
llai@ats.com
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).
—David Capeci
dcapeci@harleysvillegroup.com
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.
—Mark A. Medici
mark@dbma.com
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.
—Phil Mongelluzzo
phimon@snet.net
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.
—Thomas Schuy
thomas.schuy@zeda.de
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.
—Nick Baldwin
nick@nbit.freeserve.co.uk
Prev. page
[1]
2
next page 
