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 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.

 

 

MDTTaskSequence

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.

SMP-DP SMP-PXE

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 https://technet.microsoft.com/en-us/mt210917.aspx.

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.

image

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.

image

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