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

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

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. So in previous post we covered what and why we want to do. Now it is time for the where. Let me describe what my lab looks like, so you can understand better later on as I will be saying things like connect to SCO or open SCSM Self Service Portal.

Basically we will be using four Microsoft products that are also part of the title. Three from System Center 2012 R2 suite and free toolkit. These are:

  • System Center Configuration Manger 2012 R2, or SCCM
  • System Center Service Manager 2012 R2, or SCSM
  • System Center Orchestrator 2012 R2, or SCO, or SCOrch
  • Microsoft Deployment Toolkit 2013, or MDT

I will also name a few other products as we go along that add some bells and whistles, like Intel AMT, and DaRT.

The LAB

I am not going to count ADDS and ADCS and DNS and DHCP and … as part of our LAB as this is way beyond this scope.

This way lab contains four servers. Primary SCCM site (CMPS1), SCCM Distribution point (CMDP1), SCO server (SCO1) and SCSM server (SCSM1).

All the servers are running Windows Server 2012 R2 and are virtualized with Hyper-V. For client computers I am using either physical Lenovo computers or I just spin up some virtual computers on my notebook.

CMPS1 has installed many roles, but for this lab we are going to need Enrollment point, Management point, Out of band service point and State migration point

CMDP1 has installed Distribution point and MDT.

SCO1 has all components needed for Orchestrator installed.

SCSM1 has all components for SCSM installed. We do not leverage SCSM Data Warehouse in this example.

Installing all of the different server components is really not in the scope of this post, so here are some helpful links. I will point out what to look out for when installing different components as we go along. For now, just links. Thank you Kevin!

SCCM

http://blogs.technet.com/b/kevinholman/archive/2013/10/30/configmgr-2012-r2-quickstart-deployment-guide.aspx

http://prajwaldesai.com/sccm-2012-r2-step-by-step-guide/


SCSM

http://blogs.technet.com/b/kevinholman/archive/2013/10/18/service-manager-2012-r2-quickstart-deployment-guide.aspx


SCO

http://blogs.technet.com/b/kevinholman/archive/2013/10/18/orchestrator-2012-r2-quickstart-deployment-guide.aspx


MDT

http://jasonmlee.com/archives/178

This is it for the lab. Now we need to do something with it. This is now what, why and where. Just the how remains…

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

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

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

This is a rough outline that I in vision at the beginning of writing, so it will probably change. I will link the following posts back to these bullet points for easier following.

So without further ado, let get stuck in. First, let’s try to sum up what we will be doing and why.

INTRO:

There are a few goals I would like to achieve with OSD deployment process, I will explain reasoning for them below:

  • Monitor deployment from end-to-end from help desk technicians workstation
  • Deploy OS to known rather than unknown computers
  • Support computer Replace and Refresh scenarios besides bare metal deployment
  • In Replace and Refresh scenarios ensure user data is preserved
  • Enable self service portal for requesting OSD
  • In refresh scenarios do not use PXE boot

Monitoring OSD is achieved in 3 steps. One is enabling monitoring in MDT. This gives us the ability to check on progress of all deployments. Second is enabling DaRT in conjunction with MDT monitoring. This gives the ability to “remote” into WinPE and see remote screen from out workstation. This is very useful for when errors occur and we need to troubleshoot. The third option we will enable is Intel AMT. With this we get the ability to connect to computer event when it is turned off. We can adjust BIOS settings, force it to use specific device for boot at next start-up and most importantly, from monitoring perspective, we get the ability to connect to it using VNC. Now we can see and interact with remote computer all the way from start to finish.

More about monitoring in the following posts. We will also answer questions like, why DaRT and Intel AMT, and not just the latter?

Why deploying OS to “known” rather than unknown computers? When deploying OS with SCCM you have two basic options, you can deploy your task sequence to Unknown computers, or you can deploy to other collections. If you deploy to unknown computers you can just start any new computer, PXE boot it and windows will install, sort of 🙂 BUT, what will the name be? MININT-****** does not suit you? OK then. MDT to the rescue! You can add computers to MDT DB and give it a name. OK. Good. Computer is still Unknown from SCCMs point of view, so it will deploy OS to it, but the computer is “known” from MDTs view, so it will get correct name and all other settings that you put in there.

So, what is the downside to this kind of deploying? Well say you want to Replace a computer. You would have to make a computer association in SCCM, which cannot be done until new computer is finished deploying. And since we are already importing computers to MDT prior to actually deploying them, why not create them in SCCM as well?

Another upside for this would be that you completely control who can deploy computers. No more need for protecting PXE sites with passwords and enabling F12 for extra protection. If computer is not assigned for a deployment, it will not have anything to deploy.

Support computer Replace and Refresh scenarios besides bare metal deployment is described in previous paragraph. This requirement is directly linked and dependent on deploying to known computers.

In Replace and Refresh scenarios ensure user data is preserved requirement leverages USMT at its core. Basically what it does it copies users data from old computer to a new one, or in case of Refresh, it makes sure it is copied back to computer. But since we are also using SCCM, it ensures that all programs are installed on new computer.

Enable self service portal for requesting OSD.  With SCSM self service protal, we can enable users to request Refresh scenarios for their own computers, or if you find this too risky:) help desk technicians can do this for any user and never leave their desk. This way we do not to distribute any scripts, help desk does not have to ask administrators every time a computer needs to be deployed to put it in MDT, … just point them to SCSM Self Service portal, where they fill out a form and wait.

In refresh scenarios do not use PXE boot was not requirement in the beginning, but once I found it, it was a must. I will go in depth why we need this so badly. I’ll give you a hint, it has to do with TFTP. 🙂

OK. I think we covered all the objectives, and why they matter, now lets go to our LAB environment.

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

This is a rough outline that I in vision at the beginning of writing, so it will probably change. I will link the following posts back to these bullet points for easier following.

Converting SCCM 2012 custom reports to use RBAC. 

In SCCM 2007 we had many custom reports that were needed by different people. Often it was the same report, with just one parameter differing, so it was displaying information user needed, but nothing more. For example administrators in different countries were only able to see reports about computers in countries they were responsible for, but not others.

Now in our company this quickly meant over 200 reports. in fact it was just 8 or 10 reports, differing in names, one filter value and permissions on them.

With upgrade to SCCM 2012 i thought it would be a good time to update our reports as well. And since SCCM 2012 enables us to use RBAC, I gave it a go. Firstly you have to set permissions for users. I will explain how to do this in another post. For now let’s just say that users have permissions correctly assigned to them.

If you are creating new report, rather than reusing old ones, you can skip first couple of steps and just open Report Builder. Continue reading