Deploy new Azure RM template

To create new Azure RM template you open up Visual Studio -> File -> New -> Project ->

Under Visual C# select Cloud and select Azure Resource Group.


Select pre-built template


Now you have a script and .json file.


Json file describes template and .ps1 script deploys it to resource group.
The problem is that cmdlets in .PS1 file are outdated.

So if you are like me and regularly update your modules, then you have to explore AzureRM module. Well. To be honest there is more than one.

Install AzureRM.Storage cmdlets and change script:

Comment out any Switch-AzureMode
Replace last command with

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation
New-AzureRmResourceGroupDeployment -ResourceGroupName $ResourceGroupName -TemplateFile $TemplateFile -TemplateParameterFile $TemplateParametersFile -Force -Verbose

Now basic deploy will work.

To deploy template to Azure

Right click soluiton in VS and select Deploy -> New Deployment
Enter your subscription details and other parameters, click Edit Parameters

Azure8 Azure9

That is it. just wait for it to deploy and you have a template deployed to Azure.

Have fun automating 😉




DSC Pull Server in Azure

I was working on a DSC pull server v2 for the last couple of months. I heard about all the great new bells and whistles it brings and I was eager to test them. I was also working on a web interface such as Mark Gray showcased on PowerShell Summit Europe 2015 in Stockholm. Here is the video for his session:

So I was working on an interface for pull server to upload DSC configs, assign them to servers and to monitor the deployment. then a couple of days back, I saw this video up on Channel 9, where they were talking about Azure automation,–with-special-guest-Jeffrey-Snover. Really a great video, except for that guy that keep on interrupting. 🙂 Just kidding Jeffrey 😉

There I saw that Azure now has DSC pull server option that can also manage on-prem servers. I just had to try it out!

So let’s open our Azure portal, and then click through

  1. New Automation Account
  2. Dsc Configurations
  3. Add a configuration
  4. Compile configuration

You have to create a new automation account, then click on DSC Configurations Upload a configuration file and compile it. I created a simple test config, that just installs XPS Viewer. (Sorry for lack of indentation…it keeps disappearing :/)

XPSTest - Microsoft Azure
configuration XPSTest
node test
WindowsFeature XPS
Ensure = 'Present'
Name = 'XPS-Viewer'


Now that we have config uploaded and compiled we have to apply it to a node.

If you want to manage Azure VMs.

  1. Make sure you user Virtual machines with new “Resource mode”
  2. Click on Automation Accout you just created
  3. Click on DSC Nodes
  4. Add Azure VM
  5. Select virtual machines to onboard
  6. Click OK
  7. Configure registration data
  8. Click OK
  9. And click Create


There is one catch though. You can only manage “new” Azure VMs, created in Resource Mode, not “classic” VMs. Read here for explanation of differences:


If you want to configure on prem machine you can select Add on-prem VM in step 4. you will find some instructions on how to do that, but cmdlets you have there are out of date!


These instructions are out of date!

So if you are like me and regularly update your modules, then you have to explore AzureRM module. Well. To be honest there is more than one.

For onboarding on-prem VM to Azure DSC pull server, you will need AzureRM.Automation.

Get-AzureRmAutomationDscOnboardingMetaconfig -ResourceGroupName 'RG name' -AutomationAccountName 'Automation Acc Name' -ComputerName 'Computer Name' -OutputFolder 'Folder for MOF files'

Apply mof to server

Set-DscLocalConfigurationManager -Path .\DscMetaConfigs\ -ComputerName DSCJBK2-T

Now you can see both types of machines in your Azure automation account. You can also change which configuration they should pick up, and see the history, basically all I was about to do on my own, I just found out can be done in Azure. 🙂

Happy automating 🙂


Deploying Operating systems with MDT, SCCM, Orchestrator and SCSM – part 7

I intend this to be a series of blog posts about my experience in implementing end to end OSD solution. I will be writing about my lab implementation, as production version has much unneeded clutter that would just confuse the whole blog post.

I thought this blog series would be split in following posts:

  1. Intro
  2. Lab setup
  3. MDT
  4. SCCM
  5. Intel AMT
  6. Orchestrator
  7. SCSM
  8. Bringing it all together
  9. Recap

