When Virtual Worlds Collide

Posted by on February 21, 2012 No comments

Seems like lately I only remember to post after taking a training class.  This time it was a series of two classes, both for vSphere.  One was a “What’s New” class that was mostly repeat of a previous vSphere 5.0 Anything and Everything class and the other was for automation and scripting via PowerCLI. One of the classes came with a voucher for a free VCP exam and I just barely squeezed that in before it expired and just barely squeezed a passing score (more on that later).

I think I’ve stated my suspicions before, but I’ll reiterate that PowerShell is the future for Windows systems administration.  I’m almost at the point where I’m mad when I’m not using PowerShell to do things, but it’s a very conflicting state to be in since I never actually use PowerShell for anything…. well, until today that is. I did a quick script to list all the VMs in our environment along with their VMware Tools versions since we have many that are running sans Tools or with an old version. Yeah, it was simple and not anything beyond a sample script, but it felt great to do because it’s practical.

As for my VCP certification…. phew that was an ordeal. Let me tell you, the testing facility was absolutely the worst I’ve ever seen.  I’m pretty sure the front desk receptionist was a stripper, but was also the main tech support for the testing systems.  I hope her night job is a more fruitful career than her day job – My test was scheduled for 7 AM but didn’t start until 8:30 due to what I believe is operator error on behalf of the receptionist.  Her troubleshooting methods for a broken desktop shortcut included using Windows Search (remember the sidebar in XP that shows the dog Fetch who will find your files? Yeah, that search) to search for the shortcut (not the target, the shortcut itself) and then clicking it a million times expecting it to load better somehow. Seriously, an hour and a half of this and similar techniques.  I walked out and sat in the lobby because it was too painful to watch after the first 30 minutes.  This killed my nerves and my mojo for when I was finally able to start and on top of that it’s a genuinely hard test!  Maybe I just don’t use enough of the available features to have a strong working knowledge, but I really don’t think VCP certification syncs with real-world challenges.

I don’t want to put the name of the company here and just blast out negativity towards them in case I had a unique and atypical experience (but mostly because I managed to pass my exam), but if you’re planning on taking a test in San Diego county and are wondering who to avoid or where to find questionable receptionists feel free to contact me

Red Hat System Administration Class

Posted by on January 13, 2012 No comments

This week I completed a week long training class on RHEL system administration. The class “RHEL 124″ was centralized for Windows admins looking to break into Linux administation. Had I paid more attention I would have picked the CLI class instead.

Fortunately I’m comfortable enough in Linux these days that I was able to just do all the classwork using the CLI equivalent of the GUI tools that were taught. But this was a small reprieve from what was otherwise a horrible class. I would like to point out I don’t believe it’s in any way the fault of the instructor at Exit Certified – my beef is with the way in which Red Hat lays out their cource objectives and materials.

My favorite part of the class was where we were given a ‘case study’ scenario in which we were directed to log into a fictional user’s account (that’s not our own) and sort through the pictures of their wife saved in their home folder. We had to sort them, and delete the “bad” pictures.  I can’t make this stuff up!  Other tests were much more mundane and had a complete lack of realistic scenarios or creativity. Usually the case studies were barely any more than “Do the stuff we just taught you on the last page, but pretend your name is Bill while you’re doing it and that your manager is micromanaging so much that it’s weird he isn’t just doing it himself.” In fact, the first step for most case studies is to run a script that undoes all the settings you just made while learning how to do a specific task. You have to do that because the case study invariably has you set nearly the exact same settings a second time.

To me, the class more resembled “how to use advanced features of a desktop OS”.  The real system administration taks were all under the hood – I caught glimpses of them by opening and evaluating the “lab-setup-*” scripts that would prepare the machines for specific case studies. Those automated scripts… those are real sysadmin tools. But we never even went over the ‘cat’ command that one would use to look at those scripts in a real world.

I can’t recommend enough that if you’re looking to break into Linux system administration, take the boot camp version of the class, and bring a healthy dose of imagination and work experience to be able to put what you learn into actual realistic system administration know-how.

I’m Still Alive… I think

Posted by on December 13, 2011 No comments

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.

All In

Posted by on June 20, 2011 No comments

