Windows Security?

This past week I was remotely preparing a customer’s server for induction into our Managed Services offering at ClearPointe.  This process sometimes includes the need to copy files from one of our servers in Little Rock to the remote server.  The server that I was remoted into was running Windows Server 2008 which, by default, with the introduction of User Access Control (UAC) and other features, is more secure than any previous Microsoft operating system….but I think Microsoft might want to rethink the situation that I am about to describe! 

From within an RDP (Remote Desktop Protocol) session on the remote server, I accessed our server in Windows Explorer via UNC path, located the file that I needed to copy to the remote server, right-clicked and selected the Copy option from the menu.  I then navigated to the root of the C: drive on the remote server, which was where I wanted to paste the file.  I right-clicked and selected Paste from the menu…but received the warning dialog box below.

Now, I understand that it can be dangerous to copy and paste certain remote files to a server and such action is oftentimes a sign of malicious activity, but where is the “security” in telling me that I do not have permission to copy files to a particular location over the network but can paste into the Documents folder and then move it to the original desired location?  I guess it could deter a malicious individual if said individual just could not wait the additional 10 seconds that it would take to get his package to the desired location!

Frampton Comes Alive!

Last summer I had the opportunity to see one of the greatest blues guitarist in history, B.B. King, in concert in Little Rock.  Last night my daughter, Katie, and I saw one of the greatest rock guitarists of all time.  Peter Frampton and his band performed at the Arkansas Music Pavilion in Fayetteville, AR, and we had second row seats.  The concert had originally been scheduled for July 21 but was postponed because some the band’s equipment had been damaged during a severe thunderstorm at a recent outdoor concert and repairs were not yet complete.  The show was well worth the four week delay!

Peter Frampton

Before Frampton took the stage, a band called The Elms did a thirty-minute set.  This band was founded in 2001 and hails from Seymour, IN.  The Elms have become one of the most respected and consistent young rock & roll bands from the midwestern U.S., both on record and on stage.  Katie and I were quite impressed with these four young lads.  The band did a very respectable job of getting the crowd ready for Frampton.

At 8:00 sharp, after a 30-minute break while the roadies shuffled equipment, Frampton and his band took the stage.  Their set included all of the Frampton classics as well as a couple of tracks from his latest CD Fingerprints, which was released in 2006, and a couple of tracks from his upcoming CD which, according to Frampton, is currently about 80% complete.  The band included long-time bassist John Regan, who has been making music with Frampton for 30 years.  Rob Arthur manned the keyboards and did a great job of filling the big shoes of the late, great Bob Mayo.  Adam Lester joined Frampton on guitar, a position also formerly occupied by Mayo.  For drummer Dan Wojciechowski, the band’s newest member, the evening was a homecoming of sorts because he is originally from Fayetteville.

This was truly one of the best, if not the absolute best, concert that I have ever attended and having my daughter along made it even more special.  Frampton has a number of concert dates scheduled through the end of September.  Should he come to a venue near you, I highly recommend that you make every effort to attend.  I have posted photographs and a couple of brief videos from the show on my Facebook page and my website.  Feel free to take a look.

Windows Server 2008 Task Scheduler

We recently performed an upgrade on one of the applications that we use to monitor and manage client servers and devices.  As a part of the upgrade  process, we decided to move the application from servers running Windows Server 2003 to new virtual servers running Windows Server 2008.   The application is configured with a series of tasks that run each day during the early morning hours.  The tasks run under an Active Directory user account created solely for the purpose of running these tasks and with only the level of privilege required to perform this action.

After the upgrade it was discovered that the tasks were no longer running.  I began to troubleshoot the problem.  From within the application, I could right-click on a task and select to run a test job from the pop-up menu.  The task completed successfully.  If I selected the option to start the job in the context that it was to run each night, it failed consistently.  So why were the test jobs succeeding when the actual tasks were failing?  I turned to good, old Google and quicky found the root cause of the problem.

I discovered that tasks run in Windows Server 2008’s Task Scheduler, by default, run only when the user is logged onto the server.  This was not the case with Scheduled Tasks in Windows Server 2003.  To remedy the problem, I accessed Task Scheduler on the new server, right-clicked on each task and selected Properties from the pop-up menu.  On the General tab of the task’s properties, I selected the Run whether user is logged on or not option as shown below, and then clicked the OK button.  Now the tasks run nightly as expected.

