none
MSI Secure repair error when repairing from DP RRS feed

  • Question

  • When I run a repair on MSIs that have been deployed as an Application but no longer have their source cached (e.g. deleted from C:\windows\ccmcache) what we expect to happen is for the installer to grab the MSI from the distribution point because we set up source management by entering the product code in the source management field of the Deployment Type properties.

    Unfortunately, I receive the following error:

    MSI (s) (1C:68) [12:05:02:272]: SECREPAIR: Hash Database: C:\WINDOWS\Installer\SourceHash{E9B27679-F362-4518-8D2C-B27D5A57ACC1}
    MSI (s) (1C:68) [12:05:02:272]: SECREPAIR: Failed to open the file:http://<dp fqdn>/sms_dp_smspkg$/content_1dfa2e07-d5c8-463b-b2dc-ddc5443fcbff.1/\HPE_CM_x86.msi for computing its hash. Error:123
    MSI (s) (1C:68) [12:05:02:272]: SECREPAIR: Failed to CreateContentHash of the file: HPE_CM_x86.msi for computing its hash. Error: 123
    MSI (c) (60:78) [12:05:02:288]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
    Error 123. The filename, directory name, or volume label syntax is incorrect.

    I have tried the following:

    • Issue occurs with other packages as well
    • Issue occurs on my home lab environment with no corporate group policy or SOE
    • I can correctly browse to, and download the file from the HTTP path specified in the above logs.
    • I can run msiexec -I http://path/to/setup.msi and the installation begins.
    • I have enabled and disabled anonymous HTTP access in the distribution point properties.
    • Running msiexec /famus {product code} as a standard user and I get the error
    • Running msiexec /famus {product code} as a domain admin in the home lab and I get the error.

    Any help would be appreciated.

    Thanks,

    Adam



    Monday, July 17, 2017 4:18 AM

Answers

  • Time to open a support case with Microsoft CSS then.

    I don't think most people ever test or use this functionality so it's something that's probably slipped through. It's clearly a Windows 10 issue even though its preventing a ConfigMgr feature from working.


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

    • Marked as answer by Adam Mancini Tuesday, July 18, 2017 2:39 AM
    Tuesday, July 18, 2017 2:32 AM

