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.

orch1

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: https://technet.microsoft.com/en-US/library/hh420367.aspx

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.

orch2

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

orch3

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.

Edit:

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 🙂

https://github.com/djanny22/PowerShell/blob/master/JANComputerManagement.psm1

Advertisements

One thought on “Deploying Operating systems with MDT, SCCM, Orchestrator and SCSM – part 6

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