4

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?

Joel Coel
  • 12,910
  • 13
  • 61
  • 99

2 Answers2

2

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".

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.

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.

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.

Surely it's not this hard? What am I missing?

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:

  • (un)installers that require user interaction when you really want them to run unattended (which AFAIK there isn't an easy way to overcome for native applications)
  • (un)installers that install for a single user but need elevated privileges (which AFAIK there isn't a practical way to automate)
  • (un)installers that purport to install for a single user but actually install for the system or vice versa

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.

alx9r
  • 1,643
  • 3
  • 16
  • 37
  • My problem here is that this program existed before our sccm implementation. You're saying that if I put a batch file into the content location, it will be distributed to computers even though the program is already installed? – Joel Coel Jul 23 '15 at 13:30
  • Yes. That application deployments predate SCCM deployment is normal and shouldn't in itself cause a problem. When the SCCM client uninstalls an application it first ensures the content is in its cache then runs the uninstall command you specified. There is only one content folder per application, so it just downloads the whole folder whether it's installing or uninstalling. – alx9r Jul 23 '15 at 14:10
  • Cool. And then when I get to 100% compliance, if I remove the deployment will the SCCM client clean up the content folder? – Joel Coel Jul 23 '15 at 14:14
  • The only cleanup would be the SCCM client removing the content from its cache. That happens transparently and automatically by SCCM's algorithms in a reasonable way whether or not the deployment is removed. You might consider leaving it deployed so that uninstallation is enforced even if someone manually installs the wrong version or rolls back a VM or boots up an old computer. SCCM application (un)installs are meant to be idempotent so you shouldn't have to be concerned with timing the removal of deployments. – alx9r Jul 23 '15 at 14:24
1

These are tough situations. Some installsheild apps are very poorly built and will only run in User context, but if a user is not a local administrator, the process will never work. You may try complaining to the vendors for new apps.

For existing apps, you can test your uninstall scripts the same way Configuration Manager runs them. Get psexec on a computer in an Administrative Command prompt and type c:\temp\psexec.exe -s -i cmd. The -s is for system, the -i is for Interactive, and the cmd is the process to launch in system context. In the new System cmd window, type in the commands you are trying to run and see if they actually work. If they do not work, you cannot use CM to run these commands (at least not in system context).

Joel Coel
  • 12,910
  • 13
  • 61
  • 99
Steve
  • 11
  • 1