Task Properties in Windows Server 2008

Although this subtle change in the way tasks are run in Windows Server 2008 is an improvement from a security standpoint, it can cause some head scratching if you are unaware of the change.  I hope this post saves saves some administrators a little head scratching.

Active Directory Performance Counter Error

Sorry about the lack of new posts lately!  I was troubleshooting an alert in Operations Manager 2007 from one of the many servers we manage.  Research on the Internet did not reveal any resolution to this specific alert although I did find a couple of postings that were somewhat similar and led me down the correct path to resolution.  Hopefully this post will help others that are troubleshooting this same alert.

Event ID:  1228
Source:  ADAM
Type:  Error
Description:  System Monitor was unable to open Active Directory performance counters.  An attempt to query the following performance counter registry key failed.
Registry key:
SYSTEM\CurrentControlSet\Services\ADAM\Performance\First Counter
Additional Data
Error value:  2 The system cannot find the file specified.

Sure enough, on my problematic server there was not a First Counter key in the registry at the location listed in the alert.  The similar posts that I came across during my research indicated that there might be an .INI file for the performance counters located at C:\WINDOWS\System32.  I had already noticed that the registry location above contained a PerfIniFile string value with a value of adamctrs.ini.  I checked the System32 directory and found no such file.  A search of the C: drive located it at located it at C:\WINDOWS\System32\ADAM.

I opened a command prompt and sourced from the C:\WINDOWS\System32\ADAM directory and ran the following command:

lodctr adamctrs.ini

I then returned to the Registry Editor and, from the menu, selected View > Refresh.  Four new DWORD values, as shown above, had been created – First Counter (the one causing my alert), First Help, Last Counter, and Last Help.  Alert resolved!  Finding the resolution to the problem took longer than the actual correction of the problem.  Again, I hope this post will help someone else resolve this error in a timelier manner with less research involved.

EMP MAPI Logon Failure

Exchange Management Pack synthetic transactions can generate a lot of noise in the Operations Manager console because there are numerous components that can contribute to the problem (i.e, Exchange, Active Directory, IIS, etc.).  Once it has been verified that the problem is an Operations Manager Agent issue rather than an actual user-impacting issue, the alerts are usually disregarded until someone has a chance to dig in and do some troubleshooting.  Today is one of those days for me.

We have been receiving the following alert from a client Exchange server for a number of days and it was initially diagnosed as an agent issue:

MAPI Logon Failure
MAPI logon verification: Problem in accessing Directory
Service caused Logon failure Exchange Server: “SERVERNAME“
MDB:”First Storage Group\Mailbox Store (SERVERNAME)”
Mailbox:”SERVERNAMEMOM” Error: The information store could not
be opened. [MAPI 1.0 - [MAPI_E_LOGON_FAILED
(80040111)]]

I checked the usual settings – mailbox rights, mailbox security, mailbox access account credentials, etc. – and everything was configured properly.  However, one thing caught my eye while checking the properties of the test mailbox user account.  On the Exchange Advanced tab of the Properties dialog box (below), the Hide from Exchange address lists option was selected.

Exchange Advanced tab

This did not seem quite right to me, so I checked test mailbox account properties in a couple of other client domains.  This option was deselected on every account that I checked.  Apparently, at some point, someone had selected this option so the account, which is disabled by default when created by the Exchange Management Pack Configuration Wizard, would not appear in the Outlook Global Address List. I promptly deselected the option and monitored the Operations Manager event log on the server.  Within minutes Event ID 19980 was logged indicating that all attempted MAPI logins of test mailboxes on the server had succeeded.

As is so often the case, an overlooked checkbox or radio button was the root of the problem and an alert that had repeated hundreds of times was finally closed.  During my troubleshooting, I did not come across anything that referenced the Hide from Exchange address lists option, although it surely exists somewhere in cyberspace, so I hope this post is beneficial to others trying to resolve a similar issue.

SharePoint Execute Method Exception (Event ID 6398)

