Years after years, projects after projects, you come to realize that some of your tasks are always the same. Instead of getting bored let’s take this opportunity to automate !!!
Today we will try to put away many of the lousy aspects of application deployment in MDT. For this purpose, I created what application packagers like to call “a launcher”. If you don’t have much ideas about how this tool can help you, I will demonstrate some use cases that should please anyone who felt loosing his time creating applications in MDT.
Logging
Your customer just gave you the apps that you should integrate to the deployment but some programs are just batch, EXE, MSI, vbscript or Powershell.
the easiest way to get around that mess is simply to do nothing !… You’ve got a Install.cmd to launch, no problem ! Just create an MDT application and fill the command box with Install.cmd and you’re done !…
Well.. you could argue that it will works (and for sure it will), you could also say that’s it’s a fast way to get things done (It’s the fastest, if you ask me), but as an IT pro you should be able to tell your customers a bit more that “ I guaranty it has launched !!” and this is where this technic fall short. I’m not saying that I can magically make any script more reliable, surely not, but wouldn’t you buy something that fairly increase the amount of logging without adding any complexity or amount of work automatically ?
Here is how you can do it by adding the application launcher like this :
Cscript.exe Install_Application.wsf /app:”MyApp.cmd”
With this small addition, you instantly get access to some extra MDT logging where you can see what commands were exactly launched, what was the current path, what was the return code ! Plus, the log will resolve ‘install.cmd’ to ‘PDF creator version 1.7.3’ (The name of the app that Install.cmd installs) for maximum readability:
You also have access to the console log where you can see how behaved every commands from your batch file :
Yes, that’s a lot of goods at no cost, but the benefits will be even bigger when you’ll need to troubleshot a failed app installation !
And of course you can obtain the same amount of detailed information from an .MSI, an MSU or an MST installation with the very same command !
Powershell support
Powershell is on every mouth and MDT is no exception, but something that you may not know, is that Powershell works only as a step in a task sequence, not as a stand alone application.
Wouldn’t you love to be able to launch Powershell script as an application without requiring trickery or complex command line ?
We have you covered ; simply set your command like this :
Cscript.exe Install_Application.wsf /app:”MyPsScript.ps1”
and we will take care of the correct execution of the script, we will even allow you to access the whole MDT properties out of the box to beef up your Powershell scripts .
Launching x86 or x64 Application accordingly
Best practices for deploying x86 and x64 version of an applications to the right platform as always been to create 3 apps: one per architecture, plus a bundle…. Oh God can’t we have something much easier to manage ?!…
Yes we have, here is our take on that matter: throw down your x86 and your x64 applications in the same folder, use the same name for both files minus their respective architecture like this:
and let our launcher decide !… don’t even lose your time telling it the full application name, a few letters will be enough ! Sounds crazy to you ?… Get it for real with this simple command line example used to deploy Internet explorer 11:
Cscript.exe Install_Application.wsf /app:"IE11" /args:"/passive /norestart /update-no"
What will happen behind the scene ; Application launcher will analyse each files names that contains the string “IE11” and if it also found an “x86” or an “x64” string in it, will select the one that match the OS architecture !
Key benefits :
- One app. fits all !
- ‘Out of the box’ Architecture management
- So much easier to maintain
Common extension handling
If your application is an .EXE, .BAT, .CMD, .REG, .PS1, .VBS, .WSF, .MSI, .MST, .MSU or MSP we know how to launch it silently for you, we even enable logging switches when they are available.
- .MSI files are launched with /I /qb /l* MydefaultLogPath\mylog.log
- .MST file found in the same place as an .MSI will be launched within the MSI with /I TRANSFORMS=MyMSTFile /qb /l* MydefaultLogPath\mylog.log
- .MSU files are launched with /quiet /no restart /log:MydefaultLogPath\mylog.evtx
- .MSP files are launched with /p /qb /l* MydefaultLogPath\mylog.log
- .EXE files are launched with /S
- .CMD and .BAT files are launched with > MydefaultLogPath\mylog.Log 2>&1 to capture console output
- .PS1, .REG, .WSF and .VBS are launched with their corresponding interpreters.
So the only thing you need to specify is the application’s executable name:
Your .EXE needs a /Q argument instead of the default /S ? No problem, specify your own parameters with the “/arg:” switch:
Cscript.exe Install_Application.wsf /app:"IMyEXEApp" /arg:"/Q"
Yes, it would have worked without specifying the extension of the application file !
And yes, it would have even worked without typing the whole file name !!
Application detection is backed with a regex function that can find your executable even if you’ve only specified 3 letters ! Of course, as long as those 3 letters can uniquely identify the app…. Love it ? … wait, there is more…
Multiple application launching
Sometimes installing an application means installing two or three different components. Regular method with MDT would be to create separate applications and pack them into a bundle. Another way to do it could be to write a script. But both solution include manipulations and time… Would you want something easier to manage, something faster to put together ? Yes everybody want this ! Here is how we have simplified the process to a single line with this example of Oracle VirtualBox Additions:
This app. install in two steps, first a certificate needs to be registered with the command VBoxCertUtil.exe -v add-trusted-publisher oracle-vbox.cer , then the tools can be installed with VBoxWindowsAdditions-x86.exe /force /S .
As you can see this is an x86 application ! An x64 version also exist in the same folder but no worries, as we’ve seen before, we can take full benefits of the launcher to install the right executable on his dedicated architecture.
So how do we pack all that stuff together ?
Like this:
Cscript.exe Install_Application.wsf /app:"CertUtil,WindowsAdditions" /arg:"-v add-trusted-publisher oracle-vbox.cer,/force /S"
let’s dive into details : the ‘app:’ and the ‘arg:’ switches have something special here, they are both split by a comma. this means that the first argument from the ‘app:’ parameter will be launched with the first argument from the ‘arg:’ one and so on.
we also used partial naming described earlier so the first set of arguments (“CertUtil” and “-v add-trusted-publisher oracle-vbox.cer”) will start VBoxCertUtil.exe -v add-trusted-publisher oracle-vbox.cer
The second set (“WindowsAdditions” and “/force /S”) will fire VBoxWindowsAdditions-86.exe /force /S or VBoxWindowsAdditions-amd64.exe /force /S according to the underlying OS architecture.
absolute sweetness !!!!
Custom Actions
Some of you may argue that the tool is too generic to avoid scripting, it becomes useless if some checks to the registry key need to be performed or if some additional files should be copied before or after launching the application ?!
Not that time guy, the script has been carefully designed for allowing custom actions to proceed just before the installation and just after it succeeds or fails.
For this purpose, you can safely edit APP-Custom_Actions.vbs and fill up one of the three functions according to your needs :
- ActionsBeforeInstall
- ActionsAfterSuccessfullInstall
- ActionsAfterFailedfullInstall
If for some reasons you need to modify the full command line dynamically or need to know the version number of the application, everything is in the box !
While processing, the application launcher outcast a bunch of MDT properties that you can use directly inside the three functions
- oEnvironment.Item("AppName")
- oEnvironment.Item("AppPublisher")
- oEnvironment.Item("AppVersion")
- oEnvironment.Item("AppComment")
- oEnvironment.Item("AppLanguage")
- oEnvironment.Item("AppExtension")
- oEnvironment.Item("AppFullName")
- oEnvironment.Item("AppFullPath")
- oEnvironment.Item("AppFolderPath")
- oEnvironment.Item("AppCommand")
The values look like this:
If for example you need to copy a file from the application directory to C:\Progarmdata after the application was installed, fill out function ActionsAfterSuccessfullInstall like this:
Function ActionsAfterSuccessfullInstall
'Copying Active Setup file
oFileHandling.CopyFile oEnvironment.Item("AppFolderPath") & "MyLicence.txt", oEnv("AllUsersProfile") &"\MyCoolApp\", 1
End Function
To make you even more productive, APP-Custom_Actions.vbs is already populated with some code examples of the most common actions you can think of, like copying/deleting a file/folder, adding/removing registry entries etc…
How to install
Now that you’ve got a strong feeling that this application launcher will save you tones of time, you may want to know how to install it, here is how:
Download this archive and place files Install_Application.wsf and APP-Custom_Actions.vbs in every application’s folder you want to manage in you deployment share.
In the MDT workbench, edit application’s settings and set the Version field in the general Tab
Other field like Publisher or Language can also be filled for a greater level of reporting information (think logs or registry tatoo) but they are not mandatory contrary to Version.
In the details tab, edit the Quiet Install Command with this syntax :
Cscript.exe Install_Application.wsf /app:"MyApp1,MyApp2…" /arg:"/arg1A /arg1B.., /arg2A /arg2B…"
/app:"MyApp1,MyApp2…"
This switch is mandatory and should at least contains one application name. Application name can be a least 3 continuous letters from the executable name, up to the full name with extension.
The executable name is retrieved with regex until an extension is specified, it is then retrieved literally.
The ‘app:’ argument must be surrounded by a single pair of double quotes, that means that even with multiple applications specified, only one opening and closing double quotes should exist.
Multiples applications can be specified, they should be separated by a comma, application’s naming follow the same rules as described above ; one app can have a full name while the next one can have only few letters.
/arg:"/setting1A /setting1B.., /setting2A /setting2B…"
This switch is optional, but when specified, supersede default application’s parameters described in Common extension handling section.
An argument is a set of parameters like "INSTALL_SILENT=1 EULA=0 REBOOT=0 SPONSORS=0"
if the ‘app:’ switch has multiple applications, you can specify a set of arguments for each application. Each set must be separated by a comma, if an app does not require augments, you can escape to the next one by adding an ‘empty’ comma like this: "INSTALL_SILENT=1 REBOOT=0,,/qb /NoRestart"
The ‘arg:’ arguments must be surrounded by a single pair of double quotes, meaning that even with multiple sets of parameters specified, only one opening and closing double quotes should exist.
Some properties should also be defined in the customsettings.ini to allow the application launcher to work :
The most important one is EventShare, as application launcher rely on MDT events. The easiest way to set it, is to create an Events folder inside your deployment share with write access permission to your MDT account. and to add the pass to EventShare property in the customsettings.ini file :
EventShare=%DeployRoot%\Logs\Events
Some optional properties can also be set to
- tatoo each application’s information into the registry.
- Change some default Log path.
As those properties are not part of MDT, they first need to be defined at the beginning of the customsettings.ini file in the [settings] section :
Properties=AppRegInfo, AppLogInfo
AppRegInfo allow to specify the registry path where appliction’s information will be written:
AppRegInfo=HKEY_LOCAL_MACHINE\SOFTWARE\OSD-Couture
Each app will then store the following information:
AppLogInfo allow to specify a custom log path for the following extensions: .MSI, .MST, .MSU, .MSP and .CMD. If the property is not set, logs are saved in %Windir%\Logs\Software:
AppLogInfo=%DeployRoot%\Logs
Golden Rules
Usage of Application launcher is easy as soon as you know well enough how it works. For this purpose i have written a set of rule that cover every situation where you can get into trouble:
- Breaking any of those rules will break the application launcher and installation will not proceed.
- If your application executable has an “x86” string in his name, the application launcher will assume it’s a true x86 application and will require an x64 counterpart application with the same base name (plus an “x64” or “amd64” string replacing the “x86” of course !).
- If your install application has an “x64” or “amd64” string in his name, the application launcher will assume it’s a true x64 application and will require an x86 counterpart application with the same base name plus an “x86” string in it.
- If an .MST file is found in the same folder as an .MSI, application launcher will automatically associate them and launch the .MSI with a “transform” option pointing to the MST.
- If an .MST file is found in the same folder as an .MSI with an “x86” string as part of the .MSI name, the .MST file must also have an “x86” string as part of his name. Application launcher will automatically associate them and launch the .MSI with a “transform” option pointing to the MST. Rules 2 and 3 also applies.
- If an .MST file is found in the same folder as an .MSI with an “x64” or an “amd64” string as part of the .MSI name, the .MST file must also have an “x64” or an “amd64” string as part of his name. Application launcher will automatically associate them and launch the .MSI with a “transform” option pointing to the MST. Rules 2 and 3 also applies.
- If your install application and another file from the same folder share the very same name with different extension, full name with extension must be provided to the “app:” switch.
Enjoy lazy admin life style and keep on deploying !