OK, it is now time to deploy our self-service portal. I will be using SCSM for this, as it was the only thing available to me at the time. 🙂 In the mean time, that is since I started to write this blog post, I have come across other solutions that are better suited, at least in my opinion, if you just need the self-service portal. Using SCSM for just this functionality is, again in my opinion, moronic. 🙂 It is such a big product, that it makes no sense what so ever to use it for just this one bit. But if you have it in your datacenter already, then it might make more sense…

To present one possible alternative that, in my opinion, is better suited is ZervicePoint by Enfo Zipper:

I had a chance to meet some of them in Stockholm and they are really great. I have also tested the solution in our datacenter and I have to say it is great! I cannot recommend it enough.

OK. With that out of the way 🙂 let’s dig into SCSM. I will not go in depth on how to install it, there are many guides online, like this one for minimum config:

But I would like to point out a few things I found out while deploying. For example, you cannot use special characters in SCSM service accounts passwords. You cannot use .$V^]@\u)D.x@on?”7IM for a password, which is a randomly generated string I wanted to use for a password for SCSM services account. It was too complex… 🙂

Another thing would be if you decide to install Self Service portal on a separate server and you want to use SCOM, make sure you install SCOM agent before you install SCSM, and leave it installed! This only applies to self service portal on a separate server. For all other roles you must uninstall SCOM agent, but for this role you must leave it installed. If you do not, then you do not have all SCOM bits you need and it does not work, and you cannot install SCOM agent, because installer detects that SCSM is installed and it will refuse to continue. There is a registry hack workaround, but I recommend planning ahead. 🙂

Link for self-service portal installation:


Now that we have SCSM and it’s self-service portal installed, we need to configure connectors so it can find computers, users, runbooks, … OK for what we will do, just runbooks will do. So let’s create an Orchestrator connector. In SCSM console:

  1. Go to Administration -> Connectors
  2. On right hand side click Create connector
  3. Select Orchestrator connector
  4. Give it a name
  5. Write in the URL for Web service
  6. Create account that has permissions on Orchestrator server (It needs read and execute permissions on runbooks)
  7. Select sync folder (Which runbooks will be available to SCSM)
  8. Write in the URL for Web console


Now we have connector created, we need to wait for a while for it to sync the runbooks. After you see it complete you can check your notebooks in Library workspace -> Runbooks. I have noted that if you rename a runbook, it will not appear in SCSM as expected. In this case it is best to remove it from SCSM manually and sync Orchestrator connector again.


Now that we have our runbooks available we need to name them available via self-service portal. now since SCSM is closely following MOF, which is following ITIL we have to get a few thins straight. 🙂 We will be creating a Service Offering in our Service Catalog in which we will make our Request Offering available.

Let’s break this down. service catalog is a list of all available services. Each service can have a Request Offering, which is something we offer to our end users. In my environment I designed is as such. Our Service is Computer management, where users/admins/HD technicians can request application deploy, OSD, … This would be our Service Offering in SCSM and each of possible tasks users can do is a Request Offering.

You can find your service catalog just beneath your runbooks in Library workspace.

Let’s create there a new Service Offering. It is a straight forward process,  just make sure you select a custom Management Pack, as is the best practice for SCSM.

Now we will not create a Request offering just yet. First we need to create a few templates. Templates will enable us to create reusable working items. In Library workspace you can find Templates on the bottom of the list on the right side.

Create a new template and select Runbook Automation Activity. Please use sth like RAA in the name, so you can differentiate different kind of templates easily. I had to learn it the hard way 🙂 Also, use custom management pack you created earlier, or a completely new one. Click on Runbook tab and select the runbook for creating New Computer. Mappings should already be configured to text fields.scsm4

Now save and create another template. This time select Service Request template. Again, name it appropriately and select your management pack! 🙂 Click on activities tab and click on the little + in top right corner. Now select your Runbook Automation Activity you created in previous step.


Now we are ready to create a Request Offering. Under Request Offerings click on Create Request Offering, give it a meaning full Title and select template. Select  Service Templates and select the one you just created. Select appropriate Management pack. Now you will have to create and configure appropriate User Prompts and map them. Now this is completely dependent on how you create your runbook in Orchestrator, mine look like this.