The sales people at Symantec never cease to amaze me.  They somehow convinced people at work that Altiris will solve every problem they have and replace all other tools we use.  I’m pretty flabbergasted!

Today I told someone that although a script could be made to add IE bookmarks to a base Windows 7 image, GPOs could do the same thing but using a couple mouse clicks instead of a customized solution.  I was told that the scripted solution would be preferred so that we could make better use of Altiris CMS tools. Despite arguing the benefits of keeping things simple, picking a non-custom solution, and using the best tool for the job, I’m instead stuck with calling a meeting for all of the operations group to “get everyone on the same page.”  Now, I want to make it clear that the person I was talking to didn’t do anything wrong – the problem is something different.  And for this post I’m choosing to blame Symantec for selling such a good cure-all that someone we’re all hoodwinked into using this one tool for everything.

Thankfully, I know that the collective smartitude of us all will overcome any single bout of shortsightedness (and let’s be honest, I’ve always got my share of moments like that)

Troubleshooting at Home

Posted by on June 13, 2011 No comments

Somehow, even though I’m horrible at returning email and phone calls, I still have a customer who comes to me regularly for consulting advice and doesn’t get the “family/close friend discount”.  She called me up last week because her kitchen computer and her laptop were dying – they wouldn’t boot up, and were constantly getting errors while booted up.  She lives just far enough away that I don’t like to go pick up the computers and take them back to my garage.  Also, I just got a new set of computer parts and it was time to rebuild my system.  Oh, and the MDT 2012 beta came out recently.  Well, that sounds like the perfect storm for setting up my own deployment server at home!

Within an hour (not counting the time that was just watching progress bars) I was able to automate the Windows install for myself, and create a hardcore USB WinPE recovery boot drive, kick off a new OS install on my SSD and drive out to recover files and run chkdsk on the broken kitchen computer. I also brought along my iPad and used it to take notes instead of my leather notebook that I’ve had for the past 15 years.  Although the stuff I was doing was rather simple compared to my official salaried job, I felt like a technopimp all weekend long and loved strutting my stuff.

I’d post more, but a system with a Windows Experience Index of 7.6 needs to play some games.  By tomorrow my machine will be obsolete I’m sure.

TechEd 2011

Posted by on May 24, 2011 No comments

And another week flys by!  I barely cooled my jets from Symantec Vision and I’m off to another conference.  Where Vision felt like a mini-vacation, TechEd was Serious Business™. Another great experience, and for people just getting into the enterprise world of IT + CMS it’s a must-have.  Unlike Vision, the sessions/panels I attended were less product-pitch and more real-world lessons and insight.  Worth the price of the pass and ticket for sure, but the definite complaint is all the e-mails and phone calls from various vendors wanting to sell me stuff.  I promise I only went to your booth for the free light-up pen.

Speaking of which…. damn you TrainStation.com – You tweeted at me saying I won 1000 dollars, but only later did I find out that it’s store-credit for your Video Professor-esque training classes. How bittersweet (80%/20%)!

You Can Lead a Horse To Water…

Posted by on May 11, 2011 No comments

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.

A Week with Altiris

Posted by on April 24, 2011 No comments

Last week I had a posse of Symantec product specialists in my office (the WHOLE week) to help me stand up a brand new Symantec/Altiris 7.1 CMS environment.  The goal is to replace four different helpdesk’s CMS solutions (including the Microsoft Deployment Toolkit stuff I am currently maintaining for one of them) with this shiny new Altiris product.

There’s just one problem with last week’s engagement: During the initial install for Altiris, I had a single setting that “wasn’t optimized”. Just that one setting was enough to make the first three days of work pretty stressful for everyone and not nearly as smooth as it ought to be. This was no fault of Symantec but because it took so long to address the individual symptoms, by the time we identified the root cause of the problems we had already fixed all the issues associated with it. Our environment is up and looking good (although we have yet to insert the actual software and deployment images we’ll be using Altiris for). Before the Symantec gang left, they helped to  identify the appropriate next steps that I’ll be working on this next few weeks. All in all, the week was a success and we’re on a good path for fully switching over to the new CMS system.

