Dynamic FSOC Calendar using SharePoint and Orchestrator (Updated)


Sorry for the slow posts.  This new job is no joke.

Here is a pretty easy one that will be invaluable to your company and provide insight to what is going on in IT.  This is a dynamic SharePoint change calendar that will show real time changes and what stage that change is in depending on the customizations you have made to the change process in SCSM.

When I say “depending” I am referring to how you utilize the change activities in your environment.  I use them extensively, from multiple review activities to manual implementation and testing activities all the way through Change Management review activities at the end of the process.  It can get quite complicated so I wont go into details for this post but one nice thing to have is to track the stage that the change is currently in.  i.e. Manager Review, CAB Review, Implementation and so on.  To give you an idea, the change process I created uses 11 runbooks throughout the whole process.  The runbooks also change a custom field I added to the extensions tab on the change ticket to track what stage the ticket is in and to assign the SharePoint list ID to each ticket.  The ID is important so we can modify the correct item in the SharePoint list as the Change moves throughout the process.  The Change stage isn’t critical to this process but very nice to have.  I will go over how to modify the change template in the Authoring tool to add these fields to the extension tab but I wont be covering details on the runbooks that modify the change stage for this article because if you where paying attention, my process uses extensive runbooks and that would be out of scope and better served up in another article.

So lets get started,

  1. Building the list in SharePoint

In SharePoint you will want to add a custom list.  You can call it something like FSOC List.

You will want to add the following columns at the minimum.

  • Title
  • Change ID
  • Implementation Start Date
  • Implementation End Date
  • Description
  • Category
  • Stage (Optional)
  • Change Link (Optional, will provide a direct link to the ticket if you are using a portal)

Once this list is complete, click the ribbon on the list and under list click Create View.  Click the Calendar View link. Name the view Normal Changes.  Your Time Interval will be the Implementation Start date and End Date.  Month View, Week View, and Day view can all be Title.  Under Filter select Show items only when the following is true and use Category is equal to Normal.  Leave everything else default and click OK.  Now do the same thing for Urgent and Emergency views.  Now we need to create the FSOC Calendar.  Add the Calendar app and name it FSOC Calendar.  In the Ribbon click the Calendar tab and click on the Calendars Overlay button.  On the next screen click New Calendar and name this Normal Changes.  Choose a color like green.  in the web URL section put in the URL for the Normal Change calendar view we built earlier.  You can get this link by clicking on the FSOC List and on the ribbon tab click list.  Under Current View drop-down and choose Normal Changes.  Copy this URL. Click the Resolve button and the List and List View boxes should populate.

(If you are using the out of the box forms then your categories will be Minor, Major, and Emergency.  I customized mine to coincide with our naming conventions for our changes)

Calendar Overlay.JPG

Now repeat this step for Urgent and Emergency Changes choosing a different color for each one and click OK on the Calendar Overlay Settings screen once complete.

Now you should have something like this in the left side bar:

Legend.JPG

 

 

 

 

 

Ok, now that we have that done lets move onto the next step.  First the prerequisites for this runbook,  you will need to download the System Center 2012 R2 – Orchestrator Component Add-ons and Extensions from Official Microsoft Download Center.  This comes with several handy IPs but the ones we are going to focus on is the System Center 2012 R2 Integration Pack for Microsoft SharePoint 2013 and the System Center 2012 Integration Pack for System Center 2012 R2 Service Manager.  This will give you the Get List Items, Create List Items, Update List Items and Delete List Items components for SharePoint and the Monitor Object component for SCSM.

Ok, man I hate writing, lets show you the runbook in its entirety and we will go over each component one by one.

Change Calendar RB.JPG

As you can see it’s pretty simple but man will this give you a bunch of kudos at work.

First we are using the Monitor Object component from the SC 2012 Service Manager activities that you just installed, I hope.

Monitor.JPG

As you can see in my screenshot the Class is Extension of Change Request.  Also notice the trigger for New and Updated is checked.  This is important so that the calendar stays updated throughout the change process.

We will head down the path that goes straight across first.  Inside that link I have a Exclude filter.

firstlink.JPG

This will exclude any changes that have been cancelled.  That will be for the link that travels down.

In the Get List Items under the Filters tab click the Add button and choose Change ID equals ID from Monitor for all Changes IP.

GetListItems2.JPGThis will only bring back that particular list item if it exists.  Now since we did that you can see two links come out from the Get List Items IP.  Each link contains a filter.  Here is the filter from the top link:

toplink.JPG

And the bottom link:

bottomlink.JPG

What this does is if it finds a matching Change ID then it knows it needs to take the update path, if it doesn’t find the Change ID then it knows it needs to take the create path.

So following the Create path I add in two Run .NET IPs and use Powershell to convert the UTC time from the change implementation start data and end date and convert that time to whatever timezone your SharePoint server resides on.  This is a very handy script to have in your arsenal since UTC time is only really useful for databases and gibberish to users.  Here is the script used to convert the times:

param(
[Parameter(Mandatory=$false)]
$time = ‘{Scheduled start date from “Monitor for All Changes”}‘,
[Parameter(Mandatory=$false)]
$fromTimeZone = ‘UTC’ ,
[Parameter(Mandatory=$false)]
$toTimeZone = ‘US Mountain Standard Time
)

function ConvertTime
{
param($time, $fromTimeZone, $toTimeZone)

$oFromTimeZone = [System.TimeZoneInfo]::FindSystemTimeZoneById($fromTimeZone)
$oToTimeZone = [System.TimeZoneInfo]::FindSystemTimeZoneById($toTimeZone)
$utc = [System.TimeZoneInfo]::ConvertTimeToUtc($time, $oFromTimeZone)
$newTime = [System.TimeZoneInfo]::ConvertTime($utc, $oToTimeZone)

return $newTime
}

function ConvertUTC
{
param($time, $fromTimeZone)

$oFromTimeZone = [System.TimeZoneInfo]::FindSystemTimeZoneById($fromTimeZone)
$utc = [System.TimeZoneInfo]::ConvertTimeToUtc($time, $oFromTimeZone)
return $utc
}

if ($toTimeZone)
{

[datetime]$time = $time
$toUTC = ConvertUTC -time $time -fromTimeZone $fromTimeZone
$toNewTimeZone = ConvertTime -time $time -fromTimeZone $fromTimeZone -toTimeZone $toTimeZone
##Write-Host (“Original Time ({0}): {1}” -f $fromTimeZone, $time)
##Write-Host (“UTC Time: {0}” -f $toUTC)
$ResultsStart = (“{1}” -f $toTimeZone, $toNewTimeZone)
}
else
{
if (!($time)) {
$fromTimeZone = (([System.TimeZoneInfo]::Local).Id).ToString()
$time = [DateTime]::SpecifyKind((Get-Date), [DateTimeKind]::Unspecified)
}
else { [datetime]$time = $time }
##Write-Host (“Original Time – {0}: {1}” -f $fromTimeZone, $time)
$toUTC = ConvertUTC -time $time -fromTimeZone $fromTimeZone
$times = @()
foreach ($timeZone in ([system.timezoneinfo]::GetSystemTimeZones()))
{
$times += (New-Object psobject -Property @{‘Name’ = $timeZone.DisplayName; ‘ID’ = $timeZone.id; ‘Time’ = (ConvertTime -time $time -fromTimeZone $fromTimeZone -toTimeZone $timeZone.id); ‘DST’ = $timeZone.SupportsDaylightSavingTime})
}
$times | Sort-Object Time | Format-Table -Property * -AutoSize
}

The blue line is the variable from the Monitor and the red line is hard coded to the timezone your SP server is in.  The blue line will change for the Convert End Time IP obviously.  Then we create the new list item that will populate the calendar.  The middle path does the same thing but instead of creating a list item it updates all of the fields, for instance if you change the start and end dates of the change it will move them on the calendar or if you are using the change stage extension it will tell the user looking at the calendar what stage its in i.e. CAB approval or Implementation.  To give you an idea of what the create and update list items IP looks like see below.  Yours will very depending on what info you want captured but the start date, end date and title are the most important since this is a calendar.  One thing you should do it concatenate the Change ID and the Title together into the Title field to make it easier on the users when viewing the calendar.  I’ve also added in a dynamic link to the portal so the user can access the change ticket directly from the calendar.

createlist.JPG

Now the very bottom path is if you cancel a change.  This will grab the Change ID from the monitor and look for that ID in the SP list and delete it removing it from the SP calendar.

And here is what your calendar will look like once it starts to get populated.

CompletedCalendar.JPG

And clicking on a calendar entry will show the user the details:

Details.JPG

As you can see I have a hyperlink directly to the change for convenience which will take the user to the portal and give them even more details:

portal.JPG

And there is your dynamic change calendar available to anyone in the business.  Now they can’t come back and yell at you when their system goes down for maintenance and they didn’t know about it because they didn’t show up to CAB 🙂

Man, maybe that wasn’t as easy as I thought.

Now, some cool things you can build on top of this is:   One thing we did which was really helpful was extend the change class to include a Boolean and added that to the top right corner of the main change template that said “Ready for Approval?” with a checkbox being checked by default since most will be ready to move through the process but we wanted our developers to put in changes that where coming in the pipeline but weren’t quite ready to go through the change process, but this helped us see changes coming in the future and verify that they would not conflict with blackout dates or other changes.  I added a Manual activity at the very beginning of the activities on the change ticket with the title of DO NOT COMPLETE MANUALLY so the change would just hang there, and created a runbook to look for that Boolean.  If it was not checked the change would not move through the process and the developers or whoever could keep going back to that change and make modifications but it would still appear on the Change Calendar as a Not Ready for Approval change and be visible to the business.  Once the user was ready to move forward they would just need to go into the change and check that box and the runbook would pick that up and close that Manual Activity automatically thus starting the change workflow.

I hope that helps someone out there.  I know it sounds harder then it really is but its not too bad and it will be invaluable to your business.  Happy automating!!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s