Wsus for remote vpn and on-premise users
-
I've been tasked with implementing patch management for our company. I worked at an MSP prior to this role (sys admin), and we handled patch management through our RMM agents. My current company does not have rmm agent/management, so I'm looking at implementing WSUS.
Just needing a little help in deciding how to implement WSUS with the current network environment/setup.
We have 16 sites. 13 out of the 16 are domain controllers. Sites are in a mesh site to site network. There is about 250-300 users between all sites, with our main site having the most users for office duties. This is a manufacturing company BTW.
I plan on creating a VM for the Upstream server at our main corporate site, which has 100/100 fiber link. The problem I have is for remote users. We have a company policy that allows users to WFH 3 days out of the week if they are capable. Some don't abide by that rule, and work remote the majority of that time. I think it would be better to have the workstations pull updates from Microsoft as opposed to downloading from wsus server over a vpn as it will rely on them staying connected to complete the download.
So I'm thinking about having workstations pull updates from Microsoft, and servers pull updates from wsus server. Or should I have some of the other remote servers function as downstream servers?
Any suggestions or ideas are much appreciated!
-
I can't recall if you can have multiple policies on one WSUS server or not. If you can, you just set your different groups to pull their updates from where you - WSUS server X or MS direct.
-
@fredtx FYI - I would NOT put WSUS on the same VM as a DC. WSUS is breaks all the time! It consumes massive amounts of disk space assuming you're using it for caching updates. I've lost count of the number of times I nearly ran out of disk space on WSUS servers.
Hopefully your DC is a VM and the only one currently on the server, so you have a spare VM from your DC's license, otherwise you're looking at more Server licenses to spin up those that need it.
You can always look at the other MS based policy management options.
-
I will have to see if can create multiple policies for specific groups. From what I read on a technet article wsus and updates via vpn, it suggested creating a replica
Yea, I've read that putting WSUS on a DC is a big no, no.
I was planning on creating a new VM on our esxi host dedicated as our wsus server. Currently the host has 4 VMs. 1 of the 4 is a WS2019 Standard which is our Fsmo role holder DC. I'm not familiar with licensing, but I guess I will have to get a new license?
-
@fredtx said in Wsus for remote vpn and on-premise users:
I will have to see if can create multiple policies for specific groups. From what I read on a technet article wsus and updates via vpn, it suggested creating a replica
Yea, I've read that putting WSUS on a DC is a big no, no.
I was planning on creating a new VM on our esxi host dedicated as our wsus server. Currently the host has 4 VMs. 1 of the 4 is a WS2019 Standard which is our Fsmo role holder DC. I'm not familiar with licensing, but I guess I will have to get a new license?
The following assumes your server has 16 or fewer hardware cores in it.
Windows Server standard licenses allow for 2 VMs per 16 cores worth of processor licensing.Therefore, if you have 4 VMs today, you are required to have a minimum of 32 cores worth of licensing.
If you have more than one DC on that single server hardware - you might consider reassigning that VM as a non DC and as WSUS instead, to save you needing to buy another license.No real value in two DCs in a VM on the same host. I mean there is a tiny bit of value, but worth the cost of another license - probably not.
-
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
-
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
Why are you assuming that? WSUS will allow you to download from MS based on what you allow.
-
@dashrender said in Wsus for remote vpn and on-premise users:
The following assumes your server has 16 or fewer hardware cores in it.
Windows Server standard licenses allow for 2 VMs per 16 cores worth of processor licensing.
Therefore, if you have 4 VMs today, you are required to have a minimum of 32 cores worth of licensing.
If you have more than one DC on that single server hardware - you might consider reassigning that VM as a non DC and as WSUS instead, to save you needing to buy another license.
No real value in two DCs in a VM on the same host. I mean there is a tiny bit of value, but worth the cost of another license - probably not.Looks like I have 1 2019 Standard license available so no need to buy additional license, and I can create a vm just dedicated for wsus.
There is only 1 DC at our main site on the same esxi host that the future wsus server will be on.
So as of now, it's looking like 1 WSUS Upstream server at main site, that remote servers will download updates from via site to site vpn. And if possible, configure existing wsus settings for workstations to download updates from MS. If it's not possible, create a replica, which would only be used to tell the workstations which updates are approved, and will not store updates on the hard drive of the server?
-
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
-
@irj said in Wsus for remote vpn and on-premise users:
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
That's another topic I want to get to as well. The topic of when and how to schedule/approve patching for your business in a Windows environment? And what is best practice? That may need to be a different post though.
-
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
I agree 99.9% of the time - the other .1% is what bites - when you have a bad patch and have to uninstall it.
-
@fredtx said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
That's another topic I want to get to as well. The topic of when and how to schedule/approve patching for your business in a Windows environment? And what is best practice? That may need to be a different post though.
Unless your company really is prepared for you and others to spend days testing all new patches before deploying them - then the best practice is to deploy ASAP after MS releases them. Zero and near zero day exploits start hitting within hours of updates being released.
-
An option that nobody has mentioned is doing split-brain dns for your WSUS.
Assuming that you've got a domain, setup something like updates.company.com with the appropriate security and forwarding externally and the necessary entries on your internal Windows DNS. Make sure that everything is setup with SSL and you're golden. So if the folks are out of the office, they'll still be pulling updates from your WSUS server, under your control. Hell, depending on how your firewall handles hairpinning, it might be best to forget about the entries in the internal DNS and just have everyone connect to the public IP, eliminating any instances of it having to deal with VPNs.
-
@fredtx said in Wsus for remote vpn and on-premise users:
I've been tasked with implementing patch management for our company. I worked at an MSP prior to this role (sys admin), and we handled patch management through our RMM agents. My current company does not have rmm agent/management, so I'm looking at implementing WSUS.
Why not add an RMM?
-
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
Yup, I'm a huge opponent of WSUS. Most of the time (nearly all of the time) it consumes huge resources, wastes ITs time, puts patching at risk, breaks things in dangerous ways, undermines security, and makes what should be simple hard and often generates more licensing needs for no reason.
It has its place, but it is so rare that it is actually beneficial. It has so many cons and effectively no pros. And only an organization with such insane scale could ever possibly truly test patches, WSUS is basically zero benefits with a HUGE invitation to problems.
-
@fredtx said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
That's another topic I want to get to as well. The topic of when and how to schedule/approve patching for your business in a Windows environment? And what is best practice? That may need to be a different post though.
Best practice (which is in my book that just came out, by the way) is ...
If you don't have a huge testing environment where you can test patches within ~24 hours of release, to patch blindly without delay.
If you create any delay, hesitation, or opportunity to not patch, you have a big problem. WSUS represents all of these. Basically, if you are asking the question, it means WSUS is wrong for you and you need immediate patching.
If you have any hesitation to that policy, it means you are running a platform you don't trust in production. That's valid as a concern. But your IT has committed its trust to Windows, so either you need to embrace that decision or you need to convince them to change.
-
@dashrender said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
I agree 99.9% of the time - the other .1% is what bites - when you have a bad patch and have to uninstall it.
WSUS doesn't fix the .1%. It just delays it, which doesn't help things.
-
@scottalanmiller said in Wsus for remote vpn and on-premise users:
@dashrender said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
I agree 99.9% of the time - the other .1% is what bites - when you have a bad patch and have to uninstall it.
WSUS doesn't fix the .1%. It just delays it, which doesn't help things.
WSUS can uninstall the patch - so sure, not fix it, but help with removal.
-
@scottalanmiller said in Wsus for remote vpn and on-premise users:
If you have any hesitation to that policy, it means you are running a platform you don't trust in production. That's valid as a concern. But your IT has committed its trust to Windows, so either you need to embrace that decision or you need to convince them to change.
With me being in this new role for 2 weeks (first system admin role), and the majority of the computers/servers on Windows, I will have to stick with this solution for now.
Currently there is no central management for patching, and currently they are logging on each server and running updates that way and hope that workstations are getting patched through the GPO they have in place.
-
@fredtx said in Wsus for remote vpn and on-premise users:
@scottalanmiller said in Wsus for remote vpn and on-premise users:
If you have any hesitation to that policy, it means you are running a platform you don't trust in production. That's valid as a concern. But your IT has committed its trust to Windows, so either you need to embrace that decision or you need to convince them to change.
With me being in this new role for 2 weeks (first system admin role), and the majority of the computers/servers on Windows, I will have to stick with this solution for now.
Currently there is no central management for patching, and currently they are logging on each server and running updates that way and hope that workstations are getting patched through the GPO they have in place.
What is the goal here? to keep the servers up to date? Do you really want WSUS to update your servers 'whenever'? Most people don't, could lead to an unexpected reboot in the middle of the day.
