I believe that this sketch by our intern clearly indicates his feelings on clustering in Ops Mgr. Not sure how much I disagree with his opinion.
Friday 7 December 2007
Thursday 29 November 2007
Event description in Monitor or Rule
When creating an alert based on the Event description, this property is missing from both the Authoring console and the Ops console.
Labels:
Authoring,
Operations Manger 2007
Wednesday 26 September 2007
Embed a Powershell Script in a Management Pack
- Updated -
OpsMgr R2 allows you to embed powershell scripts in a MP - See this MP for an example - http://derekhar.blogspot.com/2009/11/new-agent-maintenance-mode.html
----------
If you want to run powershell, perl or any other scripts not run by cscript.exe from a management pack then you invariably had to create the script and distribute it across all the servers where it needed to run. This could easily become quite complex maintaining all these scripts in multiple different locations. If you are in a situation where you have multiple management groups and none of them are quite the same then you could have multiple different versions of the script and the rule that would call the script.
To avoid this problem it is now possible to embed other scripts in a management pack, not just vbscript and jscript.
To explain how this is done we need to break in to the XML. Open the image below to view the full command. This would be executed using on a recurring basis using a System.Scheduler datasource.
The Write Action aboves enables proxying for all management servers. This check is quite easy to do using the command shell alias.
<ApplicationName>%systemroot%\System32\windowspowershell\v1.0\powershell.exe</ApplicationName>
This line launches the Powershell exe. Remember that Powershell must be installed on any server you are targeting the rule at. The same goes for any other script language that you wish to use.
<WorkingDirectory>%MOMROOT%</WorkingDirectory>
The %MOMROOT% variable point to the Installation path of OpsMgr. This is useful when targeting Powershell scripts at the RMS or Management servers as it allows you to easily load the Command Shell Snap-in. This then gives access to all the Command Shell aliases.
<CommandLine>-Command "& '$File/EnableProxy.ps1$'"</CommandLine>
The arguments being passed specifies to run the script $File/EnableProxy.ps1$. After this the file must be entered.
<Files>
<File>
<Name>EnableProxy.ps1</Name>
<Contents>
The name of the script must match the command line name. While I have not tested this there appears to be the ability to embed multiple files here.
Now we drop into the script itself. This rule is targeted to run only on the RMS so $rootMS is set as localhost. The next 3 lines load the Command Shell snapin, and opens the connection to the local management group.
$rootMS="localhost"
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$rootMS;
Here is an example Management Pack
OpsMgr R2 allows you to embed powershell scripts in a MP - See this MP for an example - http://derekhar.blogspot.com/2009/11/new-agent-maintenance-mode.html
----------
If you want to run powershell, perl or any other scripts not run by cscript.exe from a management pack then you invariably had to create the script and distribute it across all the servers where it needed to run. This could easily become quite complex maintaining all these scripts in multiple different locations. If you are in a situation where you have multiple management groups and none of them are quite the same then you could have multiple different versions of the script and the rule that would call the script.
To avoid this problem it is now possible to embed other scripts in a management pack, not just vbscript and jscript.
To explain how this is done we need to break in to the XML. Open the image below to view the full command. This would be executed using on a recurring basis using a System.Scheduler datasource.
The Write Action aboves enables proxying for all management servers. This check is quite easy to do using the command shell alias.
<ApplicationName>%systemroot%\System32\windowspowershell\v1.0\powershell.exe</ApplicationName>
This line launches the Powershell exe. Remember that Powershell must be installed on any server you are targeting the rule at. The same goes for any other script language that you wish to use.
<WorkingDirectory>%MOMROOT%</WorkingDirectory>
The %MOMROOT% variable point to the Installation path of OpsMgr. This is useful when targeting Powershell scripts at the RMS or Management servers as it allows you to easily load the Command Shell Snap-in. This then gives access to all the Command Shell aliases.
<CommandLine>-Command "& '$File/EnableProxy.ps1$'"</CommandLine>
The arguments being passed specifies to run the script $File/EnableProxy.ps1$. After this the file must be entered.
<Files>
<File>
<Name>EnableProxy.ps1</Name>
<Contents>
The name of the script must match the command line name. While I have not tested this there appears to be the ability to embed multiple files here.
Now we drop into the script itself. This rule is targeted to run only on the RMS so $rootMS is set as localhost. The next 3 lines load the Command Shell snapin, and opens the connection to the local management group.
$rootMS="localhost"
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$rootMS;
Here is an example Management Pack
Labels:
Maintenance Mode,
Operations Manger 2007,
Powershell,
Scripts
Tuesday 25 September 2007
Data Warehouse Query
If you have multiple management groups rolling up to a single data warehouse here is a query that will allow you to return a computer name and its associated management group. Not great or anything but the first attempt at digging in to the db.
SELECT ManagedEntity.DisplayName, ManagementGroup.ManagementGroupDefaultName
from OperationsManagerDW.dbo.ManagedEntity
INNER JOIN OperationsManagerDW.dbo.ManagementGroup ON
ManagedEntity.ManagementGroupRowId
= ManagementGroup.ManagementGroupRowId
WHERE fullname like 'Microsoft.Windows.Computer:%'
SELECT ManagedEntity.DisplayName, ManagementGroup.ManagementGroupDefaultName
from OperationsManagerDW.dbo.ManagedEntity
INNER JOIN OperationsManagerDW.dbo.ManagementGroup ON
ManagedEntity.ManagementGroupRowId
= ManagementGroup.ManagementGroupRowId
WHERE fullname like 'Microsoft.Windows.Computer:%'
Labels:
data warehouse,
Operations Manger 2007,
sql
Tuesday 11 September 2007
XPath statements to display event data in monitors and rule-generated alerts.
http://goteamshake.com/?p=31
Here are the XPath statements to display event data in monitors and rule-generated alerts.
Monitors
$Data/Context/EventDescription$
Rule-Generated Alerts
$Data/EventDescription$
Labels:
Operations manager 2007
Thursday 9 August 2007
Active Directory Agent Assignment using a database
The post over on System Center forum about Using Property Bags with Custom Scripting in Operations Manager 2007 has helped me to solve a problem I was having with doing Active Directory based Agent Assignment using a database. This is for integration with a CMDB type database to control agent assignment.
This will take the form of a rule that runs a script to query a database and returns multiple property bags with each property bag containing the dnshostname and distinguished name of each computer that is to be assigned to a management server.
The output fo this script can then be passed to the AD writer action that writes the computer objects to the relevant security groups in the management group OU under the Operations Manger OU.
The rule that is generated by the GUI using the LDAP provider to perform the LDAP query and returns a result for each object found and passes each result seperatley to the Ad Writer rule. This is where the multiple property bags comes in as the of the AD Writer action expects multiple inputs that can only be provided, as far as I can determine, by using multiple property bags.
The rule will run on each management server and the script will simply query the database for the agents belonging to that management server. All the load balancing will be done by the database itself.
I will be have more on this rule in future posts.
This will take the form of a rule that runs a script to query a database and returns multiple property bags with each property bag containing the dnshostname and distinguished name of each computer that is to be assigned to a management server.
The output fo this script can then be passed to the AD writer action that writes the computer objects to the relevant security groups in the management group OU under the Operations Manger OU.
The rule that is generated by the GUI using the LDAP provider to perform the LDAP query and returns a result for each object found and passes each result seperatley to the Ad Writer rule. This is where the multiple property bags comes in as the of the AD Writer action expects multiple inputs that can only be provided, as far as I can determine, by using multiple property bags.
The rule will run on each management server and the script will simply query the database for the agents belonging to that management server. All the load balancing will be done by the database itself.
I will be have more on this rule in future posts.
Thursday 19 July 2007
More about Property bags and Varant types
When returning values in a property bag that are not string values you will have to break open the XML of the management pack to be able to compare the values correctly.
The XML generated by the Authoring console will look something like:
<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="String">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>
If returning Integer values that you want to compare with integers you will have to change it to:
<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type="Integer">Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="Integer">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>
Note that the Type declaration has to be on both sides of the expression. Also be aware that some version of the Authoring console may strip the Type="Integer" from the XPath query.
Thanks to Alexandre Coelho for this fix.
The XML generated by the Authoring console will look something like:
<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="String">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>
If returning Integer values that you want to compare with integers you will have to change it to:
<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type="Integer">Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="Integer">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>
Note that the Type declaration has to be on both sides of the expression. Also be aware that some version of the Authoring console may strip the Type="Integer" from the XPath query.
Thanks to Alexandre Coelho for this fix.
Labels:
Authoring,
Operations manager 2007
Wednesday 18 July 2007
Passing an Event Description to an Alert description
Finding the correct Data Item Context Parameters to use in Operations manager can be a problem. Here is the one to pass an Event description to an Alert. Useful if you want the Alert description to contain the Event description.
$Data/Context/EventDescription$
$Data/Context/EventDescription$
Labels:
Authoring,
Operations Manger 2007
Tuesday 17 July 2007
Export a Sealed MP
Export a Sealed MP
A sealed MP can be exported to an XML file using Command Shell.
Find the correct name of the MP you want to export using:
get-managementpack | where {$_.Name -like "*Server.2003"}
Export using:
get-managementpack | where {$_.Name -eq "Microsoft.Windows.Server.2003"} | export-managementpack -path C:\MP
Labels:
management pack,
Operations manager 2007,
Powershell
Monday 16 July 2007
Property bags and Variant Types
When using script based monitors the name value pairs get returned in what is called a propert bag. A property bag is simply a blob of XML that looks like this:
<DataItem type="System.PropertyBagData" time="2007-07-16T23:10:53.1294962+01:00" sourceHealthServiceId="8FD1B472-1464-691B-9BF7-E3AC669C2310">
<Property Name="scan.dat" VariantType="3">19</Property>
<Property Name="names.dat" VariantType="3">19</Property>
<Property Name="clean.dat" VariantType="3">19</Property>
</DataItem>
The XML describes that this is a property bag, that date/time that it was submitted to the management server and the properties contained in the property bag.
The VariantType describes the type of the value that is returned. The variant types are:
Empty = 0
Null = 1
Short = 2
Integer = 3
Single = 4
Double = 5
Currency = 6
Date = 7
String = 8
Object = 9
Error = 10
Boolean = 11
Variant = 12
DataObject = 13
Decimal = 14
Byte = 15
Char = 16
Long = 17
<Property Name="scan.dat" VariantType="3">19</Property>
<Property Name="names.dat" VariantType="3">19</Property>
<Property Name="clean.dat" VariantType="3">19</Property>
</DataItem>
The XML describes that this is a property bag, that date/time that it was submitted to the management server and the properties contained in the property bag.
The VariantType describes the type of the value that is returned. The variant types are:
Empty = 0
Null = 1
Short = 2
Integer = 3
Single = 4
Double = 5
Currency = 6
Date = 7
String = 8
Object = 9
Error = 10
Boolean = 11
Variant = 12
DataObject = 13
Decimal = 14
Byte = 15
Char = 16
Long = 17
Labels:
Operations manager 2007,
Scripts
Clearing the Operation Manager Console Cache
When creating and deleting management packs you may find that the console becomes out of sync with the database. To fix this you can delete the Console cache by deleting the files under
C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\Microsoft.Mom.UI.Console
C:\Documents and Settings\
Labels:
Operation Manager
Friday 13 July 2007
Some Ops manager Agent Stuff
We had some problems every time we built a new management group in our lab. All the old agents would still be trying to report to the old management group. This was a pain because all this did was clutter up the Operations Manager Log. The solution we used was to create a task that would completely uninstall all the agents. They would then be automatically reinstalled by the active management group if you have applied the overrides to enable the recoveries as detailed in the System Center Management Pack Guide. A bit of powershell would then run this task against all agents.
To Create the Uninstall Task
On the Authoring pane on the console create a new command line agent task called CompleteUninstall. The target is Windows Computer. The command line settings are shown below.
Uninstall command for Agent (RTM)
MsiExec.exe /x {E7600A9C-6782-4221-984E-AB89C780DC2D} /quiet
This gives us a task that ca be run on an agent to perform an uninstall of an agent. To run this on all agents the easiest way is to do it in a powershell script
Powershell Script to run the task for all agents
$uninstallTask = get-task | where {$_.Name -eq "CompleteUninstall"}
foreach($agent in get-agent)
{
$server = $agent.Displayname
$server
start-task -asynchronous -task:$uninstallTask -path .\Microsoft.SystemCenter.AgentManagedComputerGroup\$server
}
Save this script as a .ps1 file and then run it from the Operations Manager Command Shell. The results of these tasks will always show in the Operations Console under Task Status as failed as the Agent has been removed.
To Create the Uninstall Task
On the Authoring pane on the console create a new command line agent task called CompleteUninstall. The target is Windows Computer. The command line settings are shown below.
Uninstall command for Agent (RTM)
MsiExec.exe /x {E7600A9C-6782-4221-984E-AB89C780DC2D} /quiet
This gives us a task that ca be run on an agent to perform an uninstall of an agent. To run this on all agents the easiest way is to do it in a powershell script
Powershell Script to run the task for all agents
$uninstallTask = get-task | where {$_.Name -eq "CompleteUninstall"}
foreach($agent in get-agent)
{
$server = $agent.Displayname
$server
start-task -asynchronous -task:$uninstallTask -path .\Microsoft.SystemCenter.AgentManagedComputerGroup\$server
}
Save this script as a .ps1 file and then run it from the Operations Manager Command Shell. The results of these tasks will always show in the Operations Console under Task Status as failed as the Agent has been removed.
Labels:
Agent,
Operations manager 2007,
Powershell
Thursday 12 July 2007
Operation Manager Command Shell on any system
This is a basic guide to get a Operations Manager Command shell on any system without having to install the UI components. You will need to have Powershell and DotNet 3.0 installed on the system.
Copy the Files
You will need to copy some files from your Ops manager install to get the command shell working.
From the Ops Manager installation directory:
Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll-help.xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml
From the SDK Binaries Folder in the Ops Manager installation directory:
Microsoft.EnterpriseManagement.OperationsManager.dll
Microsoft.EnterpriseManagement.OperationsManager.Common.dll
Copy these files to a folder on the system you want the command shell on. For this example I will copy them to C:\OpsShell.
Register the Powershell Snap-in
For the Powershell snap-in to work we need to register it. As we are not installing the UI this will have to be done manually. Add the below registry settings replacing "C:\\OpsShell" in the following regsitry entries with the correct path to the files.
-----------
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.EnterpriseManagement.OperationsManager.Client] "ApplicationBase"="C:\\OpsShell" "AssemblyName"="Microsoft.EnterpriseManagement.OperationsManager.ClientShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" "ModuleName"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll" "PowerShellVersion"="1.0" "Vendor"="Microsoft Corporation" "Version"="6.0.4900.0" "Description"="Microsoft Operations Manager Shell Snapin" "Types"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml" "Formats"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml"
-----------
Create the Startup Script
Below is a Powershell script that you can use as a shortcut to start the Command Shell. Copy it to notepad and save it in C:\OpsShell as OpsShell.ps1. Some of the script was borrowed from here
-----------
param ($rootMS)
$rootMS.Length
if ($rootMS -eq $null)
{
$rootMS = Read-Host "Root manangement server"
}
$checksnappin = Get-PSSnapin | where {$_.Name -eq "Microsoft.EnterpriseManagement.OperationsManager.Client"}
if ($checksnappin -eq $null)
{
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
}
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;
set-location $rootMS -ErrorVariable errSnapin ;
-----------
Starting the Command Shell
To start the Command Shell open powershell and run C:\OpsShell\OpsShell.ps1.
If you get the error:
File C:\OpsShell\OpsShell.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
Then run this command to change the execution policy:
Set-ExecutionPolicy Unrestricted
This works for me on XP SP2 and Server 2003 SP2
This could be expanded to offer the ability for our server admins to do things such as set Maintenance Mode on or off without having to do it in 3 different locations in the console as is currently needed.
Copy the Files
You will need to copy some files from your Ops manager install to get the command shell working.
From the Ops Manager installation directory:
Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll-help.xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml
From the SDK Binaries Folder in the Ops Manager installation directory:
Microsoft.EnterpriseManagement.OperationsManager.dll
Microsoft.EnterpriseManagement.OperationsManager.Common.dll
Copy these files to a folder on the system you want the command shell on. For this example I will copy them to C:\OpsShell.
Register the Powershell Snap-in
For the Powershell snap-in to work we need to register it. As we are not installing the UI this will have to be done manually. Add the below registry settings replacing "C:\\OpsShell" in the following regsitry entries with the correct path to the files.
-----------
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.EnterpriseManagement.OperationsManager.Client] "ApplicationBase"="C:\\OpsShell" "AssemblyName"="Microsoft.EnterpriseManagement.OperationsManager.ClientShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" "ModuleName"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll" "PowerShellVersion"="1.0" "Vendor"="Microsoft Corporation" "Version"="6.0.4900.0" "Description"="Microsoft Operations Manager Shell Snapin" "Types"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml" "Formats"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml"
-----------
Create the Startup Script
Below is a Powershell script that you can use as a shortcut to start the Command Shell. Copy it to notepad and save it in C:\OpsShell as OpsShell.ps1. Some of the script was borrowed from here
-----------
param ($rootMS)
$rootMS.Length
if ($rootMS -eq $null)
{
$rootMS = Read-Host "Root manangement server"
}
$checksnappin = Get-PSSnapin | where {$_.Name -eq "Microsoft.EnterpriseManagement.OperationsManager.Client"}
if ($checksnappin -eq $null)
{
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
}
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;
set-location $rootMS -ErrorVariable errSnapin ;
-----------
Starting the Command Shell
To start the Command Shell open powershell and run C:\OpsShell\OpsShell.ps1.
If you get the error:
File C:\OpsShell\OpsShell.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
Then run this command to change the execution policy:
Set-ExecutionPolicy Unrestricted
This works for me on XP SP2 and Server 2003 SP2
This could be expanded to offer the ability for our server admins to do things such as set Maintenance Mode on or off without having to do it in 3 different locations in the console as is currently needed.
Labels:
Command Shell,
Operations Manger 2007,
Powershell
Subscribe to:
Posts (Atom)