GPO Software Deployment Woes



  • I am working on migrating a Server 2008 R2 domain controller pair over to Server 2016. I have demoted one of the 2008 DCs and promoted a Server 2016 DC in its place. For the most part, things seem good and happy, though I'm missing something I'm sure...

    One oversight on my part was that when the Server 2008 DCs were built, I created a share on the DC itself to house files related to the Group Policies that I set up. This wasn't a big deal until it came time to retire that DC. I needed to modify all of the GPOs that point to files on that share to a new location. No big deal, right? So I copied the files to a new share on a Server 2016 file server in the environment, then edited all of the respective GPOs so that they point to the new share. All of the GPOs that reference files in the new share are happily using it, except for my Software Installation (MSI) GPOs. However, clients now now bomb on every Software Installation GPO with error 1612, which from what I understand is that the source is not available.

    I've checked the source path on the GPOs multiple times and it is correct. I've checked the permissions on the share and they should be good. The share permissions are set to Everyone with Full Control, Change, and Read all checked. The NTFS permissions are set so that Everyone, Authenticated Users, and Domain Computers can Read and Execute everything within the folder, subfolders, and files. But yet, no dice.

    Something I just thought of while typing this out is to perhaps try to specify the FQDN of the file server in the UNC path. For reference, the share is \\filesrv02\gposw$ Not that it should matter, but perhaps \\filesrv02.domain.org\gposw$ will make a difference? I'll try it for the heck of it I suppose...

    Any clue what I'm missing?



  • Help yourself in the future - make a cname DNS record for the new server and use that. Then in the future, you just have to change the DNS record instead of changing the GPOs.



  • As for your issue - have you run gpresult on a client and looked at it's error - or is that where you got the 1612 error from?



  • @Dashrender

    @Dashrender said in GPO Software Deployment Woes:

    Help yourself in the future - make a cname DNS record for the new server and use that. Then in the future, you just have to change the DNS record instead of changing the GPOs.

    Ooo that's not a bad idea. I could create a CNAME of "gposhare". I may do this once I get this sorted out.



  • @Dashrender said in GPO Software Deployment Woes:

    As for your issue - have you run gpresult on a client and looked at it's error - or is that where you got the 1612 error from?

    I grabbed that from the Event Viewer. I'll see if gpresult returns anything different.



  • @anthonyh said in GPO Software Deployment Woes:

    @Dashrender said in GPO Software Deployment Woes:

    As for your issue - have you run gpresult on a client and looked at it's error - or is that where you got the 1612 error from?

    I grabbed that from the Event Viewer. I'll see if gpresult returns anything different.

    For all of the Software Installs GPOs it just shows a Deployment State of "Assigned" and AutoInstall "True". A sample of one is below:

            GPO: SW Distribution - ESET Endpoint AV
                Name:             ESET Endpoint Antivirus (6.6.2089.2)
                Version:          6.6
                Deployment State: Assigned
                Source:           \\filesrv02\gposw$\eset\eea_nt64_enu_6.6.2089.2.msi
                AutoInstall:      True
                Origin:           Applied Application
    

    But in the Event Viewer it states:

    The install of application ESET Endpoint Antivirus (6.6.2089.2) from policy SW Distribution - ESET Endpoint AV failed. The error was : %%1612



  • To add:

    When using the Effective Access feature of Advanced Security Settings for the share, if I specify the user/group of "Authenticated Users", it shows success for the various execute and read permissions. If I do the same for "Domain Computers", it shows no access at all. Though my understanding is that "Authenticated Users" is supposed to encompass computer accounts as well and supersede "Domain Computers", but it is odd nonetheless since I explicitly give "Domain Computers" read/execute just like "Authenticated Users".



  • @anthonyh said in GPO Software Deployment Woes:

    To add:

    When using the Effective Access feature of Advanced Security Settings for the share, if I specify the user/group of "Authenticated Users", it shows success for the various execute and read permissions. If I do the same for "Domain Computers", it shows no access at all. Though my understanding is that "Authenticated Users" is supposed to encompass computer accounts as well and supersede "Domain Computers", but it is odd nonetheless since I explicitly give "Domain Computers" read/execute just like "Authenticated Users".

    That is correct. Domain computers are included in Authenticated Users.



  • @wrx7m said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    To add:

    When using the Effective Access feature of Advanced Security Settings for the share, if I specify the user/group of "Authenticated Users", it shows success for the various execute and read permissions. If I do the same for "Domain Computers", it shows no access at all. Though my understanding is that "Authenticated Users" is supposed to encompass computer accounts as well and supersede "Domain Computers", but it is odd nonetheless since I explicitly give "Domain Computers" read/execute just like "Authenticated Users".

    That is correct. Domain computers are included in Authenticated Users.

    Thanks for the confirmation!



  • Are your GPOs working now?



  • @wrx7m said in GPO Software Deployment Woes:

    Are your GPOs working now?

    Nope, as that's the permissions I've had set when this started. I'm really pulling my hair out on this one...



  • @anthonyh said in GPO Software Deployment Woes:

    @wrx7m said in GPO Software Deployment Woes:

    Are your GPOs working now?

    Nope, as that's the permissions I've had set when this started. I'm really pulling my hair out on this one...

    What does the security filtering look like for the GPO? If you removed authenticated users from there, you need to make sure that you add it as read in the delegation tab.



  • @wrx7m said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    @wrx7m said in GPO Software Deployment Woes:

    Are your GPOs working now?

    Nope, as that's the permissions I've had set when this started. I'm really pulling my hair out on this one...

    What does the security filtering look like for the GPO? If you removed authenticated users from there, you need to make sure that you add it as read in the delegation tab.

    The security filtering has both "Authenticated Users" and "Domain Computers" listed (I added Domain Computers after the fact in desperation). The Delegation tab has them both listed as well as "Read (from Security Filtering).

    The GPOs are running, it's the install that fails with error 1612.

    I need to figure out how to see if the GPO is actually trying to grab the files or not. And if it is and failing, why...



  • @anthonyh said in GPO Software Deployment Woes:

    error 1612

    Just to confirm, the share that the GPO is pointing to, has read permissions set for authenticated users all the way down to the msi file, right?



  • @wrx7m said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    error 1612

    Just to confirm, the share that the GPO is pointing to, has read permissions set for authenticated users all the way down to the msi file, right?

    Using the files from the example GPO information I posted earlier:

    Authenticated Users, Domain Computers, and even Everyone has read & execute set for the root folder (gposw). The share permissions are set to Everyone with Full Control

    The subfolder eset is inheriting these permissions properly (at least per the Advanced Security Settings dialog box).

    The file eea_nt64_enu_6.6.2089.2.msi is inheriting the expected permissions as well.



  • Hmmm. What if you create a new share and see if that works?



  • @wrx7m said in GPO Software Deployment Woes:

    Hmmm. What if you create a new share and see if that works?

    Yeah, that's an option. I may try this first to see if I can get some clarification on if it's even attempting to hit the share first...

    https://www.rootusers.com/configure-file-access-auditing-in-windows-server-2016/



  • @anthonyh Have you created a new GPO from scratch too?



  • @wrx7m said in GPO Software Deployment Woes:

    @anthonyh Have you created a new GPO from scratch too?

    No, that's something to test too.

    I'd really like to get these existing Software Installation GPOs working if at all possible. I imagine there will be some havoc if I delete and re-create them...



  • Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?



  • @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?



  • @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?

    Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.



  • @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?

    Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

    Yes, I was typing this before:


    Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”



  • @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?

    Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

    Yes, I was typing this before:


    Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”

    No, I haven't tried that. Can you delete and re-add software packages to the GPO without it triggering an attempt to re-install them? I want to avoid triggering all of my clients to re-install everything and then wig out because it's all already installed...if that makes sense.



  • @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?

    Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

    Yes, I was typing this before:


    Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”

    No, I haven't tried that. Can you delete and re-add software packages to the GPO without it triggering an attempt to re-install them? I want to avoid triggering all of my clients to re-install everything and then wig out because it's all already installed...if that makes sense.

    You can do this
    https://support.microsoft.com/en-us/help/2395088/how-to-change-the-msi-file-location-in-the-software-deployment-gpo-mut

    Or redploy the application, I assume you have set the Package to uninstall when it falls out of the scope?



  • @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    @dbeato said in GPO Software Deployment Woes:

    @anthonyh said in GPO Software Deployment Woes:

    Alright, for the heck of it, I re-created the share on my new DC (it assumed the same name as the DC it replaced, which was the DC originally hosting these files). And, guess what? All of the software installation policies applied successfully.

    So even though I'm changing the msiFileList in ADSI Edit, it's not applying somewere. Even though looking at the Deployment Information of the GPOs shows the modified path, and running gpresult shows the modified path.

    What the heck?!

    I may just kick this can down the road a bit and re-visit it later unless anyone has any ideas?

    For the heck of it, do you get to access the share while on Windows Explorer?

    Yes. I think the problem is somewhere in the bowels of the GPOs the path isn't updating.

    Yes, I was typing this before:


    Just for my own sanity reading this Thread, did you actually import each software back again from the new share? Because sometimes that is what it takes”

    No, I haven't tried that. Can you delete and re-add software packages to the GPO without it triggering an attempt to re-install them? I want to avoid triggering all of my clients to re-install everything and then wig out because it's all already installed...if that makes sense.

    You can do this
    https://support.microsoft.com/en-us/help/2395088/how-to-change-the-msi-file-location-in-the-software-deployment-gpo-mut

    Or redploy the application, I assume you have set the Package to uninstall when it falls out of the scope?

    That link is the exact article I followed.

    Some are set to uninstall when out of scope, some are not.



  • Also diplicate the GPO and then setup a TEST ou and test it there with a VM or Desktop you can test.



  • @dbeato said in GPO Software Deployment Woes:

    Also diplicate the GPO and then setup a TEST ou and test it there with a VM or Desktop you can test.

    Yeah. I'll do that. I'll set up a GPO software deployment in a test OU and then remove/re-add the package and see what happens.



  • Is your filesrv02 the actual name of the machine? I remember seeing a mention of using a DNS record... I may be wrong but IIRC DNS redirection and modern SMB don't always work together very well because Kerberos. Like I said, might be completely out to lunch on this one, still working on my 1st coffee of the day.



  • @notverypunny said in GPO Software Deployment Woes:

    Is your filesrv02 the actual name of the machine? I remember seeing a mention of using a DNS record... I may be wrong but IIRC DNS redirection and modern SMB don't always work together very well because Kerberos. Like I said, might be completely out to lunch on this one, still working on my 1st coffee of the day.

    Boy I hope not, otherwise that precludes the ability to use a generic servername that can be assigned to be used so moving the share is easy.


Log in to reply