So lets go with the first query that gets Business Services together with some other properties and relationships out of the data warehouse.

SELECT DISTINCT
SERVICE.DisplayName as “Display Name”,
USERCIOWNED.DisplayName as “Service Owner”,
USERCISERVICEDBY.DisplayName as “Service Contacts”,
USERCIIMPACT.DisplayName as “Service Customers”,
CIRELATED.DisplayName as “Related CIs”

FROM ServiceDimvw as SERVICE

– map serviceentitydimkey to configitementitydimkey to get configitemdimkey
INNER JOIN ConfigItemDimvw CIDIM ON SERVICE.EntityDimKey = CIDIM.EntityDimKey

– config item owned by user –> Service Owner
LEFT JOIN ConfigItemOwnedByUserFactvw CIOWNEDBY ON CIOWNEDBY.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCIOWNED ON USERCIOWNED.UserDimKey=CIOWNEDBY.ConfigItemOwnedByUser_UserDimKey

– config item serviced by user –> Service Contact
LEFT JOIN ConfigItemServicedByUserFactvw CISERVICEDBY ON CISERVICEDBY.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCISERVICEDBY ON USERCISERVICEDBY.UserDimKey=CISERVICEDBY.ConfigItemServicedByUser_UserDimKey

– config item impacts user –> Service Customers
LEFT JOIN ConfigItemImpactsCustomersFactvw CICUSTOMERS ON CICUSTOMERS.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCIIMPACT ON USERCIIMPACT.UserDimKey=CICUSTOMERS.ConfigItemImpactsCustomers_UserDimKey

– config item related to config item –> Related Config Items
LEFT JOIN ConfigItemRelatesToConfigItemFactvw CICI on CICI.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN ConfigItemDimvw CIRELATED on CIRELATED.ConfigItemDimKey=CICI.ConfigItemRelatesToConfigItem_ConfigItemDimKey

WHERE SERVICE.displayname IS NOT NULL
ORDER by SERVICE.displayname

The result looks something like this.

The query returns all business services with some property values and relationships, but depending on the exact configuration of a business service, there can be multiple rows per business service because of normalization. If you have a business service that has 2 related items, the query will return two rows for that service, both rows holding one of the related items. When it comes to reporting this can be painful because there are no possibilities that allows you to group or concatenate all those information of a business service together and return it as one single line. So the query needs some modification. By using temporary tables to store query results, it is possible to concatenate the different values.

SELECT DISTINCT
SERVICE.DisplayName as “Display Name”,
USERCIOWNED.DisplayName as “Service Owner”,
USERCISERVICEDBY.DisplayName as “Service Contacts”,
USERCIIMPACT.DisplayName as “Service Customers”,
CIRELATED.DisplayName as “Related CIs”

INTO ##Table1
FROM ServiceDimvw as SERVICE

– map serviceentitydimkey to configitementitydimkey to get configitemdimkey
INNER JOIN ConfigItemDimvw CIDIM ON SERVICE.EntityDimKey = CIDIM.EntityDimKey

– config item owned by user –> Service Owner
LEFT JOIN ConfigItemOwnedByUserFactvw CIOWNEDBY ON CIOWNEDBY.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCIOWNED ON USERCIOWNED.UserDimKey=CIOWNEDBY.ConfigItemOwnedByUser_UserDimKey

– config item serviced by user –> Service Contact
LEFT JOIN ConfigItemServicedByUserFactvw CISERVICEDBY ON CISERVICEDBY.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCISERVICEDBY ON USERCISERVICEDBY.UserDimKey=CISERVICEDBY.ConfigItemServicedByUser_UserDimKey

– config item impacts user –> Service Customers
LEFT JOIN ConfigItemImpactsCustomersFactvw CICUSTOMERS ON CICUSTOMERS.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN UserDimvw USERCIIMPACT ON USERCIIMPACT.UserDimKey=CICUSTOMERS.ConfigItemImpactsCustomers_UserDimKey

– config item related to config item –> Related Config Items
LEFT JOIN ConfigItemRelatesToConfigItemFactvw CICI on CICI.ConfigItemDimKey=CIDIM.ConfigItemDimKey
LEFT JOIN ConfigItemDimvw CIRELATED on CIRELATED.ConfigItemDimKey=CICI.ConfigItemRelatesToConfigItem_ConfigItemDimKey

