When the Application log on a Windows 2000 Server machine with default settings reaches capacity at 512KB, the log produces an error message that it's full, even though the default setting lets it overwrite events older than 7 days. How can I prevent the log from generating the error message?
Your system is probably generating enough events within the 7-day period to exceed the 512KB maximum log size. To prevent the error message, you can either set the event-log settings for each of your logs to Overwrite events as needed or increase the maximum log size (I typically use 5MB—5120KB—on my servers). To change these settings, open Windows NT Event Viewer (either from the Administrative Tools program folder or as a component within Microsoft Management Console—MMC), highlight the log in Event Viewer's left pane, right-click it, and choose Properties to configure that log's maximum size and how the system handles situations in which the log reaches the maximum size, as Figure 1 shows.
I've tried to use the Microsoft Windows 2000 Server Resource Kit's RDPClip utility with Windows XP's Remote Desktop Connection (RDC—XP's universal RDP client) connected to a Win2K Server Terminal Services server, but I can't copy files to or from the terminal server. Using RDPClip to copy files worked fine with the Win2K RDP client. How can I reenable this functionality?
Unfortunately, the XP RDC client (which you can install and run under both XP and Win2K) seems to break the functionality of RDPClip. This situation is particularly true on Win2K systems that have been upgraded to the XP RDC client. One possible solution is to make the following registry change:
- Open a registry editor (e.g., regedit.exe or regedt32.exe).
- Locate the HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns registry subkey.
- From the Edit menu, select New, Key.
- Name the new subkey RDPDR and press Enter.
- Exit the registry editor.
If you still experience problems with file copying after you implement this fix, another solution is to use AnalogX's freeware TSDropCopy utility (http://www.analogx.com/contents/download/system/tsdc.htm). You run the utility, which Figure 2, page 42, shows, on both the terminal server and the local client. The program creates a small window on both systems' desktops. When you drag a file into one of the windows, the utility transfers the file to a designated folder on the system (i.e., server or client) at the other end of the connection. Note that TSDropCopy requires XP's RDC client software. You can download the RDC client setup utility (msrdpcli.exe) from http://www.microsoft.com/windowsxp/pro/downloads/rdclientdl.asp. The utility is also on the XP CD-ROM in the \support\tools folder. To run the setup program, insert the CD-ROM, select Perform Additional Tasks from the menu that appears, then click Set Up Remote Desktop Connection.
How can I connect a Macintosh client to a Windows terminal server?
Microsoft recently released a version of the RDP-based Remote Desktop Connection Client for Mac OS X. This client lets you connect to any RDP-based Microsoft terminal server, including Windows .NET Server (Win.NET Server) 2003 terminal servers, Remote Desktopenabled Windows XP Professional Edition clients, Windows 2000 Server Terminal Services servers, and Windows NT Server 4.0, Terminal Server Edition (WTS) servers. You can download the client from Microsoft's Mactopia site at http://www.microsoft.com/mac/download/misc/rdc.asp. Note that the Remote Desktop Connection Client for Mac OS X is, as of this writing, available only for Mac systems with one PowerPC processor; however, Microsoft is developing a version that supports dual-processor systems.
I run a Windows 2000 Server Terminal Services environment. I installed Win2K Service Pack 3 (SP3), and now users can't print to their local printers. How can I fix this problem?
I investigated and discovered that the problem affects only certain applications running on SP3 terminal servers. (I found no information about which application characteristics cause the problem.) Microsoft is working on a fix that should soon be available through Windows Update and as a separate post-SP3 hotfix download.
I want to use the Microsoft Windows 2000 Server Resource Kit's createusers.vbs utility to automate user-account creation in our Active Directory (AD) domain. The tool's command syntax requires that I know each attribute's property name to set the attribute's value. Where can I find a list of the available property names? For example, if I want to configure the Win2K Server Terminal Services Profile Path, where can I find the attribute's property name?
You can find this information at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/adschema/w2k.asp. This Web site provides an extensive reference for the AD schema, including all classes, attributes, syntax, control access rights, and display names.
Recently, we changed a computer name and workgroup on a Windows 2000 system. We also changed from manually assigned IP addresses to automatic IP addressing through DHCP. After rebooting, we couldn't log on no matter what logon and password combination we used. Any suggestions?
If the computer is truly on a workgroup rather than a domain, the changes you made shouldn't affect your ability to log on by using the (ostensibly untouched) Administrator name and password in the local machine's SAM database. If you can't use the Administrator account (or equivalent account) to log on, you might need to use an administrative password recovery tool such as Winternals Software's Locksmith (http://www.winternals.com) to reset the password.
We've been deploying Windows 2000 Service Pack 3 (SP3) in our organization and, although the installations have generally gone smoothly, I have several systems on which the installation fails with an error message of An error in updating your system has occurred. After this problem occurs, all Windows Installerbased setup routines on that system fail. Do you know what might be happening and how to correct it?
These setup failures occur because of a problem between Windows Installer and the Distributed COM (DCOM) configuration on some Win2K systems. Specifically, if the system's default DCOM impersonation level is set to Anonymous, SP3 setup will fail. This problem occurs because certain third-party applications suggest or require that you change a system's DCOM impersonation level from the default setting of Identify. After the SP3 installation fails, one of the SP3 installer files (msisip.dll) remains on the system and causes any Windows Installerbased setup to fail.
To resolve the problem, you need to delete the msisip.dll file that remains after the failed SP3 installation and change the DCOM impersonation level back to Identify. You'll find the leftover msisip.dll file in the %systemroot%\system32 folder (e.g., C:\winnt\system32), but copies might also exist in the %windir%\installer\w2ksp3\.dll and %windir\dllcache folders. You need to remove these copies as well.
To reconfigure the DCOM impersonation level, type
dcomcnfg
at a command prompt or in the Start, Run dialog box. This command launches the DCOM configuration utility (Dcomcnfg). Navigate to the Default Properties tab, which Figure 3 shows, and change the setting for Default Impersonation Level to Identify. After you click OK, you should be able to successfully install SP3 on the system.
I have a somewhat bizarre request but one that's important to my organization. Knowing that many script kiddies, intruders, and bots with illicit purposes are preferentially targeting Microsoft products these days, can I change Microsoft Exchange Server's default identification banner during an SMTP session to identify the program as something other than Exchange? I think this change might keep us off the radar screens of malicious individuals targeting Exchange servers.
Your question is one of the more interesting ones I've received recently, and after a bit of investigating, I found that you can indeed change Exchange's identification banner.
By default, an Exchange server reports itself during an SMTP session with a message similar to 220 myserver.mydomain.net Microsoft ESMTP MAIL Service, Version: 5.0.2195.4905 ready at Tue, 9 Jul 2002 22:23:27 -0700. This identification information isn't in the registry—it's in the Microsoft IIS metabase. You can use the Microsoft Windows 2000 Server Resource Kit's MetaEdit utility to configure the metabase for SMTP banners, according to the instructions in the Microsoft article "XCON: How to Modify the SMTP Banner" (Q281224, http://support.microsoft.com), or for the POP/IMAP banner, according to the article "XCON: How to Modify the POP or IMAP Banner" (Q303513, http://support.microsoft.com).
You can change the banner to anything you want; I changed my Exchange server to appear as a Sendmail server, so it reports itself as 220 myserver.mydomain.net ESMTP Sendmail Switch-2.2.2/Switch-2.2.0; Tue, 9 Jul 002 23:22:22 -0700. Keep in mind that no mail server is immune from attacks, although Exchange might suffer, as does its Windows OS brethren, from being a more common victim of probes and analysis. However, changing your identification banner might cause intruders to try to run an exploit for the mail server type the system is posing as, further increasing the likelihood that the exploit will fail (i.e., Sendmail-specific exploits probably won't work on Exchange systems).
I want to use RDP to connect to an employee's Windows XP Professional Edition workstation. However, the XP system is a new installation with default settings that don't allow remote desktop connections over the network. What steps can I take remotely to enable me to connect to this machine over the network?
To log on to the remote XP system, you need to perform some remote registry editing. First, you must be authenticated as a Domain Administrator or Local Administrator on the remote system. Then use regedit's Registry, Connect Network Registry menu option and enter the remote system's name to connect to the remote system's registry. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server subkey and change the value of fDenyTSConnections to 0 instead of the default value of 1. After you make this change, you should be able to log on to the remote system.