…But I’ve got this nagging in the back of my head that my environment isn’t perfect because of that one wrong setting. I’m king of CMS at the office right now. When working with the Microsoft Deployment Toolkit, I must have erased everything and installed it again 10 times before I felt like I had it just right. I wish it would be an easy call to do the same with Altiris, but now it’s not just my time – I would be throwing away an extremely valuable week’s worth of collaborated effort and the stakes are a lot higher. I have to champion Altiris and help prove its worth to four different Helpdesk teams, so what do I do? I don’t have an answer for this yet and it might not even by my call to make.

A Collection of Resources

Posted by on April 12, 2011 3 comments

After writing my beginner’s guide it was immediately clear to me that I provided too much text, not enough pictures, and other people have already done what I did.

Instead of continuing down that path, maybe it will be more helpful to list out the various resources I use when I’m trying to automate a software or OS installation.

 

  • ASCII Art Table – If you’re using the command line and trying to make neat little menus with borders or just to add some pizazz, you’ll want to look up the character codes to have things display correctly. Probably not super useful in these modern times, but every ocne in a while I use something from the Extended ASCII codes to designate a section or to draw attention to stuff being output to a log file
  • Command Line Output Redirection – This is a staple for good scripting. Using > to redirect output to a file is the easiest way to set up logging. You can easily log standard output (success/expected output) and separately log standard error (failure messages)
  • Command Line Details – As soon as I start adding any complexity to batch files, I get ready to queue up this site. It does a great job of breaking down IF statements, FOR statements and has a lot of great general knowledge stuff that Microsoft Technet articles just don’t properly convey
  • Technet Script Center – Chances are good that what ever you’re trying to script has been scripted before. This is a great repository of all kinds of Windows scripts in various scripting languages
  • Sysprep Troubleshooting – Although it’s only dealing with XP, when you’re having difficulty with Sysprep there can be all kinds of reasons.  This is a great collection of troubleshooting pointers that is a great starting point when you’re stumped
  • Create a Custom Windows PE Image – Download the Windows AIK and regardless of any other tools you can have a mini boot environment that comes in at around 150 MB. This is the basis of many “uber” boot CDs. It’s Windows Lite that you can make run remote desktop, copy files, map network drives, and just about any other Windows basic troubleshooting that you need to do.  Trivia fact: When you install Windows Vista or Windows 7 from disc, you’re actually booting to WinPE which then launches the setup.exe file
  • Windows XP Storage Drivers – If you’re using RAID, AHCI or SAS hard drives you’re in for tough road to automating OS deployments. While this link is a little dated it will help you get on the road to expanding storage driver support on legacy OSes.  For even more (but also outdated) help, this Symantec post is also great (it’s to help with automating installs using Altiris but works for any situation)
  • The IT Bros’ Windows 7 Sysprep Guide – This is an off-shoot of a blog that originally posted this awesome guide to working with Sysprep in Windows 7.  If you really want to get in there and learn how to sysprep, do what I did and print this article out. Trust me it’s great.
  • Windows SysInternals – All kinds of utilities that add extra troubleshooting functionality to Windows
  • AppDeploy – When you’re automating software installs, you might as well always go here first. Nearly any installer you can think of, someone’s already posted exactly what you need to do to turn it into something deployed silently across the network while disabling the desktop shortcut and whatever other bells and whistles you could come up with.  Usually you want to check out the Package KB section first, but if you can’t find what you need then try the Software KB. And if you want to learn how people first come up with these silent install commands check out the Articles, FAQs and Tips & Tricks sections. One of the articles in there is great for explaining how to deal with installers that use an InstallShield EXE instead of a standard MSI file (and yes, it explains what the hell that means if you’re totally clueless)
  • Blogs – Here’s some very useful Microsoft blogs that help with deployments, especially related to the Microsoft Deployment Toolkit:

There’s a lot more and I’ll come back to this post and update as I can with additional resources I find myself falling back on.

A Beginner’s Guide

Posted by on March 27, 2011 No comments

On more than one occasion I’ve been asked where to start when it comes to automating Windows OS and Software deployment processes. I’ve never had a good answer because I couldn’t ever find a one-stop all-inclusive solution.  Most of my experience and expertise has come about by ramming into a wall over and over until I found a way through.  My goal in this post is to help my friends and colleagues who are looking to get started.

