locked
Troubleshooting software deployment error 1603 in SCCM RRS feed

  • Question

  • Hey all, 

    I have been testing out software deployment via SCCM and have run into an error that I can't solve.  

    For testing purposes, I downloaded Firefox49.0.2.exe and repackaged it into an MSI using Appdeploy Repackager.  I then created a package in SCCM using this MSI with the command line: msiexec /i "firefox.msi" for the install.  I distributed the package to my DP and then deployed it to my test collection (with only one computer in the collection).  Unfortunately, it returns an 1603 error.  

    I have tried installing the Firefox.msi locally on the test computer (double clicking the MSI) and it works/installs correctly.  After uninstalling and cleaning the registry (with Ccleaner), I also tested installing the MSI using msiexec /i "firefox.msi" in cmd as the system user (I used psexec.exe -s cmd to open cmd as the system user) and it works/installs correctly.  

    I then remade my package in SCCM using the command line: msiexec /i "firefox.msi" /l %temp%\logfile.log to create a log file for the install and re-deployed.  In the log file it gives me this error message:  

    Info 1603.The file C:\Windows\System32\config\DRIVERS.LOG1 is being held in use.  Close that application and retry.
    Error 1306. Another application has exclusive access to the file 'C:\Windows\System32\config\DRIVERS.LOG1'.  Please shut down all other applications, then click Retry.

    There are no other applications open on the test machine and I can't find any good info on what this Drivers.log1 file does.

    Anyone know what this is or what is causing this to not install via SCCM?

    Thursday, October 27, 2016 7:40 PM

Answers

  • Use Procmon to determine exactly what has the drivers.log1 lock open.

    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Thursday, October 27, 2016 7:44 PM
  • Ultimately, this has nothing to do with ConfigMgr; ConfigMgr simply kicked off the command-line you gave it. What that command-line does is outside the scope of ConfigMgr and what Windows does to service that command-line is also outside the scope of ConfigMgr.

    Thus, you need to troubleshoot this locked file just like you would anything other issue on a Windows system. Locked files are often indicative anti-virus scanning activity but could be for other reasons as well. As Garth recommends, you need to introduce another tool, like ProcMon, to discover what is locking this other file and figuring why it is locking the file.

    And ultimately, ConfigMgr has nothing to do with this.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, October 27, 2016 9:17 PM
  • Ultimately, this has nothing to do with ConfigMgr; ConfigMgr simply kicked off the command-line you gave it. What that command-line does is outside the scope of ConfigMgr and what Windows does to service that command-line is also outside the scope of ConfigMgr.

    That's what I thought too... but then it installed correctly when I used the same command line command on the local machine as I had used in SCCM.  So why would it install locally using "msiexec /i "firefox.msi" /l %temp%\logfile.log" but not install via SCCM when using the exact same command?

    As Jason has stated, CM12 only executes the command that give it, nothing more... The PSExec try will solve 95% of all problems the only exception to this,  is if you have x86 vs x64 issue. Then you need to adjust you psexec to open x86 cmd. 

    Again, the procmon will tell you exactly what is holding open the file in question, from there you can troubleshoot why.


    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Friday, October 28, 2016 2:17 PM

All replies

  • Use Procmon to determine exactly what has the drivers.log1 lock open.

    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Thursday, October 27, 2016 7:44 PM
  • Ultimately, this has nothing to do with ConfigMgr; ConfigMgr simply kicked off the command-line you gave it. What that command-line does is outside the scope of ConfigMgr and what Windows does to service that command-line is also outside the scope of ConfigMgr.

    Thus, you need to troubleshoot this locked file just like you would anything other issue on a Windows system. Locked files are often indicative anti-virus scanning activity but could be for other reasons as well. As Garth recommends, you need to introduce another tool, like ProcMon, to discover what is locking this other file and figuring why it is locking the file.

    And ultimately, ConfigMgr has nothing to do with this.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, October 27, 2016 9:17 PM
  • That file most likely is not related to the application and should be excluded from the capture of your MSI project.

    I would advise against creating an MSI installer and deploying it in production unless you have experience, you can cause lots of issues.

    On your issue:

    Did you grab the stub installer that goes off to the internet>? if so avoid doing this, always use an offline full installer, it will save you adding lots of crap that's not needed.

    You don't need to create an MSI to install and uninstall this application silently.

    "Firefox Setup 49.0.2.exe" /silent

    You could uninstall it with 

    "C:\Program Files (x86)\Mozilla Firefox\uninstall\helper.exe" /silent

    This is the 32bit version on a 64bit device but it points you in the right direction.

    I have tested the above and they work fine.

    You don't need to deploy everything as an MSI, as long as you can install something silently then Configuration Manager can use it.




    Thursday, October 27, 2016 10:03 PM
  • Ultimately, this has nothing to do with ConfigMgr; ConfigMgr simply kicked off the command-line you gave it. What that command-line does is outside the scope of ConfigMgr and what Windows does to service that command-line is also outside the scope of ConfigMgr.

    That's what I thought too... but then it installed correctly when I used the same command line command on the local machine as I had used in SCCM.  So why would it install locally using "msiexec /i "firefox.msi" /l %temp%\logfile.log" but not install via SCCM when using the exact same command?
    Friday, October 28, 2016 2:11 PM
  • Thanks, I'll look in to this.

    Friday, October 28, 2016 2:16 PM
  • Ultimately, this has nothing to do with ConfigMgr; ConfigMgr simply kicked off the command-line you gave it. What that command-line does is outside the scope of ConfigMgr and what Windows does to service that command-line is also outside the scope of ConfigMgr.

    That's what I thought too... but then it installed correctly when I used the same command line command on the local machine as I had used in SCCM.  So why would it install locally using "msiexec /i "firefox.msi" /l %temp%\logfile.log" but not install via SCCM when using the exact same command?

    As Jason has stated, CM12 only executes the command that give it, nothing more... The PSExec try will solve 95% of all problems the only exception to this,  is if you have x86 vs x64 issue. Then you need to adjust you psexec to open x86 cmd. 

    Again, the procmon will tell you exactly what is holding open the file in question, from there you can troubleshoot why.


    Garth Jones

    Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

    Friday, October 28, 2016 2:17 PM
  • Also, as Richard noted above, why in the world are you repackaging it? Just use the vendor's exe. Repackaging almost always introduces additional issues.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, October 28, 2016 2:34 PM