, , , ,

I once had an application upgrade over SCCM go haywire because of an old version of InstallShield. The app was being deployed via SCCM 2007 and this runs the package with admin rights under the System context. The script uninstalled the old version, manually deleted any remnants and then installed the new version.
It turns out that this app’s old InstallShield InstallDriver uses DCOM running in the security context of the Interactive User rather than the Launching User! WHY???
This meant that the installation of the new version attempted to run (most of the time) as a non-admin user. Needless to say, this failed and the user was now left with NO version of the software at all!
It took some hunting online to find out what on earth was going on (using the Install Shield log file) but once I knew what the issue was, I was able to quickly make a new script with the below fix in and get everyone back up and running and upgraded without too much downtime.

In the install batch file, after installing the InstallShield engine, I now call this VBScript to switch the DCOM entry to use Launching User before running the app setup.

On Error Resume Next

Const HKEY_CLASSES_ROOT = &H80000000

Set objWshShell = WScript.CreateObject("WScript.Shell")
Set objStdReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Set objSWbemServices = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\CIMV2")
strWQL = "SELECT Name,AppID FROM Win32_DCOMApplication WHERE Name LIKE '%InstallShield%'"

For Each objDCOM In colDCOMs
	strAppID = objDCOM.AppID
	objStdReg.DeleteValue HKEY_CLASSES_ROOT,"Appid" &"\" & strAppID, "RunAs"


That was an episode to chalk up to experience and add to the personal knowledgebase of oddities.