Your Environment

Before we get into the how or why, let’s go over what I imagine your current environment might be like. It’s hard to say where we’re going if we don’t know where we’re coming from, right?

  • You’re involved in deploying/maintaining OSes and software
  • Roughly 5-500+ employees are under your jurisdiction
  • Primarily a Windows shop. If you haven’t already moved to Windows 7, it’s looming over you like a black cloud
  • Triple Squeeze Play: Requests are up, responsibilities are increased, budgets are down
  • Hardware could be standardized or could be all over the place: Dell, HP, custom, whatever’s on sale at Best Buy…
  • OS deployments could happen through the 1997 version of Norton Ghost to “stick a CD in there and wing it”
  • You have a list of software to install by person/department, either officially or in your head

Your Goals

So you know what you’re up against, but maybe you’re not quite sure what would make life better for you.  While the business really is the ultimate dictator of your goals, it’s safe to agree on some commonalities:

  • Faster
  • Cheaper

You’re in luck! Without cutting corners or without racking up bills for software / training / professional services, you can be the hero. You may have to dedicate some personal time to pulling this off, but trust me: the payoff will be worth it.

The Plan

There’s two parts to this – the OS deployments and the Software deployments.  But both parts are going to use the same tools.

Setting up your OS and Software deployment server

Before we even get into this too far: If you don’t have Volume Licensing for your Windows licenses, but you support enough people to where you’re reading this article, it’s time to change your ways.  Unfortunately I don’t have personal experience with establishing a volume license agreement, but you can check out Microsoft’s website here. If people chime in and recommend additional resources I’ll be happy to post them here later. Without volume licensing you’re going to have a tough time automating OS installations, as well as Office installations. I think the license agreements for consumer/retail licenses prohibit you from taking advantage of a lot of this stuff anyway.

Now that we’ve got that out of the way, let’s gather up some resources we’ll need:

  • A machine that you can designate as a Deployment Server. In my first setup I used my own desktop PC, running Windows 7 x64 Professional. I highly recommend using this OS (or Enterprise or Ultimate or Server 2008 R2), but if you can have a machine around that can be dedicated for this that’d be great. For all other bullet points in this section, assume I’m telling you to use this machine unless I specifically say otherwise.
  • This machine will need to be on a network that other computers will have access to. Whether it’s expensive Cisco gear or a $30 refurb router from Woot, set up whatever it takes to have DHCP, internet access and (optionally and if applicable) access to your Active Directory domain to bind machines as part of the deployment process. This doesn’t have to be the final network that the machine will connect to when you hand it off to your customer. It could be its own little “build network” that’s just for loading systems before shipping it to Timbuktu.
  • Get some storage space – I recommend a 500 GB drive added as a secondary to the OS/boot drive. Using a pair with RAID 1 and/or making sure you take regular backups would be great but I doubt it’s going to kill you if things go south and you have to recreate everything, especially this early in the game. For something really simple, you can get by with 50 GB or less, but particularly with hard drives I believe that good decisions now will save you a lot in the end.
  • Download and install 7-zip (32- or 64-bit, whatever works). Get the MSI installer version – it installs just like an EXE file but will be used again later to demonstrate automating software installs. 7-Zip s a WinZip / WinRAR alternative that’s free. The GUI for it sucks, but you won’t be using it for this and everything else about it is great. Keep the installer saved on that extra hard drive in its own little folder. In fact, go ahead and download both the 32-bit and the 64-bit versions into separate folders. Do it even if you’re completely sure you’ll never see a 64-bit system at work (I hope the opposite case is true, but regardless to learn good software deployment we want to have both versions for this walkthrough)
  • Have your Windows install discs and product keys handy, or (preferably) download them from Microsoft’s Volume Licensing site. There’s no need to burn the ISO file if you download it – you’d just be copying the data right back onto your server anyway.
  • Either have some blank CD-Rs around, or a thumb drive with at least 256 MB total space. The thumb drive will be a million times better than CDs. I regret not discovering that earlier.
  • Download the Microsoft Depoyment Toolkit (aka MDT). Get the 2010 64-bit Update 1 version. Seriously, even if you are only ever going to deploy 32-bit OSes, just do it.

