Category Archives: Standardization

Automatically Update your MDT Reference Images

Typical workflow for handling reference images in MDT:

  1. Import OS install media from an ISO you downloaded off Technet / Microsoft Volume Licensing
  2. Build a task sequence to deploy it (I call this my Build Image task)
  3. Capture it to the Captures folder on your deployment share
  4. Import the captured OS
  5. Build a task sequence to deploy it (I call this my Deploy Image task)
This looks mundane, but doing steps 3, 4 and 5 sucks! Trying to remember exactly how you customized your task sequence is no way to live when it’d be way easier to re-use the existing Deploy Image task when updating your reference image.  I also would love it if I’m not the only one who can perform updates to reference images ….so I figured it all out and now I live happily every after!
It’s a little extra work up front, but here’s how you can turn updating your reference images into a one step process that anyone could perform:
  1. Create a script called Relocate.cmd in your Scripts directory off the Deployment Share that contains the following one-liner:
    • move /Y "%DEPLOYDRIVE%\Captures\%1.wim" "%DEPLOYDRIVE%\Operating Systems\%1"
  2. Create your Build Image task. Keep the ID short. For example, let’s say we’re deploying a general purpose Windows 8 image.  My Task Sequence ID that builds the reference image is 8_GP
  3. Run this task sequence and capture your reference image. Make sure to save it to the Captures folder and name it after your task sequence. For my example, this is .\Captures\8_GP.wim
  4. This one time, you’ll need to use the Import Operating System wizard. Be sure to name the folder for this operating system to match your task sequence that builds the reference image. For my example, I have .\Operating Systems\8_GP\8_GP.wim
  5. Go back into your Build task sequence and add a custom task that runs the following command as the final step (you don’t need to set the Start In value):
    • cmd /? %SCRIPTROOT%\Relocate.cmd %TaskSequenceID%

      Note: Do to ever-vigilent WordPress Security, I had to change out the letter C to a question mark. Pleaee change it back when trying on your own.

  6. Create your new Deploy Image task sequence using the OS from the previous step. I recommend that for your Task Sequence ID you use something like 8_GP_DEPLOY
You’re done! At this point, to get the latest Windows Updates into an image, just run your “Build Image” task  sequence – the WIM is captured and automatically replaces the OS that gets deployed when someone runs the “Deploy Image” task.
There is one word of caution: Significant changes to the OS in your WIM (Service pack, new IE version, etc.) might break the Deploy OS task. If that happens go through step 3 and step 6 again so that the MDT can “refresh” what it knows about the deployment OS you’re using

I’m Still Alive… I think

Yes, it’s been quite a few months since I blogged, but sometimes life is just busy and you have to concentrate on what matters most. I’m in the midst of some back-to-back training – it’s nice when class gets done early, but since I just moved it’s not worth fighting traffic to head out – so instead here I am blogging. And hopefully I’ll keep it up without having to make a New Year’s resolution!

Virtualization is cool stuff. Last week I finished up a foundational class all about VMware’s vSphere/vCenter products. It wasn’t really “new” to me, but they went really in depth into enterprise storage fundamentals and how to hook up SANs. That’s actually where I got the most benefit! And now this week I’m learning all about Puppet. I’m pretty jealous because we’re diving headlong into wrangling our linux environment and getting things properly managed. Now if only I could convince someone that doing the same with Windows is just as important!

Over the past few months I’ve been prepping my group (Systems Engineering) for taking ownership of our company’s AD environment (previous owner being “….uhh?”). Our boss is pushing hard to align what our customers want/need with specific services that IT provides. And at the same time we’re aligning our department’s strategy on managing those services in a Plan/Build/Run model. I have no idea if it’s an actual thing, but I like the premise – We have a team that plans it out, another that builds it, and another that does daily run tasks.

As an Engineer I’m excited because I might get to be a little more distanced from the daily break/fix distractions and do more quality ‘building’ work.  My real question is where the line is between Planning and Building, but whatever.  I ended up writing about 13 pages of a Word doc that spells out anything and everything related to the AD service and is I believe what all our future projects should embrace when trying to match this PBR model. If we stick with it, I think there’s actually some hope of getting out of technical debt and eventually becoming a much more valuable asset for the business teams our IT group supports.

You Can Lead a Horse To Water…

I recently got back from my trip to Las Vegas for a Symantec conference.  I never really thought that Symantec would be able to throw an event that would hold my interest and actually get me exited, but they pulled through. Just being in the presence of so many other companies struggling with CMS implementations and deployment strategies was a big morale boost for me.  I’m not alone, and the difficulties in getting my company to the Utopia that our Symantec sales rep promised us are common and (more importantly) surmountable.

But not two days back and I’m facing the reality of how things are. We have four Helpdesk teams, all with their own way of doing things.  Someone emailed me and said “Hey Slowest Zombie, we got some new VAIO laptops in and it’s a pain in the butt to get them rolled out to our end-users. Can’t you get this automated like everything else?” Well, my answer was not short. I could have said yes for this one new laptop, but what about the next new laptop and the one after that? I brought up the fact that the end-users we support are currently given the choice of whatever laptop they want with no limits. The complexity of laptop drivers, dealing with custom system image discs, and the fact that (especially with VAIOs) there’s rarely more than two users in the company who end up ordering the same specific laptop brand and model all adds up to the fact that the time to automate the laptop deployment process will probably never generate benefits greater than just dealing with each one manually.

It’s very disheartening to hear the response “This is how we’ve always done it and how we’ll keep on doing it forever” from one of the most senior helpdesk staff members. It’s completely understandable – their customers have come to expect that type of flexibility – but someone somewhere signed a VERY expensive contract that said “Let’s buy Altiris and in the end we’ll save money by making things efficient.”  Well, I’m offering up a path to get there, but no one is interested in even talking about possibilities or discussing things that would change the way they approach support. It makes me wonder if I’m just spinning my wheels trying to engineer a solution that no one really wants, and all this rant is just about dealing with one of the four helpdesk sites – I’ll be honest and say I’m not looking forward to even attempting to build a process that works for all of them.