WHERE SERVICE.displayname IS NOT NULL
ORDER by SERVICE.displayname

SELECT DISTINCT t1.[Display Name], [Service Owner_], [Service Contacts_], [Service Customers_], [Related CIs_]
INTO ##Table2
FROM ##Table1 as t1

CROSS APPLY ( SELECT DISTINCT [Service Owner] + ‘, ‘
              FROM ##table1 t2
              WHERE t2.[Display Name] = t1.[Display Name]
              FOR XML PATH(”) )  T21 ( [Service Owner_] )

CROSS APPLY ( SELECT DISTINCT [Service Contacts] + ‘, ‘
              FROM ##table1 t3
              WHERE t3.[Display Name] = t1.[Display Name]
              FOR XML PATH(”) )  T31 ( [Service Contacts_] )

CROSS APPLY ( SELECT DISTINCT [Service Customers] + ‘, ‘
              FROM ##table1 t4
              WHERE t4.[Display Name] = t1.[Display Name]
              FOR XML PATH(”) )  T41 ( [Service Customers_] )

CROSS APPLY ( SELECT DISTINCT [Related CIs] + ‘, ‘
              FROM ##table1 t5
              WHERE t5.[Display Name] = t1.[Display Name]
              FOR XML PATH(”) )  T51 ( [Related CIs_] )

– clean commas
UPDATE ##table2
SET [Service Owner_] = LEFT([Service Owner_], LEN([Service Owner_])-1)
WHERE LEN([Service Owner_]) > 0

UPDATE ##table2
SET [Service Contacts_] = LEFT([Service Contacts_], LEN([Service Contacts_])-1)
WHERE LEN([Service Contacts_]) > 0

UPDATE ##table2
SET [Service Customers_] = LEFT([Service Customers_], LEN([Service Customers_])-1)
WHERE LEN([Service Customers_]) > 0

UPDATE ##table2
SET [Related CIs_] = LEFT([Related CIs_], LEN([Related CIs_])-1)
WHERE LEN([Related CIs_]) > 0

SELECT * FROM ##table2

DROP table ##table1
DROP table ##table2

Here’s the result if you fire this query.

This time, every business service only shows up once and all the values are concatenated. Now this query can be used to create your report, e.g. by using SQL Report Builder or something.

Cheers
Marcel

After talking to Catapult Systems we decided to bring this great event to Europe. We are now in the planning phase, talking to partners, speakers, sponsors etc. that are interested to partner with us and help making this event coming true. Visit the event web site where we will start publishing more information shortly!

http://www.systemcenteruniverse.ch

Cheers
Marcel

Cheers
Marcel

Cheers
Marcel

To make a Service Desk employees life easier we created an Intake Form that allows to register all relevant information before making choice about the correct ticket type. The information can be entered in some form and at the very end the employee can choose if it is an Incident or a Service Request. If needed, the requests can also be resolved/completed immediately (quick fix).

The Intake Form is started from the tasks pane.

Now some information needs to be filled out. At the end, the selection about the ticket type can be made.

When “OK” is hit, the selected request is created. If it is not resolved/completed automatically, the ticket is opened and more information can be added if needed.

Another thing that makes a Service Desk guys life easier …