I spent some time today troubleshooting an alert that we received in Operations Manager 2007 from one of the client SharePoint servers that we manage in our Operations Center.  The alert referenced Event ID 6398 which indicates that the execute method of a SharePoint timer job definition had thrown an exception.  I logged onto the client SharePoint server and looked in the Application event log and, sure enough, it was full of the following 6398 event:

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Timer
Event ID:    6398
Date:        11/19/2008
Time:        1:05:53 PM
User:        N/A
Computer:    <ServerName>
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 03d6f1b3-879c-42d9-8921-3f14b9e5678f) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.

The System event log contained numerous instances of the following DCOM error as well:

Event Type:    Error
Event Source:    DCOM
Event Category:    None
Event ID:    10016
Date:        11/19/2008
Time:        1:06:26 PM
User:        NT AUTHORITY\NETWORK SERVICE
Computer:    ATI-SHAREPOINT
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

This problem can be resolved by accessing the Component Services applet by way of Start > Administrative Tools > Component Services.  In the task pane expand Component Services, expand Computers, and expand My Computer, and click on DCOM Config.

In the details pane on right, locate and right-click on the OSearch application and select Properties from the menu.  On the OSearch Properties dialog box, click on the Security tab.  In the Launch and Activation Permissions section, select the Customize option and then click the Edit button.

OSearch Launch Permissions

On the Launch Permissions dialog box, add the NETWORK SERVICE user and grant it Local Launch and Local Activation permissions as shown above.  Click the OK button twice and then close the Component Services applet.  You should now have a much quieter and happier event log!

ADMP Replication Monitor and Unmanaged DC

Operation Manager 2007’s Active Directory Management Pack (ADMP) is designed for managing all domain controllers within a given site or organization.  However, we recently encountered one of the rare instances when not all DCs are managed – a client was in the process of retiring one of three DCs in their domain and wanted to remove it from our Managed Services offering.

We went through the normal steps for removing a server from Operations Manager 2007 – uninstalled the OM Agent, deleted the server from the OM database, deleted automated reports, etc.  Within 24 hours, however, the Active Directory Replication Monitor began alerting our Operations Center that a domain controller had failed to update its MOMLatencyMonitor object within the specified time period (24 hours by default).  The retired server’s MOMLatencyMonitor object had been deleted from Active Directory during its removal from Managed Services so how was the ADMP still aware of the unmanaged, albeit still running, domain controller?

Windows Server 2003 adds two additional Active Directory application naming contexts, DomainDNSZones and ForestDNSZones, when you Active Directory Integrate a DNS zone on a domain controller.  We use ADSI Edit to modify the objects and attributes of these naming contexts as follows:

1. Click Start > Run, type adsiedit.msc in the textbox, and click the OK button.
2. In the ADSI Edit task pane, right-click ADSI Edit and select Connect to from the menu.
3. In the Connection Point section of the Connection Settings dialog box shown below, select the Select or type a Distinguished Name or Naming Context option, type the following in the textbox, substituting the appropriate domain and extension values, and then click the OK button:

   DC=DomainDNSZones,DC=Domain,DC=Domain_extension

   

   ADSI Edit Connection Settings

4. In the ADSI Edit task pane, locate and click on the CN=MOMLatencyMonitors container as shown below.
   

   ADSI Edit

5. In the details pane to the right, locate and delete the directory for the server that is no longer managed.
6. Repeat steps 3-5 and specify ForestDNSZones in the Connection Point string rather than DomainDNSZones.
7. Close the ADSI Edit window.

Now the ADMP Replication Monitor will only monitor and alert on the remaining managed domain controllers.

Odd (or even) NIC Teaming Problem

We recently encountered a situation that apparently seldom occurs or, at the very least, is not well documented on the Internet.  Our Operations Center informed me about a remote client server located in the eastern United States that was not reporting correctly into all of our management and monitoring tools.

My initial investigation revealed, for example, that the server was not communicating with our server that hosts an SNMP-based performance application.  However, the Operations Manager agent on the server was communicating with our Root Management Server (RMS), albeit with the secondary node of the cluster rather than the desired primary node.  ICMP pings from the remote server to the primary RMS node and the server hosting the SNMP application failed, while pings to the secondary RMS node succeeded.  I also observed that the server could not ping one of the client’s domain controllers located in a colocation facility in the south central United States.