You’ve now collected all the tools you need. Let’s put things together…

  1. Get your deployment server machine set up – Install the OS and updates (SP1 seems to work just fine from my experience so far), have your extra hard drive installed and formatted. Install 7-zip too, accepting default options. Don’t forget anti-virus protection, either  - you will be sharing out resources across the network and it’s a vulnerability that I’ve seen viruses exploit in my own workplace.  Optionally, bind this machine to your AD domain if it’s an option. This makes controlling access to your deployment server easier.
  2. Get your Windows install media onto that extra storage space. If you have ISO files, select them all and right-click choose 7-Zip > Extract to *\ to create a subfolder for each ISO and dump the contents to it. If you have CDs/DVDs, just start copying everything off each CD into a subfolder for each OS.
  3. Install the Microsoft Deployment Toolkit, accepting all the defaults. Remember that in the following instructions that when I say”Deployment Server or DS I’m talking about whatever machine has the MDT installed.
  4. Launch Deployment Workbench from either the Start Menu or by running C:\Program Files\Microsoft Deployment Toolkit\Bin\DeploymentWorkbench.msc – MDT is a management console snap-in, so if you’re familiar with AD management tools or Windows administrative tools the layout will be familiar to you.
  5. In the left panel, expand out Deployment Workbench > Information Center > Components. In the upper-middle section highlight Windows Automated Installation Kit (x64) and click Download in the lower-middle section. If there are any other components listed as Required, download those as well, and install them afterwards accepting all defaults.
  6. Highlight Deployment Shares in the left panel, and in the right panel click New Deployment Share. Use the following options while going through the wizard:
    1. For the Deployment share path, use the extra hard drive you added. The Folder name can be whatever you want. Chances are you’re going to have something like E:\DeploymentShare. What this does is establish the home base where all your deployment files live.
    2. The Share name is what you’ll use to connect in to access the data from step 1. For this walk-through I’m going to leave it the default, but personally I like to pick something short like DS$. In case you’re not familiar, the $ means that this is a hidden share – if you use explorer to browse to this computer from another, only shares without the $ will be listed. You should take note of the UNC path, which is just \\hostname\sharename$
    3. The Deployment share description can be whatever you want. I’m going to leave the default MDT Deployment Share name, but you might want to use something like Company XYZ Deployment Share
    4. For Allow Image Capture, Allow Admin Password and Allow Product Key, leave things default just to keep it simple. Finish out the wizard.
  7. You need to generate some boot media for your target devices. Instead of booting from a Windows install CD or a boot floppy, the Deployment Workbench will help you create custom CDs or bootable thumb drives. You will have separate boot media when installing 32- and 64-bit OSes. If you’re company uses both, you’ll need to create install media for each.
    1. In t he left pane, right-click on the Deployment Share you created (the level just below Deployment Shares with the custom name of your deployment server). Choose Update Deployment Share and accept all defaults for the wizard.
    2. In Explorer, browse to the path of your deployment share. In my case it’s E:\DeploymentShare\ – In there you’ll see a folder structure similar to what you see within the Deployment Workbench. In the Boot subfolder, you’ll find the .ISO files you just created. Burn to a CD-R by double-clicking, or right-click it and use 7-zip to extract to a new folder and follow the next few steps to make a bootable USB drive. If there’s important data on this drive, save it out somewhere first – you’re going to be erasing the whole thing.
    3. Attach a thumb drive, and then open a command prompt by typing cmd into the Start menu search bar. In the shell type diskpart. You may be prompted about elevating privileges, go ahead and accept.
    4. At the diskpart> prompt, type list disk to see all attached physical and USB drives. Identify your thumb drive based on the size and type select disk #, filling in the number for your drive. If you’re not sure about this stop now. Drive zero is more than likely your C: drive and the next step will instantly erase all partitions on that drive.
    5. Type clean to clean out partition data. This is now a raw, unformatted drive. Now type create partition primary and then active to make a partition and flag it as bootable.
    6. Type format fs=ntfs quick to format it, and assign to automatically give it a drive letter. You’re all done and you can exit.
    7. Use explorer to copy the extracted contents of your LiteTouchPE ISO to your thumb drive.

