SCCM 2012 Client.msi Fails RRS feed

  • Question

  • I am able to install the SCCM client on many machines, but two machines are failing.  First I looked in ccmsetup.log:

    <![LOG[File C:\Windows\ccmsetup\{59A0EA77-D28C-4286-83A6-04BB57B9CDD6}\client.msi installation failed. Error text: ExitCode: 1603
    ]LOG]!><time="16:25:20.476+00" date="03-16-2013" component="ccmsetup" context="" type="3" thread="1512" file="msiutil.cpp:860">
    <![LOG[Next retry in 120 minute(s)...]LOG]!><time="16:25:20.507+00" date="03-16-2013" component="ccmsetup" context="" type="0" thread="1512" file="ccmsetup.cpp:7554">

    Then i looked at client.msi.log for more detail, and searced for "return value 3".  This log file is hug so i included an excerpt from it.  Let me know where to look in the log file for more descriptive text.

    [15:43:48] Automatic Delayed Start configuration is enabled for CCMEXEC
    MSI (s) (70:64) [15:43:48:682]: Executing op: CustomActionSchedule(Action=CcmRegisterWinTaskRollback,ActionType=3329,Source=BinaryData,Target=CcmRegisterWinTaskRollback,)
    MSI (s) (70:64) [15:43:48:697]: Executing op: ActionStart(Name=CcmRegisterWinTask,Description=Registers tasks with Windows Task Scheduler.,)
    MSI (s) (70:64) [15:43:48:697]: Executing op: CustomActionSchedule(Action=CcmRegisterWinTask,ActionType=3073,Source=BinaryData,Target=CcmRegisterWinTask,)
    MSI (s) (70:64) [15:43:48:697]: Creating MSIHANDLE (24379) of type 790536 for thread 1892
    MSI (s) (70:10) [15:43:48:697]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI6477.tmp, Entrypoint: CcmRegisterWinTask
    MSI (s) (70!24) [15:43:48:713]: Creating MSIHANDLE (24380) of type 790531 for thread 3620
    MSI (s) (70!24) [15:43:48:713]: Closing MSIHANDLE (24380) of type 790531 for thread 3620
    [15:43:48] Registering windows task 'Configuration Manager Idle Detection'
    MSI (s) (70:10) [15:43:48:713]: Closing MSIHANDLE (24379) of type 790536 for thread 1892
    CustomAction CcmRegisterWinTask returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
    MSI (s) (70:64) [15:43:48:760]: User policy value 'DisableRollback' is 0
    MSI (s) (70:64) [15:43:48:760]: Machine policy value 'DisableRollback' is 0
    Action ended 15:43:48: InstallFinalize. Return value 3.
    MSI (s) (70:64) [15:43:48:838]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1114668398,LangId=1033,Platform=589824,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
    MSI (s) (70:64) [15:43:48:838]: Executing op: DialogInfo(Type=0,Argument=1033)
    MSI (s) (70:64) [15:43:48:838]: Executing op: DialogInfo(Type=1,Argument=Configuration Manager Client)
    MSI (s) (70:64) [15:43:48:838]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
    MSI (s) (70:64) [15:43:48:838]: Executing op: ActionStart(Name=CcmRegisterWinTask,Description=Registers tasks with Windows Task Scheduler.,)
    MSI (s) (70:64) [15:43:48:838]: Executing op: ProductInfo(ProductKey={D6804B3A-BFEC-4AB4-BFA5-FD9BECC80630},ProductName=Configuration Manager Client,PackageName=client.msi,Language=1033,Version=83893884,Assignment=1,ObsoleteArg=0,,,PackageCode={59A0EA77-D28C-4286-83A6-04BB57B9CDD6},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)
    MSI (s) (70:64) [15:43:48:838]: Executing op: ActionStart(Name=CcmRegisterWinTaskRollback,Description=Rolls back the changes made by CcmRegisterWinTask.,)
    MSI (s) (70:64) [15:43:48:838]: Executing op: CustomActionRollback(Action=CcmRegisterWinTaskRollback,ActionType=3329,Source=BinaryData,Target=CcmRegisterWinTaskRollback,)
    MSI (s) (70:64) [15:43:48:838]: Creating MSIHANDLE (24381) of type 790536 for thread 1892
    MSI (s) (70:8C) [15:43:48:838]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI6504.tmp, Entrypoint: CcmRegisterWinTaskRollback
    MSI (s) (70!DC) [15:43:48:853]: Creating MSIHANDLE (24382) of type 790531 for thread 3548
    MSI (s) (70!DC) [15:43:48:853]: Closing MSIHANDLE (24382) of type 790531 for thread 3548
    MSI (s) (70:8C) [15:43:48:853]: Closing MSIHANDLE (24381) of type 790536 for thread 1892
    [15:43:48] Removing windows task 'Configuration Manager Idle Detection'

    From successfully installation i typically see folders created in C:\Windows\CCM\* but in this particular case there are only a couple .tmp files and other misc.  Where should i look next?  I have tried ccmsetup.exe /uninstall and then ccmsetup.exe /mp:<machine> SMSSITECODE=<code> /noservice and also with /service.

    I have tried winmgmt /resetrepository

    I have checked that BITS service is running.

    What else should i look for?


    Saturday, March 16, 2013 4:39 PM


