A couple of weeks ago I came across a vendor setup I was trying to install silently. I identified this as an Inno Setup by finding the uninstall command line in the registry being unins….exe /SILENT.

So trying the /SILENT switch worked on the installation worked fine except that the nested MDAC 2.6 installation wasn’t using an unattended switch, so it would still require a click. I tried installing MDAC beforehand, but the installation still behaved the same waiting for a click. I could have captured the installation of MDAC along with the rest of the installation, but I prefer to install this type of standard prerequisite with the vendor’s standard setup, so I attempted to find some way to dig into the Inno Setup.

I found an Inno setup unpacker called innounp, which extracted the installation. I also downloaded the latest version of InnoSetup so that I could view and compile the installation. What I ended up doing was finding the prerequisites in the installation, grabbing the files and finding the silent install commands and then removing them from the installation. I compiled the installation then, but still got a few more errors, in particular with:

• InnoSetupVersion=5.1.7 (which I removed)
• and a couple of duplicated file copies.

Once I removed all of these, I recompiled the installation.

I could then:

• install the prerequisites (Jet, MDAC, VB6)
• start a SetupCapture of my recompilation
• run my recompilation
• close capture

And then the capture held only the program installation that I was interested in.

Here’s how you can deploy Remote Server Administration Tools for Windows Vista remotely:

1. Download .msu file from http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en
2. Install this by running wusa “blah.msu” /quiet /norestart
3. Run ocsetup.exe WindowsAdministrationTools to activate windows features
4. Set these registry keys to activate start menu folder (can be done manually through properties)

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
“Start_AdminToolsRoot”=dword:00000002
“StartMenuAdminTools”=dword:00000001

For Remote Server Administration Tools for Windows 7:

1. Download .msu file from http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en
2. Install this by running wusa “blah.msu” /quiet /norestart
3. Run dism /online /Get-Features to give a list of all the features
4. Run dism /online /Enable-Feature /FeatureName:RemoteServerAdministrationTools
5. Then run dism /online /Enable-Feature /FeatureName:RemoteServerAdministrationTools-ServerManager etc. to install the desired features
6. Set reg keys to activate start menu folder (can be done manually through properties)

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
“Start_AdminToolsRoot”=dword:00000002
“StartMenuAdminTools”=dword:00000001

I’ve written before about the usefulness of ActiveSetup, but today am here to warn you about a pitfall of using ActiveSetup.

When working with roaming profiles, depending on how your environment is configured, the HKCU registry hive will also roam with users. This is fine if your active setup action is a profile related thing (perhaps create a file in their profile, run a script to move something in their profile). However, if it’s not (maybe creating a local AppData file or something else local), ActiveSetup will work fine the first time, but won’t re-run for the user when they logon to another computer. This could break what you were trying to do.

So, some final words: take care with ActiveSetup, it may not be the tool for your job. An alternative could be the Run key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) or RunOnce (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce)

This came up at work again, so I’ve decided that so I can find it this time, I’ll post it here. This is directly from SMS Guys who have moved on to here.

1. Create a collection that will contain all clients to be excluded from another collection (we’ll call it ‘ExclusionsCollection’ for this example.)

2. Once you have that, go into the Collections table in the SMS SQL database and find the row that contains ‘ExclusionsCollection’. Note the cooresponding ‘ResultTableName’.

3. In the collection that you want to exclude the members of ‘ExclusionsList’ from, copy and paste the following query:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,
SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,
SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client
from SMS_R_System where Client = 1 and ClientType = 1 and
ResourceId not in (select ResourceID from SMS_CM_RES_COLL_XXXxxxxx)

4. Replace the item above in red with your ResultTableName.

I read about MSIFASTINSTALL with great hope that it would reduce installation times as documented in Alex Verboon’s article. Sadly this hasn’t been my experience. I decided I’d test a sequence of installations including Flash Player, Access Runtimes, Reader, QuickTime, Java 6, Silverlight and Shockwave on Windows 7 RC. There were also some other non msi installations.

My average time for 2 runs without MSIFASTINSTALL was 7 min 29 secs, 3 runs with MSIFASTINSTALL=7 was 8 min 3 secs and 2 runs with MSIFASTINSTALL=1 was 7 min 47 seconds. I would have loved to have seen this speed up a few installs, but sorry to say – not for me!

Java 6 Runtime installations will automatically upgrade older Java 6 version through the beauty of the msi upgrade table. However, if you need to install a specific Java version, Sun has some documentation.

Basically run the setup.exe with the parameter STATIC=1 and the install will generate a different msi that will install a standalone version. You can then use your standard installation of other versions (extracted or otherwise) for a different update version.

I came a across an application today that wouldn’t install on Vista, reporting that my computer required Windows NT 4 or later. In order to get the install to run on Vista, I created a shim which let it run on Vista.

What’s a shim? There’s not a lot of simple explanations around, but basically it’s some instructions to the OS for how to run a program. In particular, how to handle compatibility issues by telling the operating system how to run the program. With this you can tell the computer to run something on Vista like it would on XP or Windows 98.

The steps involved are pretty well documented on thelazyadmin, but I’ll add a couple of things.

Firstly, you need to download and install Application Compatibility Toolkit.

Then follow thelazyadmin’s guide to create your shim.

Last, run

sdbinst “path_to_my.sdb”

to implement your shim and then see how your program runs!

A recent application I repackaged into an msi put entries into the user profile. Of course, the entries didn’t work by default on XP and Vista, so I got around this by doing the following:

1. Creating a subfeature of the Complete feature. Call this OS_Specific_Files
2. For this feature, Add Condition to create 2 conditions: VersionNT >= 600 (for Vista) and VersionNT < 600 (for XP)
3. Inside the different conditions create the folder structures and place files as required.

The other aspect of this was to trigger the repair when the user logged on as there was no application entry point. ActiveSetup is one way to do this, but I did this through the Run key in order to do the repair at each logon. This can be done by:

1. Create a registry key in HKLM\Microsoft\Windows\CurrentVersion\Run
2. Name = [ProductName], Value = msiexec /fp [ProductCode] /qn

The java version installed on a PC can be determined by typing

java -version

on a command prompt, but this information is difficult to access through VBScript. I recently put together an installation that put java files into the java version currently installed. This meant finding out which one was the current version, so I put together the following VBScript to compare the version of java.exe in system32 with all java.exe files inside C:\Program Files\Java

Set oShell = CreateObject(“WScript.Shell”)
Set oFSO = CreateObject(“Scripting.FileSystemObject”)
sFile = oShell.ExpandEnvironmentStrings(“%systemroot%”) & “\system32\java.exe”
version = oFSO.GetFileVersion(sFile)
PFDir = oShell.ExpandEnvironmentStrings(“%programfiles%”)
javaDir = PFDIR & “\Java”
Set oFolder = oFSO.GetFolder(javaDir)
Set colFolders = oFolder.SubFolders
For Each folder In colFolders
 thisver = oFSO.GetFileVersion(folder & “\bin\java.exe”)
 If thisver = version Then
  JavaVersion= folder & “\”
 End If
Next

As I was doing this inside a custom action in an msi, I changed the variable JavaVersion to Session.TargetPath(“INSTALLDIR”)

This is a fairly simple one, using the FileSystemObject

Set objFSO = CreateObject("Scripting.FileSystemObject")
filePath = "C:\Temp\file.txt"
objFSO.DeleteFile(filePath)

Note that this is only going to work if the file exists