Visual Studio Online + VSCode = Easy PowerShell Source Control

In my daily work at CTGlobal we are all working a lot with PowerShell and therefor we have a big need to share code between each other and also having some version control in place when we are making changes. So for the last few months I has been playing a lot around with Visual Studio Code and Git repositories in Visual Studio Online to solve this.


To create a new code repository in VSTS go to the project you want the repository to reside in and select the Code tab. Click the repository drop down and click New repository. A box appears, enter the name for the new repository and select Git type. You now have a new repository.


To clone the repository to your local computer and work with the code click Clone in the right corner and copy the URL.


Open Visual Studio Code, press F1 to open the command palette and write Git: Cloneclip_image003

You will then be asked to enter the URL you just copied, and then the parent path where the local copy if the repository will be placed.


The repository will then be cloned to your local computer and you can start to add files to it. When you have added some files or done any changes and you want to save it to the repository you have to commit it. You commit changes by going to the Source Control tab on the left in Visual Studio Code, review the changes and click Commit.


The changes are then committed to the local copy of the repository. To sync the changes back into Visual Studio Online press F1 to open the command palette again and write Git: Sync and press enter, the changes is now pushed back to master repository and your code is in control.

Happy source controlling!

Orchestrator PowerShell Template

I recently did a webinar together with Cireson on CMDB, automation and self-service using System Center Service Manager, System Center Orchestrator and the Cireson Portal. In the webinar I showed how i always use only the .NET Script Activity in all our runbooks, and the same PowerShell “Template” to invoke scripts. The reason for only using PowerShell scripts instead of the Orchestrator activities is that you will need to add a lot of activities, which can get quite messy, to achieve the same that you can do with a few lines of PowerShell. Secondly you will also quickly realize that the Orchestrator activities are pretty limited, and finally if you want at some point to move to Azure Automation or SMA then you can quickly just copy and reuse all your scripts.

The template below is made to invoke the scripts on a targeted computer, and collect any errors in the Invoke-Command. When running a script block in Invoke-Command it will not return anything back so that is why the Try, Catch, Finally is there. Also if you want to return some data from your script you can add it in the Finally block to the $return and then split it afterward, below you can see an example on returning output from Get-NetIPAddress.

#Credentials and computer name where you wish to execute your script.
$secpasswd = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force
$Creds = New-Object System.Management.Automation.PSCredential ("USERNAME", $secpasswd)

$Computer = "Server01.domain.local"

$return = Invoke-Command -ComputerName $Computer -credential $Creds  -ScriptBlock {
#Ensures that script will fail on error
$ErrorActionPreference = "Stop"

#CODE HERE, MUST NOT RETURN ANY OUTPUT, Note: Use "| Out-Null" if cmdlet returns output
#CODE HERE, MUST NOT RETURN ANY OUTPUT, Note: Use "| Out-Null" if cmdlet returns output
#CODE HERE, MUST NOT RETURN ANY OUTPUT, Note: Use "| Out-Null" if cmdlet returns output
$IPAddress = Get-NetIPAddress

#If all code succesfully executed then $status will be Success
$Status = "Success"

#On script failure $Status will be Failed and the error message sent to $ErrorMessage
$ErrorMessage = $_.Exception.Message
$Status = "Failed"

#Will always return $Status and $ErrorMessage
$return = @($Status, $ErrorMessage, $IPAddress)
#Get Return values
$Status = $Return.Get(0)
$ErrorMessage = $Return.Get(1)
$IPAddress = $Return.Get(2)

You then need to create a published data for each variable you want to return from the activity. I always put the $Status and $ErrorMessage as published data as minimum to keep some sort of consistency.


Then make a new Run .Net Script activity below with the code to throw the error message from your script in the runbook.


And make a link that will be triggered if $Status is not equal Success.


You could also add a invoke runbook after the Error activity if you have a runbook to add something to a error log of some sort, in my case i use the Analyst log in Service Manager.


Here is the webinar recording

MPTool, Automate and Simplify Management Pack Development

This is something I have been looking forward to for a long time! The first public release of the PowerShell module MPTool, it is a module for automating and simplify OpsMgr management pack development I have been working on for almost a year together with Martin Dyrlund Arnoldi

Back in the end of 2014 we started introducing automation and self-service into our company and spend the most of 2015 automating common tasks around our daily server provisioning and de-provisioning work. In the end of 2015 we looked into automation for SCOM as we couldn’t keep up with the work the way we did it at the current point. We needed a way to automate our management pack creation to be able to create them faster and more standardized, and so we came by the awesome PowerShell module OpsMgrExtended from Tao Yang. We started to play around with Tao’s module and quickly figured out that the concept of module was exactly what we needed, but also that we required the ability to create more advanced monitoring solutions, so we decided to build our own PowerShell module, and the result is this, MPTool.

MPTool is created with the goal that if you know PowerShell you should pretty easily be able to create management packs. It contains a lot of build-in logic in each function, it automatically adds management pack references if needed, for a PowerShell discovery you only need to create a PowerShell array with the discovery data and the function it self will create the SCOM specific code needed, and so on.

We have now with great success used it internally for more than 6 months and is now ready to share it with the community, I hope you will all find it as useful as us!

Over the next weeks I will post some more articles on how you can use this module in different examples

Please report if you hit any Bugs or troubles so we can improve where it is needed, also if you have any idea for future releases we will take it in and evaluate.

Detailed documentation is available at GitHub

Download Link

GitHub Repository

16 CmdLets is available now, and a few more is already in testing and will be added soon.