Home » 2009 (Page 3)
Yearly Archives: 2009
Add a new activity to a existing service requestDetect 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.
50216 Operations Manager 2007: Advanced Configuration and Administration
This week Microsoft Learning released a new Operations Manager 2007 R2 instructor-led (classroom) course for IT Professionals. It is a 3-days course that will cover the following topics in deep, level 400.
 This course was written by myself and Maarten Goet. Maarten is also a Microsoft MVP within Operations Manager. We have tried to add as much “real world scenarios” and field experience as possible into this course and hope you will learn a lot!
Module 1: Architecture and Troubleshooting
This module will explain how the ‘internals’ of Operations Manager work and how to troubleshoot
Module 2: Management Packs
This module will explain management pack architecture and how to author a management pack.
Module 3: Reporting
This module will explain how to develop custom reports.
Module 4: Connectors
This module will explain how to connect Operations Manager to remote systems, like a ticketing system.
Module 5: Advanced Scripting and PowerShell
This module will explain how to build and work with Operations Manager scripting and PowerShell.
For more info about the course, please take a look here. If you want to attend this course in the the Nordic countries, please take a look here.
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.
test-Imapconnectivity together with PS1,VBS and R2
The Exchange 2007 management packs runs a number of test power shell cmdlet to check that Exchange is working. In some scenarios you cannot use the standard Exchange test cmdlet created by the New-TestCasConnectivityUser.ps1 script. For example in scenarios with complex namespaces or security requirements. In the Ops Mgr 2007 SP1 Exchange 2007 MP (converted) you can override the cmdlet command but The MSExchangeMonitoring service do not support scripts and only a limited set of Exchange cmdlets (test-*) and parameters (positional parameters are not allowed). The accepted syntax is also more restricted than the one accepted by the Exchange Management Shell. So even if you add parameters to the cmdlet it will not work with Ops Mgr. The new Exchange 2007 MP for Ops Mgr R2 do not support override of the cmdlet command at all, but it includes a lot of other great news.
In this example I will run the test-Imapconnectivity cmdlet with the HQ\svc-opsmgr-exchange account. I will run the power shell commands from a vbscript, then picks up the result, analyze it and send it back to Ops Mgr. I use a file, C:\cred.txt, to store the password for the test user (hq\svc-opsmgr-exchange). This file is encrypted (by a PowerShell command) and can only be used by the user created it. That is why the run as profile is so important.
There are a couple of steps to make this work
1. Create a encrypted password file on the affected machines (C:\cred.txt). More info about that file here.
2. Create a management pack to discover the exchange machines you want to use. The class that the management pack discover will be used as target for your run-as profile and for the monitor.
3. Create a two state monitor with the script and settings below, configure it to run for example every 15 minute
Unhealthy Expression: Property[@Name=’ImapConnectivity’] Does not equal Ok
Healthy Expression: Property[@Name=’ImapConnectivity’] equals Ok
Under alerting you can add $Data/Context/Property[@Name=’ImapConnectivity’]$ to see the status and also $Data/Context/Property[@Name=’varPSResult’]$ to see the result from the power shell command.
4. Configure a account and a run-as profile with the same account as you used to encrypt the password file
5. Configure your monitor to use this profile. This can (as far as I know) only be done direct in XML or in the Authoring Console
6. Import everything into Operations Manager and verify your run-as profile and your account. It is important that both your monitor is configure to use the run as profile and that your profile target the affected class/object.
The script:
pscommand = "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin; $pass = get-content C:\cred.txt | convertto-securestring; $credential = new-object -typename System.Management.Automation.PSCredential -argumentlist 'hq\svc-opsmgr-exchange',$pass; $Result = Test-ImapConnectivity -MailboxCredential:$Credential -MonitoringContext:$true -ConnectionType:2 -TrustAnySSLCertificate:$true -LightMode:$true | ft Result; $Result"
cmd = "powershell.exe " & pscommand
Set shell = CreateObject("WScript.Shell")
Set executor = shell.Exec(cmd)
executor.StdIn.Close
varPSResult = executor.StdOut.ReadAll
varString = InStr(varPSResult, "Success")
Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
Call oBag.AddValue("Result",varPSResult)
Call oBag.AddValue("varString",varString)
If varString = 0 Then
Call oBag.AddValue("ImapConnectivity","Error")
Call oAPI.Return(oBag)
Else
Call oBag.AddValue("ImapConnectivity","Ok")
Call oAPI.Return(oBag)
End If
Thanks to Pete Zerger (the run-as profile jedi) and Marco Shaw
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.
NNTP > HTTP
Microsoft has recently launched a new space at Microsoft Technet Forums for Operations Manager 2007 R2. You will find it here. The old NNTP based news group will be closed down. See you at Technet Forums!
Operations Manager forums provides you an opportunity to join a community of Operations Manager customers, product team, MVPs and experts, where you can share knowledge, get questions answered and learn from others. Start by posting Operations Manager related questions in the forum corresponding to your topic of interest and leverage the knowledge available in your new forum community.
Recent Comments