I turned to Google and began trying to find a solution to the problem.  I came across two newsgroup postings, one involving Linux Ubuntu and the other Windows 2000 Server, that described an odd behavior where a computer would only receive ICMP replies from odd or even addressed hosts.  If the fourth octet of the server’s IP address was an odd number, it would only receive ICMP replies from hosts with an even-numbered fourth octet, or vice versa.  This sounded totally bizarre, but I started pinging our servers from the remote server which, by the way has an even-numbered fourth octet.  Sure enough!  Every server with an odd-numbered fourth octet replied while even-numbered servers did not!  Even our senior-most engineers had never heard of, much less encountered, such a phenomenon.

According each posting, the problem was eventually isolated to NIC teaming and, as it turned out, our problem server had a pair of NICs teamed as well.  Ultimately, we dissolved the NIC team, assigned the IP addressing of the team to one of the physical NICs, and disabled the other NIC.  This may not be the optimal solution to the problem, but it got our client’s problem server to communicate properly again.

If you have encountered this odd/even addressing issue with NIC teaming and resolved your problem in a different manner, please provide a comment!

ADMP Replication Failure Verification

A common alert generated by the Active Directory Management Pack (ADMP) indicates that there is a problem with Active Directory replication:

The following DCs have not updated their MOMLatencyMonitor objects within the specified time period (8 hours).  This is probably caused by either replication not occurring, or because the ‘AD Replication Monitoring’ script is not running on the DC.

Format: DC, Naming Context, Hours since last update

MySite
PEGASUS, NDNC:DC=DomainDnsZones,DC=myDomain,DC=com, 11

This alert indicates that my domain controller PEGASUS has not replicated the required value to the adminDescription attribute under the MOMLatencyMonitor container in Active Directory for eleven hours or more.  But how do we know if the alert is due to actual AD replication issues or a problematic Operations Manager script?

We can validate the problem by using the repadmin utility, which is included in the Windows Server 2003 Support Tools.  At a command prompt, enter the following command (substitute the appropriate servername):

repadmin.exe /showrepl PEGASUS

The output of the repadmin utility should be similar to the following:

DC=ForestDnsZones,DC=myDomain,DC=com
mySite\Odyssey via RPC
DC object GUID: 45b3241y-z849-48rs-n76u-6×09bv432ih6
Last attempt @ 2008-10-28 08:34:55 was successful.

According to the output above, the last replication attempt was very close to the current time and was successful.  This indicates that the problem is likely with the Operations Manager script.  The dsquery command line utility can be used to troubleshoot further:

dsquery * CN=MomLatencyMonitors,DC=ForestDnsZones, DC=myDomain,DC=com -scope onelevel -attr name AdminDescription

The output of dsquery should be similar to the following:

name                                   admindescription
PEGASUS                           20081028.0200
ODYSSEY                           20081028.1330

Based on the timestamp values in these results, we are able to detemine that this particular alert is actually an Operations Manager script error.

MachineKeys Directory Permissions

Today I was troubleshooting a problematic remotely managed server that was not reporting into our Operations Center.  The OpsMgr Health Service service was running; however, we were not receiving a “heartbeat” from the server.  The Operations Manager event log contained error events that indicated a problem involving the certificate private key used to unencrypt the package received from our Root Management Server (RMS).

When I accessed the System event log on the server, I also discovered that the following event was being logged several times every hour:

Event Type:    Error
Event Source:    Schannel
Event Category:    None
Event ID:    36870
Date:        10/28/2008
Time:        9:36:08 AM
User:        N/A
Computer:    Servername
Description:
A fatal error occurred when attempting to access the SSL client credential private key. The error code returned from the cryptographic module is 0xffffffff.

My research indicated that this event is the result of improper NTFS permissions being set on the MachineKeys directory, which is located under the All Users Profile\Application Data\Microsoft\Crypto\RSA directory.  This directory is utilized by both Certificate services and Internet Explorer.  The default permissions for the MachineKeys directory are as follows:

Administrator (Full Control) This folder only
Everyone (Special) This folder, subfolders, and files
SYSTEM (Full Control) This folder, subfolders, and files