Now that you have configured all this, you just need to publish it and assign it to a Service Offering you create in the first step. once this is is done, you can see it on your self-service portal.


This is it for this blog series. It has been a looong time since I started. I hope some of you will find this useful. 🙂

Deploying Operating systems with MDT, SCCM, Orchestrator and SCSM – part 6

I intend this to be a series of blog posts about my experience in implementing end to end OSD solution. I will be writing about my lab implementation, as production version has much unneeded clutter that would just confuse the whole blog post.

I thought this blog series would be split in following posts:

  1. Intro
  2. Lab setup
  3. MDT
  4. SCCM
  5. Intel AMT
  6. Orchestrator
  7. SCSM
  8. Bringing it all together
  9. Recap

We are now able to deploy computers using MDT and SCCM, deploy specific operating system to a known computer in SCCM, and deploy New, Replace and Refresh scenarios. But all the work has to be done manually. At this point I started to look around for a solution that would enable me to automate all the steps needed to deploy computers, and that would also enable me to have a self service portal, so I would “never” have to lay my hands on this process.

One solution that I found at that time was to use System Center Orchestrator for automation part and System center Service Manager for the self service portal. This is what I built half a year ago and is a red line for this blog series. This is not a light weight solution, as it requires at least 3 servers just to do automation and self service portal, and if you only think of using it for OSD, there are probably better solutions for you, I will discuss them at the end. However, if you already have System Center license, then it comes at no additional license cost to you…

Anyway, let’s get into Orchestrator. First, you need to install it.

You will need to prepare the following:

  • Minimum of one server, I user 2012 R2
  • One service user, with which Orchestrator will run on server
  • Connector users Orchestrator will use to connect to external tools, with correct permissions.

When you have all this, you are ready to install Orchestrator.

Insert your Orchestrator installation media and run Setup.exe and follow the wizard.

I installed all features on one server.


Then enter credentials for service account and test them. On the next screen enter database server name and instance. Make sure you have enough permissions on the database server. More info here:

On the next screen you can either user existing database or create a new one. Then select group which will administrative permissions on your Orchestrator installation.

Remember the ports you select on this next page, if you change them from default.

After you finish the installation, you are ready to user Orchestrator.


Now when I first started with automating OSD with Orchestrator, I thought about doing everything using runbooks and activities. After a while I figured out that not everything can be done with available activities, be it built in, or those from additional Integration Packs (OIP). I always ended up using PowerShell for one or another task, for example MDT. I also figured out that Orchestrator does not really like PowerShell. 🙂 I had to use Run .Net Script activity, or play around with PowerShell OIP.

So I set up writing my own OIP for missing features. And I slowly created MDT OIP, and a few other bells and whistles that were missing for this specific task I wanted to do. Then as a mental exercise I created PowerShell scripts that did the needed steps. I ended up running them with Run .Net Script. This was kind of OK, but then I have re-written and re-think the whole thing once again, and created one script that did all necessary steps in one go. In the end I created PowerShell Module for Computer Management which script being run from Orchestrator calls with parameters you enter.

It was quite a journey for me and I really learned a lot during this time. It is also one of the reasons it has taken almost 6 months to get to this point in blog series. I was always fine tuning the script, or module, or OIP to the point where I had a working solution in my development environment but I was adding new ways of achieving the same thing, that seemed better to me, at least at the time.. 🙂

So this is how it ended up looking in a runbook.


Really simple. I just get the data from Initialize Data, which I end up passing to Run command, like that:


Now I pass on quite a lot of information, because of the way I do permissions testing, Computer name structure, … We have quite a lot of rules there we have to adhere to. This also means I have a bit of a problem sharing all my scripts and modules with you… I will have to, you guessed it, re-write them all. 🙂 I will do it as soon as time permits and then release them in the wild, so you guys can use them as well. I will put the link to GIT here once I do that.


So, now we have Orchestrator installed, and hopefully I will be able to share the scripts I use with you soon, so then you have everything automated as well. Next step, creating a self service portal, where users, or HD guys, can request OSD for a computer.


