Hi There!

This is the first in a series of blogs that I plan to do about Service Manager and PowerShell.  These will be posted in two places - the Service Manager Blog and my spaces page, you can go to the Service Manager blog to see more posts on Service Manager, and if you found this on the Service Manager blog, you can take a look on my Spaces (http://jtruher.spaces.live.com/) page which has a number of different posts on PowerShell and my other hobbies.  My semi-regular readers know that I was one of the co-creators of the PowerShell scripting language and I was one of the first members of the PowerShell team and had a whole lot to do with the first release of PowerShell, but you may not know that I am now part of the System Center Service Manager team where my area of responsibility is the SDK.  This is a great new challenge for me, with an entire new area of system management to learn, so it’s very exciting.

One of great things about the Service Manager product is that it is based on managed code, and because of that, PowerShell can take direct advantage of all that great code.  As these articles are really about using PowerShell with Service Manager, I’m not going to spend too much time in a tutorial on PowerShell in general as there are a number of great sources for information on PowerShell (to which I’ll provide links at the end of this article). 

At the moment there are no cmdlets for Service Manager. We will likely be providing some later in our release cycle, but for these first articles, I’ll be interacting directly against the managed interfaces that are part of the SDK.  This does make the scripting a bit more advanced from a PowerShell perspective, but it shouldn’t be too much to start – We’ll essentially be approaching this similarly to how you would approach programming against Service Manager in C#.  Jakub Olesky, a dev lead on the project has a great blog here: http://blogs.mdn.com/jakuboleksy/ he has a ton of great articles about programming against Service Manager (and Operations Manager).

Here we go!

To get access to the Service Manager object space, we’ll need to load the appropriate assemblies.  When you install Service Manager, the libraries we need are put on the file-system and by default can be found in the directory C:\Program Files\Microsoft System Center\Service Manager 2010\SDK Binaries.  The following lines should allow you to load the Service Manage core assembly.

PS> $SMDIR = "C:\Program Files\Microsoft System Center\Service Manager 2010"
PS> $COREDLL = "${SMDIR}/SDK Binaries/Microsoft.EnterpriseManagement.Core.dll"
PS> [reflection.assembly]::LoadFile($COREDLL)

GAC    Version        Location
---    -------        --------
True   v2.0.50727     C:\Windows\assembly\GAC_MSIL\Microsoft.EnterpriseManagement.Core\1.0.2700.0__9396306c2be7fcc4\...

As we progress with these articles, we’ll do the above every time, so to save typing, you should put those three lines in your $profile so it just happens automatically. 

Now that we have the assembly loaded we can start interacting with Service Manager.  The way that you communicate with Service Manager is via the Microsoft.EnterpriseManagement.EnterpriseManagementGroup object and there are a number of ways to create this object. We’ll create it via the simplest method, just by providing the server name where the Service Manager management server has been installed.   Since I’m running these examples on the same system where the Service Manager management server is installed, I’ll use the server name “localhost” (by the way, if you run the Service Manager Console on a different the system than where the Service Manager management server is installed, you’ll need to provide the name of the management server here).

How did I know that Microsoft.EnterpriseManagement.EnterpriseManagementGroup was the place to start?  I looked that up in the SDK documentation. 

PS> $MGroup = New-Object Microsoft.EnterpriseManagement.EnterpriseManagementGroup localhost

Excellent!  If there was a problem in creating the object, I would have gotten an error message, now I can inspect the $MGroup object that I just created.

PS> $MGroup 

ConnectorFramework : Microsoft.EnterpriseManagement.ConnectorFramework.ConnectorFrameworkConfigurationManagement
EntityTypes        : Microsoft.EnterpriseManagement.EntityTypeManagement
Instances          : Microsoft.EnterpriseManagement.InstancesManagement
Knowledge          : Microsoft.EnterpriseManagement.KnowledgeManagement
LanguagePacks      : Microsoft.EnterpriseManagement.LanguagePacksManagement
ManagementPacks    : Microsoft.EnterpriseManagement.ManagementPackManagement
Monitoring         : Microsoft.EnterpriseManagement.MonitoringConfigurationManagement
Overrides          : Microsoft.EnterpriseManagement.OverridesManagement
Presentation       : Microsoft.EnterpriseManagement.PresentationManagement
Reporting          : Microsoft.EnterpriseManagement.ReportingConfigurationManagement
Resources          : Microsoft.EnterpriseManagement.ResourceManagement
Security           : Microsoft.EnterpriseManagement.SecurityConfigurationManagement
Subscription       : Microsoft.EnterpriseManagement.Subscriptions.SubscriptionManagement
Tasks              : Microsoft.EnterpriseManagement.TaskConfigurationManagement
Templates          : Microsoft.EnterpriseManagement.TemplatesManagement
TypeCache          : Microsoft.EnterpriseManagement.TypeCacheManagement
TypeDefinitions    : Microsoft.EnterpriseManagement.TypeDefinitionsManagement
DataWarehouse      : Microsoft.EnterpriseManagement.DataWarehouseManagement
Notifications      : Microsoft.EnterpriseManagement.NotificationManagement
Name               : Woodgrove
Id                 : 86a8c51c-4680-3ba0-4843-1c38f462b0b6
IsConnected        : True
CacheMode          : Configuration
AutoRefreshCache   : True
SkuForLicense      : Select
SkuForProduct      : SCOM
TimeOfExpiration   : 12/31/9999 11:59:59 PM
ProductId          :
ConnectionSettings : Microsoft.EnterpriseManagement.EnterpriseManagementConnectionSettings
Version            : 1.0.3105.0

You can see a number of different interesting bits of information here:  First you can see that the IsConnected property is true, which means that I have a connection to the Service Manager SDK service.  If this is ever “false”, it means that I won’t be able to get any data from Service Manager because I’m no longer connected to the service that talks to Service Manager.

it’s ok if that happens, the object has a Reconnect() method which I can use to open my connection again

This object also has version information, and a whole lot of other stuff.  You'll notice a number of more complicated properties (the top 2/3rds of the output).  These properties provide us the access points to the various parts of the product such as the sort of classes that are installed (EntityTypes), the actual data stored in Service Manager (Instances), and a whole bunch of other things that we’ll explore in later articles.  Take a look at the SDK documentation if you want more information.

The management pack is the way that you determine what sort of data you will track in Service Manager.  Management packs define a whole bunch of information about the various entities such as Computers, Users, Network Cards, as well as actions that can be used with these various entities – so knowing what management packs are installed is really important.  If you start the Analyst Console you’ll see something that looks like this if you select the Administration tab:

AdminConsole002

We can approximate this view of the ManagementPack table with PowerShell with the following command line:

PS> $MGroup.ManagementPacks.GetManagementPacks()|format-Table Sealed,Name,Description -au 

Sealed Name                                                            Description
------ ----                                                            -----------
  True Microsoft.SystemCenter.InstanceGroup.Library                    Microsoft System Center Instance Group Librar...
  True Microsoft.Windows.Peripheral.Library                            Microsoft Windows Peripheral Library: This ma...
 False Woodgrove.AutomatedActivity.AddUserToUserGroup
  True ServiceManager.ActivityManagement.Library
  True System.Software.Library                                         System Software Library: This Management Pack...
  True Microsoft.SystemCenter.Deployment.Library
  True ServiceManager.KnowledgeManagement.Library
  True Microsoft.EnterpriseManagement.ServiceManager.UI.Administration ServiceManager Administration ManagementPack
 False ServiceManager.LinkingFramework.Configuration
  True ServiceManager.LinkingFramework.Library
  True System.Snmp.Library                                             SNMP Library: Contains SNMP definitions.
  True ServiceManager.Core.Library
  True Microsoft.EnterpriseManagement.ServiceManager.UI.Console        Service Manager Console ManagementPack
  True System.ApplicationLog.Library                                   System Application Log Library: This Manageme...
  True Microsoft.EnterpriseManagement.ServiceManager.UI.Authoring      Service Manager Authoring ManagementPack
  True Microsoft.SystemCenter.Library                                  Microsoft System Center Library: This Managem...
 False Microsoft.EnterpriseManagement.ServiceManager.Default
  True Microsoft.SystemCenter.WorkItemGroup.Library                    Microsoft System Center Instance Group Librar...
  True System.Library                                                  System Library: Root for all Management Packs...
  True Microsoft.Windows.Library                                       Microsoft Windows Core Library: This Manageme...
  True Microsoft.SystemCenter.ConfigurationManager                     Microsoft System Center Configuration Manager...
  True Microsoft.EnterpriseManagement.ServiceManager.Connector.Sms
 False ServiceManager.ChangeManagement.Configuration
  True System.Health.Library                                           System Health Library: This Management Pack c...
  True Microsoft.SystemCenter.WorkflowFoundation.Library               Microsoft System Center Workflow Foundation L...
  True Microsoft.SystemCenter.Report.Library
  True ServiceManager.Datawarehouse.Library
  True Microsoft.EnterpriseManagement.ServiceManager.Connector.AD
  True ServiceManager.ConfigurationManagement.Library
 False ServiceManager.ActivityManagement.Configuration
  True System.Notifications.Library                                    System Notification Library: This Management ...
  True ServiceManager.IncidentManagement.Library
  True Microsoft.SystemCenter.Subscriptions
  True ServiceManager.ChangeManagement.Library
  True System.Performance.Library                                      System Performance Library: This Management P...
 False ServiceManager.IncidentManagement.Configuration 

Viola!  Now we can get access to the management packs that are installed without having to use the GUI!  At this point, all of the usual PowerShell utility can be used.  For example, if I wanted to see only those management packs which are unsealed I can use where-object (aliased to “?”) to look for where the Sealed property is false (not true).

PS> $MGroup.ManagementPacks.GetManagementPacks()|?{ ! $_.Sealed}|format-Table Sealed,Name,Description -au

Sealed Name                                                            Description
------ ----                                                            -----------
 False Woodgrove.AutomatedActivity.AddUserToUserGroup 
 False ServiceManager.LinkingFramework.Configuration 
 False Microsoft.EnterpriseManagement.ServiceManager.Default 
 False ServiceManager.ChangeManagement.Configuration 
 False ServiceManager.ActivityManagement.Configuration 
 False ServiceManager.IncidentManagement.Configuration

We’ve barely scratched the surface with the way that PowerShell can interact with Service Manager.  In the next article we’ll take a closer look at the contents of a management pack.

Here are those PowerShell links I promised:

http://blogs.msdn.com/powershell/
http://thepowershellguy.com/
http://www.leeholmes.com/blog/default.aspx
http://mow001.blogspot.com/