I used to believe the source code of the Windows operating system would be the best kept secret in the world, but I was taught there is another best kept secret on this planet. Yes, the secret was/is – “How do you configure https for Agentless Exception Monitoring (AEM)?”. There is very poor documentation from Microsoft in form of guides or on TechNet on this topic (sorry Microsoft). I could not find any answer at all. Not even in the holy SCOM bible “System Center 2012 Operations Manager Unleashed” can be found anything about this, so I decided to figure it out.
First, what am I exactly talking about? Agentless Exception Monitoring is a feature in SCOM which basically collects Dr. Watson on Windows XP or Windows Error Reporting (WER) information on Vista and later operating systems. SCOM collects error information generated from clients and applications and displays its detail in the SCOM console or reports. Marnix Wolf, MVP and SCOM Guru, has written some time ago a great post series about configuring AEM which you can find here. I am not going to repeat all this for SCOM 2012, because 99% of this stuff is the same.
Just to make things short, if you have a Windows XP client and a application crashes Dr. Watson sends the error data by connecting to the configured SCOM file share and dropping it’s error data on this share. If you have a Windows Vista client or higher the behavior changed because there is a Windows Error Reporting (WER) engine behind which handles the error data. One of the many big differences is how the data is submitted between Dr. Watson and WER. If you configure AEM in SCOM the wizard creates a http/https listener in the background and this is the service which WER uses to send the data to SCOM. I wanted to use https to submit the data from a Windows 8 client to SCOM.
I will show how to do it in 5 parts:
1. Configure your management server and group policy
2. Create self-signed certificate which we use for https
3. Bind the certificate to AEM https listener port
4. Configure the client to trust the self-signed certificate
5. Testing AEM
1. Configure your management server
Let’s start. Go to a SCOM management server and start the Configure Client Monitoring wizard in the SCOM console under Administrations/Management Servers (here the link is greyed out because it is already configured)…
The wizard starts and I choose that I don’t want SCOM to send CEIP data…
Configure the file share where you want to store the AEM data and here it comes, select Use Secure Socket Layer (SSL) protocol. This setting configures if the listener for http or https, of course we want https. This is the first important part of the puzzle…
Configure if you want to send the error data to Microsoft or not. In my case I just leave it disabled…
Choose account which has enough permission to create the file share and groups on the management server….
Keep in mind you need to configure AEM according to your needs, I am just focusing on the https implementation.
Next we need to configure where to save the group policy ms01.bigfirm.com.adm template. I store it also in the C:\AEMError folder. Finish the wizard…
If you navigate to the C:\AEMError folder you will see several folders and the ms01.bigfirm.com.adm group policy template…
Let’s now check the management server health see if the Crash Listener is ready and healthy, in my case it looks now like this…
Next we copy the ms01.bigfirm.com.adm template to a domain controller or to another system which has the Group Policy Management Console (GPMC) installed. We are going to create a domain wide group policy and import the previously generated ms01.bigfirm.com.adm group policy template. After that configure the group policy as your requirements are.
I configured the Group Policy like here…
The group policy configures the Windows client registry to send the data to our management server according to your settings. For exact details see the posts from Marnix Wolf .
Of course the policy settings I made are just for testing and might not match a real world scenario. There are many other sources on the internet which will give you detailed instructions.
So far we have the management server configured and the group policy for the clients configured.
Now we need to create a certificate for the https communication. Since I don’t have a PKI infrastructure I am going to use a self-signed certificate. Don’t use self-signed certificates in production environments, in production you need to have certificates from a internal or external PKI infrastructure! Of course if you use a PKI infrastructure there are steps you don’t need to make e.g. trusting your own certificate but to understand how it works it is a perfect example.
2. Create self-signed certificate which we use for https
Let’s create a certificate. First you need to download the makecert.exe utility. The easiest way is to get it from the TechNet gallery. For a complete syntax overview check MSDN link.
Next we need to execute the command on the management server which is AEM enabled. In my case my management server is called ms01.bigfirm.com, replace this name in the command to your management server accordingly. The crtificate “type” needs to be a server authentication certificate which identifies our management server. The Object Identifier or OID for server authentication has a specific value which is 1.3.6.1.5.5.7.3.1 . The same certificate could also be used for a web server (IIS) where https is required, there is no difference. On TechNet is a great description how to configure a SSL certificate.
The command looks like this…
makecert -r -pe -n “CN=ms01.bigfirm.com” -b 01/01/2013 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12
And here the explanation to each switch…
-r
Creates a self-signed certificate. A self-signed certificate is a certificate that is not signed by a certificate authority. Because it is not signed by a certificate authority, it can be used for encryption required in SSL but cannot be used for server authentication.
-nSpecifies the server name. This name must comply with the X.500 standard. The simplest method is to specify the name in double quotation marks, preceded by CN=.
-ekuSpecifies a list of comma-separated, enhanced key usage object identifiers (OIDs) into the certificate. For SQL Server, an SSL certificate that is valid for server authentication that has an OID of 1.3.6.1.5.5.7.3.1 (szOID_PKIX_KP_SERVER_AUTH) is required.
-ssSpecifies the certificate store where the created certificate is saved. We recommend saving this in the my store, although it can be saved anywhere in the certificate store.
-srSpecifies the certificate store where the certificate is located. Location can be either: currentuser (the default), or localmachine. Because this certificate is being created for a service, it should be placed in the local computer.
-skySpecifies the certificate key type. This must be signature, exchange, or an integer, such as 4. For RSA public key exchange algorithm, exchange is required here. This is the type of key used to encrypt and decrypt session keys.
-spSpecifies the CryptoAPI provider name. For certificates created for SQL Server, this can be set to Microsoft RSA SChannel Cryptographic Provider.
-sy
Specifies the CryptoAPI provider type. When the provider is Microsoft RSA SChannel Cryptographic Provider, this is 12.
After you executed the command you can go to your local computer certificate store on your management server and check if the certificate is present…
If you check the properties of the certificate you will recognize that the certificate chain is broken. Because we are using a self-signed certificate there is no root certificate which would “complete” the chain therefore we need to trust our self.
In the certificate MMC on your management server right-click on the certificate and choose Export…
Follow the wizard and choose No, do not export the private key…
I choose a DER encoded binary X.509 (.CER)…
Choose a file name and finish the wizard…
Now you finished the wizard and we need to trust this certificate and therefore we put this into the Trusted Root Certification Authorities store from our management sever. Go back to your certificates MMC and right click on your Trusted Root Certification Authorities folder and choose import…
Follow the wizard and select the previously exported *.cer certificate…
And place it Trusted Root Certification Authorities and finish the wizard…
Now if you look at the properties of your certificate, the certificate chain is complete…
So far we have an AEM enabled management server installed, group policy configured and a certificate installed for https. Next we need to map the certificate to the SCOM AEM https listener which is the other important part of the puzzle.
3. Bind the certificate to AEM https listener port
In order to bind the certificate to the listener we need the netsh command. In previous version of Windows until Windows XP / Windows Server 2003 you would need a tool called httpcfg.exe which is available in the Windows XP Service Pack 2 Support Tools. For Windows 2008 and later we are going to use netsh. A detail information is available here on Technet.
The netsh command looks like this…
netsh http add sslcert ipport=192.168.0.160:51906 certhash=9aa24568dad8494144e9af3851ca9372555fe720 appid={00112233-4455-6677-8899-AABBCCDDEEFF}
Looks like a scary command but if we split it in small parts then it makes sense…
netsh http add sslcert -> tells netsh that you want to add a ssl certificate
ipport=192.168.0.160:51906 –> this tells the command to which IP and port you want to bind the certificate. In my case the 192.168.0.160 is the management server IP and 51906 is the default AEM listener port.
certhash=9aa24568dad8494144e9af3851ca9372555fe720 –> this long number is the thumbprint of the certificate we created. You will find this number if you double click on the certificate and go to Details…
appid={00112233-4455-6677-8899-AABBCCDDEEFF} –> this GUID can be any value you choose it has to be in a GUID format though. This GUID is mapped to the service you binding the certificate to and is mandatory. It uniquely identifies the service for which the certificate is used.
If you fire off the command above you will see something like this…
If you need to check the binding and settings und can run…
netsh http show sslcert
As you can see the settings are ok and the management server is just ready. Next we need to add / trust the self-signed certificate on the client…
4. Configure the client to trust the self-signed certificate
Go to your client, in my case Windows 8 of course and open the local computer certificate store. Right click on Trusted Root Certification Authorities folder and choose import…
Select now the certificate we exported on the management server in step 2. Of course you need to copy this certificate to your client first…
Next, choose Trusted Root Certification Authorities again and finish the wizard…
Your certificate store should look like this…
That’s it your client trusts the self-signed certificate from the management server. If you want to make a simple test, open Internet Explorer and navigate to your AEM URL in my case https://ms01.bigfirm.com:51906/ and immediately this 405 error will appear which is normal, because there is no website…
If you did something wrong you will hit e.g. this page…
Ok next we want to test if AEM works…
5. Testing AEM
First, get the an application which is used to simulate crashes. I recommend using Accivo from Sysinternals it is a simple exe file which triggers Windows Error Reporting.
Open a command prompt and run the tool in the command window. As soon the WER appears click Send information…
If you like to crash your Windows 8 box, open Task Manager / Details and click on smss.exe and End task. Your Windows 8 will be gone…
and you are the winner of a smile :(…
In your SCOM console you should see now first your application crash in your Agentless Exception Monitoring / Error Events view…
…and also your Blue Screen / Smile Error in your System Error Group View…
This post is not intended to be a AEM beginners / learning post, instead I wanted to document how to configure the https listener so you don’t need to spend a lot of time finding this information.
Let me know if you like this post…
Just wanted to say THANK YOU for this post. If you lived in Phoenix I would have bought you a beer.
Very welcome 🙂
Hello Stefan,
Thanks for the post, Do we need to create multiple group policies if we enable client monitoring on multiple Management servers ?
Thank you