Using Public Certificates With SCOM Part 3

In Part 1 and Part 2 of this series, I have explained how to configure your SCOM servers to accept manual agent installations and also how to manually install these agents onto your untrusted servers and clients.

In this part of the series, I will demonstrate what is needed to create a custom Certificate Template that will be used to create the Certificate Request to the Public 3rd Party Certificate Authority (this Certificate Template could also be used for an Internal CA too) and I will also go through the process of bringing the newly issued certificate into SCOM.

Certificate Request Process for SCOM RMS / MS and Untrusted Servers / Clients

First up, logon to your SCOM server as an Administrator, open Notepad and copy the text below into a new page and save it onto the root of the C drive of the server as a .INF file named something similar to catemplate.inf

[Version]

Signature= "$Windows NT$"

[NewRequest]

Subject = "CN=YourFullComputerNameHere,OU=MyOU,O=MyOrg,L=MyCity,S=MyState,C=US"

KeySpec= 1

KeyLength = 2048

KeyUsage = 0xa0

ProviderName = "Microsoft RSA Schannel Cryptographic Provider"

ProviderType = 12

RequestType = PKCS10

Exportable = TRUE

MachineKeySet = TRUE

UseExistingKeySet = FALSE

[EnhancedKeyUsageExtension]

OID = 1.3.6.1.5.5.7.3.1

OID = 1.3.6.1.5.5.7.3.2

Change my text in RED ITALICS to your actual computer name making sure that you specify the ‘Full Computer Name’ of your server or computer. This name could be simply a NETBIOS name or an FQDN.
(This is a crucial setting to note as it is going to be used again later on in determining the Certificate Subject Name.)

To get the exact full computer name of the server you are working on, follow this simple procedure:

Windows Server 2003

Click Start, Click Run, type ‘sysdm.cpl’ (without the quotations)

Go to the ‘Computer Name’ tab and take a note of the full computer name

Windows Server 2008

Click Start, Click on ‘Search Programs and Files’, type ‘sysdm.cpl’ (without the quotations)

From the ‘Computer Name’ tab, take a note of the full computer name

Now, open up a command prompt ensuring you select ‘Run As Administrator’ so you have the proper permissions to continue

Type cd\ and press ‘Enter’ to take you back to the root of the C drive

Type the following to create the certificate request using the catemplate.inf file that we created earlier:

certreq –new c:\catemplate.inf mycert.req

This will create a file on the root of your C drive called ‘mycert.req’. This file will now need to be sent to your external CA provider to create a new externally secured trusted certificate with the subject name of the certificate being the same as the ‘Full Computer Name’ of your server

Once you have the certificate back from the external CA, copy it to the root of the C drive so the certificate template, request file and issued certificate are all in the same location

(I have found that although this seems irrelevant, if these files are not in the same location, sometimes the next step doesn’t work!)

Open back up your command prompt ensuring again that you ‘Run As Administrator’

Type the following to install the certificate into the Local Computers Personal Certificate Store, substituting the certificate name below with the full name and extension of your newly issued certificate, then press ‘Enter’ to accept the certificate:

certreq -accept mynewlyissuedcertificate.cer

Now, you need to use the command prompt to browse to the ‘MOMCertImport.exe’ utility on the SCOM installation media (make sure you browse to the correct architecture folder i.e. AMD64 or i386) and using the /subjectname switch you need to specify the certificate name exactly as you see it (substituting my.fullcomputername.com in the example below) when you open up the ‘Certificates’ MMC snapin and select the ‘Local Computer’ option.

From the 'Local Computer Certificates' MMC, you need to browse to the ‘Personal\Certificates’ subfolder to see (and make a note of) the full name of the certificate that you would have imported using the certreq utility earlier.

Your command should look something similar to this:

MOMCertImport.exe /subjectname my.fullcomputername.com

Make sure that this process is repeated on all SCOM RMS/MS and untrusted server and clients.

Once the above commands have been carried out on all SCOM and untrusted servers and clients, it is a good idea to restart the Health Service on the untrusted clients first and then if needed, you will need to restart the Health Service on the SCOM RMS/MS servers too.

Restarting the Health Service will then kick-start the Agent discovery and authentication and if all is configured the way it should be, then you will see your untrusted server show up in the 'Pending Management' section of the 'Administration' tab within the SCOM Console Wunderbar.

