Mailto Address List Truncated
When you click a Mailto hyperlink for a recipient address list that exceeds 260 characters, Windows NT 4.0 truncates the string to 260 characters before passing it on to Outlook or Outlook Express. The URL travels to the NT 4.0 shell function ShellExecute which creates a process for the mail client. The Shell function passes the address list as a parameter, and the variable that the parameter uses has a fixed buffer size of 260 bytes. No fix is available for this problem. Microsoft suggests that you replace the long Mailto string with a distribution list name to work around the problem. See Microsoft article Q269272 for details.
New NT 4.0 Post-SP6a Fixes
The following recent bug fixes for Windows NT 4.0 Service Pack 6a (SP6a) address/correct a remote procedure call (RPC) code memory leak and an NTFS problem.
- RPC memory leak. Microsoft article Q265433 documents a potential RPC code memory leak. The private bytes in rpcss.exe can accumulate over time if a program calls CoCreateInstance and a release on a COM object without terminating the apartment. The leak occurs every time the system creates a server process for the COM object for the same apartment because the RPC code doesn't release the client OXIDs until the client quits. Call Microsoft Support for the bug fix, a new version of rpcss.exe released July 25.
- NTFS deadlock. Microsoft article Q269819 describes a situation in which NT 4.0 might stop responding or deadlock randomly during heavy file I/O operations on an NTFS partition. This behavior results from an attempt to remove the attribute list stream for an NTFS file while other streams still exist for the file control block (FCB). When NT 4.0 hangs, two threads are involved. One thread is in the process of opening the attribute stream and waiting for the FCB lock. The other thread has the FCB lock and is attempting to close the stream but can't until the reference count is zero. Call Microsoft Support for the bug fix, a new version of ntfs.sys released July 26.
NTRights Utility
Supplement 3 of the Microsoft Windows NT Server 4.0 Resource Kit includes a nifty tool called NTRights that you might want to add to your toolbox. With ntrights.exe, you can grant or deny user rights to users and groups from a command line or a batch file. You must have Administrator privileges to modify rights for an individual or group. The ntrights.exe utility uses the following syntax:
ntrights +r/-r user_right-u "account_name" -m\\computer_name
where
+r adds a user right -r revokes a user right user_right is the user right you want to grant or revoke "account _name" is the name of the user or group enclosed in quotation marks) whose user rights you want to modify computer_name is the name of the remote computer where the user rights are being changed;if you don't specify the -m option and the computer name, the changes occur on the local computer
See Microsoft article Q266280 for a table of permissible values for the user_rights argument (e.g., SeCreatePagefilePrivilege, SeInteractiveLogonRight) and several examples of how you can use the Ntrights command.
What Does Netlogon Do?
Have you ever wondered what the Netlogon process is responsible for? On standalone servers and NT workstations, Netlogon performs four important tasks: locating a domain controller, retrieving a list of users, authenticating nonlocal (domain) accounts, and changing machine account passwords. On domain controllers, Netlogon also creates secure channels for domain controller-to-domain controller communications, performs domain and pass-through authentication, updates machine account and trust relationship password changes, and synchronizes the SAM database. See Microsoft article Q266729 for more information about how Netlogon creates a secure channel and performs its other duties. The article includes references to several other documents that provide additional details about Netlogon's functions.
Building NT 4.0 from Scratch
You might encounter an interesting hiccup when you install NT 4.0 from the original distribution media. Apparently, when you attempt to install on an NTFS partition, a timing issue between the hard disk and the original version of the OS hal.dll file causes a new installation to crash and display stop code 0x0000007f . To work around the problem, reboot the system after the blue screen and let Setup restart. If the problem occurs repeatedly, format the OS partition with the FAT file system and then install NT 4.0.
If you want to use the NTFS, use the Convert command to format the partition to NTFS after the installation completes. Then, as soon as possible, install NT 4.0 SP6a, which includes an updated hal.dll file that eliminates this setup problem.
