none
SCCM 2012 Client.msi Fails

    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
    Action: 
    ErrorMessages:
    ]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?

    thanks

    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 | http://blog.configmgrftw.com

    Monday, March 18, 2013 12:36 AM
    Moderator
  • 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 02, 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?

    Thanks!

    Megs

    Tuesday, October 08, 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 | http://blog.configmgrftw.com

    Wednesday, October 09, 2013 12:00 AM
    Moderator
  • 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!

    Megs

    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 | http://blog.configmgrftw.com

    Thursday, October 10, 2013 9:44 PM
    Moderator
  • 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 | http://blog.configmgrftw.com


    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 | http://blog.configmgrftw.com

    Thursday, October 17, 2013 6:39 PM
    Moderator
  • 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
    sc sdset bits "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)" >%temp%\SetServiceObjectSecurity.log
    sc sdset wuauserv "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)" >>%temp%\SetServiceObjectSecurity.log
    @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 http://groups.msn.com/NTarabia
    @echo off
    Pause

    &  also check below command

    msiexec.exe /unregister
    msiexec.exe /regserver
    REGSVR32 WUPS2.DLL /S
    REGSVR32 WUPS.DLL /S
    REGSVR32 WUAUENG.DLL /S
    REGSVR32 WUAPI.DLL /S
    REGSVR32 MUCLTUI.DLL /S
    REGSVR32 WUCLTUI.DLL /S
    REGSVR32 WUWEB.DLL /S
    REGSVR32 MUWEB.DLL /S
    REGSVR32 QMGR.DLL /S
    REGSVR32 QMGRPRXY.DLL /S
    regsvr32 atl.dll /s
    C:\
    sc sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

    & 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:

      fsutil
      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