Now we’re down to the last of the building blocks.   One of the more important ones to be honest.   It’s called Dependencies.

Now in all fairness if you DON’T care about the order the applications go in and DON’T care if your Service Packs and updates are installed WITH the applications you can skip Dependencies.  But after having done a little Deployment I’ve learned to appreciate them.

Let’s try a simple scenario.   You’ve got an application that can only install IF Outlook is already installed.  Maybe you would prefer the Antivirus is the last thing installed.   Or maybe (just maybe) you WOULD like to have the newest Service Pack for Office installed AS you deploy the operating system. 

Just cuz.

Those are Dependencies.   They’re not actually difficult, they’re just overlooked many times and forgotten, because to be quite honest we got over the hard part of getting things to install themselves.   “Meh!  What’s a simple service Pack?   It’ll only take 15 minutes to do afterwards.”

That’s right, only 15 minutes.  Or maybe it’s only a 2 minute hotfix? 

Multiply that by even three computers and setting up a Dependency will eliminate that time already.    And remember, this is not a “one shot deal”.   Because the MDT environment we’re putting together is very much like a box of Legos where we can build something new by selecting different pieces; this time you spend now can be used on multiple different sites and images.

Dependencies are a part of your Applications.   So in our present environment I have download and imported into my MDT 2010 setup something as simple as the “Junk mail filter” update for Outlook 2007.  I’d like to ensure that as soon as my users get Outlook 2007 they can immediately have the best possible protection against all the “Free stuff” the internet is offering.   I’d like to offer them as few “Investment opportunities” as possible.

So in this case our Junk Mail filter “Depends” upon the install of Outlook happening first.   To ensure this occurs we establish a Dependency within the “Junk Mail Filter”


So right click on the entry for “Microsoft Outlook 2007 Junk Mail Filter April 2011” will pull up it’s properties.  This should be familiar it’s the same way we edited the application for a Silent Install.   We’re now choosing the “Dependencies” tab which will open up and be not so impressive looking.  That’s because we haven’t added any yet.


So clicking on “Add” will allow me to browse my current imported Applications structure within MDT 2010 and select an application this Depends upon before it’s allowed to install.

In this case I have browsed to “Microsoft Office 2007 SBE” and clicked ok.  I COULD keeping repeating this process and establish (That for whatever reason has twisted my mind) that Adobe Flash Player 10 must be loaded as well before the Junk Mail filter is applied.  Because (as well all know) “Flash” is the root of all evil and viruses.  So “Obviously” if Flash isn’t installed you’ll get no viruses.

No?  that’s not true?  That’s good because I completely made that bit up.   But we can establish MULTIPLE dependencies if so needed before an application is allowed to install.  Just be adding them to the list


Now you’ve done a BASIC simple Dependency.  The process is pretty simple.

But what if you need to be more complex?   Say you’re installing Office 2007 and would like to have 35 updates, Service Pack 3 for Office 2007 as WELL as the most current Junk Mail filter?

Well THAT is a PERFECT example of an Application Bundle.

Do you remember back when we first imported an application we had an option to choose “Application Bundle” which had no Command line?   An “Application Bundle” is really just a predefined list of Dependencies.   If you were to import one into your list of Applications and call it “Microsoft Office 2007 – All the Bells and Whistles” , you would have with you a single Dependency list.   This list as an ENTITY is treated (when we get to Selections) as a SINGLE APPLICATION (including all the hotfixes and whatever else is in your dependency list)

Take note as well that when working dependencies you CAN move entries up and down the list to make sure a specific order happens there.

Now here’s a final piece on Application Bundles.    Think of them as a template for how you’d like Application configurations (At the Service Pack level) to be applied.  Let’s just say you’d like to have Service Pack 3 for Office 2007 applied for one Division, but Service Pack 2 for Office 2007 applied for another division.  (Ok, I don’t know WHY you’d want to do this.  Perhaps you had some leftover been burritos last night and it SEEMED like a good idea).

If you place a dependency directly on an application itself it will ALWAYS apply.  If you place it within an Application Bundle, then it applies only when you want it to.

So all this prep work.  All this effort.   Soon we’ll see where all this is taking us. 

Next up? We begin to make a real image!   We create a TASK SEQUENCE