Mit DSM 2014 wurden erstmals die Begriffe "Patch Kategorien" und "Patch Rollout Rules" eingeführt. Um diese neuen Konzepte zu verstehen, ist ersteinmal einiges herumprobieren notwendig. Der folgende Designvorschlag soll den Einstieg in dieses mittlerweile komplexe Thema erleichtern. Es wird folgend ausschliesslich auf die Konfiguration dieser neuen Features eingegangen. Für die vollständige Konfiguration von APM im jeweiligen DSM Umfeld müssen noch diverse weitere Dinge (Installationsreihenfolge von Patchen in Bezug auf Softwarepakete, Definition der Patchziele, Rolloutzyklen, Zusammenarbeit mit WSUS, etc.) betrachtet werden.

Anforderungen (Definition eines klassischen Szenarios):

• Es sollen Windows Server, Windows Terminal Server und Windows Workstations mit Patchen versorgt werden.
• Für jede dieser Gruppen sollen möglichst nur die Patche zugewiesen werden, die für die jeweilge Plattform notwendig sind um die Anzahl der zu verwaltenen Policies pro Plattform möglichst gering zu halten.
• Für jeden Client (aus Sicht DSM sind Server und Workstations als "Clients" zu betrachten) muss die Wahlmöglichkeit bestehen, zwischen einem reinem "Security Patching" und ein "vollen Patching" zu wählen (Da man nicht-kritsche Patche ggf. einer längeren Testphase unterzieht).
• Einzelne Produkte sollen aus dem Patch Vorgang komplett ausgeschlossen werden.
• Es sollen nur Patche ausgerollt werden, die vollständig heruntergeladen sind und nicht durch neuere Patche ersetzt wurden. 
• Manuelle Veränderungen an Produkten (z.B. Konfiguration des Adobe Readers) dürfen nicht durch ein APM Paket "zerstört" werden.
• Weiterhin soll der Rollout von Patchen in der Produktion (nach einer angemessenen Testphase) bewußt manuell gestartet werden.

Umsetzung:

1. Erstellen der Patch Kategorien "Workstations", "Server" und "Terminal Server". Als Filter wird die Patch Paket Eigenschaft "Product Family" verwendet und alle Produkte angewählt, die für die jeweilge Zielplattform wichtig sind. Hier ist es entscheidend, dass diese Produktauswahl regelmäßig auf Aktualität überprüft wird (-> Outlook Erinnerung).
2. Erstellen einer Patch Kategorie "Download incomplete" in der auf die Patch Paket Eigenschaft "Download State" abgefragt wird. Es werden die Werte "Download Pending" und "Not selected" aufgenommen.
3. Erstellen einer Patch Kategorie "Not released" in der auf die Software Eigenschaft "Release Status" abgefragt wird. Es werden die Werte "Under construction" und "retired" aufgenommen.
4. Erstellen einer Patch Kategorie "Superseeded" in der auf die Patch Paket Eigenschaft "Superseeded" abgefragt wird. Es wird der Wert "Yes" aufgenommen.
5. Erstellen einer Patch Mangement Regel mit folgenden Eigenschaften:
   1. Name = "Workstation - Security Updates - Pilot"
   2. IsActive = true
   3. Action = Download & Assign
   4. Policy Targets = Ein Ziel (Gruppe/Container) das alle Workstations umfasst die als Pilot Clients für Security Updates dienen (i.d.R. eine dynamische Gruppe aufgrund einer Schemaerweiterung)
   5. Show advanced options = Yes
   6. Included Patch Categories = Patch Kategorie für Workstations
   7. Excluded Patch Categories = "Disabled Products", "Download incomplete", "Not released", "Superseeded"
   8. Classification = "Critical Updates", "Microsoft Security Updates", "Non Microsoft Security Updates"
   9. Severities = Nach Bedarf (Vorschlag: "Serious", "Critical")
   10. Activate Policy = True
   11. Policy Offset = Nach Bedarf
   12. Languages = Je nach Policy Ziel Definition (Bei Sprachbezogenen Patchen macht der Einsatz von Patch Templates Rules und Sprachbezogenen Zielen Sinn, wenn möglich sollte man diesen Grad von Komplexität aber eher vermeiden)
6. Die Schritte aus Punkt 5 werden für Server und Terminal Server mit den je dazugehörigen Patch Kategorien wiederholt. Es werden insgesamt also die folgenden Rollout Rules generiert:
   1. Workstation - Security Updates - Pilot
   2. Server - Security Updates - Pilot
   3. Terminal Server - Security Updates - Pilot
7. Die Schritte aus Punkt 5 werden nocheinmal für alle drei Zielpattformen wiederholt, diesmal wird bei Classification und Severity aber alles zugelassen und ein Ziel definiert, was alles Clients umfasst die voll gepatched werden sollen. Dabei werden die folgenden Rollout Rules generiert:

   1. Workstation - Full Updates - Pilot

   2. Server - Full Updates - Pilot

   3. Terminal Server - Full Updates - Pilot

8. Nun werden 6 weitere Rollout Rules (wie in Punkt 6 & 7) angelegt, die über die identischen Eigenschaften verfügen wie in Punkt 5 definiert. Die Eigenschaft "Activate Policy" ist nun aber auf "false" gesetzt. Dies führt dazu, dass die Policies die durch diese Regel erstellt werden, grundsätzlich inaktiv sind und manuell aktivert werden müssen.
   1. 1. Workstation - Security Updates - Production
      2. Server - Security Updates - Production
      3. Terminal Server - Security Updates - Production
      4. Workstation - Full Updates - Production
      5. Server - Full Updates - Production
      6. Terminal Server - Full Updates - Production
9. Für alle Produkte bei denen weitere Anpassungen durchgeführt werden müssen (z.B. Adobe Reader), wird eine Patch Kategorie erstellt und mit einem Patch Template verknüpft, das alle Produktspezifischen Anpassungen enthält.
10. Zu empfehlen ist, nach der Synchronisation alle Patche zu markieren und die Eigenschaft "Automatic Patch Assigment" auf "Always" zu setzen um auch bei Änderung der Ziele (oder der Rollout Regeln) neue Policies zu erhalten. Anmerkung: Multiselect ist ein wenig mühsam in der DSMC, hier emfiehlt sich der Einsatz von PSX.

Dieses gesamte Vorgehen kann/muss nun mit bestehenden Konzepten kombiniert werden. Wie schon zuvor erwähnt, soll dies keine Schritt-für-Schritt Anleitung für die Integration von APM darstellen, sondern einem ersten Ansatz zeigen und ein schnelleres Verständnis für die neuen Funktionen von APM fördern.