Install Software via GPO - Computer Configuration vs User Configuration
-
So this is where it currently stands, as it works like this, but not the way we want it to.
Without editing it as it stands, this is where we were placing the same script path when we were doing it via Computer Config.
-
Show me which OU it is linked to and I would also like to see the filtering settings
-
@IRJ said:
Show me which OU it is linked to and I would also like to see the filtering settings
What do you need to see in the OU? And okay, give me just a minute.
-
Security Group we WERE testing with for the security filtering:
Members include our domain admin account (because it wasn't working as a computer config GPO) and our VM that we use:
Our new security group is part of no other groups:
This is the OU we've been trying to use:
GPO is not currently linked and no filters are in place, but we were using the softwareinstallation security group as the security filter for the link at the root level.
-
Is that what you needed @IRJ ?
-
-
The Security Filtering cannot be empty or else nothing will be applied. Computers are treated as Authenticated Users as well.
-
@IRJ said:
The Security Filtering cannot be empty or else nothing will be applied. Computers are treated as Authenticated Users as well.
Yes, I know. When we try adding a computer directly, it gave some error message if we didn't have a security group in there. Also, we removed authenticated users, but now that I think about it, if we're doing a computer config GPO and we leave Authenticated users in there and then just subsequently add all our computers, shouldn't it work? It'll apply the GPO to all authenticated users but because it's a computer config and not user config GPO, that doesn't hurt us, right?
-
Security Filtering is used more with User GPOs than it is with Computer GPOs. I usually just leave the default "Authenticated Users" which will include all computers in the OU that the GPO is linked with.
-
@thanksaj said:
@IRJ said:
The Security Filtering cannot be empty or else nothing will be applied. Computers are treated as Authenticated Users as well.
then just subsequently add all our computers, shouldn't it work? It'll apply the GPO to all authenticated users but because it's a computer config and not user config GPO, that doesn't hurt us, right?
Yes
-
Try testing again and let me know if it works
-
Testing it right now.
-
Tested it but it didn't work. The script was placed in startup and I had the security filter using Authenticated Users and just the VM that we use that I'm testing this with. I ran gpupdate /force and confirmed it applied. It didn't work.
-
Open a Run prompt and type in rsop.msc
What do you see here?
-
Looks like the script is running, as that last execution time is when I last rebooted.
-
I just rebooted again and it ran again, but still didn't install. Am I missing something?
-
Does the 'authenticated users' group have permissions to the folder where your files are located?
I personally don't like messing with security filtering until AFTER everything else tests OK. This is one place where most people muck it up and change all sorts of other things when it's this aspect that is incorrect.
-
@IRJ and I kind of figured out that it probably isn't running because the script pulls the installer from a domain path, which if it's a computer config, it runs as local admin right? That would mean it wouldn't have access to a domain path, maybe. Still haven't gotten it working..
-
It is actually the system account, not local administrator since we are talking about an computer object and actual users do not come into play here. If the share and subsequent files don't have 'authenticated users' or that computer name somehow (either by group or by name) specified with permissions, then you are correct, the computer's system account won't be able to access those files and your installation will fail.
-
Why do the installation through a script? Can you create a package for it instead and publish it in GP?
