My feedback

  1. 148 votes
    Sign in
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    12 comments  ·  Installation and Patching » Patch Management  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Cody commented  · 

    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.

    Cody supported this idea  · 

Feedback and Knowledge Base