Chris Nackers Blog

Dynamic Applications – 1618 error codes

So as i’ve mentioned in previous blogs, i’ve been working with dynamic applications quite a bit lately.  The one issue i kept running into lately was 1618 error codes for the execution history.  Eventually i was able to resolve everything, but there were a few reasons for those types of errors to show up, so i wanted to create a blog to help others troubleshoot the issue.  Obviously the 1618 error messages are related to MSI based installs. So you won’t receive such an error with a setup.exe or another type of install.

I found 2 main causes of the 1618 error codes, and you could have one or both of the issues in your environment depending on configurations.

1) Conflicting installs with SMS 2003

2) SMS Client Health Script

1 - Conflicting install with SMS 2003

I specifically mention SMS 2003 here because from what i understand and have been told, SCCM does not have this issue anymore. Essentially what happens is that when ZTIPackages is installing it’s applications, SMS can also attempt to install it’s applications, so you end up with 2 MSI installs trying to run at the same time and one of them will work, the other(s) will fail with the 1618 error code which is “another installation in progress.”   I didn’t run into this problem very often, if at all, on a new computer build, since there wouldn’t be a client history and standing advertisements.  However, the problem was very easy to reproduce when doing a ZTI through SMS.  Since the advertisements were standing and ready to go, when the machine was doing imaging and back online, there was enough time while ZTIPackages was running for the client to receive it’s policies and attempt to start installing the requested applications.

So, now that we identified the issue, how do we resolve it?  Well simply we need to “take care” of the SMS Client, and stop it from doing anything while ZTIPackages is running.  The 2 best ways to do this are to either stop the SMS Client Service, or to disable the Software Distribution Component.  Disabling the Software Distribution component is a more reliable method, but also has a great risk since you are disabling the component, if your “re-enable” script doesn’t work, you are stuck with a machine or machines that won’t install software until the issue is resolved.  Stopping the SMS server (CCMEXEC) works as well, but is less reliable, because if the service starts up again for some reason, you are back to square 1 and installs will start conflicting. 

Stopping the CCMEXEC service:

You can use a few methods of stopping the service.  You can use simple command lines like “net stop” and “sc stop”, along with “net start” and “sc start”.  Or you could use a more advanced method calling a script.  Here is a script from the Deployment Guys that allows you to stop and start a service.    Here is the usage of the script:

Usage:     cscript zCFG-Services.wsf [/service:ServiceName] [/state:Start or Stop] [/debug:true]

NOTE: /service:ServiceName is case sensitive. /state: can be Start or Stop only

Any of the above methods will work, just each have their advantages and disadvantages.  Just remember to restart the service back up after the fact.  I typically put the stop service command at the beginning of the State Restore phase.  I restart the service after User State in the State Restore phase, this makes sure that no program from SMS are running while you are restoring the user state data.    The only important thing is that you are stopping and starting the service before/after ZTIpackages, “Install Packages”.

Disabling the Software Distribution agent:

I’ve blogged on this before, so i won’t repost that info again.  The information you need is located here: http://myitforum.com/cs2/blogs/cnackers/archive/2009/01/25/pausing-or-stopping-sms-software-distribution.aspx

If you are using this method, I disable the agent before ZTIPackages runs, and i re-enable it after USMT restores user data.

2 - SMS Client Health Script

The client health script is a wonderful script created by some of the guys on MyITForum that work with Dudeworks.  This is a great free solution to dealing with common client issues and just keeping a good watch over your clients. Typically you would configure this script to run through Group Policy as a start up script. 

I did run into a few issues with the script and conflicting with the Dynamic Applications process.   Here are the checks that can be enabled/disabled for the script to verify.

do_CHK_CCMEXEC = true

do_CHK_SYSTEMPATH = true
do_CHK_AUTOUPDATE = true 
do_CHK_SMSLOCALADMIN = false
do_CHK_ADMSHARE = true
do_CHK_RemoteReg = true
do_CHK_WMI_SERVICE = true
do_CHK_BITS_SERVICE = true
do_CHK_REGXML = true
do_CHK_AdvClient = true
do_SEND_CCR = true
do_RUN_CCMSETUP = false
do_CHK_CACHESIZE = false

So first off you can see the script is checking for the CCMEXEC service to be started :)  Well that’s a problem if we are stopping it for ZTIPackages to run. Depending on the alignment of the planets (or just simple timing), the startup script will see that CCMEXEC is stopped and restart it, which then allows SMS to start running programs again, which will give you the wonderful application conflicts, again. 

The next main point of interest is “RUN_CCMSETUP”.  If some of the checks fail, the script will automatically initiate a reinstall of the SMS Client.  Which is a MSI based install :) So you can also end up with some 1618 failures, because the SMS Client will be reinstalling while ZTIPackages starts running it’s first few applications. 

Now if you are using the disable software distribution agent method, software distribution will still be disabled, so the only issue that will likely run into is that the first few applications from ZTIPackages might fail with a 1618 error code because of the SMS Client being reinstalled.  In my case, only my first application was failing, everything else would go through successfully after the fact.  Quite frustrating.  If you are stopping/starting the service, you will most likely have more failures since you will have ZTIPackages and SMS butting heads throughout the ZTIPackages process, it’s first come first serve.

Hope that information helps, let me know if you have any questions.

-Chris