Tuesday, September 3, 2013

SCSM 2012: Self Service Portal Service category color customization

The is a great solution and worthy of a repost.

http://www.expiscornovus.com/2012/05/06/scsm2012-self-service-portal-service-category-color-customization/


SCSM 2012: Self Service Portal Service category color customization

Lately I’ve been wandering a bit more on the Technet Forums, this has been pretty useful. Friday I came across this thread from Bart Timmermans about customization in the Self Service Portal of the product System Center Service Manager 2012. He asked if it was possible to adjust the styling of Service category headers. Of course I accepted the challenge.
Analysis
The Self Service Portal is a solution on SharePoint 2010 which deploys some web parts. Like Travis Wright described in his latest Self Service Portal blogpost those web parts use Silverlight .xap files. After some .NET Reflector work on the Portal.BasicResources DLL. I found that a lot of the color styling for the portal is being done by using brushes.
Brushes
A brush is an Silverlight object which can be used to paint for example solid colors or linear gradient. In that DLL I found a .xaml file which defined some solidcolorbrushes and they had a key. In Silverlight they use a 8 digit notation for the color, this is a RGBA value.
Settings.xml
The Self Service Portal actually has a settings.xml file which can be used to define some basic settings. I noticed it also had some setting keys for colors. This triggered me to add a key for one of the brushes, ExpanderHeaderBgBrush. My attempt worked. After adjusting the Settings.xml and clearing my browsers cache I saw a new green color!
Service Category background color
Solution
1. Go to C:\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin (or another location if your installation directory was different
2. Open the Settings.xml file
3. Add a setting key for ExpanderHeaderBgBrush with your desired RGBA color:
ExpanderHeaderBgBrush setting key
Happy customizing!

Tuesday, July 23, 2013

Isolating Powershell Sessions in Workflows in Service Manager

Problem:
One common issue I have ran into with writing workflows for Service Manager is the powershell sessions seem to be shared. When I call a set of cmdlets, such as the Active Directory cmdlets, they do not always load/unload properly, causing issues with subsequent scripts.

Solution:
We can isolate the powershell sessions inside the Service Manager Workflows. While powershell experts may know this, most of us don't, so here is my non-expert explanation.

  • When you run Service Manager Workflows, they run in the same process. 
  • If these workflows are running powershell, the powershell sessions are sometimes (or always) shared. 
  • By "running powershell inside a powershell" we can isolate our scripts, preventing issues between shared sessions.
  • Once the script is complete, it cleans itself up, and completely closes the sessions.
The only issue I see with this method is that it might take the workflow a second or two longer to run because of having to open the new session - plan accordingly.

How we do it:
Take your completed script, and simply wrap the script in powershell.
For example, if my script is: 

Import-Module Activedirectory
Get-User

I simply wrap it like this:

Powershell {
Import-Module Activedirectory
Get-User
}

Another Example with Parameters:
Powershell {
param($Name, $pcc);
get-process $Name -ComputerName $pcc;} -args "explorer", "localhost"



Thanks goes out to Thomas Bianco for coming up with this simple workaround as a way to isolate Powershell Sessions.

Friday, May 3, 2013

Create and Assign Service Manager Incidents Directly from SCOM on Demand

The Issue

If you use Operations Manager and Service Manager, you know by now that SCOM will automatically create Incidents in Service Manager. However, for most organizations, this just doesn’t make sense because they do not have a 1-to-1 Alert-to-Action ratio. You can set up basic criteria to limit the automatic creation, but this usually still results in too many unnecessary incidents. As a result, most organizations do not utilize this connector, which at one point was one of the most requested features of SCOM – to do really cool things with ticketing systems.

The Solution

So, instead, I have created a solution that will allow you to create incidents on demand directly from a SCOM Alert, while utilizing all the cool features of the Service Manager SCOM Alert connector. All you have to do is right click the alert(s) to create the on-demand tickets.

What are some features of the solution in conjunction with the native Connector:

  • Right click one more multiple alerts and assign incidents directly to the specified group/user
  • Closing the alert closes the ticket and vice-versa
  • The Assigned User and the Ticket Id are maintained in the alert as sourced from SCSM
  • The affected component in SCOM is automatically added as a related configuration item in SCSM
  • Easily can be extended to do more fun stuff with only basic PowerShell Knowledge

How Does it Work

The solution utilizes the following components:

  1. SCOM and SCSM obviously
  2. A very small PowerShell Script
  3. SCOM CMDLETS

Workflow:

  1. A user right clicks the alert and sets the resolution State.
  2. A Command Subscription triggers based on the resolution state, sets a couple of custom fields, and changes the resolution state to “Generate Incident” a
  3. The SCSM Alert connector triggers based on the new resolution state, generates an incident, and applies an incident template based on data in the custom fields.

How to Implement the Solution

These Steps need to be performed in SCOM

Step One

Copy the following PowerShell script code and save on your SCOM management server as UpdateCustomFieldPowershell.ps1. (I took this code from another blog online and modified it as my own. Unfortunately, I don’t know who wrote the original script.)

Param($alertid) 

$alertid = $alertid.toString()

write-eventlog -logname "Operations Manager" -source "Health Service Script" -eventID 1234 -entrytype "Information" -message "Running UpdateCustomFieldPowershell"

Import-Module OperationsManager; "C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\Functions.ps1"; "C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\Startup.ps1"

$alert = Get-SCOMAlert -Criteria "Id = '$alertid'"

write-host $alert

If ($alert.CustomField2 -ne "AlertProcessed")

    {

$AlertResState = (get-SCOMAlertResolutionState -ResolutionStateCode ($Alert.ResolutionState)).Name

$AlertResState

   # $alert.CustomField1 = $alert.NetBIOSComputerName

     $alert.CustomField1 = $AlertResState

     $alert.CustomField2 = "AlertProcessed"

$alert.ResolutionState  = 254

    $alert.Update("")

    }

exit

Step Two

We need to create some new alert resolution states. The alert resolution states will trigger the script. You want to create a resolution state for each support group you would assign an alert. You can use whatever format you want. I used the format of “Assign to GROUPNAME”. Also keep in mind the Resolution State Ids and order you will use. I made my alphabetical. DO NOT use the resolution state 0,1,254, or 255.

To create new resolution states:

  • Go to the SCOM Console
  • Go to the Administration Workspace
  • Go to Settings
  • Select Alerts
  • Select the new button, create a resolution state and assign an Id. Resolution states will always be ordered by their Id
  • Repeat for each resolution state

After you create your alert resolution states, you will need to create one more that triggers the SCSM Connect. Name this Alert Resolution State “Generate Incident.” Also, make sure this is the exact name as the script requires. If you want to change the name, you will have to update the script. Also, set the Id to 254.

Step Three

We need to set up a command channel and subscription that will trigger and run the script.

  • Open the SCOM Console
  • Go the the Administration Workspace
  • Go to Channels
  • Create a new Command Channel
  • Enter the full path of the above script
  • Enter the command line parameters as shown in the example below (Be sure the use the double and single quotes correctly)
    • "C:\OpsMgrProductionScripts\SCOMUpdateCustomField.ps1" '$Data/Context/DataItem/AlertId$'
  • Enter the startup folder as C:\windows\system32\windowspowershell\v1.0\
  • Save the new Channel

Next, we need to set up the subscriber for the command channel.

  • Open the SCOM Console
  • Go the the Administration Workspace
  • Open subscribers
  • Create a new subscriber
  • In the addresses tab, click Add
  • In the subscriber address, set the channel type to command and then select the channel you set up in the previous steps.
  • Save the address and the subscriber

Next, we need to set up the Command Subscription

  • Open the SCOM Console
  • Go the the Administration Workspace
  • Open Subscriptions
  • Create a new Subscription
  • On the subscription criteria, check the checkbox “with a specific resolution state
  • Select all the new resolution states except “Generate Incident” (Do not select anything other than the assignment states)
  • On the subscribers, add the new subscriber you created in the previous steps
  • On the Channels, add the new channel you created in the previous steps
  • Save the subscription

Step Four

The last thing we have to do in SCOM is set up the Alert connector. The alert connector will be triggered based on the resolution status of “Generate Incident”.

  • Open the SCOM Console
  • Go the the Administration Workspace
  • Go to connectors and select Internal Connectors
  • Open the SCSM Alert Connector
  • Create a new subscription in the connector
  • In the criteria of the subscription

These Steps need to be performed in SCSM 

Step One

The first thing you want to do is enable and connect your SCSM SCOM Alert Connector. If you do not know how to do that, you can refer to technet. http://technet.microsoft.com/en-us/library/hh524325.aspx. Verify it works before moving any further.

Step Two

  • Create a new Management Pack dedicated to storing the SCOM Incident Templates in SCSM
  • Create a SCOM incident template for each group that you want to assign via SCOM. Typically, this is about 10-20 templates. For testing purposes, I would just start with one or two.
  • Add the correct group as the assigned to in each template. It is not necessary to fill any other information.

Step Three

  • In SCSM open the SCOM Alert Connector
  • Go to the alert routing rules and add a new rule
    • For each rule select one of the templates that you created
    • On the select criteria type, select the Custom Field radio button
    • For custom field one, enter the exact name of the resolution state you used in SCOM. For example, if you are going to assign to the server team, and the name of resolution state is called “Assign to ServerTeam”, this is the exact phrase you need to enter into Custom Field one.
  • Select Custom Field two from the drop down
  • For custom field two, enter “AlertProcessed”
  • Click OK
  • Repeat for each template

Time for Testing! 

Now you are ready to test. Find an alert in SCOM, right click the alert and set it to a resolution state for assignment. Give the subscription time to run and the SCSM connector time to run. Usually, if the connector is running every 2 minutes, it takes the total process about 5 minutes to complete. While the actual workflows are running in a second, it simply takes time for both of them to trigger.

 

Troubleshooting

If there are any issues with the configuration, the event logs will usually tell you about failures. If it is not working, but you don’t see any failures, your criteria probably do not match.

Conclusion

This is a great alternative solution to automatically creating tickets from SCOM. You can still automatically create tickets as well simply by adding subscriptions to the SCSM SCOM Alert connector. If you have any issues, question, leave a comment.

Tuesday, January 15, 2013

Notes Regarding SCSM 2012 Upgrade


I just wanted to share some notes regarding the Service Manager 2012 SP1 Upgrade, that might not be obvious unless you thoroughly read the documentation. I hope these notes help prevent some problems.

Release Notes:
http://technet.microsoft.com/en-us/library/jj614520.aspx

The SCSM Console New Requirement:
Upgrade Note2-core 2.0 GHz CPU
4 GB of RAM
10 GB of available disk spaces
new requirement of Microsoft SQL Server 2012 Analysis Management Objects (AMO). Microsoft SQL Server 2012 AMO is supported on SQL Server 2008 and SQL Server 2012


Self-Service Portal: Web Content Server with SharePoint Web Parts
8-Core 2.66 GHz CPU
8-core, 64-bit CPU for medium deployments
16 GB of RAM for 20,000 users, 32 GB of RAM for 50,000 users (See the Hardware Performance section in this guide.)
80 GB of available hard disk space


When you upgrade from System Center 2012 – Service Manager, you perform an in-place upgrade of the Self-Service Portal. - This is the only thing the documentation says. I am not sure what it means.

Authoring Tool Workflows
When you use the Service Manager SP1 version of the Authoring tool to create a workflow, then custom scripts using Windows PowerShell cmdlets called by the workflow fail. This is due to a problem in the Service Manager MonitoringHost.exe.config file.

To work around this problem, update the MonitoringHost.exe.config XML file using the following steps.



1.     Navigate to %ProgramFiles%\Microsoft System Center 2012\Service Manager\ or the location where you installed Service Manager.
2.     Edit the MonitoringHost.exe.config file and add the section in italic type from the example below in the corresponding section of your file. You must insert the section before <publisherPolicy apply="yes" />.
3.     Save your changes to the file.
4.     Restart the System Center Management service on the Service Manager management server.


<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="uri" type="System.Configuration.UriSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </configSections>
  <uri>
    <iriParsing enabled="true" />
  </uri>  
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Mom.Modules.DataTypes" publicKeyToken="31bf3856ad364e35" />
        <publisherPolicy apply="no" />
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EnterpriseManagement.HealthService.Modules.WorkflowFoundation" publicKeyToken="31bf3856ad364e35" />
        <publisherPolicy apply="no" />
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />
      </dependentAssembly>
  <dependentAssembly> 
         <assemblyIdentity name="Microsoft.EnterpriseManagement.Modules.PowerShell" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />
     </dependentAssembly> 
      <publisherPolicy apply="yes" />
      <probing privatePath="" />
    </assemblyBinding>
    <gcConcurrent enabled="true" />
  </runtime>
</configuration>

SCOM Agent Supported in SCSM 2012 SP1


System Center 2012 – Operations Manager
System Center 2012 – Operations Manager agents were not supported with System Center 2012 – Service Manager. However, the agent that is automatically installed by System Center 2012 – Service Manager SP1 is compatible with System Center 2012 – Operations Manager and System Center 2012 – Operations Manager SP1.  After Service Manager Setup completes, you must manually configure the agent to communicate with the Operations Manager management server.
To validate that the Operations Manager Agent was installed, open Control Panel and verify that the Operations Manager Agent is present. To manually configure the Operations Manager agent, see Configuring Agents.
You can upgrade Service Manager servers in the presence of an System Center 2012 – Operations Manager console.

Source: MS Documentation
http://www.microsoft.com/en-us/download/details.aspx?id=27850