Provide full powershell integration for patching
There should full powershell integration for both WSUS and Server Side WU Client. This would enable scenarios such as post reboot checks for additional patches and mass patching automation.
It would also allow for things like managing small server deployments that don't have WSUS by being able to use remote powershell to query the patches currently installed on servers, check for available patches and then tell them to remediate and reboot if required.
Currently these can be done mostly through WMI and customer powershell scripts that wrap around these, but it really needs proper integration.
Having powershell to query required updates for a server/s and then use that information to approve just those updates in WSUS would be a huge plus as well.
In general, if it could have the functionality of the PSWindowsUpdate module natively (https://www.powershellgallery.com/packages/PSWindowsUpdate/18.104.22.168) and extended powershell in WSUS role, it would be a huge step forward.
Want to add that you already know how to do this really well with Cluster Aware Updating! Just do the same thing but allow it to work against any machine not in a cluster.
+1 PSWindowsUpdate version 2.0 is even better but unfortunately no longer open source. This shoudl be a core Microsoft tool though!
Yeah I would love seeing something like it. Would make things much easier for me.
Must be able to do this without WSUS 3 or lower. WSUS is a POS.
Miguel Guarachi commented
This seems like a no brainer.. i wonder if MSFT has a reason not to do it (beside lazyness)
This would be a great step Forward! PowerShell Updates and remote Updates would it mkke easier for admins
Bump, should have been there with WS2012R2 it's past overdue.
I'm a DBA and manage the patching of a few hundred SQL Servers.
We do this by allowing Infrastructure teams to deploy all updates using WSUS (these are the SQL Server service packs and some security updates). After WSUS has completed its patching and while we are still within outage windows we log on and apply cumulative updates and further security patches.
This means we use this functionality:
* A cmdlet to pull back all the groups on a WSUS server.
* A cmdlet to pull back all the computers from one or more groups on a WSUS server.
* A cmdlet to pull back summarised information for each computer; e.g. how many approved packages are needed (left to install) and how many approved packages failed to install. These are important for us because we have to wait for their patching to finish before we can safely start our patching.
* We also need a cmdlet to identify the detailed information for each computer; e.g. which packages have failed to install. We do that so if an SQL Server service pack failed part-way through, we aren't waiting for the needed list to drop to 0, and we know we have to rectify something before the outage window closes.
We also use a non-WSUS cmdlet to detect msiexec activity on each server remotely; that might indicate patching is still ongoing (or has possibly stalled for some reason).
We also use a non-WSUS cmdlet to detect whether reboots are pending (usually pending file move/rename operations) as this is required after patching for SQL Server often to prevent SQLCLR from failing. We use a script from one of the galleries that can detect a lot of different possible reboot conditions for this.
Sharepoint teams also encounter largely the same problems in their coordination.
Anyway these are the kinds of real world issues we deal with. As the WSUS API is just not written to be easily consumed by non-programmers, we instead do it all with T-SQL queries on the provided views, and performance isn't great (even though it's on an Enterprise instance and do proper database maintenance) because of terrible WSUS indexing. Also those APIs appear to normally return a lot of data in a non-aggregated form which is very slow and not very usable for the things above unless you were operating on far fewer servers.
Hope that provides some insight when building this thing.
Can we get WSUS on RDS management boxes chucked in too?
Ben Thomas (Datacom) commented
Yes bonus points if the powershell remoting of these modules work downlevel. Eg. WMF5 on 2016 can talk to WMF5 on 2012R2 and make the same calls and commands
Anthony Ross commented
And please release it down level to at least Vista Server!
Anthony Ross commented
About time the old wuauclt client got a revamp or replaced by something useful like Powershell.
It's still living in the dark ages.