I have managed to create a quick sample code for Computer Management. It is a smaller version of what I actually created, I just omitted proprietary information and functions that check for permissions and computer name structure. The code is on GitHub, my first try with GitHub 🙂

Deploying Operating systems with MDT, SCCM, Orchestrator and SCSM – part 4

I intend this to be a series of blog posts about my experience in implementing end to end OSD solution. I will be writing about my lab implementation, as production version has much unneeded clutter that would just confuse the whole blog post.

I thought this blog series would be split in following posts:

  1. Intro
  2. Lab setup
  3. MDT
  4. SCCM
  5. Intel AMT
  6. Orchestrator
  7. SCSM
  8. Bringing it all together
  9. Recap

Now that we have MDT ready, we are prepared to configure SCCM. First we need to integrate MDT with SCCM. On your SCCM server, where MDT is also installed, click Configure ConfigMgr Integration in your All Programs -> Microsoft Deployment Toolkit.

Now we need to import boot image we created in MDT in SCCM, so we can leverage monitoring we created in previous chapter. In your SCCM console right click on Boot images and select Add Boot Image. Then navigate to your deployment share you created in MDT and select boot image from there. Now when you create task sequence use this image for your boot image.

Now you are ready to create MDT task sequences from SCCM. Open Task Sequences from your SCCM console -> Software Library -> Operating Systems node and select create MDT task sequence.




Task sequences are a veery large topic, so I will not go into depth what to do here. Johan Arwidmark has a lot of great posts on his deploymentresearch website. I created 3 different task sequences, one for New computer, one for Refesh and one for Replace scenario. For Replace there are actually 2 seperate task sequences, one for old computer, that gathers computer state and one for new computer, that installs OS and also copies data from old computer.

You also need 4 new collections, one for new, one for refresh and another two for replace scenarios. Replace needs 2 collections, one for “old” computers and another for new computer. Now you can deploy created task sequences to appropriate collections.

To create mappings for replace scenario, you need to configure Computer associations. This way SCCM knows how to manage user data from old computer to appropriate new computer. This will be done via script, because we do not know in advance all these mappings.

There are also a few site roles we need to provide to SCCM server(s) that are needed for all the bits and pieces to work. For migrating users data we need State Migration Point, for OSD we also need Distribution Point enabled. I’ll assume you already have DP enabled in your hierarchy, so here are just a few tips on installing SMP.

  • Make sure you have SMP installed on your DPs. If you add it to another server, that is not a DP, it will cause you problems. You have to connect your SMP to a boundary group and when you do that SCCM automatically assumes your SMP is also DP and your distributions will fail…
  • Also, if you use HTTPS for your DP communications, and you should, you probably have certificate issued by your PKI. When you install SMP suddenly your PKI cert is no longer selected and SCCM reverts to self-signed certificate and you have to manually re-import your PKI cert. When you do that, SCCM says cert is already in use, but that is OK. I figure this is an undocumented feature when you add SMP to your existing infrastructure…
  • You have to re-enable your PXE point after you install SMP, as it gets disabled.


OK…This should do for now. We have installed Site Components we need on SCCM, integrated it with MDT, created Task Sequences and Collections and target deployments. We have also found a few new undocumented features and now we are ready to automate the deployment.

If you do not want to automate deployment, right now is where things stand. We have collections to which we add computers. When computer is added a relevant task sequence is deployed. If we want to deploy Replace scenario then we add old computer to one Collection and new computer to another. We also have to create Computer Association for them. We can now play with deployments. 😉

Another nifty feature with deploying OSD in such a way is that you can download WinPE image from Windows using BITS instead of using network boot and PXE. This comes to great use when deploying over WAN as PXE is limited by RTT and not bandwidth. We have had deployments over WAN where WinPE was being downloaded for over 3 hours! So this is a great time saver for some of our deployments.

So. next time we will dive into automation. I will skip AMT for now and come back to it later…maybe, since Microsoft announced deprecation for OOBM in SCCM

Deploying Operating systems with MDT, SCCM, Orchestrator and SCSM – part 3

I intend this to be a series of blog posts about my experience in implementing end to end OSD solution. I will be writing about my lab implementation, as production version has much unneeded clutter that would just confuse the whole blog post.

