I'm trying to use System Center Configuration Manager 2012 to upgrade an existing program installed on most of our computers. The program uses an InstallShield installer. We're new to SCCM here, and this program has been around since long before we had SCCM available.
The new version of the program and the installer do not have anything built in that I can find to detect or remove old versions. If you just run the new installer without removing the old version of the program, things seem okay for a while, but eventually you start to find things that aren't right. The vendor recommends manually removing the old version before installing the new.
I can already use SCCM to deploy the new version to a clean workstation. However, I am not at this time able to successfully remove the old version.
After doing a lot of research, I've got to the point where I have recorded an answer file for InstallShield. I used a dummy MSI file to create an install template for the old program. Then I edited the detection properties in SCCM to accurately find the old program. I changed the installation program to a dummy command that just exits, and I looked up the uninstall command for the program in the Windows registry.
At this point, if I create an Uninstall deployment from SCCM for this dummy Application it will correctly detect whether or not the program is installed. Software Center on my workstations will show if it's installed or not, and the completion percentage shown in SCCM is accurate. I can also get the uninstaller to run arbitrary scripts, as long as the entire script fits in the Uninstall program: field on the Programs tab of the SCCM deployment type for that application. I just have to enclose the command with something like cmd /d /c"command goes here".
If I edit the uninstall command for the program to not need any quotes and put it inside that command syntax, I can see via Process Explorer that the uninstaller does start, but it's hidden on a private desktop for the local system account, where it will wait for input that never comes. It looks like I need to tell it about the answer file to get the installation to finish. However, this presents two problems.
The first problem is if don't use cmd /d /c"..." syntax, I can't see that uninstall program ever starts at all, but if I do use the syntax I can't include the answer file, because it must be enclosed with quotes. There's no way I can see to escape the quotes in the Uninstall program: field I need to use.
Even if I get around this problem, now I need to know how to push the answer file out to individual systems. From what I've seen, I can't use a network share for this, because the uninstaller will run as local system account that won't have permissions for any network resources. If I could just push random files to computers, I could also push a more complicated uninstall script… but that would also leave artifacts that I still need a way to remove.
I've spent way too much time on this already and seem to be running into a brick wall. InstallShield and SCCM are both widely used. Surely it's not this hard? What am I missing?
Best Answer
I have standardized on batch files to host the commands to perform (un)installation. So the "Install Program" field reads
Install-Application.bat. This allows me to test the (un)installation process entirely separate from SCCM by simply running the batch file. Then when that is working, I can use SCCM to run that batch file with confidence that it will execute in the same way as I already tested (assuming you tested in the same context as SCCM uses). The batch files get distributed along with the other files that comprise the content for that application.SCCM takes care of content distribution (including caching and cleanup) for you. It does a good job of this. I think you might be missing the concept of content and distribution for SCCM applications. SCCM will handle distributing the contents of whatever UNC folder you put in the "Content Location" field to all the clients that need it. I have found this to work reliably and automagically. My content folders commonly include batch files, installers, powershell scripts, XML files, .msp files and any other trappings of an unattended installation process.
It is this hard. Or at least it often is. It might be worth stating that SCCM does not help with installation and uninstallation of software. SCCM really only handles software distribution (and does a rather good job of that). SCCM relies entirely on pre-built installers and uninstallers to perform those tasks. SCCM can't help you if you don't already have an (un)installer that functions the way you want it to. Pain usually results (for about 60% of installers I see) from some combination of the following:
Some of those problems can be overcome by App-V (but that won't help you uninstall your existing native application). As best I can tell, however, there are some applications whose installation and uninstallation just cannot be reliably automated.