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.

Identify Agent with PowerShell Script

Earlier this week, one of the analysts in our Operations Center informed me about an alert received in System Center Operations Manager 2007 from one of our managed servers.  The alert was regarding the need for agent proxying to be enabled on a server and was similar to the following:

Source:  Servername.contoso.com
Path:  Servername.contoso.com
Last modified by:  System
Last modified time:  8/5/2008 2:36:47 PM
Alert description:  Details: Health service (9AAFF032-4567-2270-B09A-A34025D969F3) could not generate data about this managed object (EC7903B7-72FC-BFD0-3CA2-473774E60AD4).

So how in the world do we translate the GUID into a recognizable computer name?  The answer is Windows PowerShell.  Save the following script with a .ps1 file extension (for example, AgentProxy.ps1):

Param([string]$MonitoringObjectID)
Get-MonitoringObject -id $MonitoringObjectID | select name

Run the script from the command shell console as follows:

C:\MyWorkspace\AgentProxy.ps1 EC7903B7-72FC-BFD0-3CA2-473774E60AD4

The script will return the name of the computer in question and then you can enable agent proxying from within the Administration space of the Operations Manager console.

Resolving ASP Performance Counter Warnings

Recently I was troubleshooting some ASP performance counter warnings that were appearing in the Application event log of one of the servers we manage with System Center Operations Manager 2007.  The events were similar to the following:

Event ID: 35
Source: WinMgmt
Description: WMI ADAP was unable to load the ASP.NET_64_2.0.50727 performance library because it returned invalid data: 0×0

Event ID: 35
Source: WinMgmt
Description: WMI ADAP was unable to load the ASP.NET_64 performance library because it returned invalid data: 0×0

Event ID: 40
Source: WinMgmt
Description: WMI ADAP was unable to create the object Win32_PerfRawData_ASPNET_64_2050727_ASPNETAppsv2050727 for Performance Library ASP.NET_64_2.0.50727 because error 0×80041001 was returned

Event ID: 40
Source: WinMgmt
Description: WMI ADAP was unable to create the object Win32_PerfRawData_ASPNET_64_ASPNETApplications for Performance Library ASP.NET_64 because error 0×80041001 was returned

I came across a posting at MCPGuides.com that explained that these events can occur frequently and, in a large environment, can be quite bothersome.  The errors are related to a known Microsoft bug in the way WMI attempts to query ASP.NET performance counters.  As of the posting on MSPGuides.com (May 23, 2008), no hotfix currently exists.  The posting offered two possible workarounds provided that you do not need to monitor ASP.NET performance counters outside of System Center Operations Manager 2007:

1. Download the Windows 2000 Resource Kit tool “Extensible Performance Counter List” (exctrlst.exe).  Install and launch the tool.  Once open, uncheck the Performance Counters Enabled checkbox for all versions of ASP.NET that are installed.The checkbox is below the Extensible Performance Counters listbox.
2. If your environement is large and installing the tool on each impacted computer is not an option, you can script the registry key that exctrlst.exe modifies.  The net impact of unchecking the Performace Counters Enabled option in the tool is that the DWORD value of Disable Performance Counters is set to 1.  The registry key is located at HKLM\SYSTEM\CurrentControlSet\Services\%Insert ASP.NET node%\Performance.  If the key does not exist, it must be manually created.

Once either of these options have been implemented, you should have a clean Application log on the impacted server(s).  It worked for me!