From here and once you see your server listed, simply click on the 'Approve' option in the 'Actions' window on the right hand side to complete the final step to bring your untrusted server into your SCOM monitoring environment.

Using Public Certificates With SCOM Part 2

In Part 1 of this series, I explained the basic options for bringing untrusted servers and clients into your SCOM monitoring environment and outlined a High Level Overview of the process required to use a 3rd Party Public Certificate Authority for SCOM authentication.

In this blog post, I will go into deeper detail around the steps required to get this working. If you are reading this and feel that at times I am explaining some of the steps at too basic a level, then apologies but - believe me when I say this - 'It is VERY easy to make a mistake in this process!'

Initial SCOM Server Configuration

• Ensure that TCP Port 5723 is allowed from the DMZ / Untrusted Domain to both the RMS and MS servers
• From the 'Administration' tab in the SCOM Console Wunderbar, select 'Setttings' and then 'Security' and then select 'Review new manual agent installations in pending management' and click 'OK' (See Below)

Manual SCOM Agent Installation


Run the SCOM installer on each untrusted server or client and select 'Install Operations Manager 2007 R2 Agent' from the startup splash screen

Click 'Next' from the first window that pops up

Accept the default installation path and click 'Next' again

Ensure 'Specify Management Group information' is selected, then click 'Next' again

In this next window, it is VERY important that you get the information here correct. You must input in your SCOM Management Group Name, Management Server name and Management Server Port number. The key here is to ensure that you input in the FQDN of your Management Server and not just the NETBIOS name.

Leave 'Local System' selected in the next window, then click 'Next'

From the next window, verify that all of your settings are correct, and then select 'Install'

Finally, when the wizard is completed, click on 'Finish' to close the Agent installation.

This completes the manual SCOM agent installation onto your DMZ / untrusted based servers and clients.

In part 3 of this series, I will demonstrate how to build a certificate template to create and approve the Public 3rd Party certificate using the 'CertReq.exe' utility and to then bring the new agent into your SCOM Management Console.

Using Public Certificates With SCOM Part 1

From time to time with SCOM, you will need to enable monitoring of servers and clients that are outside of the normal boundaries of your Active Directory environment. These servers and clients may be in your DMZ as workgroup machines, or maybe you have a number of completely different Active Directory domains and forests that have no relation with each other yet need to be centrally monitored by your SCOM implementation.

If you have a large number of servers and clients in an untrusted domain to the SCOM domain, then you would most definitely want to install a SCOM gateway server into that domain and have this as the central point of contact with your main SCOM RMS and MS servers.

The SCOM Gateway Server uses certificate authentication to authenticate with the SCOM RMS / MS servers and certificate configuration has to only be carried out once between the SCOM RMS /MS and SCOM Gateway devices. The SCOM Gateway Server would then distribute the SCOM agents to each client in the untrusted domain / workgroup and pass the monitoring information over to the RMS and MS in the trusted domain.

See the link below for some additional information on SCOM Gateway Servers and their configuration from MS Technet:

http://technet.microsoft.com/en-us/library/bb432149.aspx

No matter whether you decide to use a SCOM Gateway Server or just install the SCOM agents manually onto your DMZ based servers and clients, you will need to configure Certificate Authentication with either an internal Certificate Authority (such as an Active Directory CA) or if that isn't an option (or you're brave enough to attempt it!), then you could also use a 3rd Party Certificate Authority such as Thawte or Veritas as an example.

This short series of blog posts have come about from the necessity of a particular project I was working on recently that had procedures in place to only use Public Certificates on all of their servers. I managed to get Public Certificates working with this client's DMZ machines using information from a number of different blog posts, forums and also some thrown in knowledge of my own based around public certificates. I felt that although the information is available if you look on the internet, I couldn't find one single source of information that took me from step to step with this process, so therefore I decided to blog about it myself to save someone else the hassle!!

Update:
If you are using an internal Certificate Authority for issuing your certificates to your SCOM environment, read my blog posts on internal CA's with SCOM here for more information.

Here's a High Level Overview of the process to get your SCOM environment monitoring your untrusted DMZ, Domain or Workgroup machines when a SCOM Gateway Server is not being used:

• Allow Port 5723 from your untrusted DMZ/Domain to the SCOM RMS and MS Servers
• Enable Manual Agent Installation from the SCOM Administration Wunderbar
• Manually install the SCOM Agent onto each untrusted server and client that you want SCOM to monitor
• Create a Certificate Template .INF file that will assist with the Certificate Request to the Public CA
• Use 'CertReq.exe' to create the Certificate Request on the SCOM RMS/MS and untrusted servers
• Forward the Certificate Request to the Public Certificate Authority
• Use 'CertReq.exe' to approve and install the newly issued Certifcate from the Public CA on the SCOM RMS/MS and untrusted servers
• Use the 'MOMCertImport.exe' utility on all servers (SCOM and untrusted) with the '/subjectname' switch to tell SCOM which certificate to use for authentication
• Restart the 'Health Service' on the SCOM and untrusted servers
• Approve the Manual Agent Installation from the SCOM Console Wunderbar

In part 2 and part 3 of this series, I will go into more granular detail on this process with some screenshots included too!

New SCOM Exchange 2010 SP1 Management Pack

Microsoft have just released (well 2 days ago but I didn't get around to blogging until today about it!), the updated Microsoft Exchange 2010 Management Pack which includes support for Microsoft Exchange 2010 Service Pack 1 and the associated roll-ups that SP1 comes with.

There are quite a few significant changes to this Management Pack that makes it even better than the original Exchange 2010 MP that was released last year.

Here's some of the highlights that are included in this new update:

• Capacity planning and performance reports - New reports dig deep into the performance of individual servers and provide detailed information about how much capacity is used in each site. 

• SMTP and remote PowerShell availability report - The management pack now includes two new availability reports for SMTP client connections and management end points. 

• New Test-SMTPConnectivity synthetic transaction - In addition to the inbound mail connectivity tasks for protocols such as Outlook Web App, Outlook, IMAP, POP, and Exchange ActiveSync, the Management Pack now includes SMTP-connectivity monitoring for outbound mail from IMAP and POP clients.

• New Test-ECPConnectivity view - Views for the Exchange Control Panel test task are now included in the monitoring tree. 

• Cross-premises mail flow monitoring and reporting - The Management Pack includes new mail flow monitoring and reporting capabilities for customers who use our hosted service. 

• Improved Content Indexing and Mailbox Disk Space monitoring - New scripts have been created to better monitor context indexing and mailbox disk space. These new scripts enable automatic repair of indexes and more accurately report of disk space issues. 

• The ability to disable Automatic Alert Resolution in environments that include OpsMgr connectors -    When you disable Automatic Alert Resolution, the Correlation Engine won't automatically resolve alerts. This lets you use your support ticketing system to manage your environment.

• Several other updates and improvements were also added to this version of the Management Pack, including the following. 

• Suppression of alerts when the alerts only occur occasionally was added to many monitors. 

• Most of the event monitors in the Exchange 2010 Management Pack are automatically reset by the Correlation Engine. Automatic reset was added to those event monitors so that issues aren't missed the next time they occur.

• Monitoring was added for processes that crash repeatedly. 

• Additional performance monitoring was added for Outlook Web App. 

• Monitoring of Active Directory access was improved. 

• Monitoring of anonymous calendar sharing was added. 

• Reliability of database offline alerts was improved. 

• Monitoring for the database engine (ESE) was added.

Also, Microsoft had promised that they would update their documentation guide for the original Exchange 2010 MP to include information on making the Microsoft Exchange Monitoring Correlation Service Highly Available in a cluster environment but I didn't see anything in the new and updated guide in relation to this. See my earlier blog posts on this if you want to make the Correlation Service Highly Available:

http://kevingreeneitblog.blogspot.com/2011/04/clustering-scom-microsoft-exchange.html

If you are one of the many thousands who have already deployed the original SCOM Exchange 2010 MP, then you will need to download the new updated one from the link below and import it into your SCOM infrastructure as you had done previously with the older MP (you can't update this MP from the SCOM Catalog automatically - it needs to be downloaded first and then have it's .MSI file run to accomodate the Correlation Service installation)

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7150bfed-64a4-42a4-97a2-07048cca5d23

As always, don't forget to read the MP guide fully before you install the MP into your live environment and implement any recommendations that the guide gives around configuration and alert tuning.

Happy SCOMming!!!

Clustering the SCOM Microsoft Exchange Monitoring Correlation Service Part 2

In part 1 of this guide, I explained what the Microsoft Exchange Monitoring Correlation Service was and in this part, I will demonstrate what is needed to make this service Highly Available.

Follow the steps below to begin your configuration:

• Run the .msi installer for the Exchange 2010 MP on all cluster nodes first as this creates the ‘Microsoft Exchange Monitoring Correlation’ service

• Go to the ‘services.msc’ snapin on each cluster node and stop the ‘Microsoft Exchange Monitoring Correlation’ service 

• Set the startup type for this service on all nodes to ‘Manual’ 

• Edit the CONFIG file located at 'C:\Program Files\Microsoft\Exchange Server\V14\Bin\Microsoft.Exchange.Monitoring.CorrelationEngine.exe' for the Microsoft Exchange Monitoring Correlation Service to reflect the Virtual RMS Cluster name (it is set as 'Localhost' initially and this is what needs to be changed)

• Provision a LUN from your shared storage and present it to the cluster nodes (1GB or 2GB should be more than enough)

• From one of the cluster nodes, open 'Failover Cluster Manager' from the 'Administrative Tools' menu, expand your cluster name, right mouse click on 'Services and Applications' and then click on 'Configure a Service or Application' to open the 'High Availability Wizard'

• Select 'Next' and then click on 'Generic Service'

• Click 'Next again and then select 'Microsoft Exchange Monitoring Correlation' from the 'Select Service' window

• Click 'Next and then input in the name and IP address that you are going to assign to the newly clustered service

• Select your shared storage that you had presented to the cluster previously

• Don’t bother selecting any registry settings to transfer over as the service is already installed on the other nodes. 

• Click on ‘Next’ until you come to the review page, then click on ‘Finish’ to complete the service clustering. 

• Test service cluster failover by moving the service between nodes using ‘Failover Cluster Manager’ and keep an eye on the service state from the ‘services.msc’ snapin as this should go from started to stopped on the current node, then from stopped to started on the new node you have chosen to move the service to. 

This completes your Microsoft Exchange Server 2010 Monitoring Correlation Service clustering.

All that’s left to do now is to import the Exchange 2010 MP into your environment and then tune away those noisy alerts (if any!)

Clustering the SCOM Microsoft Exchange Monitoring Correlation Service Part 1

It's not often I get to install SCOM into RMS clusters and this week was no exception. I'm finishing off a project that involves the installation of a SCOM 2007 R2 Highly Available environment configured as an RMS cluster on an SQL 2008 R2 cluster.

See the link below for the initial SCOM cluster installation steps:

http://kevingreeneitblog.blogspot.com/2011/02/clustering-scom-2007-r2-rms-role-on.html

The part of this project I am working on this week is based around a new Highly Available Exchange 2010 messaging environment and bringing this into the existing SCOM infrastructure.

Now, for those of you that are used to installing the Exchange 2010 Management Pack, you will be familiar with a new method that Microsoft have been pursuing in relation to management packs, and this is based around the new 'Microsoft Exchange Monitoring Correlation Service'.

The 'Microsoft Exchange Monitoring Correlation Service' is basically a noise reduction utility that sits between the Exchange 2010 and SCOM environments and filters out unnecessary alerts before you even need to start thinking about tuning!

It's based on nearly 2 years of in-house deployment from the MSIT team on their own SCOM and Exchange 2010 environment.

The Microsoft Exchange Monitoring Correlation Service installs itself as a standard Windows Service on the SCOM RMS and is viewable from within the 'services.msc' snap-in.

When I install a Management Pack into SCOM, no matter how often I have installed the same MP into other SCOM environments, I will always read the MP guide that accompanies the Management Pack as it can contain valuable information on configuration and initial tuning settings that need to be deployed to get the most out of your new MP.

When I started to read through the Exchange 2010 MP guide, I was looking specifically for instructions on clustering the Correlation Service as there's no point in having a HA environment for your RMS and SQL services and then not having the main noise reduction service for your Exchange 2010 MP not failing over to your other cluster nodes in the case of an emergency. The Exchange 2010 MP guide unfortunately has no information on clustering this service at all and after searching the web for some additional info, all I found was some references to it being added to the next version of the Exchange 2010 MP guide - whenever that gets released!! I set about clustering this service using the Failover Clustering Wizard that is built into Windows Server 2008 R2 and decided to blog about it for anyone else who finds that the Microsoft documentation falls just short of this type of information.

In part 2 of this short guide, I will demonstrate how to cluster this service and make it Highly Available within your SCOM environment.