you are getting your policies. the issue with not getting the wsus updates has to do with an incorrect setting in the actual wsus GPO itself.
change Set the intranet update service for detecting updates: //per510:8530/selfupdate
to Set the intranet update service for detecting updates: //per510 <--- assuming this is also your WSUS.
change Set the intranet update service for detecting updates: //per510:8530/selfupdate
to Set the intranet update service for detecting updates: //per510 <--- assuming this is also your WSUS.
Done!
And this is another client computer just to clear the client computer from being the issue
Result
Why would my test computer poilcy be being filtered? what else can it be?
And this is another client computer just to clear the client computer from being the issue
Result
Why would my test computer poilcy be being filtered? what else can it be?
Last edited:
Please post a screenshot of the computer in the computer OU. From all your screen shots, I don't see a computer OU or a users OU for that matter. Also stacking all kinds of group policy objects at the domain root is recipe for a mess.
The windows security groups have little to do with group policy and they do not do what I think you think they do.
For example, I can see than you have CN=JB Pollard,CN=Users,DC=chesapeakcontrols,DC=local and CN=PATSYEVANS,CN=Computers,DC=chesapeakcontrols,DC=local.
That user and computer are not in in an OU and group policy will not apply consistently.
It would be correct if it looked like this:
CN=JB Pollard,OU=CH Users,DC=chesapeakcontrols,DC=local
Where the OU was CH Users
The windows security groups have little to do with group policy and they do not do what I think you think they do.
For example, I can see than you have CN=JB Pollard,CN=Users,DC=chesapeakcontrols,DC=local and CN=PATSYEVANS,CN=Computers,DC=chesapeakcontrols,DC=local.
That user and computer are not in in an OU and group policy will not apply consistently.
It would be correct if it looked like this:
CN=JB Pollard,OU=CH Users,DC=chesapeakcontrols,DC=local
Where the OU was CH Users
Last edited:
Took your advice
This is what I had and all the computers where in the computer container
This is what your saying to do
This is what I had and all the computers where in the computer container
This is what your saying to do
And then add each gpo in the OU like i did here for windows update servers. So id drop all the gpo for users in the chesapeake controls user OU and all the computer gpo in the chesapeake controls computers OU
That is the jist of it yes. You can also create OU's inside OU's. This is handy if you want to divide up the Users in to say departments
IE
OU Users
|
---> Accounting
|
---> Warehouse
etc
Anything you apply at the Users level hits everyone while you can attach smaller targeted GPO at the other groups.
Generally avoid going more than 4 layers deep. When you hit that level, there is typically a better way.
In that picture, (the one with Windows Update Services highlighted) your security filtering has no users in it so it won't apply. The default entry would be "Authenticated Users." You should readd that. Or at least add the computers you want it to apply to.
You divide this up like this because it is very rare that you have the exact same settings applied to the Domain controllers and user workstations. 95% of your GPO config should be down in that area.
IE
OU Users
|
---> Accounting
|
---> Warehouse
etc
Anything you apply at the Users level hits everyone while you can attach smaller targeted GPO at the other groups.
Generally avoid going more than 4 layers deep. When you hit that level, there is typically a better way.
In that picture, (the one with Windows Update Services highlighted) your security filtering has no users in it so it won't apply. The default entry would be "Authenticated Users." You should readd that. Or at least add the computers you want it to apply to.
You divide this up like this because it is very rare that you have the exact same settings applied to the Domain controllers and user workstations. 95% of your GPO config should be down in that area.
Last edited:
Genius it works!
Thanks a ton Ive been pissed of for days!!
Is there anyway to automatically add the windows update services gpo to all computers in the domain without having to join them first then move the computer into the Chesapeake Controls Computer OU?
In order to managed a computer via the domain, it needs to be a member of the domain. However you can dump the registry info from one PC to another, it just might not work quite as you expect.
It is worth the effort to do the leg work and get them all joined.
I guess what i was trying to say is after I join them to the network and there still just in the computer container getting wsus gpo to apply before i drop it in the OU? Not a big deal I only have about 15 user computers that I want to apply this to
GPO's only apply to the items in the OU they are attached so you need to move them after you join them. This becomes far more obvious if you deploy via AD as moving the computers / users around can cause apps to be uninstalled.
If the GPO is at the domain level, sure it will. You can't attach a GPO to the users or computers containers, but objects in those containers can absolutely get policy linked at a higher level. GPOs don't apply inconsistently. They either work or they don't.
The wsus gpo at the domain level wouldn't apply that was my whole problem as soon as I moved all the users and computers in to OU's and applied the gpo to it everything worked
That wasn't your problem. Your screenshot on the first page clearly shows that the WSUS policy linked at the domain level was being applied before you moved the computer and user objects into OUs.
Last edited:
My replies are based on 'MS best practices.' You are right, they should work however in real life I have found that not always to be the case and have had strange errors appear. For example, here in my own office, when I add a new computer to the domain, while in the computers container, it will not pick up the NTLM settings until I move the computer to the proper group even though that is applied at the DC level.
The recommended way is to place machines and users in to OU's and apply from there. As such I stand by my direction.
I view applying all group policy to the root of the domain just to make the default containers work a disaster waiting to happen. It is very rare that you actually want every machine (including servers) following the same policies. You can block it with inheritance blocking but that is even messier.
pollardhimself did have the security on the GPO wrong in some cases which would have also caused him problems. I wanted to fix it "right" before we messed around with it further.
I mean we can send network data down a couple of coat hangers... but may as well use network cables no?
Last edited:
I missed that is applied I must have been looking at the user settings, one of my other polices that was applied at the domain level must have had conflict with it. All I care is it works and id rather do it the correct way to avoid further issues down the road thanks for all the help
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter