SCSM 2012: Asset Management

This blog will be the first part of a series about my Asset Management solution for SCSM 2012 R2. It will give a general overview about the solution. The following parts will go into the details.

Part 2: Authoring – Classes and Relationships
Part 3: Authoring – Folders and Views
Part 4: Authoring – Forms
Part 5: Reports
Part 6: Runbook/Automation details

I was asked by a colleague end of last year, if we can manage hardware assets with System Center Service Manager 2012 R2. I found a solution from Steve Beaumont for SCSM 2010 besides the solutions with costs from Cireson or Provance for example. I contacted Steve and after discussing the options I started to create a new solution for SCSM 2012 R2 based on Steves template. The new solution is designed to meet the requirements of the requesting company but can also be adopted to other companies needs.

The solution covers the following requirements:

• Sync with Active Directory (User), SCCM (PCs)
• Assets should stay in the DB
• Custodian should be linked to Asset
• Read PC warranty information from Dell
• Fill location information automatically
• Additional categories for Computer Assets: Kiosk, Lab, Test
• Create Assets automatically based on existing Windows Computer objects in SCSM (sync with SCCM)
• Email notifications for new/deleted/updated objects

Prerequisites:

• The Windows Computer names need to follow this structure: ❤ letter site Code><Serialnumber>.
• Enable AD and SCCM connectors in SCSM.
• Install Service Management console and SMlets on the Orchestrator Runbook Server.

How is this implemented?

To achieve that the asset stays in the DB, the solution creates an Asset class based on the ComputerHardware class. When a new Asset gets created then it needs to be assigned to the Windows Computer object. The Orchestrator automation runbooks are handling that. So it can happen that multiple Windows Computer objects which are created in SCSM get linked to one Asset object. With that you can see the history of the Asset deployment.

The Custodian also needs to be linked to the Asset, because the Asset is the hardware that should have a defined owner, which does not change when the system gets reimaged. The automation will take the primary user of the deployed Windows Computer as first Custodian, but this needs to be manually reviewed, because this could not be the real owner of the hardware (shared machines, etc.).

Classes and Relationships:

An Asset Management workspace is created and views for the new classes and some additional useful views.

This form shows which information can be entered for the ComputerAsset. The other asset forms look nearly the same (only the Category field is missing).

The Custodian can be selected in the AssetCustodian field. All other drop down fields reference predefined liss. The Windows Computer can be assigned in the Related Items tab. Also the Order can be referenced there.

The order form is very short and simple.

Some runbooks are created in Orchestrator to automate the creation of the ComputerAsset objects in SCSM and keep them updated, . Here is a short overview:

All three main runbooks (Create Asset, Update Asset, Check deleted Windows Computer) check the Windows Computer objects first, then the Computer (Deployed) objects (synced from SCCM) and at last checks if an Asset object exists.

Additionally to that sub workflows are called to check the location, get the warranty, etc.

General considerations

• Not everything can be automated, so every created/updated/deleted asset needs to be reviewed. Emails are send out to inform responsible teams to review.
• The solution is an example how hardware asset management can be done with SCSM. It can be extended with additional class types, other properties, different automation, etc.

The solution can be downloaded from Github and you can watch a video on YouTube, which shows the solution in the SCSM console and the Orchestrator runbooks. I already presented about this solution at a German conference. So if you want to watch a German video, then you find it here.

In the other parts of my series I will go into more details how the solution is designed. So stay tuned ;-).

 

 

 

SCOM 2012: Monitor MSAs with the HP Storageworks MP 4.2.1

If you ever implemented the HP Storageworks Management Pack for System Center Operations Manager 2012 then you will find that it needs some improvements. Beside the missing monitor alerts and the view properties there is one other topic: it would require a better documentation about the prerequisites on the monitored systems.

I have recently implemented the HP Storageworks MSA Management Pack which is one part of this Storageworks solution and followed Chiyo’s blog to do the initial configuration. But I had problems to connect some MSAs to the Management Server (Error: “Unable to connect to the remote system” in the HP Storage Management Pack User Configuration Tool) and there was nothing in the Management Pack documentation about how to fix it.

Here is what I found out, what was missing:

• The Firmware had to  be updated (Firmware TS240* or later is required for SMI-S)
• SMI-S unencrypted had to be enabled (new setting in the newer Firmware)
• The monitoring user (which you enter in the HP Storage Management Pack User Configuration Tool) needs SMI-S access permissions.

With that the error went away and SCOM started to monitor.

I hope this helps you too.

 

SCOM 2012: Updated SCUtils APC PDU MP V1.1

