Install Software via GPO - Computer Configuration vs User Configuration
-
@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?
-
@Dashrender said:
Why do the installation through a script? Can you create a package for it instead and publish it in GP?
Haven't found a way to bundle Lync 2013 client as an MSI, so no.
-
@Rob-Dunn said:
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.
The share has permissions for "Everyone" to have "Read" access. Is that enough?
-
@thanksaj this should work just fine. If you want to exclude other accounts like 'guest' and 'local service' - i.e. non-passworded accounts, use 'authenticated users' instead.
If there is ever any need for anyone (and I mean anyone) to write anything to this share, you're going to want to change 'everyone' to 'full control' on the share, and then set the permissions on the folder for read only for that group. That way, administrators can still mount the share and write/edit files there.
-
@Rob-Dunn said:
@thanksaj this should work just fine. If you want to exclude other accounts like 'guest' and 'local service' - i.e. non-passworded accounts, use 'authenticated users' instead.
If there is ever any need for anyone (and I mean anyone) to write anything to this share, you're going to want to change 'everyone' to 'full control' on the share, and then set the permissions on the folder for read only for that group. That way, administrators can still mount the share and write/edit files there.
Yeah, that's fine. Just trying to figure out why my GPOs and scripts aren't working...
-
I just tested the commands from the local admin account. Now could the issue be where these scripts are located? I have them on one of the DC's NETLOGON folders. That should be fine AFAIK, but it seems like the computer config GPOs are having issues pulling from a domain location, even the scripts. Any thoughts?
-
@thanksaj
Using the local admin account is not the same as the computer using the computer account - these are two different things. The local administrator account will access the files in the context of a user object (albeit a local user), whereas the computer will access them as the computer object (a domain computer object). Kind of an odd concept to grasp, but the computer has it's own identity when it accesses network resources.
-
@Rob-Dunn said:
@thanksaj
Using the local admin account is not the same as the computer using the computer account - these are two different things. The local administrator account will access the files in the context of a user object (albeit a local user), whereas the computer will access them as the computer object (a domain computer object). Kind of an odd concept to grasp, but the computer has it's own identity when it accesses network resources.
Ok, so it should have the permissions to access a domain resource then? That's what I always figured but this whole thing is getting confusing.
