Home » System Center Operations Manager 2007 (Page 5)
Category Archives: System Center Operations Manager 2007
From Service Map to Network Security GroupConfigure Command Notification in R2
There has been a number of questions about the command notification channel in Technet forums. Here is a example how to configure a command notification channel, a subscriber for the channel and a subscription. This example configure a command notification channel to run a vbscript. The vbscript echo a time stamp and the alertname to a local file.
1. Go to Administration/Notification/Channels and create a new command notification channel. For example
Channel name: Contoso Command Notification Channel
Full path of the command file: C:\windows\system32\cmd.exe
Command line paramters: /c C:\logfile.vbs $Data/Context/DataItem/AlertName$
Startup folder for the command line: C:\
2. Go to Subscribers and create a new subscriber
Subscriber name: Contoso Command Line Subscriber (note that you do not need to select a AD user)
Schedule: Always send notification
Addresses: Added a new address
-Address name: Contoso Command Address
-Channel type: Command
-Command Channel: Contoso Command Notification Channel
-Delivery address for the selected channel: I just left this with default, something about sip: but it resultet in a blank field, so just leave it
-Schedule: Always send notification
3. Goto Subscriptions and add a new subscription, for example
Name: Contoso Command Line Subscription
Criteria: with a specific resolution state: new(0) and closed (255)
Subscribers: Contoso Command Line Subscriber
Channel: Contoso Command Notification Channel
Summary: Make sure the channel is enabled
Thats it, and the logfile.vbs looks like:
' ******************************************
' GET PARAMETERS INTO SCRIPT
' ******************************************
strAlert = Wscript.Arguments.Item(0)
‘ ******************************************
‘ LOG TO FILE (DATE,TIME,TO,ALERT NAME,STATE
‘ ******************************************
Dim Stuff, myFSO, WriteStuff, dateStamp
strdateStamp = Date()
strTimeStamp = Time()
‘Write information to Text File
Stuff = strDateStamp & “,” & strTimeStamp & “,” & strAlert
Set myFSO = CreateObject(“Scripting.FileSystemObject”)
Set WriteStuff = myFSO.OpenTextFile(“opsmgr_notification_logfile.txt”, 8, True)
WriteStuff.WriteLine(Stuff)
WriteStuff.Close
More info about command notification channel here.
Ops Mgr R2 and multiple gateway servers
Some time ago I posted an article about gateway servers, Ops Mgr R2 and Server 2008. This week I have extended that scenario by adding two more management servers and one more gateway server.
To make this scenario work I had to configure both my gateway servers to use corp-MS03 and corp-MS02 as primary and secondary management servers. You can do that with operations manager command shell.
Log on to a machine with command shell installed, for example a workstation. Run the following script (save it as a .ps1 script file)
$primaryMS = Get-ManagementServer | where {$_.Name -eq 'corp-ms02.corp.contoso.local'}
$failoverMS = Get-ManagementServer | where {$_.Name -eq 'corp-r2.corp.contoso.local'}
$gatewayMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
Set-ManagementServer -GatewayManagementServer: $gatewayMS -primarymanagementserver: $primaryMS -FailoverServer: $failoverMS
That script configure the gateway server, DMZ01, to use corp-MS02 as primary management server and corp-R2 as failover management server. When you run this command you have to be aware that when the current management server gets this update it will stop accepting connections from your gateway server (if it is not primary or failover management server in the new configuration). That could result in a orphaned gateway server, the gateway server is not allowed to communicate with any management server. If this happends you will have to logon to your gateway server, check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Group\<Management Group Name>\Parent Health Services\0 and look for the authenticationName string. You must then run the set-managementserver cmdlet again and change the management server back to the one in the register. To make sure you don´t end up with orphaned gateway servers use your current management server as failover server in your script, then the gateway server can receive new configuration from the new failover server (current management server) and when you have confirm the configuration change, you can update the failover server for the gateway server.
To verify that your gateway server has received the new configuration you can look in the OpsMgrConnector.Config.XML file on your Gateway server, search for Parents in the file. Default location is C:\Program Files\System Center operations Manager 2007\Health Service State\Connector Configuration Cache\.
You can also run the following command shell commands to see he primary and failover server for a gateway server
Get-GatewayManagementServer | where {$_.Name -like 'DMZ01'} | Get-PrimaryManagementServer
Get-GatewayManagementServer | where {$_.Name -like 'DMZ01'} | Get-FailoverManagementServer
If everything looks ok, you could now run the power shell script again, and update the failoverMS to the correct failover management server.
To configure the agent to communicate with the two gateway servers I ran the following two scripts. corp-r2 was the primary/only management server for the agent when I started.
$primaryMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
$failoverMS = Get-ManagementServer | where {$_.Name -eq 'corp-r2.corp.contoso.local'}
$agent = Get-agent | where {$_.Name -eq 'DMZ-A01'}
Set-ManagementServer -AgentManagedComputer: $agent -PrimaryManagementServer: $primaryMS -FailoverServer: $failoverMS
after I verified that the agent had recived the new configuration I ran
$primaryMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
$failoverMS = Get-gatewayManagementServer | where {$_.Name -eq 'dmz-02'}
$agent = Get-agent | where {$_.Name -eq 'DMZ-A01'}
Set-ManagementServer -AgentManagedComputer: $agent -PrimaryManagementServer: $primaryMS -FailoverServer: $failoverMS
The result of these commands is that my agent (DMZ-A01) can communicate with both gateway servers. Both my gateway servers can communicate with both my management servers. If I shutdown DMZ01 my agent, DMZ-A01, failover to DMZ-02. If I start DMZ01 again the agent will automatic return to DMZ01. If I shutdown corp-MS02 my gateway server will automatic failover to corp-ms03. If I shutdown one gateway server and one management server the agent will still communicate with the management group.
List Status for Resource Groups
If you want to see the active node for a cluster group you can do that with a task. Create a task target to “Cluster Node”, then add the following command line configuration
Full path to file: %WINDIR%\system32\cluster.exe
Parameters: $Target/Property[Type="MicrosoftWindowsClusterManagementLibrary6065680!Microsoft.Windows.Cluster.Node"]/ClusterName$ group
You can then run the task from the Cluster Node State view in the cluster MP. The task will list status for all available resource groups.
Detect all SQL Server cluster resources
A couple of days I ago when I was working with a SQL cluster I found something interesting. I had problem with a SQL cluster, Operations Manager 2007 R2 only found the first network name in my cluster group, not the one for my SQL cluster. After some time I found the following text in the SQL management pack guide:
Having a SQL Server cluster resource group that contains more than one network name resource might mean that the clustered SQL Server resource is not monitored. For more information, see Knowledge Base article 919594.
…and KB 919594 tells you
To resolve this issue, configure existing resources in the cluster group so that System Center Operations Manager or MOM detects the virtual server, or create and configure the necessary resources. For example, you may have to create a generic application resource that does nothing. This generic application resource will enable System Center Operations Manager or MOM to discover the virtual server on which the resource is hosted.
Note If more than one Network Name resource is configured in a group, System Center Operations Manager or MOM uses the first network name that it detects as the name of the virtual server..
As soon as I had re-organized my cluster resources for SQL into a new cluster group Operations Manager 2007 R2 found the other cluster resource group and the SQL running on it. It also discovered all the SQL components for example databases and logical disks.
There is a KB article about this, KB959865, that shows you another solution, where you can do a override and enable “Multiple Servers Discovery” within the cluster MP.
Changing Passwords with Operations Manager
Yesterday when I was going to do some tests in one of my labs I could not remember the password. Fortunately the Operations Manager R2 RMS machine was unlocked so I could use it. I then created a rule that ran a modification of the following script on each machine, and swish! I could logon again 🙂
Set WshNetwork = WScript.CreateObject("WScript.Network")
strComputer = WshNetwork.ComputerName
strComputer = "."
Set objUser = GetObject("WinNT://" & strComputer & "/Administrator,user")
objUser.SetPassword "NewPasswordHere"
objUser.SetInfo
With that in mind it is funny how some organization look at security and accounts. It is not unusual that a consultant or co-worker get Administrator permissions or Author permissions in Operations Manager, but they would never get full exchange administrator or domain administrator permissions in the environment.
Some interesting link regarding the subject, Ops Mgr security guide and Ops Mgr Security Hardening Guide.
Measure the time it takes to write a file
Update, download a MP with this script here, Contoso.Write.File.to.Share
I have written a script that writes a line of text to a file on a share. It will then return the time it took in the strTimer parameter. You can use this script to measure the time it takes to write text to a file on your network. The default share is \\10.1.1.10\share. You can also change the loop (default 1500) to write the text line more times to the file, that would result in a test with a larger file.
Multi-home X-plat machine
If you want to multi-home a X plat machine (configure  it to report to multiple management groups) there are a couple of steps you need to take. You can not simple discover it from different management groups as we do with Windows agents.
1. Discover your Linux machine from management group 1
2. Export the certificate from the management server which discovered the Linux box in management group 1. The SCX-agent certificates are signed by a key on the management server that has discovered them, and that machine needs to be a trusted root CA on the management server in management group 2
3. Copy the root CA certificate from the management server in management group 1 to the management server in management group 2
4. Import the certificate as a trusted root CA on the management server in management group 2
5. Run discovery wizard in management group 2 and discover the Linux machine
In this scenario it is very important that both management servers communicate with the Linux machine with the same FQDN.
R2, Gateway server and a SUSE machine
Here are some notes from what I did when I connected a SUSE box through a gateway server to Operations Manager 2007 R2. During the discovery I found received two error messages. The first one was solved by selecting correct management server. By mistake I selected my root management server that are on the other side of a ISA server, so it could not copy the files to my SUSE box. When I selected my gateway server instead, that are on the same subnet as SUSE, there was no problem copy the files.
< ![CDATA[Executing command: rm -rf /tmp/scx-root; mkdir -m 755 /tmp/scx-root
Transferring file: E:\Program Files\System Center Operations Manager 2007\AgentManagement\UnixAgents\GetOSVersion.sh to location: /tmp/scx-root/
Verifying that file: GetOSVersion.sh was transferred properly
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
]]>
The second error message was about Windows Remote Management (WinRM). You need to configure WinRM on the gateway server, unfortunately the error message doesn’t tell you that it should be run on the gateway server, but as it is the selected management server for the discovery, that is where you need to configure WinRM.
After that there was no problem discover the SUSE machine from a gateway server.
When I shutdown my gateway server I could see that the SUSE box was changed to a unknown state
I then changed primary management server for my SUSE box, under the Administrator workspace in the console. After a couple of minutes the SUSE box turned red (from unknown) and start alerting about certification problems.
The SCX-agent certificates are signed by a key on the management server that has discovered them, and that machine, in this case my gateway server DMZ01, is not a trusted root CA on my root management server, corp-R2. To verify that the SCX Agent on the remote system is running properly, try enumerating the SCX_Agent provider using the following command from the primary management server
winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://.:1270 -u: -p:
-auth:basic -encoding:utf-8
gave
To solve this, you need to copy the SCX-Certificate from the gateway server, or the management server discovered the SUSE box, to your new primary management server. Import the certificate as a trusted root certification authorities. Once the certificate is in place you can run the WINrm e command again and you will get another result
Summary. The SUSE box can be discovered by your gateway server. The SUSE box can also do a manually failover between a gateway server and a management server, as long as the certificate is in place. Communication between management server and the Linux box use TCP port 1270 and always originates from the management server or gateway server. In some cases, such as when the WSMAN layer is not present on the Linux box or it has failed, the communication can occur over SSH TCP 22. SSH can be used for installing the WSMAN layer or performing diagnostics tasks. There will be no “heartbeat failure” for the SUSE box, at least I did not received that first five minutes. I did received alerts for the gateway server and some “logfile module error” but not a clear “heartbeat missing” alert for my SUSE box.
Ops Mgr R2 and a untrusted agent
Here are some notes from what I did when I installed a new agent in a workgroup/untrusted environment with Operations Manager 2007 R2. In this example my CA server is named DC01 and my agent is named DMZ-a01. These steps presuppose that the other side, a gateway server or a management server, is already configure correct. In this scenario I had a gateway server between the management server and the agent.
Remember to configure your management group to allow manually installed agent (Administration/Settings/Security).
1. From the agent, browse to http://dc01/certsrv
2. Add http://dc01 to your trusted sites in IE
3. If you get a error saying that the CA must be configured to use HTTPS authentication or ActiveX can’t be loaded, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
3. Download a CA certificate, certificate chain, or CRL
4. Download CA Certificate chain
5. Once the cert is downloaded, open a MMC with the Certificates (Local Computer) snap-in and import the certificate under Trusted Root Certification Authorities
The next step is to request and install the proper certificate from the root CA server.
1. From the agent browse to http://dc01/certsrv
2. Request a certificate
3. Advanced certificate request
4. Create and submit a request to this CA
5. If you get a error saying that the CA must be configured to use HTTPS authentication, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
6. On the Advanced Certificate Request page input
Name, needs to be FQDN of the machine, for example dmz-a01
Type of certificate needed: Other
OID: 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
CSP: Microsoft Enhanced Cryptographic Provider v1.0
Check Mark keys as exportable
Name: needs to be FQDN of the machine, for example dmz-a01
7. Submit the request
8. On your root CA (DC01), open the Certification Authority console, issue the certificate under pending requests
9. On the machine that request a certificate (DMZ-a01), browse to http://dc01/certsrv
10. View the status of a pending certificate request
11. Install the certificate by clicking on it
12. Open a MMC with the Certificates snap-in, for “my user accountâ€. Under Personal certificates, export the certificate including the private key.
13. Open a MMC with the Certificates snap-in, for “local computerâ€. Import the certificate under personal certificates.
Next step is to install the agent software. You need to copy the MOMCertImport.exe and the suitable agent folder (for example AMD64) from the installation source to your agent machine. Run the agent setup, input the FQDN of the management server and the name of the management group. Select a action account, if you unsure, select local system and click next. When the installation of the agent is complete, run MOMCertImport.exe and import the certificate. Then restart the System Center Management service (HealthService).
Your agent should now show up under pending management in the Operations Manager console. Approve it and you are done!
There is a tool, certificate generation wizard, that you can download here, it can make untrusted agent scenarios easier.
Ops Mgr R2 and server 2008 in a gateway scenario
I installed a gateway server on Windows server 2008 X64 this week. Here are some steps from what I did. I started with installing a new standalone root certificate authority on a Windows Server 2008 X64 domain controller (DC01) with the following steps.
1. Add role
2. Active Directory Certificate Services
3. Certification Authority and Certification Authority Web Enrollment
4. Standalone, this CA does not use Directory Service data to issue or manage certificates
5. Root CA
6. Create a new private key
7. Default values on cryptography, CA Name, validity period (5 years), certificate database, web server (IIS), Role services
8. Confirm and install, the close the wizard
After that installed the root CA certificate and a certificate on both my management server (corp-R2) and on the gateway server (DMZ01).
1. From both the gateway server and the management server, browse to http://dc01/certsrv
2. Add http://dc01 to your trusted sites in IE
3. Download a CA certificate, certificate chain, or CRL
4. Download CA Certificate chain
5. Once the cert is downloaded, open a MMC with the Certificates (Local Computer) snap-in and import the certificate under Trusted Root Certification Authorities
There is a tool, certificate generation wizard, that you can download here, it can make gateway scenarios easier.
CertGenWizard.exe is a wizard tool which will take your CA information as input (it isn’t required if you are running the wizard on the box with the CA), take in the computer names (has to be FQDNs), and send out a request for the certificates you need. Now, you no longer have to fill out the Certificate Request form or enter parameters or connect to the web enrollment service. Once the certificates are approved, there is a Retrieve button in the CertGenWizard which will allow you to retrieve the certificates that you have requested. On top of the personal certificates, the wizard will retrieve the root CA certificate.
The next step is to request and install the proper certificate from the root CA server, this needs to be done on both the gateway and the management server.
1. From both the gateway server and the management server, browse to http://dc01/certsrv
2. Request a certificate
3. Advanced certificate request
4. Create and submit a request to this CA
5. If you get a error saying that the CA must be configured to use HTTPS authentication, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
6. Input
Name, needs to be FQDN of the machine, for example dc01.corp.contoso.local
Type of certificate needed: Other
OID: 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
CSP: Microsoft Enhanced Cryptographic Provider v1.0
Check Mark keys as exportable
Name: needs to be FQDN of the machine, for example dc01.corp.contoso.local
7. Submit the request
8. On your root CA, open the Certification Authority console, issue the certificate under pending requests
9. On the machine that request a certificate, browse to http://dc01/certsrv
10. View the status of a pending certificate request
11. Install the certificate by clicking on it
12. Open a MMC with the Certificates snap-in, for “my user account”. Under Personal certificates, export the certificate including the private key.
13. Open a MMC with the Certificates snap-in, for “local computer”. Import the certificate under personal certificates.
When both your gateway machine and your management server has each two certificates, the next step will be to run the MOMCertImport.exe tool on your management server. This tool will import the certificate into Operations Manager, writes the serial number of the certificate to use to the registry so Operations Manager components can determine which certificate to use for authentication. Run the tool and select the certificate to use. Then restart the System Center Management service on the management server.
Now it is time to approve the new gateway server. This is done with the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe. This tool depends on a dll file in the Operations Manager installation folder, copy the approval tool to that folder. Run the tool and approve your gateway, for example
Microsoft.EnterpriseManagement.GatewayApprovalTool.exe /ManagementServerName=corp-r2.corp.contoso.local /GatewayName=DMZ01 /SiteName=DMZ /Action=Create
Next step is to install the gateway server. You need to copy the MOMCertImport.exe and the suitable gateway folder (for example AMD64) from the installation source to your gateway server. You need the whole gateway folder, including MOMGateway.msi and tree cabinet files named OMGW, SCXAGTS and OMAGTMGT). The run the MOMGateway.msi as administrator. It will fail if you not run it as administrator. Input the FQDN of the management server and the name of the management group. Select a action account, if you unsure, select local system and click next. When the installation of the gateway server is complete, run MOMCertImport.exe and import the certificate. Then restart the System Center Management service (HealthService).
Open the Operations Manager console and verify that your new gateway server is green and healthy. You can now move on and start install agents.
Recent Comments