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.