Your environment is now set up. It doesn’t look like much just staring at the screen, but you have all the right framework to deploy operating systems and software easier than ever. There’s just one last thing to do as a best-practice security measure for your server. Open up your hard drive that contains your Deployment Share. Right-click on the DeploymentShare folder (if you went off the beaten path in the previous step, this folder name might be different) and choose Properties. In the Sharing tab click Advanced Sharing… and then Permissions. Click Add… and give either yourself, the Administrators, or a domain admin group Full Control. Then Remove the Everyone group. This prevents random joes from accessing your deployment server which is important for security and to prevent end users from gaining access to your deployment media where they have the potential to wipe out their hard drive by clicking willy nilly all over the place where they shouldn’t.

Adding your first OS and Software to the Deployment Server

If you’ve been comfortable with everything up to this point, the rest is going to be just as much of a breeze. Let’s start by putting your Windows install media into the Deployment Server. In the Deployment Workbench left panel, expand out Deployment Shares < MDT Deployment Share and click Operating Systems. Remember that in your cause the deployment share might be called Company XYZ Deployment Share.

To keep everything as simple as possible, let’s keep our operating systems separated out by folder (even if you only have one OS to deploy for now). In the right panel, click New Folder and complete the wizard.  Make a folder for each OS and be descriptive in the name. Good examples are:

  • Windows 7 SP1 Enterprise x64
  • Windows 7 Professional x86
  • Windows Server 2008 R2 x64
  • Windows XP SP3 x86

After you have your folders, use the left pane to go into one and then click Import Operating System from the right pane. Use the following information to answer the questions in the wizard:

  1. OS Type: Use the Full set of source files. This means you’ll be using a stock vanilla OS. When you get more advanced you may decide to start using custom image files, but that’s a topic for another day.
  2. Source directory: Remember way back toward the start of this whole project when I had you gather your Windows discs or ISOs and copy them to folders on your extra hard drive? Well, now’s when you need them. Browse to the parent folder containing your OS, and click the “Move the files to the deployment share instead of copying them.” This will save you time and disk space, but remember if you end up deleting this OS entry you’ll have to re-copy or re-download the files again later. I’m not sure but I think if you’re pulling OS files from a network share rather than local, you won’t have the option to move instead of copy.
  3. Destination: You can leave it as default if you want. Since I’m using Win7 disks that have SP1 included, my folder name ended up being Windows 7 x64 SP1.
  4. Finish out the wizard. Notice that you might have more than one OS that’s been added. That’s because Windows 7 DVDs can include all the versions from Basic to Ultimate. Server OSes also will generate several. But XP, and Win7 Enterprise discs will just add a single entry. Right-click the new entry for your new entry, and clean up the name.  I renamed mine to be “Windows 7 Enterprise x64 SP1 – Just pick something unique that is easy to find in this list of opearting systems later. If you had more than one entry added in this step, just pick the on you’ll likely be using the most and run with that for the rest of this tutorial.

That’s it! You can repeat this for other OS install files, but your deployment server is now ripe with OS deployment goodness. But before we work on actually pushing these installers out, let’s throw some software in there.  We’re going to start very small.  Let’s go over some quick background info on how installations happen:

Most application installers come to you in the form of a .EXE file. When you run it, usually the first thing you’ll see is a quick progress bar before you even get to answer questions about what directory to install to, what the EULA is, etc. It turns out that usually a .EXE file when used to distribute files is actually a gussied up .ZIP file. That little progress bar? Yep, it’s unzipping the actual install files, and then launching the actual installation program. Microsoft created a standardized way of installing software and it’s done through the Microsoft Software Installer. On every Windows machine you’ll see in the Windows\System32 folder there’s an application called msiexec.exe. That program is the helper that presents the installation wizard, makes sure files go in their right place, that the registry updates correctly, etc. Software publishers simply take their files and settings, create a configuration file ending in .msi to tell Windows exactly what to do with those files and settings, and optionally smooshes it all into the .msi file or in .cab files to keep everything orderly. So when you double-click “7-zip.msi” to install it, you’re actually launching MSIExec.exe /install “Path\To\7-zip.msi”. If you don’t believe me, uninstall 7-zip and try installing it through MSIExec: In the start menu search bar type MSIExec /i “E:\7-zip.msi”.  Remember that your path and filename might be different, but you can figure it out. You’ll get the same wizard as before. Now let’s really blow your mind: Uninstall again, but this time run MSIExec /i “E:\7-zip.msi” /passive. You just installed automated an application installation. Admittedly they’re not all this easy, but a simple rule of thumb is that if you can automate an installation on your own machine, making it into something that can be deployed  is probably just as easy. For the full list of options, use MSIExec /?

