Friday 20 July 2012

Configuring SCOM 2012 - Part 3

For the final part in this series on configuring SCOM 2012, I want to look at additional Exchange 2003 tweaks that will (mostly) clear down the alerts generated in SCOM.  First let's take a look at the current alert view to see what I need to work on.
OK, the NNTP service isn't something I plan on using, and isn't actually a dependency for Exchange 2003 core functionality, only for the pre-reqs for install.  As such, the services can be un-installed now that Exchange is installed.  This can be done by running "sc delete NNTPSvc" from the command prompt, which I ran on both the Back-End and Front-End exchange 2003 servers.
Next, I wanted to clean up the accounts left behind from running LoadGen.  In this case I simply deleted the LoadGen objects OU in the root of the domain.
I then ran the cleanup agent on each database to ensure the LoadGen mailboxes were now in a disconnected state.
Next, I wanted to run the Exchange Management Pack configuration utility, which can be downloaded here.  With the utility downloaded I launched the installer.
The installer is pretty straight forward. Click Next, accept the license agreement, Next, choose the install path, Next and finish.  With the tool installed, it can be launched from the start menu.  You get the standard welcome screen and after that are prompted to select the Administrative Group containing the servers you want to configure.
After that you are prompted to select the servers you want to configure.  I selected both the Back-End and Front-End servers.
I'll be going with custom configuration options.
I then ticked all boxes for properties to configure.
Selected that Message Tracking should be enabled.
Selected that Front-End monitoring should be enabled.
I kept the services to be monitored at the defaults.
For availability monitoring, I selected per store.
Next, you are prompted to configure the sending and receiving servers for the mail flow tests, I've only got one back end, but that shouldn't be an issue, as I'll be running the tests at the database level.
I then opened ADUC, and created a MOM Mailboxes OU inside the Service Accounts OU I created earlier, and in there created a new user named MOMMailMonitor.
I entered the details for this account in the next step of the configuration wizard.
After clicking Next again, a summary is presented.
Next one final time and the wizard runs.  It completed successfully.
Next, I moved the MOM mailboxes that were created by the wizard from the Users container to the MOM Mailboxes OU I created earlier.
In ESM, I verified each database had it's own MOM Mailbox, and that the mailboxes were being accessed by the MOMMailMonitor account.
Next, also in ESM, I loaded the Exchange Administration Delegation Wizard.
Here, I added the MOMMailMonitor to the Exchange View Only Administrator role.
 I then went into Mobile Services and enabled OMA.
Next I opened the boot.ini file on the Exchange 2003 Back-End and added the /3GB /USERVA=3030 configuration parameters.
I opened RegEdit, and modified the HeapDeCommitFreeBlockThreshold DWORD property at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager to 40000 (Hexadecimal).
Next, I performed a reboot of the Exchange 2003 Back-End and verified event ID 9665 no longer appeared in the Application event log at startup. Next, I looked at the following alert I was seeing in SCOM.
As you can see from the above, the alert states that the issue is that SSL is not configured.  But this is a Back-End server - SSL shouldn't be configured.  The only web results I could find on this pointed to disabling the alert for back end servers, or creating an override.  I have a general dislike of creating overrides unless absolutely necessary so decided to dig into this one a little further.  I came across event ID 9110 in the Operations Manager event log on the Exchange Back-End server, this shed a little more light on the reasons the alert was actually being generated.
So there are two criteria that must be met for alert generation - No SSL configuration AND Basic Authentication enabled for a given virtual directory.  Now, I don't actually need Basic Authentication enabled on the Back-End server, authentication from Front-End servers is done via Integrated Auth (First Kerberos, then NTLM), and only if both of those fail will it attempt to use Basic Authentication. (See this technet article for more information).  So I disabled Basic Authentication for the Exchange, Microsoft-Server-ActiveSync, OMA, and Public virtual directories on the Back-End Exchange server in IIS, ensuring that integrated authentication was enabled.
With that configuration change made, I rebooted the Exchange 2003 Back-End a second time, and verified there was no repeat of the Event ID 9110, and that the SCOM alert had cleared itself.  I also verified the change hadn't caused problems accessing OWA, and that I could still connect the outlook client using both RPC over HTTPS and direct MAPI to the Back-End - all the tests came back good.

Next, I wanted to look at the following 3 alerts that had cropped up after running the Exchange Management Pack configuration wizard.
As you can see from the above, I was getting alerts about availability of the OWA, OMA and Activesync services.  The SCOM resolutions all pointed to the SSL config which I knew was fine for the Front-End, so with the recent success of tracking down useful information in the Operations Manager event log of the server in question, I immediately checked the Operations Manager event log on the Front-End.  In there I came across alerts in groups of 3 along similar to the example below.
A quick search on "0x80131502(-2146233086)" led me straight to Microsoft KB943511.  Looks like security update 931212 causes issues with the Exchange Management Pack Monitoring, and a hotfix is available from the KB article.  I downloaded and ran the hotfix.
A simple Next > Accept license agreement > finish is all that is required.  After that, I rebooted the Front-End and the SCOM alerts cleared themselves.

At this stage I was down to a single remaining alert in SCOM.
Now, I won't be clearing the alert on truncated log files until I start looking at DPM, so that one will have to sit there for now, but I'm basically at the stage where I can say the lab deployment of SCOM is complete, and all alerts have been cleared, and I didn't even have to resort to setting overrides to clear any of them.

No comments:

Post a Comment