Opalis lab in the hammock 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.
Recent Comments