I've instructed Microsoft Internet Explorer (IE) to store passwords I use for Web sites that I visit regularly. Also, I use Microsoft Outlook 2000 to make POP3 connections to my ISP's mail server. I'm experiencing problems with both setups. When I visit my regular Web sites, IE now generates a Protected Storage Service dialog box that asks for a password. In addition, Outlook 2000 refuses to save my mail account's POP3 password. Can you tell me what is causing these problems?
The cause of your problems is the Protected Storage Service and the password cache it creates for your user account. Occasionally, the registry data associated with this service becomes corrupted and requires reinitialization. The good news is that I have a fix for you. The bad news is that the fix will delete all the passwords residing in the cache, and you'll have to remind IE and Outlook about the passwords later.
Use the Control Panel Services applet to stop the Protected Storage Service. Next, use the regedt32 registry editor to navigate to the HKEY_CURRENT_USERSoftware\Microsoft\Protected Storage System Provider registry subkey. As Figure 1 shows, at least one subkey has a name that is equivalent to your Windows NT user account's SID (e.g., S-1-5-21-36516332-637091160-1803697834-1001). You need to delete this subkey, but you don't have permission to do so. Therefore, you need to add yourself to the registry subkey's ACL. Highlight the subkey that represents the SID, and select Permissions from the Security menu. Next, add your user account to the ACL with Full Control rights. Now, you can delete the subkey and restart the Protected Storage Service in the Services applet.
Although I'm happy with the reliability and performance of my Windows 2000 Professional system, I'm having compatibility problems with some of my applications. One particular application runs fine on a system that I upgraded from Windows 98 to Win2K Pro. However, when I try to install the same application on a new Win2K Pro installation, the installation fails, stating that I need to have Windows NT 4.0 Service Pack 4 (SP4) or later installed. I also have a digital camera application that supports USB, but only on Win98. However, I know that Win2K Pro supports USB, and the OS recognized and loaded a driver for my camera. Can I trick these applications into thinking that Win2K Pro is an earlier version of NT or a different version of Windows?
These problems are common because many applications and installation utilities existed long before Win2K; many of the tools' version-checking methods consider Win2K to be an earlier version of NT rather than a successor. I've also discovered that many applications that claim not to be Win2K-compatible actually run smoothly under Win2K (if you can bypass the version-detection problem).
Microsoft included a utility on the NT 4.0 CD-ROM called setwin95.cmd that lets you fool programs such as games into thinking that NT is Win95. Microsoft has taken this idea a step further in Win2K by introducing the Application Compatibility tool (apcompat.exe). Figure 2 shows the GUI for this utility, which is available on the Win2K CD-ROM and is part of Win2K's Support Tools. (Located in the CD-ROM's \Support folder, apcompat.exe installs when you install Support Tools.)
In some cases, you can use Application Compatibility to fool a legacy application into thinking that the application is compatible with one of several OSs: Win2K; NT 4.0 SP5, SP4, or SP3; or Win9x. The tool also lets you modify behaviors that sometimes cause problems for legacy applications; for example, you can prevent an application from seeing more than 2GB on a disk volume, use a pre-Win2K-style \Temp directory, and disable Win2K's Heap Manager. If a specific application requires a particular set of changes to run, you can make the spoofing behavior permanent so that you don't need to launch Application Compatibility each time you run the application. Finally, you can use one command line to launch a program through the Application Compatibility tool and its various options.
The command's format and supported parameters are as follows. (Don't put a space between the —v or —x options and their related parameter data, or they won't work.)
apcompat -? -vVersion Name -xProgram Path -d -t -g -k
in which -? displays the syntax for the command-line parameters, -vVersion Name specifies the name of the OS you want to return to the specified program (i.e., 1 returns NT 4.0 SP3, 2 returns NT 4.0 SP4, 3 returns NT 4.0 SP5, 4 returns Win98, and 5 returns Win95), -xProgram Path specifies the path and name of the .exe file for the program you want to run, -d disables the Heap Manager for the portion of memory reserved for the specified program, -t uses \Temp for the Temp folder when running the specified program, -g corrects disk space detection, and -k stores the specified Application Compatibility settings. For example,
apcompat —v4 —xc:\myapp\myapp.exe
runs an application named myapp.exe in the C:\myapp folder and makes the application believe it's running under Win98.
Occasionally, I need to install Windows NT 4.0 BDCs and other NT systems over a WAN connection, and the PDC is on the other side of the link. However, when I enter the third phase of Setup (i.e., the GUI part), an error message tells me that the computer can't find the domain controller (DC); therefore, I'm unable to join the domain. I use an LMHOSTS file that contains the following lines:
10.10.10.1 MY_PDC #PRE #DOM:MY_DOMAIN 10.10.10.1 "MY_DOMAIN \0x1b" #PRE
According to the Microsoft article "How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues" (http://support.microsoft.com/support/kb/articles/q180/0/94.asp), my method should work. What am I doing wrong?
I've encountered the situation you describe on several occasions. A potential workaround exists. First, I want to provide some clarification: I believe the Microsoft article you're referring to is "How to Install a BDC in a Routed TCP/IP Environment" (http://support.microsoft.com/support/kb/articles/q140/4/76.asp).
However, this article contains an apparent contradiction: The article states that the total length of the domain name string inside the double quotes in the LMHOSTS entry needs to be 20 characters. However, in the article's example, Microsoft lists a domain name that contains 10 characters (i.e., DOMAINNAME), followed by one space and the \0x1b hexadecimal code—a total of only 16 characters. The 20-character statement is correct, despite the typographical error.
The significance behind the 16-character length is that NetBIOS names (e.g., domain names, machine names) can contain as many as 15 characters, as well as a 16th character that indicates the NetBIOS suffix (representing the NetBIOS service type). In the case of your LMHOSTS entry, the suffix that the hex code \0x1b represents is that of the domain master browser. For a complete list of NetBIOS suffixes and their respective meanings, see the Microsoft article "Net-BIOS Suffixes (16th Character of the NetBIOS Name)" at http://support.microsoft.com/support/kb/articles/q163/4/09.asp.
Creating an LMHOSTS file might resolve your problem, depending on whether the file existed before the system initialized the TCP/IP stack. If the file did exist, the domain name and domain master browser (i.e., PDC) name should be in the NetBIOS name cache. However, plenty of circumstances exist in which a perfectly good LMHOSTS file won't resolve your problem. In such cases, you can fool NT into opening a command-prompt session.
When you configure the TCP/IP stack during Setup, go to the WINS tab and click Import LMHOSTS. In the Open With dialog box, which Figure 3 shows, right-click any file that doesn't already have a file association and choose Open With from the menu. Next, click Other, browse to the \%systemroot%\system32 folder, and select cmd.exe as the command to use to open the file. Be careful not to select the Always use this program to open this file check box, because you don't want to create a long-term association for that file type with cmd.exe. After you click OK, NT drops you to a command prompt instead of opening the file.
Now that you have a command-prompt window open, you can take diagnostic and corrective actions that are otherwise impossible during Setup. For example, you can use Ping and Tracert to diagnose connectivity problems, and you can use Nbtstat —R to reload the NetBIOS name cache (including any new entries in the LMHOSTS file) or Nbtstat —c to list cached names and verify that the cache lists the PDC and domain names.
However, remember that NT Setup might not have copied to the hard disk all the utilities you want to use during this session. In this case, simply copy the files you want to a 3.5" disk on another NT system. Then, either use the utilities from the 3.5" disk or copy the utilities to the hard disk of the system on which you're running the installation.
My company uses many long filenames in the directory structures of our network's various disk volumes. Because I'm an old command-line DOS jockey, I like to work at a command prompt, but navigating with the Cd command can be frustrating, especially with long filenames. For example, changing to a directory such as C:\program files\my application at the command prompt requires a lengthy Cd command (e.g., Cd "\program files\my application"). How can I simplify my life at the command line?
I can provide a few tips that you might find useful in command-prompt sessions. All of these tips work with both Windows 2000 and Windows NT.
First, when you're changing to a directory underneath the current directory at the command prompt, you don't need to type the target directory's full name. Instead, you can use an asterisk (*) wildcard with the Cd command. For example, to change to a directory called Program Files underneath the current directory, simply type
cd prog*
This command moves you into the closest directory that begins with "prog," which in this case is Program Files. (Note that this technique might not take you to the correct directory if other directories share the same match string before the asterisk. Therefore, be sure to provide as much information as necessary to uniquely match the desired target directory.)
Another tip that you might find helpful is modifying the Windows Explorer GUI so that you can easily drop to a command prompt from any Windows Explorer folder. One way to obtain this functionality is to download the Microsoft PowerToy called Command Prompt Here from http://www.microsoft.com/ntworkstation/downloads. To install the utility, simply expand the self-extracting executable, right-click the extracted doshere.inf file, and choose Install from the resulting menu. After you install the utility, you'll have a menu option in every Windows Explorer folder window that lets you drop to a command-prompt session (with the selected folder as the default directory). You can use this tool in several ways. The primary advantage is that you can right-click a folder icon in a Windows Explorer window and choose the Command Prompt Here option from the resulting menu. Additionally, you can right-click the icon in the upper-left corner of any open folder and choose the Command Prompt Here option from the resulting menu.
Another command-line trick enables command-line completion. If you're familiar with UNIX, you might lament that NT won't let you use the Tab key at the command line to autocomplete filenames within the current directory. However, you can mimic this ability in Win2K or NT: Edit the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor or HKEY_CURRENT_USER\Software\Microsoft\Command Processor registry subkey. (If the value exists in both locations, the value in HKEY_CURRENT_USER will override the value in HKEY_LOCAL_MACHINE.) Using regedit or regedt32, navigate to either key, double-click the CompletionChar value of type REG_DWORD (or add the value, and the Command Processor registry subkey, if they don't exist), and set the data to 9. In future command-prompt sessions, you'll be able to use Tab to autocomplete filenames at the command line.
Alternatively, to automatically complete the names of folders you're specifying in a command-prompt window, be sure that you're running the command-prompt session in a window rather than in full-screen mode. Type the portion of the command you're entering up to the name of the directory you want to reference (e.g., "Cd" includes a space after Cd before the directory name). If you open any Windows Explorer window from which you can see the target folder that you want to reference, you can simply drag the folder icon into the command-prompt window. This action causes the system to automatically insert the folder name—including the double quotes—at the end of the current command line. This tip works with any command line in a command-prompt window.
Windows NT Service Pack 4 (SP4) and later contain the Setprfdc utility, which you use to assign a preferred domain controller (DC) for a site without using the LMHOSTS file. We're using one domain with backup domains located all over the country. I need to be sure that Windows 95 machines are also using the local BDC to authenticate the local users, but we don't want to use LMHOSTS files. What can we do?
The Setprfdc utility is NT-centric. You can use other methods to control the secure channel establishment and DC validation, including #PRE and #DOM tags in the workstation's LMHOSTS file. However, you mention that you don't want to use this method, so you might consider an alternative approach, such as setting M-node resolution on the Win95 clients (e.g., through a DHCP scope option or a config.pol system policy file to modify the corresponding registry option related to the WINS node type).
By default, a client broadcasts to establish a secure channel with a DC and authenticate a logon. However, clients don't wait very long for a response. Because of this impatience, a client will often end up using WINS to discover a DC, a process that might return the address of a domain controller located across a slow WAN link. However, if you set M-node name resolution—which uses broadcasts first and point-to-point name server resolution second (i.e., the opposite of the default H-node type for WINS-enabled clients)—the client will wait longer for a reply. Therefore, a BDC on the local LAN segment will be more likely to respond to the client authentication request. (For more information about this topic, see the Microsoft article "Secure Channel Manipulation with TCP/IP" at http://support.microsoft.com/support/kb/articles/q181/1/71.asp.) One caveat regarding M-node resolution: The increased broadcast traffic this setting causes makes it more appropriate for smaller branch-office LANs than for larger LAN segments with many machines.
My company's Windows NT environment uses roaming profiles, which are great for users who log on to different machines in the office. However, logon and logoff times have recently become extremely sluggish. I was baffled until I checked the User Profiles tab in the Control Panel System applet on one user's machine—the user's profile was larger than 170MB. Further checking revealed that other users had the same problem. I checked the users' profile directory structures (in C:\winnt\profiles\username) but couldn't find any large files that might explain the unusual profile size. Why are these profiles becoming so large, and what can I do about it?
Bloated roaming profiles that cause poor logon and logoff performance are one of the most common problems I encounter. Here's a quick rundown of the typical causes of this problem.
By far, the biggest culprit contributing to excessively large roaming profiles (or any bloated profile) is Microsoft Internet Explorer's (IE's) Temporary Internet Files folder. By default, IE places this folder in the user's profile directory (e.g., in C:\winnt\profiles\username\temporary internet files). Over time, IE can store enormous amounts of cached data in this directory, and all this data must synchronize to and from the server at logon and logoff. You can alter this behavior in several ways.
The first option is to change IE's configuration so that it doesn't save cached pages when you close the browser (i.e., IE clears the contents of the Temporary Internet Files folder at shutdown). To enable this option, choose Internet Options from the View or Tools menu. On the Advanced tab, go to the Security section and select the Delete saved pages when browser closed or Empty Temporary Internet Files folder when browser is closed check box. (These options delete cached pages, but not cookies, from the folder.)
If you need to make this change on several machines and you're willing to reinstall IE, you can use the Internet Explorer Administration Kit (IEAK), the Outlook Deployment Kit (ODK), or Microsoft Office 2000 Setup (essentially a superset of the IEAK and ODK) to establish this option as a default for the browser. However, if you use the IEAK, ODK, or Office 2000 Setup to modify this behavior, you'll need to set an additional option: During setup, clear the Disable Roaming Cache option. (This option appears during the setup wizard, within the User Profiles section of the System Policies and Restrictions configuration.) Although this step seems counterintuitive, the Microsoft article "How Not to Save Cached Internet Files with Roaming User Profiles" (http://support.microsoft.com/support/kb/articles/q185/2/55.asp) assures that it is the appropriate setting.
If reinstalling IE on all your machines doesn't appeal to you, you can use System Policy Editor (SPE) to implement a system policy file (i.e., ntconfig.pol) that includes references to the registry value that controls this behavior. The IEAK and ODK ship with a policy template file called inetset.adm. This file contains several IE-related policy settings, including one to disable saving cached pages at exit. If you load this .adm policy template file into SPE with your other templates (e.g., winnt.adm, common.adm), you'll have a new Advanced Settings menu whenever you create or edit a user policy. If you select the Delete saved pages when browser closed check box on this menu, which Figure 4 shows, IE will discontinue caching pages in the Temporary Internet Files folder.
If neither option appeals to you, or if you want to prevent more than the Temporary Internet Files folder from roaming, you have a third option. In NT 4.0 Service Pack 4 (SP4) or later, you can use a system policy file to instruct NT to exclude specific directories within the profile when the system saves the profile back to the server. This policy is part of the winnt.adm policy template file; you can find it in the Windows NT\User Profiles section of any user policy. To use this policy, select the Exclude directories in roaming profile check box and enter the directories you want to exclude, separated by a semicolon. You must enter the directory string relative to that directory's position from the root of the user's profile folder. For example, Temporary Internet Files is in the profile's root directory, so all you need to enter is Temporary Internet Files. However, if you want to exclude the C:\winnt\profiles\username\application data\microsoft\outlook folder from roaming, you must enter it as Application Data\Microsoft\Outlook (without a leading backslash).
Apart from IE's cache folder, the other major space culprits I've found inside user profile directories are Outlook Personal Storage Folders (i.e., .pst files) and miscellaneous large files that users have stored on their desktop or in a desktop subfolder. In these cases, you might need to tell users to avoid storing these large files in their profile folder and teach them how to move the files to a better location. SPE also contains an option that lets you limit the size of a user's profile. The user receives an error message if the profile exceeds this limit during the profile's synchronization at logoff.
Determining which is the most effective method to reduce profile size depends largely on the number of machines involved and which approach will work best for you. If you have many machines to change, I recommend the system policy or redeployment methods. Although this problem also affects Windows 2000, it does so to a lesser degree because Win2K has a more efficient algorithm than NT 4.0 has for copying roaming profiles to and from the server. However, for best performance, you'll still want to make sure that profiles remain as small as possible.
On several occasions, I've tried to copy a user profile from the Control Panel System applet's User Profile tab, only to receive the bizarre error message Copy Profile Error: The operation completed successfully. Despite the supposed successful completion of the operation, the profile doesn't copy. What can I do to get around this problem?
Your problem is common on Windows NT 4.0 systems with Microsoft Internet Explorer (IE) 4.01 or IE 4.0. The cause of the error message is a permissions problem on a registry key related to the Protected Storage Service. To resolve this problem, you can try manually resetting the permissions on the HKEY_ LOCAL_MACHINE\SOFTWARE\Microsoft\Protected Storage System ProviderSID registry subkey, where SID is the security identifier of the user whose profile you're attempting to copy. (Typically, only one SID will appear, and it will be your user account's SID.) To set permissions for the profile you're currently logged on as, run the regedt32 registry editor and locate the HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider\SID registry subkey. If you need to determine your SID, you can use the Microsoft Windows NT Server 4.0 Resource Kit's Getsid utility or look for the name of the user within the various CentralProfile values that exist under each of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows NT\CurrentVersion\ProfileList subkeys.
To fix the permissions glitch that causes this problem, select Permissions from the registry editor's Security menu. In the Type of Access drop-down list, select Read permissions for the Administrators group. You should now be able to successfully complete the profile copy operation.
The Microsoft article "Error Message: Copy Profile Error" (http://support.microsoft.com/support/kb/articles/q175/6/67.asp) discusses another potential solution for this problem. However, the solution works only if you're willing to create a new profile for the user. Another potential solution is to upgrade the browser to IE 5.0 or later.
