Blog Posts tagged with Software Deployment

Ask a question

The Grand Quest

I work at a University and we have something like 15 main softwares that are included on our "Gold" Windows 7 Images. After that there is a long tail orf probably another 40 or 50 softwares that are installed on only a handful (sometimes only 1) of machines.

I look forward to bothering all of you people quite often as I attempt to create a customized silent installer for as many of these titles as possible. :D

Currently I include as much software as possible on the Gold image, and then capture the .WIM for that system which is then included in a win7 Source CD which is deployed from the K1 with scripted installs.

Of course this doesn't work out for all of our needs, and so I end up created other custom scripted installs, or less frequently have installed the needed software as a post-installation task.

I would like to get to the point where I install most of the softwares as a post-installation task as it increases the ease in maintaining the software.

And thus ends this random brain-dump, thanks!

View comments (5)

VBScript to Kill a Process

This worked great for me. Just use as function and kill as many processes as you like.

For more such stuff regarding packaging, visit my blog and follow it for more updates:



KillProc "abc.exe"

Sub KillProc( myProcess )    

Dim blnRunning, colProcesses, objProcess    

blnRunning = False    

Set colProcesses = GetObject("winmgmts:{impersonationLevel=impersonate}").ExecQuery( "Select * From Win32_Process", , 48 )    

For Each objProcess in colProcesses        

If LCase( myProcess ) = LCase( objProcess.Name ) Then             ' Confirm that the process was actually running             blnRunning = True             ' Get exact case for the actual process name            

 myProcess  = objProcess.Name             ' Kill all instances of the process            


 End If    


 If blnRunning Then        

Do Until Not blnRunning            

 Set colProcesses = GetObject("winmgmts:{impersonationLevel=impersonate}").ExecQuery( "Select * From Win32_Process Where Name = '"& myProcess & "'" )            

WScript.Sleep 100 'Wait for 100 MilliSeconds            

If colProcesses.Count = 0 Then 'If no more processes are running, exit loop                

 blnRunning = False            

End If        


End If

End Sub

View comments (5)

Automatically Deploy Software Based on AD Membership

I have figured out a way using current LDAP label behavior to install software automatically on a computer according to a user's group membership in Active Directory.

Example: A new employee started this week and you need to have Adobe Reader installed on their computer.



1. Create a group in Active Directory (AD) called "Software Adobe Reader". This will be a group of all users that have Adobe Reader installed.

2. Create a normal label in KACE and name it "Adobe Reader Install". Put some notes in the "Notes" field so you don't forget what this is doing. Select the checkbox for 'Computer Inventory' and 'Software' and leave the rest blank.

3. Create a LDAP label in KACE and choose the Associated Label Name "Adobe Reader Install" which you just created in step #2. Follow the example LDAP label configuration below. After this LDAP label is created it will be looking to the group "Software Adobe Reader" in AD. This LDAP label checks if the user is a member of the group "Software Adobe Reader" in AD, and if they are, it applies that LDAP label to their computer.

NOTE: LDAP labels cannot be applied to users, only computers. This means that your user list under Service Desk > Users cannot have LDAP labels applied to them according to AD membership. This is because users don't sync with KACE, computers do. I sure wish it would work though!

Example LDAP Label Configuration:

Server Hostname: YourServerName/IP

LDAP Port Number: YourPort (example: 389)

Search Base DN: DC=YourDomain,DC=com

Search Filter: (&(sAMAccountName=KBOX_USERNAME)(memberOf=CN=Software Adobe Reader,OU=SoftwareDeploy,OU=IT Department,DC=YourDomain,DC=com))

LDAP Login: CN=kaceldap,OU=Users,DC=YourDomain,DC=com (or wherever your account is to your LDAP authentication account)


Visual of above, albeit kinda small...

4. Apply the normal label created in step #2 above to a script or MI so that that task will be ran on that computer when it has that label.



In Active Directory add the new employee to the AD group "Software Adobe Reader". The next time the computer the new user is using checks into KACE it will get the LDAP label "Adobe Reader Install", then the script(s)/MI(s) will run since the label "Adobe Reader Install" is now applied on that computer and is also associated to the script/MI.

View comments (4)

KACE: Microsoft App-V integration scripts for the K1000 now available!

Wanted to let everyone know about some scripts that are now available for the K1000 that you’ll find of interest if you are using, or considering using Microsoft App-V for application virtualization.  Best of all, you can download them here, now and at no cost!

These scripts allow you to manage Microsoft App-V sequencing and deployment directly from your K1000 console in the same manner you deploy all traditionally installed software applications.  To be clear, it does not replace any Microsoft App-V licensing or software (you still need to be compliant and have the software installed on each machine), but this does allow you send software images from either a DVD or network share to the MS sequencer and deploy that sequenced image to your client machines directly from the K1000 interface.  In addition, K1000 inventory will include all App-V installed applications from each machine, right next to all of your traditionally installed software applications. So if you are a K1000 customer that wants an easy way to sequence, deploy and track App-V applications, these scripts are for you!

You can download these scripts and a User Guide for setup HERE.  The guide will walk you through importing and setting up / executing the scripts to help manage your App-V environment!


For more information on Microsoft App-V and whether it might be a good fit for your organization, visit Microsoft's App-V home page.


We hope you find these scripts helpful!  Let us know what you think!

View comments (1)

A General Approach to Software Packaging – Starting from consistent installer analysis

The goal of this blog post is to provide people who need to provide silent installers for softwares with a general framework on how to approach this process. I often run into posts on IT-ninja, and Appdeploy before that, along the lines of ‘how to silently install this or that software’, that could easily be answered if the poster had a general approach to creating silent installations.. While I realise seasoned packagers will find alot (if not all) of this stuff to be trivial and self-evident, I still believe it has its value in teaching people a good packaging methodology.

I myself am what you might call a software packaging veteran, having been active in the field pretty much continuously for the past 9 years. During this time, like many of my colleagues, I’ve developed a standard approach in analysing installers. While posting this might cost me some much-coveted Ninja-points, I still think it might be appreciated :-)

This post will be mainly geared towards MSI packaging. While I am well aware of the advent of software virtualisation technologies like app-V, I still believe it worthwhile to focus on MSI in this post for a number of reasons:

  1. While some might deny this, MSI will be around for a while yet. There are still a number of inherent limitations to software virtualisation, specifically App-V,  that will make the use of (complementary) MSI packages necessary. Most notably I’m thinking about drivers, context menu’s  and yes, Office applications
  2. I absolutely believe in the future of App-V, but would like to stress that many of the principles of MSI packaging can and should be adhered to in App-V sequencing, even if a case could be made that App-V is more forgiving to ‘quick and dirty’ packaging, but that does not have to mean I like it…
  3. Continuing on the last point, MSI packaging will remain a more labor-intensive job when trying to build silent, customised installers.
  4. Even when building a virtualised package, a well built or customised MSI can be an easy starting point.

Generally speaking, when analysing an installer, 3 phases can be distinguished in the process:

  1. Analysing required customisations: What exactly is it that the customer wants the install to look like? Is it a pretty much standard install, or are heavy modifications required? One should always remember packaging is a customer-oriented activity, and the whole process should start with a detailed description of exactly how the customer wants the software to be installed.
  2. Analysing installation executables, keeping in mind the requirements from step 1: Now that we know what to change, what is the best way to implement this change? What is the core install source (MSI, Executable) and to what extent can the customisations easily be passed to these installers?
  3. Customising the installers with either install parameters or transforms

The focus of this blog post will be on step 2, and to a lesser extent on step 1. While I will give a couple pointers on how to customise efficiently, this is very case-by-case, and it is my belief that a consistent method of installer analysis will make this more streamlined as well.



As stated, we will always go looking for MSI’s, whether they ARE the actual source installer, or are CONTAINED within the installer executable. To this end it is always advisable, if the installer is not natively a (vendor) MSI, to run the installer exe, and keep an eye on the system during this installation. First step I take is to try and open the exe in WinRAR, it might just be a self-extracting archive, and the MSIs might be just that easy to find.. If that does not work run the installer with /? and pray for an extraction parameter that gives you an MSI, final action is to monitor the installing user’s %TEMP% and %APPDATA% folders while running the exe.  In about 95% of cases, if not more, any msi contained in the installer will be extracted here. If so, grab it!! If not, we move on…



We haven’t found an MSI… damn… now what? This is when we go looking for command line parameters to the installer. Keeping in mind the customisations we want I’d suggest doing the following:

-          Look at the package KB on IT-Ninja for a list of parameters. There might even be one to extract an MSI after all, although, if you got past the previous paragraph, this is usually not the case. Second stop is the vendor website. If neither provide parameters, we might be stuck repackaging the installer.

-          Now the choice becomes whether or not to snapshot the install and build an msi ourselves. This can be avoided if ALL the required changes can be leveraged through command-line parameters or simple enough script statements (copying settings files for example). To me snapshotting is still an option in this case, since you will get increased control of what the installation does to the target machine, but this is where TIME constraints come into play, since tailoring a snapshot MSI generally takes longer than collecting the required command-line parameters.

-          If all the above does not pan out, we’re basically stuck snapshotting the installation and creating our own MSI

So now we either have a simple enough set of command line parameters for the setup executable, or we will be working with an MSI, either of our own making or provided by the vendor. Let’s quickly run through some basic priciples for the latter case


-          When changing vendor MSIs, ALWAYS use transforms!! Why, do you ask? Well, in order to be able to maintain the ability to call on the vendor for assistance when building the installer, you’ll always want to hold on to their core installer. Otherwise it will become too easy for them to say you ‘messed up’ their installer, and they won’t help you. I know it sounds silly, but it happens, trust me. Also a transform is the most easily revertible means of modifying the installer.

-          NEVER REPACKAGE AN MSI. For basically the same reason as above, and the added reason of being able to implement possible future patches. Repackaging an MSI is actually far worse than changing it without a transform, so beware!!

-          Change AS LITTLE AS POSSIBLE  in transforms. While tools like Adminstudio’s InstallTailor will show you what changes are made to the properties of an MSI during an install, I tend to consider this a starting point only. Often during install a number of properties in the MSI are changed that are not strictly needed. Try to filter these out and leave them alone.

-          Analyse the installer’s DIALOGS: in order to identify exactly which properties you want to change, it is often useful to look through the MSI’s Dialog and Control tables, trying to link textboxes, radiogroups etc to the specific properties they change. Good thing here is it can actually be done without access to a complete packaging IDE, using just Orca or InstedIt.

-          When snapshotting, CLEAN UP!!  Only include changes relevant to the application in question, take out everything else. This is also where good exclusion lists are paramount, as well as, I hate to say, experience. Learn to distinguish the gold from the rubble. When not sure, take a stepwise approach. Try to exclude something and see if the application still works, but make a backup just in case..


Another point  I’d like to make is you always want to be aware of the possibility that the setup that contained an MSI, might actually be doing more during the installation than just installing these MSI’s. If you ever run into problems just running the MSI(s) contained in a setup, be prepared to do a so-called GAP CAPTURE. The principle behind this is as follows:

1)      Install the vendor msi, with any transforms you made

2)      Start your snapshotting tool of choice

3)      Run the setup.exe over your MSI

4)      (Run the application for the first time, there might be some settings done here)

5)      Stop the capture and look at the result

This might allow you to detect a number of extra actions that sneaky setup did, that you were never aware of. Or some settings that are done by that pesky application at first startup, that you just did not capture in your snapshot. Generally speaking, including a first startup of the application while snapshotting is a good idea, though not always necessary.


Many seem to fear these packages. Me, I like em…

My general advise would be to ask yourself 2 questions

1)      Do I need more than just the driver for a piece of software?? While often a load of extra stuff gets installed, you might just need a driver. If this is the case, just look through the sources of the installer for the INF and CAT files, and make a package (using DifxAPP) to install them. An excellent blog post on this can be found here: http://www.itninja.com/blog/view/driver-installation-from-an-msi-using-microsoft-difx


2)      Are the drivers signed?? If they are not, try to get a signed version off the vendor, or if that does not work, SIGN THEM YOURSELVES. In today’s desktop world it is just no longer viable to work with unsigned drivers. There is an excellent guide on ITNinja on how to selfsign drivers here:  http://www.itninja.com/question/guide-to-signing-unsigned-drivers


So, that’s about it. While there is undoubtedly a lot more to cover, I think this a good start. Further topics can afterall be covered in later posts




View comments (4)
Showing 11 - 15 of 411 results

Top Contributors

Talk About Asset Management