Since we just figured out the secret to automating a 7-zip install, let’s use it as our first software deployment. In my workplace I always install it and encourage its use to get away from the old stodgy WinZip/WinRAR apps.

  1. There’s one little bit of set up in our environment, but it’s really more of a Best Practice than a hafta. Open the Deployment Workbench and go to Deployment Shares > MDT Deployment Share > Applications. Create a New Folder and name it Components. I’m not going to explain the reasoning for it in this post, but you might figure it out by the end of this tutorial anyway.
  2. In the folder you just created, make another one called 7-Zip. Go into that folder and click New Application. Use the following to answer the questions asked by the almighty Wizard:
    1. Application Type: You are using the .msi file you just downloaded, so pick Application with Source files.
    2. Details: Leave Publisher blank. For application name type 7-Zip x64 or 7-Zip x86 as appropriate. For version and language you can leave them blank but I recommend filling them in. At the time of this post, 7-Zip is on version 9.20
    3. For the Source directory, browse to the folder containing your installer and pick the option to Move files instead of copying them.  Using Explorer, double-check that the folder only contains the single .MSI file. Don’t have the 32-bit version at e:\7zip and the 64-bit version at e:\7zip\64. And make sure you do point to the folder that actually contains the installer and not a directory that contains a directory that contains the installer. No funny business.
    4. The default Destination should be just fine.
    5. For Command Details, use the following Command line: MSIExec.exe /i name-of.msi /passive. The /passive flag means “show a progress bar but don’t ask me any questions during the install.” I always prefer this over the /quiet flag that completely hides everything including the progress bar.
    6. Complete out the wizard. Your first automated installer is now ready, but first let’s get tricky. Double-click on the entry you just created.
    7. In the General tab, check the box for Hide this application in the Deployment Wizard. In the Details tab pick This can only run on the specified client platforms and in the list below check All x86 Pre-Vista and All x86 Vista and Newer if this installer is the 32-bit version, or click the appropriate x64 boxes.  These are the last 4 items listed, and the point of this is to say “Hey, this is a 32-bit app so only let it be installed on a 32-bit OS”. We’re picking these particular boxes to make it available for XP and Win7 OSes. Click OK
  3. Repeat step 2 for the other 7-zip version.  You should now have a 32-bit and a 64-bit 7-Zip installer in the Components\7-Zip folder.
  4. Now you’re going to create an Application Bundle that doesn’t hold any particular install files, but creates a list of software to install as if it were all a big single item. Go back up to the main Applications folder and create a new application, similar to before. But this time you’ll use some different options:
    1. This time pick Application bundle
    2. The application name will simply be 7-Zip. Fill in the version number and complete the wizard.
    3. Go right back into this bundle by double-clicking it. In the Dependencies tab, click Add, and (one at a time) add each 7-Zip installer from the Components folder. Then click OK.

You’re all set! You don’t know exactly how it will happen yet, but I can tell you that with this set up you’ll simply have to pick “7-zip” to install, and the correct x86 or x64 version will be put into place.

