Azure or Azure Stack “Write Once, Deploy Anywhere” Update

A while back I wrote a blog post about being able to take one IaaS VM Azure Resource Manager (ARM) template and deploy it to both Azure or Azure Stack. This blog post included a JSON file and the PowerShell to do this. The idea for that came from needing to set up a cool and working demo for MMS 2016 and the need to showcase the power of Microsoft’s HybridCloud. Here is a link to that original blog post:

Write once, deploy anywhere (Azure or Azure Stack)

Today I have finished updating the PowerShell and ARM template/JSON file to be more streamlined and to work with TP2. Here is the link to download these:Here are the updates:

https://gallery.technet.microsoft.com/Create-VM-on-Azure-or-3c6d0420

Here are the updates:

  • The JSON and PowerShell script have been modified to work with Azure Stack TP2.
  • This script now utilizes the connection PowerShell module AzureStack.Connect.psm1 from Azure Stack tools.
  • This is included with the download of this script and JSON file on TechNet Gallery.
  • The script is hard coded to look locally to import the AzureStack.Connect.psm1 module.
  • Streamlined the JSON file and PowerShell script.
  • The script no longer prompts for the publicDNS name. It is now automatically set to the same as the vmname.
  • The script no longer prompts for the storage account name. It is automatically set to vmnamestorage.
  • The script no longer prompts for the resourcegroup name. This is now automatically set to vmname-RG.
  • By default this script now uses a JSON file hosted on Github. This is set in the $templateFilePath variable as shown on the next line.
  • To keep it to the local directory just use the JSON file name.

GITHUB: $templateFilePath = “https://raw.githubusercontent.com/Buchatech/Azure-AzureStackVM/master/AzureandAzureStack.json”
LOCAL: $templateFilePath = “AzureandAzureStack.json

This will be my last blog post of 2016. See you next year folks…..

Happy Stacking!

Read more

Resource Group Clean-up in Azure Stack

If you are like me, you end up creating a ton of resource groups in Azure Stack when testing things out. I needed a way to delete them without having to click one each one via the portal. The best option of course is to leverage PowerShell. I threw together some PowerShell to handle this. I came up with two options #1 can be used to delete a bunch of RG’s that have a common name. For example, I had a bunch of VM00* resource groups. I use the script to go loop through and delete all resource groups with VMO in the name. Option #2 pop’s up a GUI window so I could select the RG’s I wanted to delete. It put them in an array and then looped through to delete them in one shot.

This is great because I can kick this off and go do something else. I will share both below in this blog post along with some screenshots. I won’t have a download for the PowerShell syntax so just copy from this post if you want to use it. Be sure to use AzureStack.Connect.psm1 for connecting to your Azure Stack environment before running any of the following code.

Code:
#1

#Create Variable of RG’s with common name
$Resourcegroups = Get-AzureRmResourceGroup | where {$_.ResourceGroupName -like (‘*VM0*’)}

#Create array of RG’s
$RGLIST = $Resourcegroups.ResourceGroupName

#Loop to remove each resource group in the array
ForEach(
$rg in $RGLIST
)
{
Get-AzureRmResourceGroup -Name $rg -ErrorAction SilentlyContinue | Remove-AzureRmResourceGroup -Force -Verbose
}

This image shows the array of RG’s that will be looped through. I highlighted vm003rg in the array and in the PowerShell status message.

rgcleanup-1

The following screenshot shows VM003RG being deleted in the Azure Stack portal.

rgcleanup-2

#2

#Create Variable of RG’s from GUI selection
$selectedrgs = (Get-AzureRmResourceGroup | Out-GridView ` -Title “Select ResouceGroups you want to remove.”` -PassThru).ResourceGroupName

#Loop to remove each resource group in the array
ForEach(
$rg in $selectedrgs
)
{
Get-AzureRmResourceGroup -Name $rg -ErrorAction SilentlyContinue | Remove-AzureRmResourceGroup -Force -Verbose
}

After running the Create Variable of RG’s from GUI selection part of the code a window as shown in the following screenshot will pop up. Select the RG’s you want to remove, click Ok and they will be placed into an array.

rgcleanup-3

