JAMA00

SCOM 2007 R2

Archive for the ‘Manual installation’ Category

Setting the primary management server

Posted by MarcKlaver on November 27, 2009

This blog will show how we have implemented a script to control the agent’s primary and fail-over servers.

Manually installed agents – Since the upgrade to Operations Manager 2007 R2, Microsoft removed the possibility to set the primary management server of an agent that was manually installed in the Operations Manager 2007 console. Since it is only a true/false field in the database, one could opt for changing this value and again use the Operations Manager 2007 console to change the primary management server for an agent.

In our case that would lead to two problems:

  1. It is not supported.
  2. The root management server is still used as fail-over server (our root management server is not reachable for agents).

So we decided to use a powershell script to set the primary and fail-over servers for each agent. The idea is that every management server in production will hold the same amount of agents, so we use al our management servers. One is set as a primary management server, all others are used as fail-over management servers. The root management server is not reachable from the clients, so it will not be used for primary or fail-over server.

Since we do not care with which primary management server an agents is communicating, we created a simple “load balancing” script:

#——————————————————————————-
# File        : jamaLoadBalanceManagementServers.ps1
# Use         : Balance the load for the management servers.
# Input       : —
# $cvs_file_id: jamaLoadBalanceManagementServers.ps1,v 1.5 2009/11/09 13:23:29 $
# Note(s)     : 1) All other management servers are set as failover management
#                  servers.
#
#               3) In production the RMS may not be used as a fail-over or
#                  primary management server. The RMS is not reachable in
#                  production for agents.
#——————————————————————————-
set-psdebug –strict                     # strict variable handling.

#——————————————————————————-
# jamaInitOpsMgr
#
# Use    : Add OpsMgr snapin and connect to the root management server.
# Input  : $strRMS – string – Name of the root management server.
# Returns: —
# Note(s): 1) —
#——————————————————————————-
function jamaInitOpsMgr([string] $strRMS) {
    add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
    set-location "OperationsManagerMonitoring::";
    new-managementGroupConnection -ConnectionString:$strRMS;
}

#——————————————————————————-
# jamaCloseOpsMgr
#
# Use    : Close the connection to the OpsMgr environment.
# Input  : $strLocation – string – Location to switch to before snapin removal.
# Returns: —
# Note(s): 1) —
#——————————————————————————-
function jamaCloseOpsMgr([string] $strLocation) {
    set-location $strLocation
    remove-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
}

#——————————————————————————-
#                              Start the script
#
# Set to false for production environment.
#——————————————————————————-
$bOTA = $true

#——————————————————————————-
# Setting environment dependend values.
#——————————————————————————-
if($bOTA) {
    $rootMS   = ‘RMS.test.local’
    $MSName01 = ‘MGT01.test.local’
    $MSName02 = ‘RMS.test.local’
    $MSName03 = ‘RMS.test.local’
}
else {
    $rootMS   = ‘RMS.prod.local’
    $MSName01 = ‘MGT01.prod.local’
    $MSName02 = ‘MGT02.prod.local’
    $MSName03 = ‘MGT03.prod.local’
}
jamaInitOpsMgr($rootMS)

#——————————————————————————-
# Retrieve the management servers.
#——————————————————————————-
$MS01 = Get-ManagementServer | where {$_.Name -eq $MSName01}
$MS02 = Get-ManagementServer | where {$_.Name -eq $MSName02}
$MS03 = Get-ManagementServer | where {$_.Name -eq $MSName03}

#——————————————————————————-
# Variable for load balancing.
#——————————————————————————-
$iLoadBalanceId = 1

#——————————————————————————-
# Retrieve all agents!
#——————————————————————————-
$Agents = get-agent

#——————————————————————————-
# Assign each agent the primary and failover management servers.
#——————————————————————————-
foreach($Agent in $Agents) {
    if($iLoadBalanceId -eq 1) {
        Set-ManagementServer -AgentManagedComputer $Agent -PrimaryManagementServer: $MS01 -FailoverServer: $MS02,$MS03
    }
    elseif($iLoadBalanceId -eq 2) {
        Set-ManagementServer -AgentManagedComputer $Agent -PrimaryManagementServer: $MS02 -FailoverServer: $MS03,$MS01
    }
    elseif($iLoadBalanceId -eq 3) {
        Set-ManagementServer -AgentManagedComputer $Agent -PrimaryManagementServer: $MS03 -FailoverServer: $MS01,$MS02
    }
    #—————————————————————————
    # Set what to assign to next agent.
    #—————————————————————————
    if($iLoadBalanceId -ge 3) {
        $iLoadBalanceId = 1
    }
    else {
        $iLoadBalanceId += 1
    }
}

jamaCloseOpsMgr(‘C:’)

This script must be run by an Operations Manager 2007 administrator. We run this script manually after a bulk of agents is installed or when the “load balancing” is way off (our installation script has a fixed primary management server configured).

Advertisements

Posted in Management Servers, Manual installation | Leave a Comment »

Using certificates

Posted by MarcKlaver on November 25, 2009

This blog will explain how we use certificates with SCOM 2007 R2. Since we do not have any trusts with the monitored customer forests, we greatly depend on certificates.

CA Server – We have a single stand-alone CA server, which only purpose is to create certificates for the SCOM 2007 environment. The root CA is called JAMA00.