I thought this blog series would be split in following posts:

  1. Intro
  2. Lab setup
  3. MDT
  4. SCCM
  5. Intel AMT
  6. Orchestrator
  7. SCSM
  8. Bringing it all together
  9. Recap

I finally got around to writing the next part of this blog series. It has been long overdue, but circumstances did not allow me to get to it. I plan on doing it now in a swift fashion.

I have managed to finish this setup in my dev environment, but for some reason, I cannot put it into production, even though it is all ready to deploy, god understand managers if he can… Now with my chest cleared, let’s get cracking 🙂

Microsoft Deployment Toolkit, MDT, is a free collection of scripts that allow for Lite Touch Installation (LTI) deployment of Windows. It actually supports ZTI, LTI and UDI, but it is regarded as a LTI solution. Only when connected to SCCM it becomes true ZTI. There is a great explanation of this in a book written by Johan Arwidmark, Stealing with Pride. It is a great resource on MDT and deployment.

So we are going to leverage MDT for its database, monitoring, logging and we will create MDT task sequences in SCCM. We will also import DaRT in MDT and boot image, so we can connect to deploying computer and actually see the screen while Windows is deploying.

Installing MDT is straight forward, as well as using deployment database. There are many great guides on internet, but for starters basic next, next, finish should be enough, even though I prefer PowerShell scripted solutions 🙂 Once it is installed, you need to create a new deployment share and new database, it is just a matter of right clicking deplyoment share and database node and you should be on your way.

Since we will leverage SCCM for deployment we do not need to create a task sequence in MDT, or install images, but we do want to create a boot image, so we can manage monitoring later on.

To enable monitoring you have to go to deployment share and under monitoring tab enable monitoring. be aware though that monitoring has it own logging as well. By default it is set to information level, and default path is C:\temp !! So if you have this folder on your C: drive, it will start saving logs to your temp folder and it will fill your disk and break your computer 🙂 So to prevent this from happening, we want to change log level and change log file location. Johan has a great post about it here.


So now we have monitoring and log files for it are under control. We just need to enable DaRT in our boot images, so we can actually connect to computer and see what is going on on the screen. First you need to get DaRT, it is part of MDOP. After you download DaRT you have to install it. Then

  1. Copy the file from the DaRT installation to the appropriate tools folder (either Tool\x86 or Tools\x64) in a deployment share.
  2. In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares
  3. In the details pane, click deployment_share (where deployment_share is the name of the deployment share for which you want to enable DaRT support).
  4. In the Actions pane, click Properties.
    The deployment_share Properties dialog box appears (where deployment_share is the name of the deployment share for which you want to enable DaRT support).
  5. In the deployment_share Properties dialog box, on the Windows PE tab, select platform (where deployment_share is the name of the deployment share for which you want to enable DaRT support and platform is the processor architecture platform for which you want to enable DaRT support), select the Microsoft Diagnostics and Recovery Toolkit (DaRT) check box, and then click OK.
  6. Update the deployment share.

That is it. now you have a WinPE, boot image, with DaRT integrated. you can also see an extra button if you click on a computer under Monitoring node in MDT Workbench.


Here are some resources I found while exploring MDT and DaRT. Hope you find them helpful.

Deploy DaRT with the Microsoft Deployment Toolkit:

Integrating DaRT (8.x) with MDT (2013) and enable DaRT Remote Control:

Adding DaRT 8.1 from MDOP 2013 R2 to ConfigMgr 2012 R2:

Empty Credential Manager store

We all know, that Windows enables us to save our credentials when we connect to other systems. One example would be Remote Desktop Connection, mstsc.exe. You can choose to save your username and password, so the next time, you can connect more easily. Well these credentials have to be saved somewhere, which can

A) Cause problems when you change your password

B) Present a security risk, since all your passwords are saved on a disk

You can delete these saved credentials by opening Credential Manager from Control Panel and Remove one-by-one. But, if you have many, that is not really an option. So it’s script time:

cmdkey /list | %{ if($_.startswith(”    Target:”)){cmdkey “/delete:$($_.split(‘=’)[1])”} }

This simple one line, run from within PowerShell, will remove all your Windows Credentials entered in your Credential Manager.

Hope it helps you.