Although resetting the permissions on the MachineKeys directory did not totally resolve the Operations Manager agent heartbeat problem (I also had to uninstall and reinstall the agent), it did eliminate the Schannel events in the System event log.

Addtional information can be found in Microsoft Knowledge Base Article 278381.

Exchange Management Pack MAPI Logon Alert

The Operations Manager management packs for Exchange Server are usually the noisiest of all of the management packs.  As a result, they also require considerable attention from an Operations Manager administrator.  In our Managed Services operation at ClearPointe, which manages many Exchange organizations of various size, the synthetic logons (OWA, OAS, and EAS) and MAPI logon verifications seem to generate the most alert traffic and are forwarded to me for resolution.

There are several MAPI logon verification alerts but the one shown below that includes the error text of [Collaboration Data Objects – [MAPI_E_NOT_INITIALIZED(80040605)]] was initially a little perplexing because the canned knowledge information listed with the alert in no way addresses this particular error.  Once I discovered the cause of the problem, however, it has become one of the easiest Exchange Management Pack alerts to resolve.

[MAPI_E_NOT_INITIALIZED(80040605)] indicates that there are conflicting versions of the dynamic link library file CDO.DLL on the server.  From my experience, this almost always means that Microsoft Outlook is installed on the Exchange server, which goes against Microsoft best practices but appears to be somewhat commonplace unfortunately.  Outlook and Exchange each have their own version of CDO.DLL and they butt heads when installed on the same computer.  To resolve the error, we must unregister the Outlook version of CDO.DLL and register the Exchange version from the command prompt.

You can use the Search feature within Windows Explorer to locate the two DLL files.  The Outlook version is likely somewhere in a “Common Files” directory such as C:\Program Files\Common Files\System\MSMAPI\1033.  The Exchange version will be located in the Exchsrvr\bin directory.  At the command prompt, navigate to the directory that contains the Outlook version of CDO.DLL, type regsvr32.exe /u cdo.dll, and press [Enter] to unregister the DLL file.  Now navigate to the directory that contains the Exchange version of CDO.DLL, type regsvr32.exe cdo.dll, and press [Enter] to register this DLL with the system.  Your [MAPI_E_NOT_INITIALIZED(80040605)] alerts should now be a thing of the past.

Group Policy Replication and DNS

I ran into a problem today while trying to get a remotely managed server to receive new Group Policy Objects (GPOs).  In the Group Policy Management Console (GPMC), the GPO was linked at the domain level, the Authenticated Users group was removed from the security filtering section of the policy, and the computer’s machine account was explicitly added along with the machine accounts of other servers.  From a command prompt on the destination server, I ran gpupdate /force to force the server to update its group policy settings.  The event logs indicated that the server had successfully updated its policies; however, I could immediately tell that the server did not receive the new GPOs by checking a couple of registry keys.

I ran the Resultant Set of Policy (RSOP) wizard in the GPMC and it indicated that the server was being denied the GPOs due to security filtering.  This did not make sense as I had explicitly added the server to the GPO’s security filtering.  I checked the advanced permissions to ensure that the server did not have a Deny permission buried somewhere.  Everything was configured just as it should be!  I then checked the DNS Event Log and noticed the 4515 events shown below (the computer name and domain name have been blurred to protect the guilty).

I checked the %systemroot%\dns directory on the server and discovered a static DNS zone file, which also happened to include an incorrect IP address for the server.   DNS in the domain is Active Directory-Integrated so I knew the zone file was not needed but was unsure whether it could be the cause of the GPO problem.  I deleted the zone file and forced another group policy update from the command prompt.  The server successfully received the new GPOs.   The moral of the story is, if all else fails when troubleshooting group policy issues, check the DNS event log!

DHCP Management Pack Bug

Our Operations Center asked me to investigate an alert that they had received from a client’s managed server.  The associated event initially seemed to indicate a problem with the System event log:

Type:  Error
Source:  Health Service Modules
Category:  N/A
Event ID:  25004
Date:  2008-09-09
Time:  09:13:47
User:  N/A
Computer:  CLIENTDC1
Description:
The Windows Event Log Provider is still unable to open the System event log on computer ‘{BE6AEC47-3H7F-97C4-20G4-D37GB234BC98}’.  The Provider has been unable to open the System event log for 4390 seconds.

