Service Management Automation and SharePoint - #MVP

Goal: End to End Service Delivery

Background

1.       Opalis 6.3 Automation engine with Custom .NET web front ends

2.       System Center Orchestrator 2012 with Service Manager Self Service Portal

3.       System Center Orchestrator 2012 with SharePoint

Swapping out the Engine

Image may be NSFW.
Clik here to view.

Benefits

1.       It allows authors automation in PowerShell (supports v4 with 64 bit!)

a.       For many this is huge as the amount of reference material / scripts for PowerShell is much larger than it was for Orchestrator

·   Ryan and team believe this means that there will be  less ‘re-inventing’ of the wheel that the team has to do

·   There is more PowerShell experience on other infrastructure teams inside of their company than there was Orchestrator experience

b.      The number of integration points for PowerShell is huge

·   The number of PowerShell Modules from Microsoft and other vendors is huge compared to the number of integration packs

·   PowerShell is much more adopted in the industry and is the standard for automating infrastructure. This level of adoption means that it makes sense financially for third parties to make PowerShell modules. This was not necessarily true for Orchestrator Integration Packs.

·   Just like Orchestrator if you can’t find a Module you can create one. In Ryan’s opinion creating PowerShell modules is far more documented and supportable than creating Integration Packs was (and Ryan has created his fair share of Integration Packs and Modules).

c.       If there isn’t a module for PowerShell you can fallback to .Net

·   PowerShell really is just another interface to the .Net runtime. This means that if it cannot be done with native modules you can drop down to .Net classes and get the work done. This is a large benefit if you have any developer available to your teams

2.       Check pointing becomes a reality

a.       You now have the ability to check point our automation. This means that you can instrument your automation to save state once it reaches a certain point

·   Allowing you to ‘stop’ running automation to do automation and then ‘resume’ it.

b.      Better resiliency – if for any reason a Runbook server crashes all automation can now re-start from the latest check point without having to completely re-run

c.       Hugely simplifies making automation that is ‘enterprise grade’ and can handle infrastructure related failures

3.       Everything that can be done through a UI can be done through code

a.       This is huge, the fact that there is no ‘hidden’ calls or undocumented COM classes, if it can be done through the WAP UI it can be directly coded

b.      Automated environmental tasks, like Change Control / Code Promotion can be automated! In fact some people from my team at Microsoft have already built us some examples of how this can be done (Thanks to Jim!).

c.       Automated tasks like nightly Runbook backups to TFS should be very easy to codify

·   Plus, because you now have PowerShell scripts that you are exporting, diffs between versions in TFS will actually be human readable!

4.       Better load balancing

a.       Gone is the ‘spill-over’ load balancing that we had with Orchestrator which often left lots of resources / Runbook Servers unused. Now when a Runbook Server is brought on-line it has a portion of the job cache given to it. This means that you should see load distributed across all Runbook Servers

b.      Note, this balancing is done when the Runbook Server is brought online and there is some coordination that needs to be done between all Runbook Servers for scale in / scale out operations. This also means that the balancing is done statically not in response to load on any one Runbook Server

c.       See http://technet.microsoft.com/en-us/library/dn530618(v=sc.20).aspx for more information

5.       Easier understanding for parallel and sequential processing

Draw Backs

1.       SMA is a v1.0 product

·         PowerShell workflow, the engine, has been around for a long time, and its underlying engine, Windows Workflow Foundation, has been around for even longer but never less SMA is v1

2.       SMA has only one roll, administrator. If you have access to SMA you have access to everything

3.       SMA has no ‘graphical’ design for Runbooks like we had in Orchestrator

Decision

Next Steps

Example:

The PowerShell Workflow Script (Not SMA integrated)