All replies

  • Created a test IIS website and put the MSI files on there. I receive the same error message on the test HTTP website as I do on the DP.

    I did a procmon and found this:

    If you cant read the text in that screenshot, the path is in the below command line where I try to re-produce making the file:

    notepad C:\windows\system32\http:\testsite\7zip\7z1700-x64.msi

    ---------------------------
    Notepad
    ---------------------------
    The filename, directory name, or volume label syntax is incorrect.


    ---------------------------
    OK   
    ---------------------------

    Same error that windows installer throws.



    Monday, July 17, 2017 6:07 AM
  • Ultimately, this doesn't have anything to directly do with ConfigMgr so posting in a Windows Installer forum (if you can find one) will get you better results most likely.

    Why are you choosing /famus for the command-line options when manually attempting to repro the issue?


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

    Monday, July 17, 2017 1:39 PM
  • I also reproduce the error with /fous and by triggering self-heal when running an advertised shortcut. 
    Tuesday, July 18, 2017 12:18 AM
  • Have tried copying the source MSI somewhere different, like a local location on a system and testing?

    If that works, you can then try from a UNC.

    If both of those work, it could be an issue with the repair over HTTP.

    What OS is the client?


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

    Tuesday, July 18, 2017 12:36 AM
  • Editing: [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\96F071321C0420727100000010000000\SourceList\URL]

    1. Set key value to: \\CM01\packagesource\Library\Applications\7zip\
    2. Repair Success
    3. Clear ccm cache. 
    4. Set key value to: C:\temp\7zip
    5. Repair Success
    6. Clear ccm cache. 
    7. Set key value to:http://cm01.corp.viamonstra.com:80/sms_dp_smspkg$/content_1a0a7c54-eb73-4fa4-972f-b97bfa9e3452.1/
    8. Repair error
    9. Clear ccm cache.
    10. Set key value to: http://testsite/7zip
    11. Repair Error

    All repair errors are: "The filename, directory name, or volume label syntax is incorrect."

    http://testsite is a new IIS website I setup for testing. Target user/computer can browse to and download the MSI via the web browser.

    Even though im reproducing in a lab, I am getting the same error in our production environment.

    Tuesday, July 18, 2017 12:54 AM
  • What OS is the client?

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

    Tuesday, July 18, 2017 1:51 AM
  • Mainly Win10 1607.

    Also happens on Win10 1511.

    Tuesday, July 18, 2017 1:54 AM
  • There were hotfixes for Win 7 and 8: https://support.microsoft.com/en-us/help/3139923/windows-installer-msi-repair-doesn-t-work-when-msi-package-is-installe

    Setting the WinHttpAutoLogonLevel policy (using group policy or by directly changing the registry value) may also help: https://msdn.microsoft.com/en-us/library/windows/desktop/hh706787(v=vs.85).aspx


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


    Tuesday, July 18, 2017 2:06 AM
  • Tried setting it to Low and I got the same error.
    Tuesday, July 18, 2017 2:21 AM
  • Time to open a support case with Microsoft CSS then.

    I don't think most people ever test or use this functionality so it's something that's probably slipped through. It's clearly a Windows 10 issue even though its preventing a ConfigMgr feature from working.


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

    • Marked as answer by Adam Mancini Tuesday, July 18, 2017 2:39 AM
    Tuesday, July 18, 2017 2:32 AM
  • Thanks for you assistance with this issue, Jason. I will see if we can raise a support call.

    I'll build up a patched Win7 machine and see what happens.

    Tuesday, July 18, 2017 2:39 AM
  • Thanks for you assistance with this issue, Jason. I will see if we can raise a support call.

    I'll build up a patched Win7 machine and see what happens.

    Did you ever get to the bottom of this, we are having the exact same issues?

    It's happening on our Windows 7 Machines too

    Edit - Found a solution to this, the thread is here https://support.microsoft.com/en-us/help/2918614/ms14-049-description-of-the-security-update-for-windows-installer-serv

    Basically you have to add the Product Code of the msi you are using for your repair as a string value in the SecureRepairWhitelist key......

    Thursday, October 12, 2017 9:23 AM
  • Hi Adam,

    We have a case open with Microsoft as some of our environments the cache gets filled quickly. Did you log one?

    Packages can be worked around - copying to share, although it does take up space. No solution for Application Model.

     

    Monday, October 30, 2017 11:58 PM
  • I was going to suggest "Allow Anonymous", which solved the issue for us with Packages years ago but I see you tried already...

    Jack

    • Edited by JFetter Tuesday, October 31, 2017 3:13 AM
    Tuesday, October 31, 2017 3:11 AM
  • There was 2 security issues, these go back about 2 years -

    Microsoft made changes so MSI Installer needs to verify the hash value of the MSI.

    The second change was to only Authenticate to intranet sites (Which you cant add to a list and it doesn't include the sccm FQDN) when doing MSI install/repair. So that forces everyone enable Anonymous access on Distribution points OR set your security to low and trust everyone.
    .

    This third issue, I don't have a date for as we have been using packages with a workaround

    It seems to happen when verifying the hash of the msi file. The log file shows it opening an incorrect URL as it adds a backslash. I think that's the issue.


    • Edited by Jay - HappySCCM Tuesday, October 31, 2017 5:09 AM To make sense
    Tuesday, October 31, 2017 3:43 AM
  • Hi Everyone,

    Sorry I did not have alerts enabled for this thread.

    @Brian - yes we implemented the SecureRepairWhitelist workaround

    @Jack - Yep - anonymous access did not help.

    @Jay - No we did not log a case with Microsoft. Nice observation - bug with Windows Installer?

    Monday, January 8, 2018 3:12 AM
  • Hi all,

    Update:

    The issue has been logged with Microsoft and currently they are not exactly sure except that the ACL token isn't being set correctly. And the only account that works is the built-in Administrator account.

    This is now with the product team but feel free to log your issue referencing this forum post and my case REG:117102316533973 if you are affected.

    I also have a user voice suggestion for a SCCM work around that needs votes :)

    https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/32849911-enable-copy-the-content-in-this-package-to-a-pack

    Monday, January 8, 2018 3:48 AM
  • It looks like Microsoft product group don't have plans on fixing this since they don't have plans on further developing msi/windows installer. Going to test the whitelist using registry on the link below, too hard to fight for a fix :)

    https://support.microsoft.com/en-us/help/2918614/ms14-049-description-of-the-security-update-for-windows-installer-serv

    Thursday, March 22, 2018 5:53 AM
  • Is there any further update to this? We are getting constant issues now doing an in-place upgrade (8.1 - 10(1709)) and applications requiring a repair post upgrade.

    Of course generally the application source has slipped out of the CCMCACHE and it is prompting for source. I was really hoping this option would be fixed by now.

    My only other option is to inject the network source location into the registry for each application we find with this issue which frankly is a pain.


    • Edited by DavoPaulo Thursday, July 5, 2018 12:52 AM
    Thursday, July 5, 2018 12:46 AM
  • Create a package and program for each msi app
    - Enable 'Copy the content in this package to a package share on distribution points'
    - Import the msi on the programs properties.

    You don't have to advertise this program.

    It's not getting fixed but maybe make some noise with a ticket if you want.

    Thursday, July 5, 2018 12:54 AM
  • Cheers for that grumble grumble. 

    Probably stick with my current method applying the network location in the registry by a compliance rule.

    But yes I have been meaning to raise a ticket for a while.

    Thursday, July 5, 2018 12:59 AM
  • Any thoughts on this? When I repair an app that uses the SCCM URL as system it truncates the source paths with ~1 - as in 

    <DISTRIBUTION POINT>/sms_dp_smspkg$/content_424a11e5-d87f-4d07-b624-4837352583c6.1//PROGRA~1/CISCOS~1/CISCOI~1/IPCOMM~1.VBS

    Whereas the file is accessible - 

    <DISTRIBUTION POINT>/sms_dp_smspkg$/content_424a11e5-d87f-4d07-b624-4837352583c6.1/program%20files/Cisco%20Systems/Cisco%20IP%20Communicator/IPCommunicatorWrapper.vbs

    I expect it may be the MSI itself that is at fault here so either way if the issue is fixed it would not help in this case.

    Thursday, July 5, 2018 2:48 AM