Most recent error details:  The RPC server is unavailable.

One or more workflows were affected by this.

Workflow name:
Microsoft.Windows.DHCPServer.Library.Server.UnitMonitor.DependentServiceHealth
Instance Name:  clientdc1.somedomain.com
Instance ID:  {BE6AEC47-3H7F-97C4-20G4-D37GB234BC98}
Management Group:  MGMTGP1

During my troubleshooting, I came across a recent posting on the Microsoft Connect web site that indicated that the problem was due to an apparent bug in the current DHCP Management Pack rather than a System event log problem.  The admin that submitted the bug uninstalled the management pack and the alerts stopped.  I did not want to uninstall the entire management pack so I began searching through the monitors looking for the culprit that was causing the noise.

From the Authoring space of the System Center Operations Manager 2007 Console, I selected Monitors in the Authoring pane, located and expanded Microsoft Windows DHCP Server in the Monitors pane and expanded the Entity Health and Availability aggregate rollups.  I then right-clicked on the DHCP Dependent Service Health Monitor and selected Overrides > Override the Monitor > For all objects of type: Microsoft Windows DHCP Server to configure the override of the monitor.

The monitor triggers the 25004 event every 12 minutes.  Once I had created the override, I monitored the System event log for approximately 30 minutes and saw no repeat alerts.

Remember, when working with management packs, it is considered a best practice to create overrides to rules and monitors rather than disable them.  Also, do not save overrides to the Default Management Pack – create a new management pack for the override with a descriptive name.

MS Exchange MTA Service and Event 2000

Earlier this week I encountered an alert in Operations Manager 2007 from a managed client’s Exchange server with Event ID 2000 which stated:

Verify that the Microsoft Exchange MTA service has started.  Consecutive ma-open calls are failing with error 3051.

I knew that the Microsoft Exchange MTA service was not in use in the client environment as it is not necessary in a single-Exchange server organization.  The service was in a ”Disabled” state but this did not prevent the alerts.

My research led me to Microsoft Knowledge Base article 810489  which confirmed that stopping and disabling the service was not enough to resolve the problem.  Two registry entries must be created on the Exchange server for each public or private database as follows:

1. Click on Start > Run and type regedit in the textbox and click the OK button.
2. In Registry Editor, navigate to the following key:  HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ServerName.  Take the following actions on each private or public database that is listed under this key.
3. Right-click on the database and select New > DWord Value from the pop-up menu.  Name the value Gateway In Threads.
4. Set the Gateway In Threads value to 0 (zero).
5. Right-click on the database and select New > DWord Value from the pop-up menu.  Name the value Gateway Out Threads.
6. Set the Gateway Out Threads value to 0 (zero).
7. Restart the Microsoft Exchange Information Store service to enable the changes.

The Gateway In Threads and Gateway Out Threads values should also be set on any new databases created on the server.

Performance Issues & TCP Chimney

I was recently troubleshooting a performance issue on one of the servers we manage and I came across a posting on Greg Galipeau’s Weblog that covered problems that a couple of network adapters have with TCP Chimney.  TCP Chimney is a concept introduced with Service Pack 2 for Windows Server 2003 and is supposed to increase a server’s performance.  However, two network adapters have a known issue with TCP Chimney:

• BroadCom NetXtreme II
• Hewlett-Packard NC373i Multifunction Gigabit Server Adapter

As it turned out, the server I was troubleshooting had the HP adapter installed so I followed Greg’s instructions, which are outlined below:

1. Disable TCP Chimney from a command prompt by typing Netsh int ip set chimney DISABLED
2. Make a few registry changes to make sure that performance is not hindered by disabling TCP Chimney.  Click Start, click Run, type regedit in the textbox, and then click the OK button.
3. Locate the following registry subkey:  HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
4. Double-click the EnableTCPChimney registry entry.
5. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
6. Double-click the EnableRSS registry entry.
7. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
8. Double-click the EnableTCPA registry entry.
9. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
10. Restart the server.

For additional information regarding TCP Chimney issues, please review Microsoft Knowledge Base article 942861.