none
GPO package deploy after logon

    Question

  • Hi All,

    I'm still fairly new to the whole GPO world but have been having some good successes with things.  However, I've run into a snag with one of my .msi files.  Running it manually I can install it from the .msi silently without issue.  However when I put it into a GPO in either user or computer configuration sections I get the error message:

    The error was : %%1603

    From what I can find on this its likely a permissions error on the install itself.  I was hoping that by making it a user item I could get around it but looks like it is still not executing the package in the context of the actual user signing into the machine.  My next step is to get a verbose msi log when I install it manually just to see what its touching. 

    Any ideas on how to get this deployed?

    Thanks

    Monday, October 12, 2015 3:38 PM

Answers

  • > You are correct that error 1603 usually indicates a permission issue.
     
    No.
     
    1603 is the generic installer error if something INSIDE the msi went
    wrong. So - at least to my experience - 1603 NEVER is a permission
    issue, but mostly a custom action or a locked file or whatever else. It
    is a pity that installer masks the real error code with this 1603
    (0x80070643) for ages now.
     
    # as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x643
    # for hex 0x643 / decimal 1603 :
      ERROR_INSTALL_FAILURE
    winerror.h
    # Fatal error during installation.
     
    To find the root cause, you should enable installer logging, then
    redeploy your package and examine the msi*.log files in %windir%\temp.
     
    To enable logging, enable http://gpsearch.azurewebsites.net/#1985 and
    set it to "voicewarmup" (really :-))
     
    A permission issue on the source file would result in 1612.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, October 13, 2015 11:24 AM

All replies

  • However when I put it into a GPO in either user or computer configuration sections I get the error message:

    The error was : %%1603


    You mean the "Software Installation" policy setting under Computer Configuration\Policies\Software Settings? Could you please share the detailed steps on how you did this?
     
    You are correct that error 1603 usually indicates a permission issue (Edit: As was pointed out below, this is not correct. There are different known causes for this error to occur, the most recommended troubleshooting step is to re-run the setup with logging enabled). When doing this, the first step is to create a distribution point/shared folder on the publishing server, then copy the .MSI file into it.
     
    Please make sure that you have configured the permissions on this folder in order to allow access to the distribution package.
     

    Regards,

    Ethan Hua


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com


    Tuesday, October 13, 2015 8:00 AM
    Moderator
  • Check your steps against this article and see if anything missed:

    https://support.microsoft.com/en-us/kb/816102

    Tuesday, October 13, 2015 8:07 AM
  • > You are correct that error 1603 usually indicates a permission issue.
     
    No.
     
    1603 is the generic installer error if something INSIDE the msi went
    wrong. So - at least to my experience - 1603 NEVER is a permission
    issue, but mostly a custom action or a locked file or whatever else. It
    is a pity that installer masks the real error code with this 1603
    (0x80070643) for ages now.
     
    # as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x643
    # for hex 0x643 / decimal 1603 :
      ERROR_INSTALL_FAILURE
    winerror.h
    # Fatal error during installation.
     
    To find the root cause, you should enable installer logging, then
    redeploy your package and examine the msi*.log files in %windir%\temp.
     
    To enable logging, enable http://gpsearch.azurewebsites.net/#1985 and
    set it to "voicewarmup" (really :-))
     
    A permission issue on the source file would result in 1612.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, October 13, 2015 11:24 AM
  • Correct.  It is in the User configuration | Policies | Software Settings | Software installation.  I have tried it in both User and Computer Configuration to the same result. 

    I double checked folder level permissions and they are ok.  Also there is a second .msi in a parallel folder that I am able to deploy from Computer Configuration without issue. 

    Tuesday, October 13, 2015 1:01 PM
  • here's a thing to try

    turn off client side firewall

    also turn off " use sharing wizard " on client folder options

    retry


    • Edited by AlexAdkin Tuesday, October 13, 2015 6:58 PM
    Tuesday, October 13, 2015 6:58 PM
  • 1603 is the generic installer error if something INSIDE the msi went
    wrong. So - at least to my experience - 1603 NEVER is a permission
    issue, but mostly a custom action or a locked file or whatever else. It
    is a pity that installer masks the real error code with this 1603
    (0x80070643) for ages now
    This is a great lesson. Thank you Martin for pointing out this.
     

    Regards,

    Ethan Hua


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Wednesday, October 14, 2015 1:53 AM
    Moderator
  • No.
     
    1603 is the generic installer error if something INSIDE the msi went
    wrong. So - at least to my experience - 1603 NEVER is a permission
    issue, but mostly a custom action or a locked file or whatever else. It
    is a pity that installer masks the real error code with this 1603
    (0x80070643) for ages now.
     

    Maybe not that absolute. My opinion is permission is at least one of the possible cause of this generic error. I can see some cases about this over the net. :) (the Cause section in the kb article shared Aravindhan above)

    Jarrod, for the specific question, as suggested by Martin, examine the msi*.log files in %windir%\temp...

    --

    Jacob

    Wednesday, October 14, 2015 2:06 AM
  • Hi,
     
    How is it going? Have you ever tried to enable the installer logging, and any useful info out there?
     

    Regards,

    Ethan Hua


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Monday, October 19, 2015 10:30 AM
    Moderator