Thursday, April 21, 2011

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:

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!!

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!


  1. Hi Kevin,

    This is a great blog. I am currently monitoring many machines in SCOM on my RMS which are WorkGroup Machines. We have a DR for SCOM with a DB and 1 MS (which will be the RMS incase of disaster to current RMS)

    Right now all work group machines are pointing to RMS. If I import a certificate on the DR MS will all the work group machines automatically point to DR Server when the current RMS fails or do I need to import certificates on all the Work Group Machines. Please advise. Any solution will be helpful.

    Thank You

  2. Hi Rob,

    Thanks for the comments about the blog!

    There's a few things here that could cause you some problems.

    Firstly, I would always recommend if you have a lot of machines in an untrusted domain or workgroup that you use a SCOM Gateway server and point all of the workgroup machines to it, this way you will only need to configure a certficate change once and the gateway server will be the main device communicating with your RMS.

    It gets messy if you don't use a SCOM gateway server and then need to repoint a load of workgroup machines to a different RMS as you would have to reconfigure the certificate on each one using MOMCertImport.exe each time.

    Another train of thought on this (and its just in theory as I haven't tried it myself) would be if your DR RMS had the exact same FQDN and Management Group name as your production RMS, then you might just be able to trick the workgroup machines into thinking it is the same RMS from a certificate point of view, the agents however would probably throw up errors as the BME guid reference in the OpsMgr SQL DB for the DR RMS server would be different.

    If you don't want to use a SCOM gateway server but still need a DR solution for your RMS, I would highly recommend a cluster configuration of the RMS and SQL databases. It is a fully supported solution by Microsoft for high availability within a SCOM environment.

    I wrote a series of posts on this a while back:

    Hope this helps!

  3. Hi Kevin, I'm just about to renew a certificate on a single gateway. I have never dealt with certificates before. I have checked in MMC add/remove snapin to see the expiry date of the GW certificate. I also have 2 MS and I notice that both of these have certificates also. Why would these have certificates when they communicate via Kerberos to the RMS which is in the same domain as the 2 MS? I'm also unsure where I should be running momcertimport for the new GW certificate? Should I run this on the GW, 2 x MS and RMS?

    I do hope you can help,



  4. Hi Michael,

    Thanks for the comment. To answer your question, if the certificate on the Gateway server is about to expire, then this should be the only certificate that you need to replace using the MomCertimport.exe utility.

    The reason the MS and RMS servers have certificates is that when SCOM is communicating with a gateway server that is based in an untrusted domain (i.e. does not use Kerberos), then the SCOM Management Servers and Gateway servers exchange certificates to authenticate communication.

    Once the RMS and MS certificates are all in date and they are from the same trusted root CA as the new Gateway server certificate, then these should not need to be changed.

    The exception to this is if you are replacing the Gateway certificate with a certificate that has been issued by a Certificate Authority that is different to the RMS and MS certifcates CA, then all servers will need their certificates updated.

    Hope this helps!

  5. Thanks for this post. If I just want to have 1-3 servers at different parts of the USA, I would not do a Gateway server correct? We need some external agents to monitor our hosted URLs, so I would assume an external server with an agent is the best bet. Then I can select to use that server as my monitoring server for my app tests.

    How does RMS point to the external agent? Public IP address I assume?

  6. Hi There,

    If you have only 1-3 servers on different sites around the USA, then a SCOM gateway server on each site would be a bit of a waste of time - unless of course you are planning to add more network devices or servers for monitoring on those sites in the future.

    FOr SCOM to be able to monitor these servers in real-tims, you need to have a VPN link between these sites so the SCOM Management Server can communicate with them. If you have a VPN between the sites, then your routing infrastructure will translate any public IP addresses into locally routed internal ip ranges. If this is the case, then you can just follow my blog posts on certificate creation the same way as if they were in a DMZ.

    If there are no VPN tunnels between the sites, then SCOM will not be able to monitor these devices.

    I would instead suggest you look at Microsoft's System Center Advisor (formely codename Atlanta) which is a cloud based monitoring service that provides some basic Windows Server and SQL monitoring for your remote sites.

    Hope this helps!

  7. Here's the link for the System Center Advisor tool: