Hallo MrSonei6,

also WSUS ist nur für Microsoft's Produkte (Betriebssysteme und Software) gedacht. Deren Strategie zufolge sollte jedes System via WSUS fullpatched gehalten werden. D.h. alle Clients installieren was sie durch Analyse des WU-Agenten für erforderlich halten und vollziehen zeitnah die Entwicklung von MS mit.

Leider ist es so, das HW bzgl. Treiber rumzickt oder auch SW von anderen Herstellern nicht so sauber aufsetzen, wie es MS sich wünscht. Selbst das Programm Windows-Logo kann Hersteller sensibilisieren ... aber nicht zu korrekter SW zwingen.
Daher ist es immer mal gegeben, dass bestimmte Updates besser nicht in Systeme eingebracht werden.
Was nützt Fullpatched, wenn der eigentliche Zweck des Systems dann nicht mehr gegeben ist ?! 

Entscheidend ist also, welche Software von welchem Hersteller mit welchen Einschränkungen in Deiner zu versorgenden Infrastruktur betrieben wird.
Liegen diese Erkenntnisse nicht vor ... bleibt nur absichern und testen. Besonders Kombinationen von diverser SW können gewisse Eigenheiten zu Tage fördern. Diese Erkenntnisse sind in der Regel nicht irgendwo katalogisiert ... man muss diese sich selbst erarbeiten - leider.

Hier ein kleiner Abriss meiner Erfahrungen:

1.) bei mehreren Standorten mit je >250 Clients (verknüpft durch WAN) für jeden Standort einen eigenen WSUS,
2.) Steuerung erfogt in AD via GPO's,
3.) alle Rechner werden mit  Informationen zur Zuordnung einer Standard Gruppe versorgt, so kann die automatische Gruppenzuordnung genutzt werden,
4.) der WSUS mit den besten Inet-Zugang wird Master, die anderen nur Replikas dieses Masters ... am Master wird der Umfang und die Genehmigung aller Updates gesteuert,
5.) für den Standardbereich werden alle erforderlichen Updates genehmigt ... das sind Systeme, die unkritisch mit Fullpatched zurecht kommen,

6.) für Problem-Clients werden eigene sinnhafte Gruppen und eigene GPO's genutzt, diese bekommen bestimmte exklusive Update-Genehmigungen ... so wird verhindert, dass ein nicht vollständig Eingeweihter mal alles Anstehende installiert und damit das System killt.
7.) ausgewählte repräsentative Clients werden zusätzlich einer statischen Testgruppe zugeordnet ... die Nutzer wissen darüber bescheid - diese spiegeln HW-SW-Kombinationen wieder und sind besonders bzgl. einer schnellen Wiederherstellung gerüstet (z.B. Acronis o.ä.),
8.) alle neuen Updates (Patchday) werden vorher nur für die Testgruppe genehmigt und auf Verträglichkeit in der Infrastruktur hin getesten ... wenn OK, dann Genehmigung für alle (Standard) und je nach festgelegten Regeln für die Problem-Clients,
9.) auf Servern werden Updates nur vor Ort durch Admins ausgeführt ... da behält man über die Vorgänge vollständig Kontrolle und kann auch die Neustarts koordinieren, ohne das die Nutzer behindert werden,
10.) normale Clients werden möglichst ohne Zutun der Benutzer aktualisiert (siehe GPO von Sunny hier im Forum),

11.) für WSUS sollte ein Desaster-Recovery-Konzept funktionstüchtig(!) betrieben werden,
12.) der Aufräum-Assisten sollte regelmäßig zum Entschlacken des Contents und der SUSDB genutzt werden,
13.) sind Updates mit Problemen auszurollen, sollten die örtlichen Verantwortlichen immer einbezogen werden ... manchmal ist ein Gang direkt zum Client und Handarbeit nicht zu vermeiden,
14.) auf Deadlines (Stichtag-Installation) sollte man verzichten ... siehe Zwangsneustart vs. GPO mitten im Betrieb,
15.) Sonderfallsysteme sind regelmäßig auf Rückkehr in die größere Gruppe der Fullpatched-Systeme hin zu prüfen, ggf. alternative SW planen und einsetzen.

16.) Cloning muss sicher und zuverlässig betrieben werden ... siehe im Forum bzgl. der Verhaltensweisen solcher Clients,
17.) auf das Aktualisieren von HW-Treibern besser verzichten ... bringt mehr Probleme als Nutzen und braucht sehr viel Plattenplatz,
18.) je nach hauseigener Strategie bzgl. der Erstinstallation von Clients können (!) SP's via WSUS verzichtbar sein,
19.) wirklich sicher nicht benötigte Updates (z.Bsp. Itanium-Quark) ablehnen ... abgelehnte Updates werden bei der Bedarfsanalyse durch den WU-Agenten nicht mehr berücksichtigt,
20.) WSUS nach der Etablierung nicht dem Selbstlauf überlassen, Berechtigungen im WSUS aufs Notwendige begrenzen ... Vertrauen ist gut - Kontrolle ist besser - jederzeit muss klar sein, was genau da passiert.

Hinweis: Das "Blocken" von Genehmigungen ist nicht so Toll wie man denkt ... es gelten nicht die gleichen Vererbungsregeln wie für GPO's im AD (!!!) - d.h. :
Ist ein Client zwei Gruppen zuordnet und ein Update wird in der einen Gruppe erlaubt und in der anderen Gruppe verboten ... wird das Update installiert - weil min. eine Erlaunis vorliegt (!!!) 
Ich meine "Ablehnen", "Genehmigt" und "Nicht genehmigt" (Default) reicht zur Steuerung.

Auf die Kombination eines Domänencontrollers (DC) mit dem WSUS auf gemeinsamen Blech würde ich ebenfalls verzichten ... die DC's sind für Aufgaben im AD zuständig ... wenn dann noch Profilverwaltung und Berechtigungssteuerung dazu kommt ... naja

Bei uns werden Notebooks, Desktops und Server weitgehend nicht mehr getrennt ... wir haben die Infrastruktur fast vollständig auf Fullpatched via WSUS getrimmt ... über einem langen und beschwerlichen Weg natürlich.
Am Ende steht eine hohe Automatisation mit sehr wenigen Ausnahmen, reduziertem Aufwand und einer "spitzenaktuellen" Updateversorgung.

PS: "Fragen sind keine Klagen" ... dieses Forum hilft weiter ... aber KnowHow muss jeder am Ende für sich selbst erarbeiten. 

Siehe auch mal hier:
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).

Gruß Dani