Below if the output of the array. Run the Loop to remove each resource group in the array part of the code and each of the RG’s will be removed.

rgcleanup-4

I have also used this when a resource group would not delete from the portal. On some stubborn resource groups I have had to run this a couple of times. This is a short post. I hope this helps someone out!

Read more

WordPress as front-end for Azure Automation

With Azure Automation there are cases where you will need to have a form that end users can go fill out to kick off an automation runbook. Back with System Center Orchestrator we could use Service Manager’s self-service portal as the front end for our automations. This was a solution that worked well. With Azure Automation we do not have that luxury at least not yet we don’t. There is a community based Azure automation webhook Service Manager (SCSM) connector in the works. One of my colleagues Rob Plank is a part of this project and says it should ready to release very soon. This connector will allow you to use the SCSM portal as the frontend of Azure Automation via webhooks, know when a webhook expires, and see a runbooks job status. Here are some teaser screenshots of the  connector.

image001

image002

There also are a few posts out there on how to leverage other platforms as the frontend for Azure Automation these are “how to use SharePoint as the frontend of Azure Automation” by Anders Bengtsson and “how to use an ASP website as the frontend to Azure Automation” by a friend of mine and fellow Microsoft MVP Florent Appointaire. Well in this post I am going to show you how to use the popular platform WordPress as the frontend for Azure Automation. The cool thing here is that this is another instance of showcasing the ability to utilize Microsoft and Open Source technologies together. 🙂

Here are the steps at a high level

  • Have an Azure Automation account on Azure
  • Setup your runbook/s in Azure Automation
  • Setup a webhook on your runbook/s in Azure Automation
  • Have a WordPress instance
  • Install Ninja Forms plugin in the WordPress instance
  • Install the Webhooks add on for Ninja Forms
  • Setup your runbook frontend form/s
  • Configure the runbook frontend form/s to connect to the Azure Automation webhook

Let’s get started!

Step 1: Have an Azure Automation account on Azure

To get started with Azure Automation go here: https://azure.microsoft.com/en-us/documentation/articles/automation-intro. I am not going to cover this within this blog post.

Step 2: Setup your runbook/s in Azure Automation

For this testing this scenario and this post I grabbed a couple of Azure Automation runbooks built by the Microsoft AzureAutomationTeam and made available in the Azure Automation Runbook Gallery. These runbooks start and stop Azure virtual machines.

Runbook #1 Name:

Start-AzureV2VMs

Description:

This runbook connects to Azure and starts all VMs in an Azure subscription or resource group.

Runbook #2 Name:

Stop-AzureV2VMs

Description:

This runbook connects to Azure and stops all VMs in an Azure subscription or resource group.

Both runbooks have two parameters they need. These are:

