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 Tools.cab 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:

https://technet.microsoft.com/en-us/windows/hh475799.aspx?f=255&MSPPError=-2147217396

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

http://www.vkernel.ro/blog/integrating-dart-8-x-with-mdt-2013-and-enable-dart-remote-control

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

http://deploymentresearch.com/Research/Post/334/Adding-DaRT-8-1-from-MDOP-2013-R2-to-ConfigMgr-2012-R2

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.