Requesting SCOM 2007 Gateway or Agent Certificates for Server 2008 from a Server 2003 Enterprise Certificate Authority
This is a pretty specific set of instructions for a specific environment:
- you are using Microsoft System Center Operations Manager 2007
- you have a Microsoft Certificate Services 2003 Certificate Authority on your domain
- you have non-domain Windows Server 2008 servers you wish to monitor or set up as a gateway server.
Getting a certificate for either a Gateway Server or remotely monitored Server can be a touch vexing. If you’re installing on the same domain as the SCOM management server the security settings take care of themselves, not so for non-domain servers, which require mutual certificate authentication. The Gateway must trust the Domain CA and identify itself as trusted to the Management Server. I have bashed my head against this several times now, so I thought I’d make a precise blog post to cover the steps required!
In this scenario, we will have 2 servers CA01, the Windows 2003 Certificate Authority, and Gateway01, the SCOM 2007 gateway. The certificate template for Operations Manager has been created on CA01 as per the documentation and is called “OperationsManagerCert”. On Gateway01 I have copied the Gateway installer to c:\SCOM\Gateway and the SCOM Tools to c:\SCOM\Tools. SCOM01 is our SCOM collection server.
CA01: Navigate to https://ca01/certsrv and download the CA Certificate.
Gateway01: Copy the CA Certificate to the c:\SCOM folder by whatever means you have. Open mmc.exe and add the Certificates Snap-in for the local computer account. Right click the Trusted Root Certification Authorities store and Import the CA01 CA certificate.
Gateway01: Open notepad and create a new certificate request file with the contents below. Name the file Gateway01.inf and save in c:\SCOM
Subject="CN=<FQDN of Gateway01>"
Gateway01: Open a command prompt as administrator and navigate to c:\SCOM, use certreq.exe to generate a certificate request:
certreq –new –f Gateway01.inf Gateway01.req
Gateway01: Open Gateway01.req in notepad and copy the contents to clipboard.
CA01: Open https://ca01/certsrv and start a new advanced certificate request, create the certificate request using a base64 encoded CMC. Paste the data from Gateway01.req into the “Saved Request” box. Select your SCOM certificate template and click next. Save the response as a Base 64 encoded certificate.
Gateway01: Copy the certificate file over to c:\SCOM on Gateway01 by whatever method you have available. Open a command prompt with admin rights and approve the new certificate with certutil.
certreq –accept Gateway01.cer
Check that the certificate has been imported into the Computer/Personal store using mmc.exe.
SCOM01: At this point you can either install your SCOM agent, or Gateway Server on Gateway01 – if you are installing the Gateway Server like me, you need to first approve the Gateway using the Gateway Approval Tool. Open a command prompt as administrator and navigate to “c:\Program Files\System Center Operations Manager 2007” or wherever your SCOM install is. Copy the Microsoft.EnterpriseManagement.GatewayApproval.Tool.exe from Support Tools into the parent folder (it requires .dlls in that folder).
Gateway01: Run the Gateway Server installer and enter the details of the Management Server and Management Group name. When that’s finished, you need to tell SCOM which certificate to use with the MOMCertImport.exe tool located in c:\SCOM\Tools
MOMCertImport /SubjectName Gateway01.Domain.Lcl
Give it a few minutes and you should be able to see the new gateway under Management Servers in the Administration console for SCOM. Remember to right-click, properties, security and allow the server to act as a proxy if it’s reporting for other servers.
I use the same procedure to install Agents in my DMZ that don’t have access to the certificate services – likewise our production web servers isolated in their hosting environment.
I hope this helps you, I know this is an article that I will be referring back to time and time again!
Exchange 2010 “New Local Move Request” and “New Remote Move Request” missing when you right-click a user’s MailBox
I’m currently testing an Exchange 2010 server for the organisation prior to a migration project, specifically testing moving mailboxes backwards and forwards. Something that confused me slightly for a few minutes was this: if there is an existing Move Request (pending, in progress, failed or completed) you will not see the “New Local Move Request” or “New Remote Move Request” -
Fortunately this is very simple to counter – simply clear the old “Move Request” and the options will be back in the Mailbox options:
Shhhh, don't tell the spam-bots, but after a blissful month of having broken the comments system and not having enough time to fix it, I've finally got round to doing it! Comments will now work without errors - and the spam-bots should have a hard time getting past reCaptcha too!
At some point I'll update to 1.6.1, but for now, I'm glad it's working again!
If you have a Windows Server 2008 box in a workgroup that you require access to one of the admin shares, it can be a little more complicated than with Server 2003. In my case, we had a SQL server on the back end which was trying to access the web server in the DMZ using PSExec.exe to remotely run a process. Executing PSExec and passing the correct credentials failed with “Access is Denied”.
Similarly, when I tried to access the c$, ADMIN$ shares on the server, it would deny me access, and would lock out my admin account when I tried. Creating a separate share would allow me access, but that’s no good for PSExec. To further confuse things, when I accessed the \\server\c$ share from the server, it worked.
Checking the share properties using “net share c$” shows that the settings are all correct, Everyone has FULL access (this is default, it uses NTFS permissions to restrict access):
This issue does not affect domain member servers, I was able to browse to the c$ shares of several Windows Server 2008 servers on the domain.
The problem is caused by UAC and the elevated privileges required to access the administrative shares. This Microsoft KB article (951016) describes the issue in Windows Vista
To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.
and the steps to resolve it, open a new PowerShell window as administrator:
New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name "LocalAccountTokenFilterPolicy" -value "1" -propertyType dword
A word of caution: this is opening up a security hole and it should only be done with careful consideration of the risks. The need to use PSExec to remotely run a process was an important part of the deployment, however the same result could be achieved using PowerShell remoting. Until it’s tested and we’re ready to deploy that, I’ll be using this method.