I already wrote about the SCUtils APC PDU Management Pack for SCOM 2012 in this post. That was about the version 1.0 which had problems with monitoring the PDUs from a Gateway Server.

SCUtils has now released the new Version 1.1, which enables the monitoring from Gateway Servers. I have tested it and it works. So download the latest version and implement it.

Here is what you need to do to get this working (directly taken out of the SCUtils APC PDU MP documentation):

1. Install the Operations Manager console on each gateway server that is a member of a resource pool for monitoring APC PDUs.

2. If the gateway server and management server are separated by a firewall, you have to adjust the firewall to open the following ports in both directions between the gateway server and its management server:

1. TCP 5723
2. TCP 5724

3. Prepare an account that is a member of Operations Manager Read-Only Operators group.

4. Copy SetAccountToRegistry.exe from the installation folder (the default path is ‘C:\Program Files\SCUtils\ SCUtils Management Pack for APC PDU’) to each gateway server that is a member of a resource pool for monitoring APC PDUs.

5. Run SetAccountToRegistry.exe using a local administrator account. Fill in all the required fields. And click on Test button.

6. If the connectivity test has succeeded, click on Save button (the password will be encrypted before saving). Otherwise, reenter the information and try to test again.

7. Repeat the procedure on each gateway server that is a member of a resource pool for monitoring APC PDUs.

 

 

Getting Dell Warranty information

If your company has Dell computers, then it could be necessary that you get the warranty information into your Asset Management System, for example: System Center Service Manager or even System Center Configuration Manager.

There was a solution in the past to get this information directly through a REST api from a dell webpage, but that services was disposed in May 2016. Perhaps you already used one of these Solutions:

• TechNet Gallery (Dell Service Tag Script)
• SystemCenter Ninja (Opalis/SCSM solution to grab Dell Warranty info)

Dell now offers a new way to get this information through the Dell Warranty Status API.
Ok, that provides more security, but…

The problem with this is, that every company needs to request access and go through an approval process:

• Request access and provide information about your environment and the tool which should grab the data incl. throughput estimates
• Then you get a key and the access to the sandbox system, where you test the connection. The key expires after 90 days.
• After giving feedback and some more reviews, you will get the approval to use the production webpage with the same key. Until that you are allowed to use the sandbox system.

More details can be found here.

You can request the access here.

I have created a PowerShell script which gets the ServiceLevelDescription and the EndDate for one Dell Computer. You can download the script here.

#===========================================================================================
# AUTHOR:         Natascia Heil
# Script Name:    GetDellWarrantyInfo.ps1
# DATE:           09/09/2016
# Version:        1.0
# COMMENT:        – Script to check Warranty information for a computer from the
#                 Dell Warranty Status API
# Example:        .\GetDellWarrantyInfo.ps1 -ServiceTag ‘1a2b3c’ -ApiKey “sdfj7122394057sdfiouwer” -Dev $true
#===========================================================================================

Param(

[Parameter(Mandatory=$true)]
[String]$ServiceTag,
[Parameter(Mandatory=$true)]
[String]$ApiKey,
[Parameter(Mandatory=$true)]
[Bool]$Dev
)

#Build URL
If ($Dev)
{
$URL1 = “https://sandbox.api.dell.com/support/assetinfo/v4/getassetwarranty/$ServiceTag&#8221;
}
else
{
$URL1 = “https://api.dell.com/support/assetinfo/v4/getassetwarranty/$ServiceTag&#8221;
}
$URL2 = “?apikey=$Apikey”
$URL = $URL1 + $URL2

# Get Data
$Request = Invoke-RestMethod -URI $URL -Method GET -contenttype ‘Application/xml’

# Extract Warranty Info
$Warranty=$Request.AssetWarrantyDTO.AssetWarrantyResponse.AssetWarrantyResponse.AssetEntitlementData.AssetEntitlement|where ServiceLevelDescription -NE ‘Dell Digitial Delivery’

# Read first entry if available
If ($Warranty -is [Object])
{
$SLA=$Warranty[0].ServiceLevelDescription
$EndDate=$Warranty[0].EndDate
}
else
{
$SLA=’Expired’
}

Here are two examples what information you can get through the API:

You can use this script in an Orchstrator Runbook or Azure Automation to feed data into i.e. SCSM.

Orchestrator Runbook example:

In the Initialize Data create a Parameter for the ServiceTag (Serialnumber of the machine).

In the Run .Net activity paste the PowerShell script, then you do not need the param part, you can directly enter the variables ($ServiceTag, $Apikey, $Dev) with the corresponding values. Enter $SLA and $EndDate as Published Data and define that as returned data of the Runbook. With that you can call this runbook from all other main runbooks and get the warranty data for a Computer.