Workflow Monitor-Demo
{
    Param([PSCredential] $credential)
    Function Update-SharePointListItem
    {
        Param([String]$listURI, [String]$PropertyName, [String]$PropertyValue, [PSCredential]$credential)
        $updatePropertyName = $PropertyName
        $updateValue = $PropertyValue
        $body = "{" + [String]::Format("{0}: '{1}'", $updatePropertyName, $updateValue) + "}"
        Invoke-RestMethod -Method Merge -Uri $listURI -Body $body -ContentType "application/json" -Headers @{"If-Match"="*"} -Credential $credential
    }
# Get the credential to authenticate to the SharePoint List with
#$credential = (Get-Credential)

# Time between polling
    $delay = 5

# SharePoint Site
    $spSite = "http://portal.contoso.com/sites/selfservice"

# List Name
    $spList = "Demo"

#Filter -- in this example only process requests in the new state. this is a default on the SP list I created
    $spFilter = "Status eq 'new'"
#$spFilter = ""

#combined uri
    $uri
if($spFilter) { $uri = [System.String]::Format("{0}/_vti_bin/listdata.svc/{1}?`$filter={2}",$spSite, $spList, $spFilter) }
else { $uri = [System.String]::Format("{0}/_vti_bin/listdata.svc/{1}",$spSite, $spList) }

while($true)
    {
        $listItemURIs = inlinescript {
            $itemIDs = @()
            $listItems = Invoke-RestMethod -Uri $Using:uri -Credential $Using:credential
#$listItems = Invoke-RestMethod -Uri $uri -Credential $credential
foreach($li in $listItems)
            {
                $itemIDs += $li.id
            }
            $itemIDs
        }
if($listItemURIs)
        {
foreach -Parallel ($listItemURI in $listItemURIs)
            {
#get requested user name -- example of getting properties
# $listItem.Content.Properties is base .UserName gets the UserName Property
                $userName = inlinescript {
                    $listItem = Invoke-RestMethod -Uri $Using:listItemURI -Credential $Using:credential
                    $userName = $listItem.Entry.Content.Properties.UserName
                    $userName
                }

#Change the Status Property
                Update-SharePointListItem -listURI $listItemURI -PropertyName "Status" -PropertyValue "Executing" -credential $credential
                Checkpoint-Workflow

                start-sleep -seconds 10;
#Change the Name Property
                Update-SharePointListItem -listURI $listItemURI -PropertyName "UserName" -PropertyValue "$userName - New Name" -credential $credential

#Change the Status Property
                Update-SharePointListItem -listURI $listItemURI -PropertyName "Status" -PropertyValue "Completed" -credential $credential
                Checkpoint-Workflow
            }
        }    
        Start-Sleep -Seconds $delay
    }
}

Monitor-Demo -credential (Get-Credential)

Changing the Script to be SMA integrated

SMA allows them to store credentials in a secure, encrypted fashion (just like Orchestrator did). It also allows them to pull configuration items, like the name of the SharePoint list, out of a script and into an environmental variable. After doing those replacements the script looks like this (Highlighted changes)

Workflow Monitor-Demo

{

    Function Update-SharePointListItem

    {

        Param([String]$listURI, [String]$PropertyName, [String]$PropertyValue, [PSCredential]$credential)

        $updatePropertyName = $PropertyName

        $updateValue = $PropertyValue

        $body = "{" + [String]::Format("{0}: '{1}'", $updatePropertyName, $updateValue) + "}"

        $listURI

        $body

        Invoke-RestMethod -Method Merge -Uri $listURI -Body $body -ContentType "application/json" -Headers @{"If-Match"="*"} -Credential $credential

    }

# Get the credential to authenticate to the SharePoint List with

    $credential = Get-AutomationPSCredential -Name ‘CONTOSO\Automation Account'



    # SharePoint Site

    $spSite = Get-AutomationVariable -Name 'SharePoint Site Base'

    # List Name

    $spList = "Demo"



    #Filter -- in this example only process requests in the new state. this is a default on the SP list I created

    $spFilter = "Status eq 'new'"

    #$spFilter = ""



    #combined uri

    $uri

    if($spFilter) { $uri = [System.String]::Format("{0}/_vti_bin/listdata.svc/{1}?`$filter={2}",$spSite, $spList, $spFilter) }

    else { $uri = [System.String]::Format("{0}/_vti_bin/listdata.svc/{1}",$spSite, $spList) }



    while($true)

    {

        # Time between polling

        $delay =  Get-AutomationVariable -Name 'SharePoint Monitor Delay'



        $listItemURIs = inlinescript {

            $itemIDs = @()

            $listItems = Invoke-RestMethod -Uri $Using:uri -Credential $Using:credential

#$listItems = Invoke-RestMethod -Uri $uri -Credential $credential

foreach($li in $listItems)

            {

                $itemIDs += $li.id

            }

            $itemIDs

        }

if($listItemURIs)

        {

foreach -Parallel ($listItemURI in $listItemURIs)

            {

#get requested user name -- example of getting properties

# $listItem.Content.Properties is base .UserName gets the UserName Property

                $userName = inlinescript {

                    $listItem = Invoke-RestMethod -Uri $Using:listItemURI -Credential $Using:credential

                    $userName = $listItem.Entry.Content.Properties.UserName

                    $userName

                }



#Change the Status Property

                Update-SharePointListItem -listURI $listItemURI -PropertyName "Status" -PropertyValue "Executing" -credential $credential

                Checkpoint-Workflow



                start-sleep -seconds 10;

#Change the Name Property

                Update-SharePointListItem -listURI $listItemURI -PropertyName "UserName" -PropertyValue "$userName - New Name" -credential $credential



#Change the Status Property

                Update-SharePointListItem -listURI $listItemURI -PropertyName "Status" -PropertyValue "Completed" -credential $credential

                Checkpoint-Workflow

            }

        }    

        Start-Sleep -Seconds $delay

    }

} 

Image may be NSFW.
Clik here to view.