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.
End of Article
Prev. page
1
[2]
next page -->
