Constant WSUS issues (Connection Errors)
-
Make sure under Delegation tab, you have Authenticated Users with Read Permissions for your Policy. Especially if you removed it from the Security Filtering.
-
@dbeato said in Constant WSUS issues (Connection Errors):
@dave247 said in Constant WSUS issues (Connection Errors):
@momurda said in Constant WSUS issues (Connection Errors):
@dave247 Yes. I apply an 'wsus' gpo to my Workstations OU. This gets all computers in the OU to show up in wsus. In wsus i make groups(local to wsus application) for grouping computers by OS.
Damn, that sounds like a much better approach. That way I don't have to add the extra step of adding all my computers to an additional AD group. So is this just a matter of not configuring the "Enable client-side" targeting option? I'm only asking because it seems like it's taking WSUS a long time before computers show up. It took like 2 days before 3 out of 7 systems showed up under the All Computers group..
Group assigments take faster to apply than OUs.
Not really, sometimes they show up instantly, other times they do not. I don't know why, but one way is not faster than the other. It just does not work like that.
When I set up a new computer, it always shows up in WSUS instantly and in the correct WSUS group. When I set an old existing computer, it typically shows up instantly.
But you have to have eveyrthing set up correctly.
-
@dave247 said in Constant WSUS issues (Connection Errors):
@momurda said in Constant WSUS issues (Connection Errors):
@dave247 Yes. I apply an 'wsus' gpo to my Workstations OU. This gets all computers in the OU to show up in wsus. In wsus i make groups(local to wsus application) for grouping computers by OS.
Damn, that sounds like a much better approach. That way I don't have to add the extra step of adding all my computers to an additional AD group. So is this just a matter of not configuring the "Enable client-side" targeting option? I'm only asking because it seems like it's taking WSUS a long time before computers show up. It took like 2 days before 3 out of 7 systems showed up under the All Computers group..
I would have originally done it that way too... but we have way too many client computers and servers to go dicking around in WSUS console every time we add a computer to WSUS (especially after initial setup, F that repetitive crap). It's MUCH simpler to stick a computer or server in an AD group, and well... that's it! Nothing more to it than that.
Step one: Put computer or server into correct AD group.
Step two: Reboot or useklist -li 0x3e7then gpupdate.Done.
Everything else is 100% automated.
-
@tim_g said in Constant WSUS issues (Connection Errors):
@dave247 said in Constant WSUS issues (Connection Errors):
@momurda said in Constant WSUS issues (Connection Errors):
@dave247 Yes. I apply an 'wsus' gpo to my Workstations OU. This gets all computers in the OU to show up in wsus. In wsus i make groups(local to wsus application) for grouping computers by OS.
Damn, that sounds like a much better approach. That way I don't have to add the extra step of adding all my computers to an additional AD group. So is this just a matter of not configuring the "Enable client-side" targeting option? I'm only asking because it seems like it's taking WSUS a long time before computers show up. It took like 2 days before 3 out of 7 systems showed up under the All Computers group..
I would have originally done it that way too... but we have way too many client computers and servers to go dicking around in WSUS console every time we add a computer to WSUS (especially after initial setup, F that repetitive crap). It's MUCH simpler to stick a computer or server in an AD group, and well... that's it! Nothing more to it than that.
Step one: Put computer or server into correct AD group.
Step two: Reboot or useklist -li 0x3e7then gpupdate.Done.
Everything else is 100% automated.
Ok you sweet talked me back into doing it that way. Do you have a separate AD group and GPO for each type of Windows OS (Windows 7, 8.1, 10; Server 2012, etc)?
And I found out why I wasn't seeing machines show up right away. Status had "Failed or Needed" selected by default and when I changed it to "any" I can now see all the computers that have the WSUS GPO applied to them. Now I just need to finish reading through the guide so I can learn the right way of going about approving and installing updates..
Also, do you use that
klist -li 0x3e7on the system needing the update remotely through Powershell or what? I'm just asking because I always discover that I've been doing things the idiot way..Also also, do you guys suggest downloading drivers as well? We also have a handful of SQL servers, should I include SQL Service Packs for those or is that something I should just do manually, to avoid problems?
Here's my classification selections:
-
@dave247 said in Constant WSUS issues (Connection Errors):
@tim_g said in Constant WSUS issues (Connection Errors):
@dave247 said in Constant WSUS issues (Connection Errors):
@momurda said in Constant WSUS issues (Connection Errors):
@dave247 Yes. I apply an 'wsus' gpo to my Workstations OU. This gets all computers in the OU to show up in wsus. In wsus i make groups(local to wsus application) for grouping computers by OS.
Damn, that sounds like a much better approach. That way I don't have to add the extra step of adding all my computers to an additional AD group. So is this just a matter of not configuring the "Enable client-side" targeting option? I'm only asking because it seems like it's taking WSUS a long time before computers show up. It took like 2 days before 3 out of 7 systems showed up under the All Computers group..
I would have originally done it that way too... but we have way too many client computers and servers to go dicking around in WSUS console every time we add a computer to WSUS (especially after initial setup, F that repetitive crap). It's MUCH simpler to stick a computer or server in an AD group, and well... that's it! Nothing more to it than that.
Step one: Put computer or server into correct AD group.
Step two: Reboot or useklist -li 0x3e7then gpupdate.Done.
Everything else is 100% automated.
Ok you sweet talked me back into doing it that way. Do you have a separate AD group and GPO for each type of Windows OS (Windows 7, 8.1, 10; Server 2012, etc)?
We only have like 2 or 3 Win8 computers, and those are just set to automatically update.
AD Groups:
Group Policies:
WSUS Groups:
Note, I left out the Hyper-V Server stuff. I've been doing those manually since there's so few and they are fast.
-
@dave247 said in Constant WSUS issues (Connection Errors):
Also, do you use that klist -li 0x3e7 on the system needing the update remotely through Powershell or what? I'm just asking because I always discover that I've been doing things the idiot way..
I've been using PsExec, mostly out of habit and ease.
But really, I set up WSUS, as well as mandatory automatic weekly reboots. So I really didn't have to do anything after I first set it up. Just testing, and then I waited for everything to happen the following week.
-
@dave247 said in Constant WSUS issues (Connection Errors):
Also also, do you guys suggest downloading drivers as well? We also have a handful of SQL servers, should I include SQL Service Packs for those or is that something I should just do manually, to avoid problems?
Never do drivers.
All I do for Win7 (since those are phasing out):
- Critical Updates
- Definition Updates
- Security Updates
For Windows10:
- Everything except drivers and Upgrades.
-
I also have a group policy set to prevent users from upgrading Windows 10 (works for them all, though). For example, if you try to upgrade from 1703 to 1709, it will fail and never upgrade.
However, if I approve the upgrade through WSUS, it will succeed. I don't want upgrades until it's been approved and expected.
-
@tim_g said in Constant WSUS issues (Connection Errors):
I also have a group policy set to prevent users from upgrading Windows 10 (works for them all, though). For example, if you try to upgrade from 1703 to 1709, it will fail and never upgrade.
However, if I approve the upgrade through WSUS, it will succeed. I don't want upgrades until it's been approved and expected.
Awesome, thanks for all the info!! I will follow your example with the groups and the types of updates.
As for Windows 10 upgrades, I never really thought twice about these and I've already upgraded Windows 10 to 1709 for the few systems we have.. no issues so far as far as I know.
-
@dave247 said in Constant WSUS issues (Connection Errors):
As for Windows 10 upgrades, I never really thought twice about these and I've already upgraded Windows 10 to 1709 for the few systems we have.. no issues so far as far as I know.
There's not problem doing it, and there shoudn't be any issues. Go ahead if you can.
When 1709 came out, there were too many issues that would have directly effected out environment. SO I'm glad I was doing it that way or there would have been great money loss.
-
@tim_g said in Constant WSUS issues (Connection Errors):
@dave247 said in Constant WSUS issues (Connection Errors):
As for Windows 10 upgrades, I never really thought twice about these and I've already upgraded Windows 10 to 1709 for the few systems we have.. no issues so far as far as I know.
There's not problem doing it, and there shoudn't be any issues. Go ahead if you can.
When 1709 came out, there were too many issues that would have directly effected out environment. SO I'm glad I was doing it that way or there would have been great money loss.
Ok, thanks so much, Tim. One last question (maybe) for you: Are all your GPO's copies of each other or what? How do they differ?
-
yeah, you definitely don't want to have Windows 10 do auto upgrades to a new version until you test it on some users.
I have a client that is 10 PCs.. so no WSUS, not worth it, the auto upgrade to 1709 caused issues with Webroot. Definitely test before full rollout.
-
@dashrender said in Constant WSUS issues (Connection Errors):
yeah, you definitely don't want to have Windows 10 do auto upgrades to a new version until you test it on some users.
I have a client that is 10 PCs.. so no WSUS, not worth it, the auto upgrade to 1709 caused issues with Webroot. Definitely test before full rollout.
Well the Windows 10 systems we have are all on 1709, so I guess I'm going to consider them my test group for now..
-
@dave247 said in Constant WSUS issues (Connection Errors):
@tim_g said in Constant WSUS issues (Connection Errors):
@dave247 said in Constant WSUS issues (Connection Errors):
As for Windows 10 upgrades, I never really thought twice about these and I've already upgraded Windows 10 to 1709 for the few systems we have.. no issues so far as far as I know.
There's not problem doing it, and there shoudn't be any issues. Go ahead if you can.
When 1709 came out, there were too many issues that would have directly effected out environment. SO I'm glad I was doing it that way or there would have been great money loss.
Ok, thanks so much, Tim. One last question (maybe) for you: Are all your GPO's copies of each other or what? How do they differ?
Each GPO points to a different WSUS group. The server GPOs have a different update schedule than the client PCs. The "Lab" groups follow a different reboot and update plan and schedule.
-
@dave247 said in Constant WSUS issues (Connection Errors):
@dashrender said in Constant WSUS issues (Connection Errors):
yeah, you definitely don't want to have Windows 10 do auto upgrades to a new version until you test it on some users.
I have a client that is 10 PCs.. so no WSUS, not worth it, the auto upgrade to 1709 caused issues with Webroot. Definitely test before full rollout.
Well the Windows 10 systems we have are all on 1709, so I guess I'm going to consider them my test group for now..
lol, then 1803 will be your first test of this.
-
Another reason to split everything up at least by OS is because it makes approving updates easier. You can show only, for example, Critical, definition, and security updates for Win7, then approve them all for the Win7 WSUS groups. Then everything else should happen automatically including reboots if needed.
Also, I have clients checking WSUS for updates ever 6 hours. So if I do approve an update, the clients will download the update from WSUS, then install it according to the schedule set in group policy.
-
Well crap... I'm back to having that connection error again. I only have about 8 computers added to WSUS and I've deselected a bunch of products and classifications I didn't really need. Should I consider increasing the private memory limit and queue lengths again?
I haven't had the connection error since I made those changes Tim_G suggested I make to the WSUS resource pool. It's worth mentioning that the server has been pretty slow since adding the WSUS role. I literally have nothing else running on this system and it's a dual six-core processors (@ 2.20 GHz) and 56.0 GB of memory. I thought this would be sufficient..
-
My system is a VM with 6 GB ram and 2 vCPU.
Your resources are way over kill.
-
We've got ~500 systems on 8GB of RAM with 2vCPUs.
-
I get the error posted in the OP every now and again from the WSUS console on my Win10 PC. A reset always reconnects it.
