A quick way to find out MSI product codes for installed products if you have the PowerShell App Deployment Toolkit (PSADT) lying around is to dot source the toolkit’s AppDeployToolkitMain.ps1, and use the Get-InstalledApplication function.
This saves you digging around the registry, and searches both the 64-bit and 32-bit sections of the registry. Also handy, is the fact that the Name parameter on Get-InstalledApplication can take partial names:
Since we moved from Shoretel 7.5 –> 8.1, we’ve had a niggling issue that’s about to become a show-stopper on a new deployment for our entire Melbourne office.
The client software is easily deployed via Active Directory and Group Policy, but there’s a problem where the Outlook integration installer requires elevation, even though the only changes that are being made are restricted to the user’s profile. This is obviously ridiculous in a corporate environment, as new user setups require the user to be made a local administrator for their first login just to install Shoretel’s Outlook integration.
I lived with this as an inconvenience over the last few years, but the time has now come to plan for a replacement of our Melbourne office’s out-dated Ericsson PABX system. This issue, then, will be a show-stopper as we’re not going to make 80+ users local administrators – even temporarily.
Last week, I sat down to think about the problem and remembered something I’d read about “shimming” applications in Vista & Windows 7. This then led me to wonder if I could create a shim that stops UAC from being triggered by the Shoretel Outlook integration installer – %programfiles%Shoreline CommunicationsShoreWare ClientUninstWrpr.exe
The above process will obviously break any functionality within UninstWrpr.exe that does actually require elevated privileges, but that’s not a concern to me. I went ahead and created a new Security Database using Microsoft’s Application Compatibility Toolkit, and set up the shim as per one of the technet documents. I installed the resulting sdb file on a test machine using the inbuilt sdbinst.exe command, and voila! The Outlook integration installed without a single UAC prompt, and worked properly to boot.
The only part of the process left, is to figure out how to deploy the shim to the client machines. For the sake of brevity, I’ll detail the entire process in a new post shortly.
I recently figured out a better way to get MYOB Premier to deploy via MSI that the previous method that I posted. This method basically stops the MSI from checking if it’s been run by a bootstrapper (Setup.exe). I’ve tested this with Premier 11 and 12 and it deploys fine on XP and Vista.
Read my update: https://daniel.streefkerkonline.com/update-deploying-myob-premier-via-msi/
After many attempts over the years to get MYOB Premier deployed via AD GPO, I stumbled across a method this morning using only free tools.
These two tools are an essential part of my MSI toolkit, keeping in mind that i’m not some sort of MSI guru like the guys at appdeploy.com
2. WinInstall LE 2003 (WinInstall LE 2003 used to be distributed for free, but now you have to trawl around the net to find it)
The steps are as follows. I used this method for Premier 11, so that’s what i’ll use below.
- Import Premier’s MSI into WinInstall, making sure you tick the option to copy the source files
- In WinInstall, turn off components you don’t need installed. I did this over creating a transform file, as that’s overly complicated for my needs
- Close WinInstall and open Orca
- Delete CustomAction->ISVerifyScriptingRuntime
- Change Directory->ISYourProductDir to “PREMIE~1|Premier 11”
- Change Directory->ISYourCompanyDir to “MYOB|MYOB”
- Change Directory->KEY_NAME_SC to “MYOB|MYOB Premier 11”
- Save the MSI file and close Orca
This worked for me, so good luck.
Some of my findings, and methods i’d use to set up the infrastructure to roll out software using Group Policy on a Windows 2000/2003 domain.