Credits to Stefan Johner (http://scsmlab.com, @scsmlab), one of our Cloud Engineers who build the form and and logic behind. Also many thanks to Kurt van Hoecke (http://authoringfriday.com, @BunkCo) and Rob Ford (http://scsmnz.net, @Manxferdey) for the great input and the interesting discussions around this topic.

For a more complex example of an intake form check this link –> http://www.authoringfriday.com/2013/04/14/scsm-showcase-incident-request-intake-task/

Cheers
Marcel

The MVP program allows you to get in touch with lots of specialists, enthusiasts and geeks, some of them becoming good friends over time. I really enjoy to be part of this family and am looking forward for an other exciting year!

Cheers
Marcel

The HP ProLiant Management Pack for SCOM discovers physical ProLiant Servers and monitors them. By using the SCOM connector in SCSM you have all those Servers in the CMDB within minutes. But I often face customers that either do not have all ProLiant Server monitored by SCOM or are running older ProLiant Server for ESX (why ever …) that are not discovered. One thing you might think of is “Hey easy, I just create these ProLiant CIs manually in the Service Manager console”. Good thought, but impossible.

When ProLiant objects are synched from SCOM to SCSM, you can create views as needed to display those – easy as 1-2-3.

Once there, you will also get a “Create HP ProLiant Server” task. Hit it to create a new object … bummer! You will get an error message telling that this is not possible because the objects of the ProLiant class are somehow hosted and there’s no hosting object present.

Let’s investigate this a little bit. When looking out for relationships you will soon find a relationship called “Windows Computer Hosts HP ProLiant Server”. It seems that you first need a Windows Computer object that will later host the ProLiant object. Unfortunately this cannot be configured in the GUI. So we need some PowerShell magic, a script that will create a Windows Computer object and a hosted HP ProLiant Server object at the same time. Sounds easy? Not that easy, but here are the steps you need.

Keep in mind that you can use this procedure not only for HP ProLiant Server objects but for any kind of other objects where you run into the same thing.

Step 1 – Create a Type Projection for the creation process

Because we will have to create both objects at the same time, we need to create a Type Projection with the Windows Computer class as the seed class and the relation to the HP ProLiant Server object. This could look something like this.

<TypeProjection ID=”itnetx.HPProLiant.TypeProjection” Accessibility=”Public” Type=”WindowsLibrary!Microsoft.Windows.Computer”>

<Component Path=”$Target/Path[Relationship='HPProLiant!HewlettPackard.Servers.ProLiant.WindowsComputerHostsHPProLiantServer']$” Alias=”HasHPProLiantServer” />

</TypeProjection>

Make sure you have the needed references in the MP, then seal and import the MP.

Step 2 – Create the script

This is how the script could look like.

#Parameters

$name = “WinCompProLiantTest007.xxxxxxxxxx..local”

$manufacturer = “HP” #Manufacturer Name

$model = “ProLiant DL360 G8″

$notes = “Placeholder CI to Host manually created HP ProLiant CI”

import-module smlets

 

#Create Windows Computer CI and hosted ProLiant CI at the same time

$proj = @{__CLASS = “Microsoft.Windows.Computer”;

__OBJECT = @{“PrincipalName” = $name;

“Notes” = $notes;

}

HasHPProLiantServer = @{__CLASS = “HewlettPackard.Servers.ProLiant.HPProLiantServer”;

__OBJECT = @{“DisplayName” = $name;

“NetworkName” = $name;

“PrincipalName” = $name;

“Name” = $name;

“Path” = $name;

“Manufacturer” = $manufacturer;

“Model” = $model;

}

}

}

 

#Create by using the Type Projection from the MP in step 1

New-SCSMObjectProjection -Type itnetx.HPProLiant.TypeProjection -Projection $Proj

Step 3 – Check out the Result

First lets check the Windows Computer object.

OK, looks god so far. Now let’s go for the HP ProLiant server object. It’s there.

Open and check the details. Don’t let the screenshot below confuse you. This is from an environment with tons of extensions that is using custom forms. So your form may look different. But your form should hold the defined data from the script. Feel free to add values for all other attributes as needed.

Cool, with this procedure you can bring all HP ProLiant objects to the CMDB within minutes, even those that are not managed by SCOM. The same procedure also works for other object types/classes. Just change Type Projection Names, Attributes etc. and you are ready to go!

For some more details about the described procedure also check out this blog post from Travis.

Have fun!
Marcel

First add a new property to an existing class. In this example I use the Windows Computer Class and add a string property called “Computer ID”. The Default value is set to “Comp{0}” and used to automatically set a value. To make sure the value increments automatically, I set the auto increment option to true. The property cannot be set as a key property because this is already defined for this scenario.

Now I seal and import the Management Pack. The property is instantly available. All existing Windows Computer objects will have the default value set, but because the system does not know about the auto incrementing yet, it really just sets the value “Comp{0}” for all existing instances. This makes no sense. So first of all, I want to set a real value for these objects by using a simple script.

import-module smlets
[string]$prefix = “Comp”
[int]$number = “1″

$class = get-scsmclass microsoft.windows.computer$
$computers = get-scsmobject -class $class

foreach($computer in $computers)
{
$computerID = $prefix + $number
set-scsmobject -smobject $computer -property mycomputerid -value $computerid
write-host “Property for computer” $computer.displayname “updated to” $computerid -foregroundcolor yellow
$number++
}

By running this script, all instances now have some value set, e.g. “Comp131”.

Now we are running into a problem. When a new Windows Computer is created manually, the system will auto set a value and use an incrementing number that is already used by another object. The problem is that the script did indeed change the values, but because the objects were already existing objects, the system still thinks that it has to use the first number from the auto increment range.

So before we start creating new Windows Computer objects (either manually, CSV import or by using some connectors), we have to increase the auto increment number to another starting point – higher that the highest number we are already using. This can only be done by a direct database change – nasty, but there’s no other way to do it. Travis Wright, Service Manager guru and my well respected MVP Lead at Microsoft, has written a post long time ago for SCSM 2010, but the procedure is still the same for SCSM 2012. Please keep in mind that this is an absolutely unsupported approach! But when you are deep in Service Manager, you already know that you have to accept that fact – Exchange Connector, IDataItem etc., you know what I mean

http://blogs.technet.com/b/servicemanager/archive/2010/09/27/top-secret-trick-how-to-change-the-auto-incrementing-value-range.aspx

If you run this SQL query against the Service Manager database, you will get a list of all incrementing values from all classes and the next value that will be used.

select
MT.TypeName,
MT.ManagedTypeId,
MTP.ManagedTypePropertyName,
MTP.ManagedTypePropertyID,
AIAR.FirstAvailableValue

from ManagedType as MT, ManagedTypeProperty as MTP, AutoIncrementAvailableRange as AIAR

where MT.ManagedTypeId = AIAR.ManagedTypeId and MTP.ManagedTypePropertyId = AIAR.ManagedTypePropertyId

By using another SQL statement, the value can be updated to a value that fits your needs. Make sure you use the correct IDs from the first query.

update AutoIncrementAvailableRange
set FirstAvailableValue = 1000
where ManagedTypeId = ’4364F5B6-7A8E-549E-4B66-9BECF551B346′ and ManagedTypePropertyId = ’2CE46CF5-FD34-F16C-FC72-3E51EFF43675′

Now as the new value is set and a new Windows Computer is created, the auto incrementing value should be set correctly.

Easy as 1-2-3, that’s it. Have fun!

Cheers
Marcel

To make things easier I put together an excel spreadsheet that lists the most important (not all) relationships in Service Manager together with the following information:

• Relationship Display Name and Internal Name
• Source Class
• Destination Class
• Relationship Type
• Management Pack information where the Relationship lives

You can download the file from my SkyDrive. Maybe I will update the spreadsheet over time. If not, feel free to download and update it on your own

Cheers
Marcel

First, I created 2 Incidents by using the console.

Because 1 Incident (IR1793 – Outlook cannot connect to Exchange Server) is a direct result of Incident 2 (IR1795 – Exchange Server down), it can make sense to link them together. This is especially the case when more and more users start calling Service Desk because they cannot use Outlook anymore.

The procedure to get to the result is as follows:

1. Declare one Incident (IR 1795) as a Parent Incident
2. Add Child Incident (IR 1793) to the Parent Incident

This is how the runbook could look like.

Initialize Data

Here I configure the runbook parameters. In this example I use two parameters, one is the ID of the Incident that will become the parent, the other one is the ID that will become the child.

Get Object (Incident 1)

Now we have to get the Incident Object that will become the parent from the Service Manager database. Use class “Incident” and filter based in on the ID. Use published data from “Initialize Data”.

Get Object (Incident 2)

Same as previous, but this time we will get the Incident Object that will become the child.

Update Object (Incident 1)

The next activity will mark one Incident (IR1795) as the parent Incident. For this we must use Published Data and get the SC Object GUID of Incident 1. Then we update the property “is parent” to “true”.

Create Relationship

As a last step, we can link the Incidents together. In the “Create Relationship” activity we have to select the source and target class (in this case “Incident” for both) as well as the relationship type “Has Parent Work Item”. To make sure the correct objects are linked together we must again use published data (SC Object GUID) to define the source and target object. The source is the SC Object GUID of the Child Incident, the target the SC Object GUID of the parent Incident.

That’s it. Now I’m going to test the runbook in the runbook tester.

After a successful run, the Incidents should be linked as expected.

Now have fun building your own solution. Maybe one that can link multiple Incidents to the same Parent Incident at the same time?

Cheers
Marcel