So now we’ve got hardware and software loaded into this stuff – can we finally get the part where we actually use the deployment server?  Well…  almost.  One last important section to look at: “Task Sequences”.  Task sequences are little mini-wizards that we run on client machines but are prepared on the server. It’s a questionaire that asks: “What OS do you want to install, what software do you want, what should the computer name be, etc?” . Follow these steps to set up a simple task sequence:

  1. In the Deployment Workbench left-hand pane go into Task Sequences and pick New Task Sequence. Use these Wizard settings for the “General Settings” page:
    1. Make up a Task sequence ID. I like to base mine off the OS I’m installing with it, but you have limited space. I’m using WIN764ENT because I want this task sequence to deploy the Win7 Enterprise OS I added earlier.
    2. For the Task sequence name, use Deploy Windows 7 x64 Enterprise from Disc, but change the Windows version to whatever you’re using. The word Deploy is important because later you might add tasks that don’t deploy an OS but just add software or do other things (the sky is the limit really). And the “from Disc” part is important in case you get more advanced and want to make a custom image of Windows with updates and software pre-installed instead of the stock image that comes with the official media.
    3. In Task sequence comments, put something like Last Modified On with the date. If you get a lot of task sequences later on, sometimes it gets hard to keep track of what the newest one is.
  2. In the Select Template section, use Standard Client Task Sequence unless you’re installing a Server OS in which case use Standard Server Task Sequence.
  3. Pick the OS you’ll be deploying, with one exception: for XP or Server 2003 you need to put in your product key and select the bottom option
  4. Fill out the rest as desired and complete the wizard.

Holy crap, you’re done preparing the server! We’re on the home stretch now.

Deploying your OS and Software

Time to get ahold of a victim machine and load an OS. Make sure to back up any important data on this target machine first – The primary hard drive is going to be erased. To keep things simple I recommend making sure only one hard drive is attached. If you can format it before hand or use a new/blank drive even better.

I’m not even going to detail out the steps to do the deployment – it’s so easy! Just check the following things on this target machine:

  • It’s connected to the same network as your deployment server
  • You have inserted either the burned CD or the USB drive we created earlier, and configured it to boot one time off this device.
  • After you boot up, you should see Windows loading and eventually end up looking at a wizard. At this point, remove the boot CD/USB dongle – otherwise, after the OS installs and the system restarts you’ll get a weird error because you were supposed to boot into the newly installed OS and not the custom boot media.
  • Use your best judgement in answering the questions asked by the wizard

Troubleshooting

If you end up needing to do some troubleshooting, here’s some starting points:

  • Network Drivers – If your custom boot media doesn’t have the necessary drivers, your deployment will not work. Here’s the rule of thumb: If you can install Windows 7 off the install disc and the network driver works without doing anything custom, then this deployment server should work fine too.  But if it won’t take those drivers and add them to the deployment server. In the Deployment Workbench, go to the Drivers section and choose Import Drivers. You’ll want to point to a folder containing the .INF file (plus all the other required files for this driver) which means if stuff is hiding in an .EXE file you’ll first need to use 7-zip to extract them out. After adding drivers, right-click your deployment share within the Deployment Workbench and choose Update Deployment Share. Accept all the defaults, but you’ll need to reburn your CDs or recopy your USB drive files to get the updates.
  • Storage Drivers – This mostly applies to XP, but if you are using RAID, AHCI or other special hard drive configurations, you’re might have some trouble. Make sure to add these drivers in the same way that you’d add network drivers. I’d recommend disabling RAID/AHCI until you can get the deployment to work without it.
  • IP Networking – If you don’t have a DHCP server, the deployment wizard that you run on your target computers needs to know what you want your IP address to be. There is a button toward the beginning of the wizard that will let you set your IP.
  • DNS Networking – If you’re on a domain, or have an advanced network configuration, you might need to help your boot media locate the deployment server. In the Deployment Workbench, right-click your Deployment Share in the left pane and go to Properties. From there go to the Rules tab and click “Edit Bootstrap.ini” toward the bottom. Notepad will open and you’ll see a line that starts with DeployRoot=. Change this line to either reference your IP address or the fully qualified domain name. So for me I might change it to DeployRoot=\\192.168.1.117\DeploymentShare$ or DeployRoot=\\TSZ.mydomain.com\DeploymentShare$. After making changes and saving them, update the boot media as if you were adding drivers, but make sure to pick the option for Completely Regenerate Boot Media in the Update wizard. Don’t forget that you have to re-burn your ISOs or rebuild your USB drives.