All replies

  • "CustomAction CcmRegisterWinTask returned actual error code 1603"

    CcmRegisterWinTask is a custom action but is not documented anywhere (that I can find or know about). My best guess -- based on the name and description "Registers tasks with Windows Task Scheduler" -- is that it is attempting to register the ccmeval Windows schedule task but cannot for some reason.

    I have seen in other forum posts some group policies doing odd things to the Windows task scheduler but given this is only happening on two of your systems, doubt that would be an issue.

    Perhaps there is an issue with the Windows task scheduler on these systems. Have you tired to open it and have you reviewed the Windows event logs for issues related to it?

    Jason |

    Monday, March 18, 2013 12:36 AM
  • I've been having this same problem and, similarly, only on a few machines. Four, with the last one being discovered today. I logged a similar question here a couple of weeks ago and, so far, I haven't been able to resolve the problem.

    Did you happen to find a solution? I'm thinking of opening a case with Microsoft if I can't fix this in the next few days...

    Tuesday, March 26, 2013 7:15 PM
  • Is the Task Scheduler service enabled and running?
    Tuesday, March 26, 2013 7:21 PM
  • I just checked one of the machines I've been working with, and the Task Scheduler service is started, and set to Automatic.

    Also, I've checked in the Event Logs, and nothing obvious jumps out. Around the same time of the CcmRegisterWinTask failure in the installation logs, I see Performance Counters for CCMFrameWork being loaded, and then unloaded, in the Application Logs. In the System log three services are installed (Agent Host, Remote Control and Task Sequence) and .NET 4 service enters the running state.

    The Performance Countes are loaded one second before the error occurs in the installation log, and are unloaded one second after. The service entries in the System log all occur at on the same second as the error in the installation log.

    Tuesday, March 26, 2013 8:31 PM
  • Can you share the entire client.msi.log?
    Tuesday, March 26, 2013 10:50 PM
  • I will. The particular system I was checking yesterday is currently unavailable. I will collect the log and corresponding data from another system.
    Wednesday, March 27, 2013 3:00 PM
  • Thanks for the hint Jason, it helped me with 4 Windows-7 machines where I just couldn't get the client installed.  I found that the Task Scheduler service startup had been changed from Automatic to Manual, which caused the SCCM client installation to fail.  The key section in Client.msi.log is shown below. "Return value 3" is the key thing to look for.

    I came across a red herring in my initial analysis of client.msi.log.  The SQL "error" shown below shows up on all my machines, whether the client installed successfully or not.  I spent way too much time looking at it...

    ERROR: Failed to execute SQL statement:
                DROP TABLE LanternDocumentToCI;
             with error (0x80040e37)

    Automatic Delayed Start configuration is enabled for CCMEXEC
    Executing op: CustomActionSchedule(Action=CcmRegisterWinTaskRollback,ActionType=3329,Source=BinaryData,Target=CcmRegisterWinTaskRollback,)
    Executing op: ActionStart(Name=CcmRegisterWinTask,Description=Registers tasks with Windows Task Scheduler.,)
    Executing op: CustomActionSchedule(Action=CcmRegisterWinTask,ActionType=3073,Source=BinaryData,Target=CcmRegisterWinTask,)
    Creating MSIHANDLE (24418) of type 790536 for thread 6296
    Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI2E61.tmp, Entrypoint: CcmRegisterWinTask
    Creating MSIHANDLE (24419) of type 790531 for thread 6500
    Closing MSIHANDLE (24419) of type 790531 for thread 6500
    Registering windows task 'Configuration Manager Idle Detection'
    Closing MSIHANDLE (24418) of type 790536 for thread 6296
    CustomAction CcmRegisterWinTask returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
    User policy value 'DisableRollback' is 0
    Machine policy value 'DisableRollback' is 0
    Action ended 23:57:22: InstallFinalize. Return value 3.

    Wednesday, October 2, 2013 3:33 PM
  • Good afternoon,

    Along the lines of this thread, we now appear to have client failures due to the Task Scheduler service being disabled (in above case, set to Manual). However, some people do this due to security reasons.

    In the past, 2012 clients installed with the Task Scheduler service being disabled. We are now seeing this surface, and I'm not sure what the change would have been. Was this an updated requirement with SP1 and/or CU1? Anyone know?



    Tuesday, October 8, 2013 9:12 PM
  • However, some people do this due to security reasons.

    Those people need to re-evaluate their rationale as doing this does not in any way increase or decrease the security posture of a system.

    ConfigMgr 2012 added the ccmeval process to check and remediate various aspects of client health. This is done using a scheduled task which the client agent itself creates (and I think also ensures is created periodically). Thus, without a started task scheduler service, the custom action that creates the task fails. They never accounted for anyone disabling the service because it really makes no sense to do so.

    Jason |

    Wednesday, October 9, 2013 12:00 AM
  • Hi Jason,

    Agreed -> fine example, as always, of security through obscurity.

    My issue is this is a security requirement. We can enable the service, but we need supporting documentation to back us up (which I cannot find) that states Task Scheduler is a requirement for SCCM 2012 clients. Have you seen it? Otherwise, I'll open a support case.

    Thank you for your response!


    Thursday, October 10, 2013 8:15 PM
  • Not everything that can be documented is actually documented -- it's simply impossible.

    You may be able to get an "official" answer by opening a support case but that's a waste of a support case IMO.

    Jason |

    Thursday, October 10, 2013 9:44 PM
  • Not everything that can be documented is actually documented -- it's simply impossible.

    You may be able to get an "official" answer by opening a support case but that's a waste of a support case IMO.

    Jason |

    That's a no-brainer. However, if it is a requirement, why wouldn't it be? That's all I have to say on the subject. Do appreciate the input.
    Thursday, October 17, 2013 6:26 PM
  • Because its a default configuration. If you've deviated from the default configuration, there's simply no way they could ever account for that. The list of all requirements would be thousands of pages long if every little detail is listed. They simply could not ever account for everything. They must make assumptions about a default, standard configuration.

    Jason |

    Thursday, October 17, 2013 6:39 PM
  • please check windows installer service & background install services 

    @echo off
    Echo This batch file will Set Service Object Security for WUAUSERV & BITS.
    REM Result will be written to %temp%\SetServiceObjectSecurity.log and then launched in Notepad.
    Echo Please wait...
    @echo on
    @echo off

    notepad %temp%\SetServiceObjectSecurity.log
    Echo Open %temp%\SetServiceObjectSecurity.log for SUCCESS entry.
    Echo Open the Services applet from control panel to see if the services are started.
    Echo For any errors; report on
    @echo off

    &  also check below command

    msiexec.exe /unregister
    msiexec.exe /regserver
    regsvr32 atl.dll /s

    & recheck  all services.

    Monday, October 21, 2013 5:53 AM
  • Hi, we had found this problem on several Vista Clients and we were able to find a solution with the Microsoft Customer Support. The cause was that the Indexing Service corrupt TXR streams included. This caused the problem during the SCCM agent installation, that the"Configuration Manager Health Evaluation"Schedule Task couldn't be created.

    The solution to this problem is as follows:

    1. First run a CHKDSK /F
    2. Reboot
    3. Open an elevated CMD and run the following command:

      resource setautoreset true C:\
    4. Reboot
    5. Install the SCCM Agent

    You can check manualy if the problem with the corrupted indexing files is active be checking the file date and time under "C:\Windows\System32\config\TxR". If there are no current files in that folder, then you run in this problem.

    Kind regards Stefan Somogyi

    Friday, March 28, 2014 1:21 PM
  • I'm having the exact same issue and the fix above did not work.  This is a really tough issue.  I'm wondering if it sees a cumulative update previously installed because something is left over in the registry and it is failing because of that.  I wish there was a good cleanup tool.

    Any other suggestions would be appreciated

    Friday, June 6, 2014 3:28 AM
  • For the record, I'm also seeing this problem with 2012 Server and the 2012 SCCM client. Error: CcmRegisterWinTask returned actual error code 1603

    I'm desperately trying to resolve this issue without resorting to a reboot.

    Any advice would be very much appreciated.

    Friday, September 26, 2014 12:28 AM
  • Many Thanks Vinay,

    this fixed the issue with me.


    Monday, September 29, 2014 10:30 AM
  • This was it for me. Task scheduler is disabled for security purposes in our environment. Is there a client setting that I can change that will prevent this from happening? Is Task Scheduler required for CCM to work properly?
    Thursday, January 22, 2015 9:57 PM
  • See "The Microsoft Task Scheduler service must be enabled on the client for the client installation to complete."

    Torsten Meringer |

    Friday, January 23, 2015 7:09 AM
  • Thankyou.
    Friday, January 23, 2015 6:45 PM
  • The stated solution doesn't work for me. Task scheduler is enabled yet the 1603 error persists.

    Still looking for a fix that doesn't require a restart.

    Wednesday, January 28, 2015 8:39 PM
  • You are incorrect. Task scheduler is a commonly targeted windows service. - See schelevator.rb

    This is just three examples out of hundreds.

    Task scheduler is also used to bypass uac prompts etc for elevation, run things under the system context, etc, etc.

    It is actually changes your system's security posture quite a bit, and is a common baseline security setting. Telling people that it doesn't change their security posture is misleading. The SCCM team should have built a scheduler into the client that can only be set by policy delivered via signed traffic from the MP instead of using the OS task scheduler.  

    You can probably just get away with disabling it on edge systems, in most cases, but it depends on your network environment, and the nature of your business.

    Thursday, January 29, 2015 6:42 PM
  • Using the task scheduler to do any of these requires admin privileges first -- if an attacker has admin privileges, then nothing else matters, you're already exposed, task schedule or no task scheduler. Task scheduler is a means to an end, it can't magically do things without someone giving it privileges.

    Also, anything referring to XP is invalid, the task scheduler was completely redesigned in Vista.

    And if you disable task scheduler in Win 8.x, you'll break most of the OS as most of the maintenance has been moved to the task scheduler and the OS heavily relies on it for normal tasks.

    Jason | | @jasonsandys

    Thursday, January 29, 2015 7:04 PM
  • *sigh* You should probably stay away from IA topics.

    There are a multitude of privilege escalation techniques that allow you to use the task scheduler.

    Here's a little school.

    Thursday, January 29, 2015 8:38 PM
  • Sorry, the only sigh here is that you didn't actually read the article or understand what's really happening. The exploits here don't use task scheduler to gain access -- they all gain access and privileges in some other manner -- a TFTP client running as SYSTEM in the example given or the XP no SP task scheduler or enabling MSI installation for all users. Once you are SYSTEM, you can do anything you want regardless of task scheduler. The exploits described here in no way exploit task scheduler, they use it as a means to launch other things once they have already gained System privileges at which point it was game over anyway.

    Jason | | @jasonsandys

    Thursday, January 29, 2015 8:54 PM
  • Did someone able to find the root cause of it and able to it resolve it, i'm currently facing the same issue:

    Error 1904. Module C:\Windows\CCM\DCMADQueryProvider.dll failed to register.
    HRESULT -2147024703. Contact your support personnel"
    This error is not
    restricted to any 1 dll but it's random like DCMADQueryProvider.dll,
    statusagent.dll, ccmcore.dll

    •I'm getting this error while installing
    SCCM 2012 client.

    Steps i tried:
    1.I did try manually registering
    oringinally but when the client fails to install, it removes all the source
    files including the ccmcore.dll. So, ccmcore.dll doesn't reside on the system
    after failing to install the client or at least not that I can see.
    2. I
    have tried timing it just right so that my "regsvr32 ccmcore.dll" is run during
    the install process while the file is in the CCM folder but that didnt work
    3. I had manually created the directory CCM\x64\ccmcore.dll and
    copied the file from a working client and try to register but it gave me an
    error " Failed to load .dll"
    4. i have tried uninstalling the client from
    ccmclean and tried to reinstall it but still it fails.

    Currently not sure what is wrong with the client install, so still
    investigating the issue, please help if someone was able to solve the issue.

    There are some
    articles out there which points to resolving this issue by registering

    However, in this
    case ATL.dll has been registered only 1 times using regsvr32.exe (system32 and
    syswow64 folders).

    Based on procmon :


    While installing, it was looking for ATL.DLL and found the location from
    registry as "

    Monday, March 2, 2015 1:33 PM
  • Some of our client installation issues have been due to 3rd party software.  Lumension EndPoint security specifically.  We had to make some setting changes or get a Lumension client patch to resolve that.  Some client install issues have been due to corrupt WMI on a machine and that took re-imaging the workstation.
    Monday, March 2, 2015 2:12 PM
  • Had the same issue and attempted several possible solutions including resetting WMI repository, running CHKDSK/fsutil and then spotted Hollisorama's post. Uninstalled Lumension EndPoint et voila, ccmsetup has finally completed successfully.
    Wednesday, July 6, 2016 12:33 PM
  • Very old thread I know, but recently ran across this myself on a few Windows 10 machines. Spent an obscene amount of time troubleshooting it, in the end there is a folder named "Configuration Manager" under the Task Scheduler -> Microsoft that I had to manually delete before I could get the client reinstalled. Apparently this isn't removed during uninstall or using CCMClean. 
    Thursday, January 19, 2017 11:38 PM
  • Uninstalled Lumension EndPoint
    this fixed the issue with me.
    Monday, May 15, 2017 8:29 AM
  • If you aren't using Lumension and still having issues with client installs.  This procedure has been golden.  I'd say it's worked 90% of the time.  No need to re-image the PC.

    Tuesday, May 16, 2017 10:11 PM