I got my first job as an SMS Administrator over 16 years ago. At that time we had just upgraded to SMS 2003 from SMS 2.0. Back then when we wanted programs to install in a given order we chained them together using the option to run another program first on the requirements tab of the program. A few years later, in SCCM 2007, Microsoft released this cool thing they called “Task Sequences”.

I remember being on campus in Redmond once and a MS employee saying to the group of MVP’s there, “I know you guys think you can cure cancer with task sequences”. The point of that comment was that Microsoft created task sequences without having envisioned many of the creative ways that SCCM Admins would use them. A tool that Microsoft designed to be used for operating system deployment was quickly adapted to do so much more. So much so that back in 2008 or 2009 publicly predicted in SCCM 2012 the task sequences node would no longer be under Operating System Deployment. Guess I got that one wrong.

Based on the title of my blog you may be asking yourself if you missed some major announcement. Has Microsoft truly added task sequences to Intune? Well no, they have not. Not only do we not have task sequences in Intune, we have no way at all to control the order in which things happen.

Those of use who’ve been control freaks in SCCM for a very long time yearn for the ability to be the same control freaks in Intune. Many use this lack of control as a reason to shy away from adopting Intune.

Even if you’re not one of those control freaks who wants this level of control just because we’ve always had it if you haven’t already run in a case where you need to ensure that action A always happens before action B you will at some point.  

Something else us old guys used to do back in the day was to use wrappers. See back then vendors who wrote the majority of software we wanted to deploy had never even heard of SMS. Those guys had no idea that we could install their software on 1000’s on PC’s without sending a Technician with a CD to each and every desk. I’m not going to go in to great details here about all then various tools that were used as wrappers back then, but there’s probably someone of you who’ve never even heard the term before. There’s likely even some of you who’ve never had to repackage an app so that it could be deployed from SCCM. Frankly I was never good at it, I don’t think many of us were. The guys who were good at it, those guys were a special breed of expert. “Packagers”, were guys used tools like Admin Studio, Orca, and SMS Installer and that’s all they did. As the software vendors realized the benefits of .msi installers and as customers demanded that apps ship as msi’s we had to repackage less and less apps. I don’t think I’ve had to have one done in over 10 years now.

Welcome to 2019! Intune is all the rage! We’ve got pointy haired Managers coming to us telling us that we need to “move everything to the cloud” no matter what functionality we lose. One of the major ones that we lose when we go to Intune for software deployment is that it is much less robust than SCCM when it comes to deploying apps. And I’m using the term “apps” VERY loosely here. An app could be anything from a line of business app, to a script, a file that needs to get copied to every computer, a shortcut, a screensaver…. you name it and we’ve deployed it from SCCM.

My typical blogs are short, sweet and to the point. If you are still with me that’s awesome because for once I felt like I needed to provide some backstory to explain why I think this blog may be useful. Or if you are like me when I read, you skipped all the crap above and you’re just looking for the technical stuff I’m getting there. I’m going to show you an old trick that can be used to solve a new challenge.

In this incredibly crude example I will show you how to use Advanced Installer (which I’ve chosen because it’s cheap and one of the easier tool to use) to copy a bunch of files to a PC and then perform actions in a given order. If you missed it above when I said I was never very good at this it may become apparent soon. This blog is not meant to be a simple step-by-step guide on how to solve a given challenge. Instead it’s me showing you that not all of your Intune fears are justified and how, with a little creativity, you can work around some things.

I’ve created a folder that contains a crude batch file and a subfolder. In the subfolder I have a few installers and some other things that I want to do one new PC’s. For instance I want to installer Acrobat Reader, then install a patch for Acrobat reader followed by setting a reg key that disables protected view.

Here’s what the tree looks like when I grep it.


And my batch file looks like this:


Obviously deploying my batch file along with the supporting files is not possible natively with Intune but it’s very easy with Advanced Installer. I simply create a new project, and add my entire source folder as a temporary folder.


Next I create a custom action to launch a file and point to my batch file.


Next with the click of one button I build my .msi



When run my msi will extract the files and folder to a temp directory and then run my bat file. Notice when I built my msi I selected to have it not register with Windows installer and to wait until my custom actions finishes before completing.

And that’s all there is to it. I’ve just deployed several files and folders as a single msi from Intune and I was able to control the order in which things happened through my batch file.

The possibilities of what can be accomplished using a wrapper and someone who actually knows how to use them are endless. This was just a crude example to get you thinking about what you need to do and how you can do accomplish it.