One of the larger projects I’ve been working on is a revamp of the SCOM platform we use for monitoring Windows servers. An annoying problem which we’ve always had is getting the agent installed on any particular server. You would think this would actually be the easiest part, but no, its actually quite a long winded process! It basically boils down to how the SCOM agent authenticates to the RMS. If the agent and RMS are in the same domain then Kerberos can be used and theres no issue. For us though all the servers are going to be on different domains or member servers so we cant use Kerberos. This means we have to use a gateway server and certificates.
The steps to installing the agent are roughly:
- Install either 32bit or 64bit agent on target server
- Configure agent with target SCOM server and management group name
- Request certificate from SCOM CA using server’s FQDN and SCOM OID’s
- Export that certificate to the SCOM agent
This seemed a perfect opportunity to do a small powershell project. The following are some tips to get the crucial parts of the process scripted, ive not gone into every detail or mentioned all the parts but this will hopefully get you on your way. The script first needs to grab some information:
- Fully qualified server name and store it in $FQDN
$Machine = get-content env:Computername $FQDN = [system.net.dns]::GetHostEntry($Machine).HostName
- Find out if the server is 32bit or 64bit and store in $ARCH
$os = get-wmiobject -class "Win32_OperatingSystem" -namespace "rootCIMV2" if ($os.OSArchitecture -eq "64-bit" -or $os.Caption -match "x64") { $arch = 64} else { $arch = 32}
We can install the agent by calling MSIEXEC from inside powershell and pass it what to install. Pass it the correct location dependent on if its 32 or 64bit and pass it the necessary arguments (gateway address and management group):
$Argue=USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=management_group_name MANAGEMENT_SERVER_DNS="scomgw address" SECURE_PORT=5723 ACTIONS_USE_COMPUTER_ACCOUNT=1 msiexec`.exe `/i agentlocationMOMAgent`.msi `/quiet /qn `/promptrestart INSTALLDIR=$InstallDir $Argue
Next we can start worrying about certificates. First step is to import the CA Chain for the SCOM CA. Here is a script for installing a certificate. I wont go into it here but there is various information online:
$Path = 'chainlocationcachain.P7B' $Storage = 'LocalMachine' $flags = "MachineKeySet" $Container = 'Root' $file = gi $Path -Force -ErrorAction Stop $certs = New-Object system.security.cryptography.x509certificates.x509certificate2 $certs = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection $certs.Import([System.IO.File]::ReadAllBytes($file.FullName)) $store = New-Object system.security.cryptography.X509Certificates.X509Store $Container, $Storage $store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $certs | %{$store.Add($_)} $store.Close()
Actually getting a certificate consists of creating a file with the relevant information in it and then turning that into a request file the CA can process. First create the information file:
add-content c:certrequest.inf "[NewRequest]`r Subject = `"CN=$FQDN`"`r Exportable = TRUE`r KeyLength=1024`r KeySpec=1`r KeyUsage=0xf0`r MachineKeySet=TRUE`r [RequestAttributes]`r [EnhancedKeyUsageExtension]`r OID=1.3.6.1.5.5.7.3.1`r OID=1.3.6.1.5.5.7.3.2`r"
We then call certreq and have it convert the text to an actual request file:
certreq.exe -new c:certrequest.inf c:certrequest.req
We use certreq again to submit our request file to the CA. An interesting problem occurs here. The CA is set to allow specific users the ability to request certificates however within the scope of powershell your identity is that of whoever is logged in, this user isn’t going to exist on the CA and so the request is always going to fail. Having tried and failed to get a way of using impersonation directly in powershell I ended up going about this in a rather round about method. I used psexec to execute certreq to submit the request, this way we can specify credentials and effectively execute it outside of the powershell scope. Its messy but does work. We also use the script to create an install user which exists on the CA and then set PSEXEC to use that account:
net user /add install-account password psexec –u install-account –p password -w certreq.exe -submit -config "CA address" c:certrequest.req c:$FQDN.cer
Next we install the certificate we receive back, certreq can also do this:
certreq.exe -accept c:dedipower$FQDN.cer
Lastly we set the SCOM agent to use that certificate by using momcertimport. With momcertimport you can you use either an actual certificate file or it can search for a certificate straight out of the local store:
momcertimport /subjectname $FQDN
After this step you should be communicating to your RMS via the gateway, you can then approve the new server in the SCOM console. If you are trying to get a script going to automate your deployment of the SCOM agent I hope this has been helpful and given you some tips.