Author Archive
Best of MMS 2010 in Stockholm/Sweden
Posted by: | CommentsBest of MMS is approaching! Only a few of weeks away now!
I will deliver a session at Best of MMS 2010 in Stockholm/Sweden. My session “Hardcore customization of Service Manager 2010” is a level 400 session that will take place day one. Amongst other usefull things I’ll show how to make incident management more efficient using custom workflows and how to create automated activities for change management.
There will be a number of System Center experts speaking at the event so bring all your SC questions!
See you in Stockholm! More info about the event here
SCSM Powershell Cmdlets goes Beta 1
Posted by: | CommentsThe PowerShell cmdlets for Service Manager has gone Beta 1. I would like to thank Jim Truher for joining the project and putting in a lot of effort in this release!
Release notes:
The snapin has been converted to a PowerShell version 2 module, so registration is not needed. To install extract the zip archive into the
C:\Windows\System32\WindowsPowerShell\v1.0\modules directory
and then run:
PS> Import-Module SMLets
This module now contains the following:
PS> get-command -module smlets |sort commandtype | ft commandtype,name -au CommandType Name ----------- ---- Alias load Alias new-mg Function New-ManagementGroup Function import-Assembly Function Get-SCSMClassProperty Function get-SCSMCommand Function get-SCSMproperty Cmdlet Get-SCSMTask Cmdlet Get-SCSMSubscription Cmdlet Get-SCSMTypeProjection Cmdlet Get-SCSMTaskResult Cmdlet Get-SCSMUserRole Cmdlet Get-SCSMTopLevelEnumeration Cmdlet Import-SCManagementPack Cmdlet Remove-SCSMSubscription Cmdlet Remove-SCSMObject Cmdlet Remove-SCManagementPack Cmdlet Set-SCSMObject Cmdlet Set-SCSMIncident Cmdlet Set-SCSMAnnouncement Cmdlet New-SCSealedManagementPack Cmdlet New-SCManagementPack Cmdlet Set-SCSMObjectProjection Cmdlet New-SCSMObject Cmdlet New-SCSMIncident Cmdlet New-SCSMAnnouncement Cmdlet Get-SCSMRunAsAccount Cmdlet Get-SCDWWarehouseModuleTypes Cmdlet Get-SCDWRelationshipFactTypes Cmdlet Get-SCManagementPack Cmdlet Get-SCSMAnnouncement Cmdlet Get-SCManagementPackElement Cmdlet Get-SCDWOutriggerTypes Cmdlet Get-DataWarehouseConfiguration Cmdlet Export-SCManagementPack Cmdlet Get-SCDWDimensionTypes Cmdlet Get-SCDWMeasureTypes Cmdlet Get-SCDWFactTypes Cmdlet Get-SCSMCategory Cmdlet Get-SCSMRelatedObject Cmdlet Get-SCSMObjectProjection Cmdlet Get-SCSMRelationshipClass Cmdlet Get-SCSMRule Cmdlet Get-SCSMResource Cmdlet Get-SCSMObject Cmdlet Get-SCSMClass Cmdlet Get-SCSMChildEnumeration Cmdlet Get-SCSMConfigItem Cmdlet Get-SCSMIncident Cmdlet Get-SCSMEnumeration |
Grab the release over at codeplex!
http://smlets.codeplex.com
Custom console tasks: Part 2
Posted by: | CommentsIn the first part of the “Custom console tasks” series i described a very simple but powerful way to use the “Tasks” functionality in the Service Manager console to reboot an affected computer of an incident. This time I’m going to show you how we can use PowerShell scripting and some custom Cmdlets I’ve published on Codeplex to create a task that can re-activate (open) a closed incident, something that isn’t possible to do in the console out-of-the-box. Before we go on, please note that according to most process frameworks you shouldn’t re-open a closed incident.
- The first thing you need is the custom Service Manager Cmdlets i published on Codeplex (download here). You can follow the instructions here to install the Cmdlets. Using these cmdlets you’re able to update some incident properties, most importantly for this scenario the “Status” property.
- Secondly you need a powershell script that uses the Cmdlets to do all the magic. I’ve written a script that forces the status of an incident to “Active” (no matter previous Status). Since this is kind of hardcore, and should be considered as an override, I wanted to prompt the user for a “reason”. The script accomplishes this by running some C# code that renders a dialog where the user can provide a reason for running the task on the incident. If the user click the “Cancel” button I abort the action and leave the status “as is”. If the user click the “OK” button I go ahead and change status to “Active” (the reason is logged in the action log).
- Place the script in a local folder, I use “C:\PowerShell Scripts”
- Create a new task in the Service Manager console: Administration – Library – Tasks
- Name: Force Activate
- Description: Used to force status of incident to active, can be used on closed incidents!
- Target Class: Incident
- Category: Incident Management Folder Tasks
- Command Line: powershell.exe
- Parameters: &’.\ForceActivate.ps1′ $Context/Property[Type='WorkItem!System.WorkItem']/Id$
- Working Directory: C:\PowerShell Scripts\
- Log in action log when this task is run: True
- Show output when this task is run: True
param($ID) Add-PSSnapin smcomlets -ErrorAction SilentlyContinue [void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing") [void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") $objForm = New-Object System.Windows.Forms.Form $objForm.Text = "Force Incident Status" $objForm.Size = New-Object System.Drawing.Size(400,200) $objForm.StartPosition = "CenterScreen" $objForm.KeyPreview = $True $objForm.Add_KeyDown({if ($_.KeyCode -eq "Enter") {$x=$objTextBox.Text;$objForm.Close()}}) $objForm.Add_KeyDown({if ($_.KeyCode -eq "Escape") {$objForm.Close()}}) $OKButton = New-Object System.Windows.Forms.Button $OKButton.Location = New-Object System.Drawing.Size(125,120) $OKButton.Size = New-Object System.Drawing.Size(75,23) $OKButton.Text = "OK" $OKButton.Add_Click({$x=$objTextBox.Text;$objForm.Close();$result="OK"}) $objForm.Controls.Add($OKButton) $CancelButton = New-Object System.Windows.Forms.Button $CancelButton.Location = New-Object System.Drawing.Size(200,120) $CancelButton.Size = New-Object System.Drawing.Size(75,23) $CancelButton.Text = "Cancel" $CancelButton.Add_Click({$objForm.Close()}) $objForm.Controls.Add($CancelButton) $objLabel = New-Object System.Windows.Forms.Label $objLabel.Location = New-Object System.Drawing.Size(10,20) $objLabel.Size = New-Object System.Drawing.Size(360,20) $objLabel.Text = "Please enter a reason for forcing the incident status to Active:" $objForm.Controls.Add($objLabel) $objTextBox = New-Object System.Windows.Forms.TextBox $objTextBox.Location = New-Object System.Drawing.Size(10,40) $objTextBox.Size = New-Object System.Drawing.Size(360,60) $objTextBox.Multiline = "True" $objForm.Controls.Add($objTextBox) $objForm.Topmost = $True $objForm.Add_Shown({$objForm.Activate()}) [void] $objForm.ShowDialog() if($result -eq "OK") { Set-SCSMIncident -ID $ID -Status Active Write-Host "Incident status forced to Active" if($x -gt 0) { Write-Host "Reason for action: $x" } else { Write-Host "No reason provided" } } else { Write-Host "Force to active status aborted" } |
You’re done! You’re now able to break all the rules and open closed incidents…
This was an example of how powerful tasks can be built using PowerShell and the Service Manager SDK (used by the Cmdlets) to customize the console functionality in Service Manager. I plan to write a final part of this series where we go all the way and use managed code only to create a custom task including a custom WPF form.
SCSM PowerShell Cmdlets v0.1
Posted by: | CommentsInspired by Travis Wright over at the product team’s Service Manager blog, I’ve started a new Codeplex project that will develop a PowerShell snap-in containing useful Service Manager cmdlets. Today I’ve released the first preview version which will give you an idea of what’s to come!
Included is a set of cmdlets which gives you the power to create, update and search for Incidents in Service Manager 2010.
Go to http://smlets.codeplex.com/ and grab the download to start testing this out!
Included cmdlets are:
- Get-SCSMIncident
Ex. get all incidents that includes the word “network” in the title (wildcard by %) and has the status “Active” - Set-SCSMIncident
Ex. update an incident’s description and attach a new file. - New-SCSMIncident
Ex. register a new incident with title, description, impact, urgency, classification and source.
Using these we can now do stuff like closing all incidents which title starts with “Network”, has the status Resolved and hasn’t been touched for a given period of time
Get-SCSMIncident –Title “Network%” –Status Resolved –InactiveFor 5.00:00:00 | Set-SCSMIncident –Status Closed –Comment “Closed due to inactive period”
Don’t miss the solution built using these cmdlets by Anders Bengtsson over at contoso.se, where he solves the intensively discussed problem regarding “update incident by mail”.
Active Directory connector behavior
Posted by: | CommentsThis week my friend Anders Bengtsson and I delivered a Service Manager event together with Microsoft in Sweden. There were a lot of good questions from the audience and a great interest in the product. One of the questions was if the Active Directory synchronize blank attributes from Active Directory if there is a value in the CMDB. Of course we have tried this in a sandbox
1. I created a new user account in Active Directory. I did not change any default values so the Office attribute (PhysicalDeliveryOfficeName) was set to “Not Set”
2. I ran the Active Directory connector synchronization
3. I verified that I had a blank Office attribute in the CMDB
4. I updated the attribute in the CMDB
5. I logged in and out with the account on a workstation
6. I ran the Active Directory connector synchronization
7. The Office attribute in the CMDB is back to blank
If my AD user object is updated, in this case some attributes was updated when the user loged into a workstation, the watermark on the user object is updated, then the whole user will be synchronized back to the CMDB.
Remember this! What you see is not always what you think in Service Manager.
You might think that looking at a computer in the computer form is in fact looking at a single object in the CMDB. This is seldom the truth since most forms in Service Manager targets TypeProjections (which could be seen as a view displaying data from several objects related to each other). As an example you might take a look at the type projection acting as source to the “computer form” in Service Manager. As you can see in the definition below, quite a few different objects support the computer form.
Microsoft.Windows.Computer.ProjectionType :
<TypeProjection Accessibility=”Public”>
<Component
Path=”$Context/Path[Relationship='ConfigurationManager!Microsoft.SystemCente
r.ConfigurationManager.DeployedComputerRunsWindowsComputer'
SeedRole='Target']$” Alias=”PhysicalComputer” /><Component
Path=”$Context/Path[Relationship='Windows!Microsoft.Windows.ComputerHostsOpe
ratingSystem']$” Alias=”OperatingSystem” /><Component
Path=”$Context/Path[Relationship='Windows!Microsoft.Windows.ComputerHostsLog
icalDevice'
TypeConstraint='Peripherals!Microsoft.Windows.Peripheral.NetworkAdapter']$”
Alias=”NetworkAdapter” /><Component
Path=”$Context/Path[Relationship='Windows!Microsoft.Windows.ComputerHostsLog
icalDevice'
TypeConstraint='Peripherals!Microsoft.Windows.Peripheral.Processor']$”
Alias=”Processor” /><Component
Path=”$Context/Path[Relationship='Windows!Microsoft.Windows.ComputerHostsLog
icalDevice'
TypeConstraint='Peripherals!Microsoft.Windows.Peripheral.PhysicalDisk']$”
Alias=”PhysicalDisk” /><Component
Path=”$Context/Path[Relationship='Windows!Microsoft.Windows.ComputerHostsLog
icalDevice'
TypeConstraint='Peripherals!Microsoft.Windows.Peripheral.LogicalDisk']$”
Alias=”LogicalDisk” /><Component
Path=”$Context/Path[Relationship='System!System.ComputerPrimaryUser']$”
Alias=”PrimaryUser” /><Component
Path=”$Context/Path[Relationship='System!System.ConfigItemOwnedByUser']$”
Alias=”Custodian” /><Component
Path=”$Context/Path[Relationship='WorkItem!System.WorkItemRelatesToConfigIte
m' SeedRole='Target']$” Alias=”ImpactedWorkItem” /><Component
Path=”$Context/Path[Relationship='WorkItem!System.WorkItemAboutConfigItem'
SeedRole='Target']$” Alias=”RelatedWorkItem” /><Component
Path=”$Context/Path[Relationship='SupportingItem!System.ConfigItemHasFileAtt
achment']$” Alias=”FileAttachment” /><Component
Path=”$Context/Path[Relationship='System!System.ConfigItemRelatesToConfigIte
m']$” Alias=”RelatedConfigItem” /><Component
Path=”$Context/Path[Relationship='System!System.ConfigItemRelatesToConfigIte
m' SeedRole='Target']$” Alias=”RelatedConfigItemSource” /><Component
Path=”$Context/Path[Relationship='CoreKnowledge!System.EntityLinksToKnowledg
eDocument']$” Alias=”RelatedKnowledgeArticles” /></TypeProjection>
A short summary of this is ”last-write wins” and that you should be very aware that a form can be a mix of the result of a number of connectors and synchronized data.
Custom console tasks: Part 1
Posted by: | CommentsIn Service Manager 2010 there is a concept of console tasks. Using tasks you’re able to quickly perform actions while working in the console. An example of this could be launching remote desktop against a computer affected by an incident by just pressing a link within the incident form.
Console tasks are a great feature of Service Manager, but what’s even greater is that you can create your own. There are two different ways to add console tasks, in the console “Library – Tasks” or by defining console tasks in a management pack and importing this. The difference between these two entry points is that you can add much more advanced tasks in the latter one. In this first post of two I’m going to show you how to add a task directly in the console. To show you how to do this – here is how to add a task for rebooting the affected computer of an incident.
- Go to Library – Tasks – New Task
- Name the task “Reboot affected computer”
- Choose the target class Incident
(This associates the task with the incident form and enables us to use properties and related objects properties of the selected incident as arguments for the task command line) - Choose the Incident management Folder Tasks category
(This controls where the task will be available in the console) - Full path to command: shutdown.exe
- On the Parameters section, click insert property and choose: Incident – About Config Item
(“About Config Items” is called “Affected Items” in the form) - Select the property called “NetBIOS Computer Name”
(Locate it faster by using the search functionality) - Working directory: “%windir%\system32”
- Check: Log in action log when this task is run
- Check: Show output when this task is run
Note: You cannot use the option to “log in action log when this task is run”, without using the “show output when this task is run”. Doing so will cause the action to not get registered in the action log. This is a reported bug (not confirmed)!
Now you’ve created a task that can be used from the Incident Management part of the console to reboot an affected computer of an incident.
Some important things to remember here:
- If the list of “Affected Items” (About Config Item) only contains one computer the task will be executed without prompting the user. In this case this would mean that, clicking the reboot task would instantly reboot the affected computer without asking questions like “Are you sure….?”. In the case of the list containing more than one computer, the user will get prompted to select which of the listed computer to reboot.
- The file specified in the command, in this case shutdown.exe, needs to be available on each machine where the console will be used to launch the task (in this specific case this shouldn’t be a problem since shutdown.exe is distributed with the OS).
- When executing a console task, the task will be executed in the context of the logged on user. You can still use roles in Service Manager to show/hide console tasks from different users, but remember that seeing a console task doesn’t automatically give a user the permission to execute the task successfully.
Related information: http://blogs.technet.com/servicemanager/archive/2010/02/11/tasks-part-1-tasks-overview.aspx
In the next part of “Custom console tasks” series I’ll show how to add more advanced console tasks using the SDK (some coding coming up!) and a custom management pack.
Incident SLA Management in Service Manager
Posted by: | CommentsA couple of days ago there was a blog post published on the official Service Manager blog that solves a really annoying problem. The problem was that it wasn’t possible to, out-of-the-box, run incident workflows based on SLA breaches in Service Manager. Using the blogged solution you are now able to do exactly that! This means that you are now able to do notification and apply templates on incidents about to or breaching their SLA. By applying templates you could for instance escalate an incident about to breach its SLA. Isn’t that sweet?!
The posted solution is a joint project that Travis Wright and I have been working on for a couple of weeks. I hope you like it!
http://blogs.technet.com/servicemanager/archive/2010/05/06/incident-sla-management-in-service-manager.aspx
Using localized resources from Service Manager in custom applications
Posted by: | CommentsWhen developing extensions to Service Manager you want to be able to use the localization support of Service Manager. The strategy chosen by the product team of Service Manager is to store localized content primarily in management packs. When you’re creating new management packs you define the ”strings” that should be displayed in the Service Manager console depending on which language the console is currently running under. You do this in the LanguagePacks section of your management packs as shown in the picture below.

As you see in the picture you can define different language packs. Within these you add references to elements of your management packs. For instance you can specify what should be the displayed name of a list item defined in the management pack. You could specify different names for English, Swedish and all other languages that could be used by your Service Manager interacting users.
To be able to use these localized values in custom forms within the Service Manager console you do this by using data binding as explained in this post by Travis Wright. Now if you’re creating an application outside the console that needs to display data from Service Manager (using the SDK) you want to be able to reuse the localization made in Service Manager. Let’s say that you want to display, as it was in my case, a localized list. To retrieve the localized values from Service Manager you use an object called ManagementPackDisplayString. You simply retrieve a ManagementPackDisplayString from the element you want to get a localized value from using a specified CultureInfo. In the picture below I’m retrieving the localized name of a list.

As you see you’re also able to get a localized description of the object. The “CurrentCulture†as seen in the picture is the culture your application is currently running under. For more information regarding CultureInfo start here.
Important, you need to make sure that there is a localization of an element in the specified language before you try to retrive it. If you try to retrive a localized value in a culture that doesn’t exist as a LanguagePack the “GetDisplayString” method will throw an exception.
Asset Management MP for Service Manager 2010
Posted by: | CommentsIn a collaborative project we, Patrik Sundqvist and Anders Bengtsson have created an embryo of an Asset Management extension for Service Manager. Our thoughts behind this management pack are to build a version one that we could extend in the future. It is not a feature complete asset management solution for enterprise organizations, but it is a foundation that could give you some ideas what you could do with Service Manager 2010.
Download management pack here and the management pack guide here.

