Shortcuts, Bug Fixes, and Verbose System Messages
Paula Sharick describes a shortcut that lets you quickly lock down your system, discusses a post-SP2 VPN bug fix, explains an FRS problem, and more.
February 11, 2002
A Lock Computer Desktop Shortcut
Here’s a cool tip you can use to create a desktop shortcut that locks your Windows 2000 system. Right-click your desktop and select New, Shortcut to launch the Create Shortcut wizard. In the "Type the location of the item" field, type the case-sensitive command
rundll32.exe user32.dll,lockworkstation
Click Next. Enter a shortcut name, such as Lock, and click Finish. The shortcut will appear on your desktop as the standard Windows icon. To change the icon to something more representative (e.g., a key), right-click the shortcut, select Properties, click Change Icon, and select the file or DLL that corresponds with the icon you want. Drag the new shortcut to the Quick Launch toolbar at the bottom of your screen. The next time you want to lock your system, simply click the new shortcut—it’s much faster than using the standard three-fingered salute. If the Quick Launch toolbar isn't visible on your system, right-click an empty area on the taskbar, select Toolbars, and click Quick Launch.
Post-SP2 VPN Bug Fix
Windows 2000 Service Pack 2 (SP2) includes a TCP hardening technique that disables TCP packet size negotiation, called Path Maximum Transmission Unit (PMTU) negotiation, on a local subnet. If you have a VPN server that assigns a client address on the same subnet as the VPN server, a bug in this algorithm can prevent VPN clients from accessing resources on other SP2 systems on the VPN server’s subnet. So, for example, a remote VPN client might not be able to copy files, access mail, print to a shared printer, or connect as a Win2K Server Terminal Services client. This problem occurs after the server authenticates the VPN connection and occurs more frequently with legacy clients. The PMTU problem occurs only when the VPN server assigns client addresses on the same local subnet, but not when the VPN server assigns client addresses from a different (i.e., the nonlocal) subnet.
Microsoft released a bug fix called PMTU Detection Update with the filename q301337_sp3_x86.exe on January 14. You can download the update from the Microsoft Web site. You don't need to install this update on the VPN server itself, because the VPN server and the client use the same MTU (TCP packet size) when they're on the same subnet. You do need to install this bug fix on all Win2K SP2 systems that offer shared resources or services to VPN clients.
Because TCP algorithms operate at the lowest level of connection negotiation, the inability of clients to access shared resources can occur in a variety of other circumstances, such as when clients are behind a router running Network Address Translation (NAT), and the far side of the network uses a different MTU (packet size). See article Q301337 for a description of other network configurations that this problem might affect.
FRS and Floppy Drives
Do you have a server that unexpectedly accesses the system’s floppy drive? If you're running the File Replication Service (FRS) on the server, here’s a possible explanation. Windows 2000 domain controllers (DCs) and servers use FRS to replicate system policy and logon scripts, and to replicate content between systems hosting the same DFS roots. The FRS service has a bug that can cause it to incorrectly query a floppy drive every 5 minutes. Obviously, FRS should ignore removable drives when it's building the drive table for file replication purposes. No bug fix is available for this problem as of February 12.
The FRS service jet database and log files are located, by default, in or below the %systemroot%tfrs directory. If FRS is querying removable drives on your system, you should see warnings in the log file such as the following:
WARN - GetvolumeInformation for A:; WStatus: ERROR_NOT_READY1368:>
Article Q221111 documents the FRS logging options and severity levels you can enable by manually editing the registry. You might need to enable a higher level of debugging before the FRS service logs this type of message in the log file. Article Q312929 documents this FRS bug.
Verbose Startup and Shutdown Messages
Did you know that a registry setting controls whether the system provides verbose messages during startup and shutdown? When you’re troubleshooting a system that's slow to start up or hangs during shutdown, you can switch between normal and verbose status messages by adding or editing a registry value on the local system. Windows 2000 checks the value entry verbosestatus in the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem. To enable verbose messages, add the value entry
verbosestatus:REG_DWORD:1
To disable verbose messages, set this entry to 0. Another registry key controls whether the system pays attention to the verbosestatus entry. If the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemDisableStatusMessages exists and is set to 1, the system ignores the verbosestatus setting. You can also implement verbose messages for all systems in a group, domain, or OU by editing the equivalent field in Group Policy: Computer ConfigurationAdministrative TemplatesSystem. For more information, see Microsoft article Q316243.
About the Author
You May Also Like