param (

[Parameter(Mandatory=$false)]

[String]  $AzureConnectionAssetName = “AzureRunAsConnection”,

[Parameter(Mandatory=$false)]

[String] $ResourceGroupName

We need to pay attention to these when setting up the webhooks and these often become your fields on your front end form.

Step 3: Setup a webhook on your runbook/s in Azure Automation

Here are the steps to setup a webhook for an Azure Automation Runbook.

First off make sure your runbook/s are in a published authoring status.

image003

Within https://portal.azure.com Navigate to

YOURAZUREAUTOMATIONACCOUNT

Runbooks

YOURRUNBOOK (Start-AzureV2VMs)

Webhooks

From here click on the Add Webhook button.

image004

The Add Webhook blade will fly out. Here you will want to click on Create new webhook to make the next blade flyout.

Here you need to give your webhook a name, set to enabled, set when it will expire and COPY THE URL TO A SAFE PLACE.

NOTE: You will not be able to access the webhook URL after this.

image005

Click OK.

Next you need to click on Configure parameters and run settings. This is where you set the parameters from the runbook.

If your parameters are required you have to set them here. If they are optional you can leave them blank here and pass the data into the runbook from the frontend form via a $WebhookData object.

In my case I put AzureRunAsConnection directly in the webhook. I created a credentials asset in Azure Automation with the account containing the needed permissions to perform the actions from the runbook in my Azure account (Start/Stop VM’s).

I left the resourcegroupname blank as I will pass this in from the front end form. I left the Run Settings to run on Azure as I do not have a Hybrid Worker setup.

NOTE: A Hybrid Worker lets you run automation runbooks on premises in your data center.

image006

One you have the Webhook and parameters configured click on the Create button to actually create the webhook.

image007

You will now see your new webhook in the webhooks blade.

image008

Note that if you click on a webhook you will not see the URL. You can enable or disable the webhook, see when it expires, and access the parameters. This is shown in the following screenshot.

image009

Step 4: Have a WordPress instance

You can host WordPress on WordPress.org on a hosting account, internally or even on Azure. Here is a link to a tutorial on how to run WordPress on Azure. https://azure.microsoft.com/en-us/documentation/articles/app-service-web-create-web-app-from-marketplace.  I am not going to cover how to setup a WordPress instance within this blog post.

Step 5: Install Ninja Forms plugin in the WordPress instance

Here are the steps to install Ninja Forms WordPress plugin.

From within the WordPress admin dashboard click on Plugins.

Click on Add New.

image010

Search for Ninja Forms. Click on the Install button to add the plugin. Make sure you activate the plugin.

image011

You also could manually download and upload the plugin or load it directly into the plugins directory. I have shown you the steps for the easiest way to install it.

The Ninja Forms plugin page can be found here:

https://wordpress.org/plugins/ninja-forms

Step 6: Install the Webhooks add on for Ninja Forms

The Webhooks for Ninja Forms add on can be found here:

https://ninjaforms.com/webhooks-for-ninja-forms

This add on has to be purchased. It is $39 by itself for 1 WordPress instance.

After you buy it you will get the files for download. Again from within the WordPress admin dashboard click on Plugins.

Click on Add New. This time click on the Upload Plugin button and browse to your downloaded Webhooks for Ninja Forms zip folder.

After it is uploaded be sure to activate it.

The final step is to install the license for the add on. To do this Click on Forms>Settings>Licenses and input the key that Ninja Forms sent in the Webhooks Key field. Click on Save & Activate.

image013

Step 7: Setup your runbook frontend form/s

Next we need to build the actual form. To do this follow the list of steps.

Click on Forms>Add New. Give your form a Title.

Add a Textbox and put in the label of ResourceGroupName.

I like to make it Required.

image014

Add a Submit button to your form. I labeled it Start.

image015

In the following screenshot is what the form looks like. Note that I have both forms loaded on the same page.

image016

Step 8: Configure the runbook frontend form/s to connect to the Azure Automation webhook

Now is the last step. This is the step in which we configure the form to send data to the Auzre Automation webhook upon submission. This is doing it via POST method.

When editing the form click on the Email & Actions tab. Click on the Add New button.

Give this Action a name.

In the Type dropdown select Webhook.

Enter the Azure Automation webhook URL in the Remote Url field.

Select Post for the Remote Method.

For Args select enter the name of and select the field from your form of the parameters you need to send to the Azure Automation runbook.

You can see this all represented in the following screenshot.

image017

One of the cool things about this solution is we can test the webhook action before actually submitting it to make sure it will work as expected. This testing can be turned on by checking the Run in Debug Mode field. I have highlighted this in the screenshot in green. Checking this box and submitting the form will show debugging information like data sent and response.

Here is an example of what the result in Debug mode will look like:

image018

Make sure you uncheck the Run in Debug Mode field when you are ready to actually start your runbook/s.

Now let’s see what this looks like in Azure Automation when we submit the form.

I have a resource group named 6716vm with one VM in it named 6716vm. So I will enter 6716vm on the form. 6716vm will be passed to the runbook as the resourcegroupname.

image019

You can see the job running in Azure now.

image020

Within the job if you click on Input you can see it has 2 inputs. One is Webhookdata. This is where the 6716vm is located. The other is the Azureconnectionassetname. Remember we hardcoded this into the webhook itself. We can also see in the following screenshot that the job completed.

image021

If we look further at the webhookdata we can see several interesting things. We can see exactly where it put the 6716vm parameter for the resourcegroupname and we can see that this request came from my blog at www.buchatech.com.

image022

{“WebhookName”:”WPhook1″,”RequestBody”:”ResourceGroupName=6716vm”,”RequestHeader”:{“Accept”:”*/*”,”Accept-Encoding”:”deflate; q=1.0″,”Host”:”s1events.azure-automation.net”,”User-Agent”:”WordPress/4.5.3; https://www.buchatech.com”,”x-ms-request-id”:”0ae47ca6-46a4-4ba7-902e-6d33840add75“}}

Pretty cool right? Check out the VM now running:

image023

Now to shut it down I can go back to my WordPress and use the Stop Azure VM form. The possibilities here are endless. I know some of you may be thinking this is great but what if I want to control who can login to see this form and will it work with Active Directory. The answer is YES. WordPress has several plugins that integrate with Active Directly and even have SSO. A couple of these are Active Directory/LDAP Login for Intranet sites and Active Directory Integration. 

You can see that WordPress can make a great frontend for your Azure Automation runbooks. That is the end of the post. Happy automating!

Read more

Write once, deploy anywhere (Azure or Azure Stack)

This blog post is a follow up to the MMS 2016 session I recently delivered together with Microsoft Azure Stack PM Daniel Savage. The session title is “Future-proof your Career with Azure Stack in the New Hybrid Cloud World!” link here: https://www.buchatech.com/2016/04/presenting-at-mms-2016-azure-stack-backup-oms.

My demo is this session was titled “Write once, deploy anywhere“. The purpose of this demo was to show using a single ARM template (JSON file) and a single PowerShell script to deploy a VM regardless of deploying to Azure or Azure Stack. The demo was a success so yes this is really possible. In this post I will break down the JSON file, the PowerShell script, how it works and the download link for the files.

Getting the JSON file and the PowerShell script just right was a challenge as there are still some slight differences between the settings of Azure and Azure Stack. Note that this is the case with Azure Stack TP1 and I fully expect that this will change when it GA’s. In any case it is good to look at this stuff now to start to learn the ins and outs. In the end it was the combined Power of the ARM template and PowerShell to overcome any challenges. Let’s start off by taking a look at the differences in ARM between Azure and Azure Stack in the following table:

Property

Azure

Azure Stack

Location

Azure region (example: CentralUS)

local

blobStorageEndpoint

blob.core.windows.net

blob.azurestack.local

vmSize

Standard_D1

Standard_A1

vmName apiVersion

2015-06-15

2015-06-15

StorageAccountName apiVersion

2015-06-15

2015-06-15

nicName apiVersion

2015-06-15

2015-05-01-preview

vrtualNetworkName apiVersion

2015-06-15

2015-05-01-preview

networkSecurityGroupName apiVersion

2015-06-15

2015-05-01-preview

dnsNameForPublicIP apiVersion

2015-06-15

2015-05-01-preview

torageAccountName apiVersion

2015-06-15

2015-05-01-preview

NOTE: For the apiVersion on the resources Azure Stack requires 2015-05-01-preview. Resources in Azure ARM templates default to apiVersion 2015-06-15. So if we left the resources in the ARM template at apiVersion 2015-06-15 the deployment would fail on Azure Stack. However we are in luck as Azure will accept apiVersion 2015-05-01-preview. So I set vmName and StorageAccountName to apiVersion 2015-06-15 and the rest of the resources apiVersion to 2015-05-01-preview.

vmName and StorageAccountName use the same apiVersion for both Azure and Azure Stack. So Azure Stack accepts 2015-06-15 for both. Even those these are not different across Azure and Azure Stack I still wanted to list it anyway in the table.

If you have multiple subscriptions you will need to input the subscription ID. In my case my Azure has multiple subscriptions but my Azure Stack does not in this lab. In my script for Azure you need the subscription ID. In Azure Stack you do not. You may need to modify this behavior in the script if your scenario is different.

For the deployment it consists of two files. These files are:

Writeonceblog (1) AzureandAzureStack.json

CreateVMAzureorAzureStack.ps1

Here is what we have if we crack open the JSON file.

Writeonceblog (2)

A few things to note about the PowerShell script is that

  1. We prompt to identify if it is an Azure or Azure Stack deployment. We then run the appropriate block of code.
  2. In each of the deployment types (Azure or Azure Stack) we have some things hard coded in (for example blobStorageEndpoint and vmSize) and somethings pulled in dynamically by prompting for them during the script execution (for example subscriptionId and adminPassword).
  3. We are pulling in the parameter and variable values when using New-AzureRmResourceGroup and New-AzureRmResourceGroupDeployment.

NOTE: I am not a PowerShell expert. I am sure there are better more efficient ways to accomplish what I am doing here in the PowerShell script. Nothing was available to accomplish the write once, deploy anywhere goal so I put something together. Feel free to enhance the script and release back to the community.

Here is an example of the location parameter and variable in the JSON file.

The parameter:

Writeonceblog (3)

The variable:

Writeonceblog (4)

Referenced in the vmName resource:

Writeonceblog (5)

Here is an example of how we are leveraging this in the PowerShell script.

For Azure:

Writeonceblog (6)

For Azure Stack:

Writeonceblog (7)

Writeonceblog (8)

Writeonceblog (9)

Note that you can deploy VM’s to Azure or Azure Stack in many ways (Visual Studio, the portal etc..). I decided to leverage PowerShell to do the deployment’s as it gives me a great amount of flexibility. For the official article on using PowerShell to deploy VM’s to Azure Stack visit:

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-deploy-template-powershell

Now let’s look at deploying a VM to both Azure and Azure Stack using a single PowerShell script and a single ARM template.

— AZURE —

Run the script and you are prompted for some of the VM info.

Writeonceblog (10)

Then you are prompted to log into your Azure account.

Writeonceblog (11)

Read more

Cant change SCOM agents Primary Management SVR in SCOM Console

Problem:

When in SCOM you go to change the primary management server on a SCOM agent but you cannot. It is grayed out.

clip_image001

More details about this issue referenced on the following links:

https://social.technet.microsoft.com/Forums/systemcenter/en-US/c5214222-0cc3-4da5-a40e-64cbeff91573/r2-cannot-change-primary-management-server?forum=operationsmanagergeneral

http://www.systemcentercentral.com/forums-archive/topic/moving-agents-from-one-gateway-server-to-another/

I built a quick script to help with this. It can be used in any SCOM environment. Details are as follows:

Script:

MoveAgentSCOMMgmtServer.ps1

Description:

This script can be used to move agents from one management server or gateway server to another.

There is a common issue “Cannot change SCOM agents Primary Management via the GUI (SCOM Console)”. This script can be used to help with this issue.

This script should be run in an administrative PowerShell console on a SCOM management server. You can run this script using: powershell.exe -executionpolicy unrestricted -command .\MoveAgentSCOMMgmtServer.ps1

How to run:

Step 1: Copy the MoveAgentSCOMMgmtServer.ps1 script to a SCOM management server.

Step 2: Open an elevated PowerShell and navigate to the script. For example: CD “C:\SCOM Scripts”

Step 3: Run powershell.exe -executionpolicy unrestricted -command .\MoveAgentSCOMMgmtServer.ps1

You will be prompted to enter the name of the management server you want the SCOM Agents set to. You need to enter in the servers full FQDN. This can be a management server or a gateway server.

clip_image002

Step 4: A window will pop up with a list of your SCOM Agents. Select the SCOM Agents you want to change the primary management server for. Click the OK button.

clip_image003

Step 5: Once the SCOM Agents are set you should see a similar output.

clip_image004

Download from TechNet Gallery:

https://gallery.technet.microsoft.com/Move-Agent-SCOM-Primary-9927d7a3

Read more

System Center Futures 2016 and Beyond

UPDATE 9-4-2015:

***There is an upcoming FREE event covering the Future of System Center. This will be held on Sep 25, 2015 at the Microsoft MTC in Minnesota (http://www.microsoft.com/en-us/mtc/locations/minneapolis.aspx). This is a must attend event for any company running System Center. For more info on this event visit: http://bit.ly/1JIHS48***

Last week I was able to attend the first ever Microsoft Ignite conference in Chicago. There was a lot of exciting news announced at this conference around the many Microsoft products and technologies. Everything was covered from SharePoint, Exchange, Unified Communications, Office, Windows server, Windows 10, all things Azure and more. This post is focused for any System Center professional that was unable to attend the MS Ignite 2015 conference but what’s to know what’s up with System Center. If you had any concern about System Center going away or just want to know about the future of System Center in general this post is for you.

During conference there were many sessions related to the various System Center components however there were a couple of critical sessions that covered the future of System Center. These are the Platform Vision & Strategy sessions. These are titled:

Windows Server & System Center Futures—Bring Azure to your Datacenter (Platform Vision & Strategy)

And

Platform Vision & Strategy (6 of 7): What’s New in System Center for Management

These sessions are important because they featured System Centers top guy Jeremy Winter and he talked about future direction of the management solutions. In this post I will sum up key information from each of these sessions.

NOTE: This post is my perspective on the Platform Vision & Strategy sessions from Ignite and do not represent the opinions of Microsoft.

Traditionally System Center has been a complete management stack for IT Operations. This is not going to change but will continue to get better. The stack consists of: Managing endpoints (PC’s/Mobile device/servers) – *SCCM/Intune* | Monitor – *SCOM* | Automation – *Orchestrator (SMA)* | Provision – *VMM* | Service Management – *SCSM* | Protection – *Data Protection Manager* | Self-service – *Azure Pack* also represented in the following screenshot from one of the session slides.

clip_image001[4]

So we are now in the year 2015 and have not had a new major version of the entire stack since 2012. However since the release of System Center 2012 we have seen a steady progression of enhancement to the stack. We have seen it move from SP1 to R2 and now updates and new features through update rollups.

These update rollups have been released on a faster cadence at a speed we have not seen from Microsoft before. In fact we have recently seen a round of new features in update rollup 6 and more announced at Ignite. Below is a list of key features that stuck out to me along with slides from one of the Platform Vision & Strategy sessions giving insight into where the System Center components are headed next.

Read more

Update to the SCSM Discovery Report

  I have made a couple of updates to the Service Manager Discovery report. The first one is that the report will now display the update rollup level within the report along with the version number. This was courtesy of Samuel Erskine and Natascia Heil. Thanks for contributing the the report! They have recently built … Read more

Service Manager Discovery Report

I recently built a PowerShell script that creates a discovery report for System Center Service Manager. The idea behind the script was to have something that I could run to gather all of the information I would want about a Service Manager deployment. I searched online and could not find anything so that’s when I decided to put something together.

This report can be used by consultants doing assessments or SCSM admins as an easy way to document what you have in your environment. This is a first pass at the report so it is version 1.1. I plan to add more information/functionality to the report in the future. Keep in mind I am not a PowerShell expert so feel free to take the script tweak it and share your updates with the community.

When the script is run it will output a report of System Center Service Manager in HTML format. This script should be run on a management server within your Service Manager’s management group. The script should be run with an account that has administrative access to Service Manager and the local server it will be running on.

The script will run on Service Manager 2012 SP1 and above. It uses SCSM 2012 SP1/R2 CMDLETS along with SMLets. If you don’t have the SMLets installed you can download them here: https://smlets.codeplex.com/

Discovered in the report:

These are the sections of information in the report.

  • Management Server Name
  • Service Manager Version
  • Management Server HDD CPU Memory
  • Service Manager Management Group Name
  • Service Manager Data Warehouse Information
  • Users connected to Service Manager
  • Service Manager Run as accounts
  • Service Manager User Roles
  • Service Manager Notification Channels
  • Service Manager Connectors
  • Service Manager Email Templates
  • Service Manager Subscriptions
  • Service Manager Groups
  • Service Manager Queues
  • Service Manager Service Offerings
  • Published Service Manager Request Offerings
  • Draft Service Manager Request Offerings
  • Service Manager Views
  • Service Manager Tasks
  • Service Manager Un-sealed Management Packs
  • Websites local to the Service Manager Server
  • Last 10 Service Manager error event logs

Example Link:

This will take you to an online example of the report.

https://www.buchatech.com/wp-content/uploads/2015/03/Service-Manager-Discovery-Report.html

Example Output:

Here is a screenshot of the report.

clip_image001

Download It:

https://gallery.technet.microsoft.com/Service-Manager-Discovery-a25c7d80

NOTE: The PowerShell report is provided AS-IS without warranty of any kind. It is recommended to run in a lab environment before running it in a production environment.

Read more

Service Manager PowerShell Extensions – SCSMPx

Recently a colleague of mine Rob Plank brought some new CMDLets for Service Manager to my attention. These are a part of a PowerShell module that can be installed on your Service Manager server. They are the System Center Service Manager PowerShell Extensions also known as SCSMPx. Here is the official description for them:

The ScsmPx module facilitates automation with Microsoft System Center Service Manager by auto-loading the native modules are included as part of that product and enabling automatic discovery of the commands that are contained within the native modules. It also includes dozens of complementary commands that are not available out of the box to allow you to do much more with your PowerShell automation efforts using the platform.

This module contains hundreds of new commands for Service Manager.

The module was built by Kirk Munro (@Poshoholic) and sponsored by Provance.

The System Center Service Manager PowerShell Extensions ( SCSMPx) module can be found here: https://github.com/KirkMunro/ScsmPx.

The module requires:

  • PowerShell 3.0
  • SnippetPx module

The module is very easy to install and can be done so by running this syntax from PowerShell on a Service Manager management server:

& ([scriptblock]::Create((iwr -uri http://tinyurl.com/Install-GitHubHostedModule).Content)) -ModuleName ScsmPx,SnippetPx

Running that will download and install the SCSMPx and SnippetPx modules. This is for all users and requires being run from an elevated PowerShell console. This module will auto-load (PowerShell 3.0 and above) so there is no need to run Import-Module to load it.

Once this module is installed on a management server it also enables auto-loading of the native Service Manager CMDlets for Service Manager 2012 and later.

The commands included in the module are:

Read more

PowerShell script for Windows Server Activation

I recently was helping a client that needed to activate over 50+ servers after an OS upgrade. I did not want to do this one by one and they did not have a KMS. PowerShell to the rescue. I was able to put together a script that loops through an OU in Active Directory and activate all computers in that OU. This script will find only computers with “Windows Server” in the name. This script could be modified to find client operating systems instead.

When you run this script it will prompt you for the domain name, organizational unit, and Windows Server product key. I was able to use this in my new lab build as well. Here is the script:


<#
Name: ActivateWinComputersfrAD.ps1
Author: System Center MVP – Steve Buchanan
Date: 2/15/2015
Version: 1.0
Website: www.buchatech.com

Description:
This script can be used to loop through an OU in Active Directory and activate all computers in that OU.
This script will find only computers with “Windows Server” in the name.
Run this script using: powershell.exe -executionpolicy unrestricted -command .\ActivateWinComputersfrAD.ps1
#>

# Load the Active Directory PowerShell module
Import-Module -Name ActiveDirectory

# Prompt script runner for information to create variables
$domain = Read-host ‘Enter domain to be used. Format as such (DOMAINNAME)’
$computersou = Read-host ‘Enter the name of the OU to be searched.’
$Productkey = Read-host ‘Enter product key. Format as such (XXXXX-XXXXX-XXXXX-XXXXX-XXXXX)’

# Create a variable that holds all of the computers from Active Directory
$results = (Get-ADComputer -LDAPFilter “(OperatingSystem=*Windows Server*)” -SearchBase “OU=$computersou,DC=$domain,DC=com”)

# Loop through the results variable and activate all computers in that variable.
# NOTE: Dont forget to replace the $key variable with your own Windows key.

foreach ($i in $results)
{
$computer = gc env:computername
$service = get-wmiObject -query “select * from SoftwareLicensingService” -computername $i.Name
$service.InstallProductKey($Productkey)
$service.RefreshLicenseStatus()
}

Write-Host “The following servers have been activated:” -ForegroundColor Green
$results | Format-Table DNSHostName -HideTableHeaders

Pause


It can be downloaded here: https://gallery.technet.microsoft.com/Windows-Server-Activation-f1c534b6

Read more