Requesting a certificate – From the target server (running the agent), we have no access to the CA server’s web interface. Therefore we must manually generate a certificate request and upload this request to a central file share.

Creating a certificate – We have automated the process of picking up the certificate requests (from the central file share) and generating a certificate file. We also generate an executable installer file, which will install the newly generated certificate on the target server and will configure SCOM to use this certificate for communication with our environment.

Importing a certificate – We support several ways for importing the certificate at the target server. This can be done before, during or after the SCOM agent has been manually installed (as long as our scripted version of the manual installation is used).


CA Server – Default a certificate issued by a CA is valid for one year. To prevent us from replacing all certificates after a year we have changed the configuration, so certificates are valid for a period of 100 years. See this Microsoft article on how to make these settings:

image

But since a certificate can not surpass the lifetime of the root CA, we have also set the expiration date of the root CA certificate to 100 years:

image

So effectively, all certificates are valid until the expiration date of the root CA certificate.


Requesting a certificate – To request a certificate, the certreq.exe application must be available on the system. This is default the case for all versions of Windows, with the exception of Windows 2000.

Remember that we do not have access to the web interface of the CA server, so we make a manual request from the command line.

The certreq.exe must be supplied with a file which describes the required certificate for which a request file must be generated. This file should contain this information:

[Version]
Signature= "$Windows NT$"
[NewRequest]
Subject = "CN=<FQDN>"
KeySpec = 1
KeyLength = 1024
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

<FQDN> must be the FQDN of the server when it is a domain member or the computer name when it is a workgroup server.

It is possible to set the value for “Exportable” to “FALSE”, so the private key is no longer exportable. However Microsoft states that the private key must be exportable (I don’t know why).

When we name this file: certreq.inf, the command to generate a certificate request file will become:

certreq -new -q -f certreq.inf certificate.req

This will generate a request file called: “certificate.req”

We have scripted all of these steps and made sure that the actual name of the request file is set to the FQDN of the computer generating the request. This will prevent any duplicate name issues when copying the request file to the shared location. So in general terms we execute:

certreq –new –q –f certreq.inf <FQDN>.req

And here the <FQDN> part is the FQDN of the computer (or the computer name for workgroup computers). So we now have a certificate request file, which name is unique in the SCOM environment.

This certificate request file can now be placed on the central file share.


Creating a certificate – After the certificate request file has been placed on the central file share, the request file will be processed by a script to generate the required certificate file for the target server.

To generate a valid certificate, the following steps are performed:

 Submit the request

To submit the request, the following command is given on the CA server:

certreq -submit -q -config "<CASERVER>" <REQUESTFILE>

Where <CASERVER> equals the FQDN of the CA server and <REQUESTFILE> is the request file from the target server.

This command will pass back an Id, which we can use in the next step of processing the certificate request. The certificate is now in the pending state and must be issued before it can be used.

Issue the request

To issue the request, the following command is given on the CA server:

certutil -resubmit <REQUESTID>

Here <REQUESTID> is the Id that was passed back from the submit command in the previous step. When completed, the certificate is issued and ready for use. We can now retrieve the certificate and use it at the target server.

Retrieve the certificate

To retrieve the request, the following command is given on the CA server:

certreq -retrieve -q -config "<CASERVER>” <REQUESTID> <CERTFILE>

Again the <CASERVER> equals the FQDN of the CA server, the <REQUESTID> equals the Id that was passed back from the first step and <CERTFILE> is the name for the retrieved certificate.

So when all is finished, we have a certificate file called <CERTFILE>, which can be imported on the target server that generated the certificate request file.

To make life easier we gave the final <CERTFILE> the same name as the FQDN of the target server, followed with the .cer extension.

So if a server is called “server01.company.local”, the final certificate file that is generated is called “server01.company.local.cer”.

Importing the certificate

To import the certificate, the newly generated certificate must be “accepted” by the machine that generated the certificate request. The following command is given on the target server:

certreq.exe -accept –q “<CERTFILE>"

This command will make the certificate file available for use on the target machine. Again, <CERTFILE> is the certificate file generated in the previous step.

Configuring SCOM agent

The final step in this process is to configure the SCOM agent to use this certificate for communication with the SCOM management servers. To do this, this command is given on the target server:

MOMCertImport.exe /SubjectName <FQDN>

Here <FQDN> is the FQDN of the target server and this should be equal to the FQDN used in the certificate.

After a restart of the SCOM agent, the agent will start communicating with the management servers, using the certificate.

Certificate installer package

When the certificate request is generated on the CA server, we also package this certificate file into an installer executable, which contains the certificate and a script that will accept this certificate on the local server and instruct the SCOM agent to start communicating, using this certificate (combining the import and configuring steps mentioned above).


The root CA certificate – Now this all works great, as long as both the agent and the management servers use a certificate generated by the same CA and do trust this CA.

The management servers are given a correct certificate and the root CA certificate during installation of the management server.

The target servers (running the agents) must also have the correct root CA certificate in the “Trusted Root Certification Authorities” in the local computer store.

image

We have completely scripted the (manual) installation of the agent and part of this script is the import of the root CA certificate in the “Trusted Root Certification Authorities” of the local computer.

This is done by running this command on the target server

certutil.exe –addstore root <ROOTCA>

The <ROOTCA> must be replaced with the root CA certificate file (JAMA00.cer in our case), which holds the root CA certificate.

Posted in Certificates, Manual installation | Leave a Comment »