Windows 10 im Unternehmensumfeld - SSO, "Hybrid" und andere Mysterien (Teil 1)

Wenn man sich mit Windows 10 und seinem Einsatz in Enterprise-Umgebungen beschäftigt, stellen sich viele Fragen - u.a. zur Verwaltbarkeit und Cloud-Anbindung. Beim Versuch, diese Fragen zu klären, wird man mit einer Vielzahl von Begriffen konfrontiert. Vermutlich haben Sie von Azure AD Join und Workplace Join gehört. Hinzu kamen dann vermutlich recht bald Single Sign On, ADFS, DirSync/AADConnect, MDM Autoenrollment, Intune, SCCM und noch vieles mehr. Ein weites Feld…

Letzten Endes geht es darum, Windows 10 unternehmenstauglich einzusetzen und zu verwalten. Aber wie geht das und was heißt das eigentlich? Es herrscht teils große Verunsicherung, wie einige neue Entwicklungen einzuordnen sind und manche Veranstaltungen oder Kommentare von Leuten, die es eigentlich wissen sollten, schüren diese Verunsicherung noch. Wie etwa: Wird Domain Join bald abgeschafft? Heißt die Zukunft Azure AD Join? Ist die klassische Verwaltung mit Tools wie SCCM tot und läuft künftig alles über MDM wie z.B. Intune?

Ich kann sie beruhigen. Ich bin zwar kein Orakel, aber bin mir mittlerweile (das war nicht immer so!) sehr sicher, dass all diese zugegebenermaßen überspitzt formulierten Fragen für die absehbare Zukunft mit "Nein" beantwortet werden können. Denn: Mit kleinen Einschränkungen ist alles da und es passt alles zusammen (auch das war nicht immer so!). Man muss nur die richtigen Teile miteinander kombinieren. Aber welche sind das, für welches Szenario?

Dieser und zukünftige Artikel rund um Windows 10 sollen etwas Licht ins Dunkel bringen. Zunächst greifen wir einen wichtigen Teilaspekt auf, der im Zusammenhang mit dem Thema "Cloud-Anbindung" steht.

Ein Beispielszenario, der Aufhänger für diesen Beitrag: Ihr Unternehmen möchte gewappnet sein für etwaige Anfragen der Benutzer à la "Ich bin viel mit meinem Surface Pro 4 unterwegs und benötige für Präsentationen die PowerPoint App aus dem Windows Store".

Eine häufige Antwort der IT-Verantwortlichen: "Windows Store? Den haben wir gesperrt. Das ist eine auf Privatpersonen zugeschnittene Geschichte, die wir im Unternehmensumfeld nicht unterstützen."

Und das ist dann das Ende vom Lied - so war es oft mit Windows 8.1.

Nun gibt es aber seit einiger Zeit den Windows Store for Business (WSfB), mit dem sich ein unternehmensspezifischer Bereich innerhalb des Windows Store definieren lässt, der allen Mitarbeitern offen steht. Der Zugriff auf diesen "Private Store" erfolgt mit denjenigen Anmeldedaten, mit denen die Benutzer bereits am Rechner angemeldet sind - sofern einige Voraussetzungen erfüllt sind. Welche dies konkret sind und welche Möglichkeiten WSfB bietet, ist genug Stoff für einen eigenen Blog-Beitrag… an dieser Stelle deshalb nur eine Zusammenfassung - Sie brauchen:

• Einen konfigurierten WSfB Private Store mit den gewünschten Apps, die den Benutzern zur Verfügung stehen bzw. zur Installation angeboten werden sollen. Das Resultat sieht z.B. so aus:

• Eine Instanz von Dirsync (d.h. AADConnect) zur Synchronisation der Benutzerobjekte zwischen dem eigenen AD und Azure AD
• Optional (aber in aller Regel dringend empfohlen) ADFS und eine Federation zu Microsoft, damit Anmeldedaten ihr Unternehmen nicht verlassen.

Anmerkung: Da die Mehrzahl unserer Kunden der o.a. Empfehlung folgt, liegt der Fokus dieses Beitrags auf dem Szenario inkl. ADFS und Federation zu Microsoft.

Sie kommen also zu dem Entschluss, dass der WSfB eine sehr nützliche Sache ist und beginnen mit der Einrichtung von ADFS, Dirsync und konfigurieren WSfB. Diese Einrichtung ist nicht ganz trivial, aber nach einiger Zeit haben Sie es geschafft. Ein Testzugriff auf SharePoint Online oder OneDrive for Business läuft für den Benutzer so, wie man es sich wünscht: Keine Authentifizierungsdialoge - Drin! Das war ja einfach… (kennt jemand noch den alten AOL Spot mit Boris Becker? Ein Klassiker :-)) OK, nun zum Store… Schade, wie kommt man denn nun an den Private Store? Antwort: Hierzu muss der Work Account hinzugefügt werden, was auch als "Workplace Join" gezeichnet wird.

Standardmäßig passiert dies nicht automatisch. Was nun?

Es gibt an dieser Stelle eigentlich nur eine offensichtliche Möglichkeit:

• Benutzer fügen Ihren Work Account selbst hinzu. Hierzu starten sie die "Einstellungen" App, wählen dort "Auf Arbeits- oder Schulkonto zugreifen", klicken auf "Verbinden", geben ihren UPN (in der Regel ist dieser identisch mit der Email-Adresse) ein. Daraufhin erfolgt eine Umleitung zu ADFS. Im darauf folgenden Formular muss der Benutzer zum Abschluss noch sein Kennwort eingeben. Nun kann der Benutzer die Store App starten und sein Work Account ist bereits dort hinterlegt. Der Zugriff erfolgt also im Kontext des Work Account und der Private Store wird angezeigt. Ziel erreicht.

Aber ist das unternehmenstauglich?

Vermutlich antworten Sie reflexartig "Nein, ganz bestimmt nicht" oder "Also bei uns nicht" und damit sind Sie in bester Gesellschaft. Tatsächlich wird auch Microsoft dies so unterschreiben. Denn "Workplace Join" ist nicht für Unternehmens-PCs gedacht, sondern für BYOD Szenarien. Was aber tun bei Unternehmens-PCs?

Unternehmens-PCs (Corporate owned devices) mit Windows 10 werden in 2 Klassen unterteilt:

• Domain-joined Computer. Das sind die klassischen PCs, Notebooks, Tablets oder Hybrid-Geräte, die z.B. mit SCCM oder einem Tool ihrer Wahl aufgesetzt und verwaltet werden. Sie sind Mitglied des on-premises AD und werden üblicherweise ganz klassisch mit SCCM und Group Policies konfiguriert.
• Azure AD-joined Computer. Für Benutzer, die hauptsächlich mit Cloud Ressourcen arbeiten und Ihren Arbeitsplatz nicht im Unternehmen haben, kann dies eine interessante Alternative sein. Azure AD-joined Computer können im Anschluss an den AAD-join automatisch in die bestehende MDM-Lösung eingebucht werden (z.B. Intune oder SCCM/Intune hybrid) und über diese verwaltet werden. Dieses Feature wird als "MDM Autoenrollment" bezeichnet. Im Vergleich zur Verwaltung von Domain-joined Computern mit SCCM (via installiertem SCCM-Client) und Group Policies wird hier oft von "MDM Channel" und "Lightweight Management" gesprochen.

Nochmal zum Festhalten: Nein, Domain-join wird nicht durch Azure AD Join abgelöst. Zumindest nicht heute und auch nicht morgen. Die Zielgruppen für die Join-Arten sind verschieden. Und SCCM und GPOs sind weiterhin die Mittel der Wahl zur Verwaltung für Domain-joined Computer! Über den MDM Channel wird Lightweight Management gemacht - und zwar für Smartphones generell, für BYOD-Computer oder für heavy-Cloud-User, die ihren Computer ggf. von der Stange kaufen (Kosten übernimmt der Arbeitgeber) und via Self Service zu Azure AD hinzufügen (Azure AD Join) - dies ist ein Beispiel für den sog. COPE-Ansatz (Corporated Owned, Personally Enabled).

Wir wollen uns an dieser Stelle auf Domain-joined Computer konzentrieren, da diese für viele deutlich relevanter sind - schließlich existieren etliche Millionen davon auf der Welt. Microsoft hat seit einiger Zeit ein Verfahren etabliert, das auf Deutsch ungefähr "Automatische Azure AD Registrierung" (Kurzform im Folgenden: "AAD Auto-Registrierung") heißt. Hierdurch wird ermöglicht, dass Domain-joined Computer automatisch in Azure AD registriert werden. Dies bietet u.a. die folgenden Vorteile:

• Für den Benutzer ist der Vorgang komplett transparent, es ist keinerlei Benutzer(inter)aktion notwendig
• Die Registrierung passiert automatisch, sobald sich Benutzer an den Computer anmelden
• Work Accounts der sich anmeldenden Benutzer werden automatisch hinzugefügt
• Die Store App ist fertig vorkonfiguriert und zeigt den Private Store
• "Enhanced" SSO beim Zugriff auf Ressourcen

"Normales" SSO versus "Enhanced" SSO

Work Accounts werden automatisch hinzugefügt? Keinerlei Benutzerinteraktion, alles vollautomatisch… klingt schon mal super! Aber was ist mit "Enhanced" SSO gemeint? Vorweg: Den Begriff haben wir uns selbst ausgedacht - um diese besondere Form von SSO abzugrenzen zu dem, was wir üblicherweise unter SSO verstehen.

Um bei diesem Beispiel zu bleiben: Greift ein Benutzer also im LAN auf SharePoint Online zu, geschieht die "Magie" unter Mitwirkung von ADFS normalerweise vollautomatisch im Hintergrund. Wenn der Benutzer aufmerksam die Adresszeile des Browsers beobachtet, sieht er lediglich die verschiedenen URLs durch die Umleitungen aufblitzen und ist im nächsten Moment schon authentifiziert bei der Zielressource angelangt.

Wir halten aber fest: Bei "normalem" SSO ist zwingend ADFS involviert.

Das heißt umgekehrt auch: Wenn ADFS gerade nicht verfügbar ist (Ausfall, Wartung, etc.), ist kein Zugriff auf MS Online Ressourcen möglich!

Das ist bei "Enhanced SSO" anders:

• Nur beim ersten Zugriff läuft alles "normal"
• Anschließend wird ein Primary Refresh Token (PRT) und darauf aufbauend Access Tokens zur Authentifizierung verwendet
• ADFS wird fortan umgangen. Die Authentifizierung erfolgt mithilfe der o.a. Tokens direkt gegen Azure AD

Die Vorteile des erweiterten SSO liegen auf der Hand:

• Der Zugriff auf MS Online Ressourcen funktioniert auch unabhängig von ADFS und dessen Verfügbarkeit
• Es ist keine Eingabe von Anmeldedaten erforderlich, egal ob der Client im LAN steht oder im Internet
• Die Authentifizierung erfolgt mit weniger Umwegen und läuft daher noch schneller

Einige weitere Vorteile der AAD Auto-Registrierung (Store App mit dem Work Account vorkonfiguriert, WSfB zeigt Private Store an, etc.) habe ich ja bereits oben erwähnt.

Darüber hinaus ist die AAD (Auto-)Registrierung übrigens die Grundlage für weitere interessante Features wie Windows Hello for Business, Enterprise State Roaming und Conditional Access - Details hierzu folgen in zukünftigen Blog-Einträgen.

Damit erst einmal genug für heute… In Teil 2 klären wir, welche Voraussetzungen für die AAD Auto-Registrierung erfüllt sein müssen und es gibt einen Überblick über den Ablauf. Ein paar Tipps zur Implementierung sind auch noch mit dabei, also: "Stay tuned" :-)

Viele Grüße

Alexander Zarenko

Ich wurde kürzlich von einem meiner Kunden gefragt, wie denn in SCCM der Zusammenhang zwischen einem Wartungsfenster und den Geschäftszeiten sei und ob sich diese Bereiche beeinflussen. Geschäftszeiten können von jedem Benutzer über das Software Center in gewissen Grenzen frei definiert werden und bringen zum Ausdruck, wann ein Benutzer nicht mit Software- oder Update-Installationen belästigt werden möchte oder positiv ausgedrückt, in welchem Zeitraum Wartungsaktionen bevorzugt stattfinden sollen. Meiner Erfahrung nach ist dies zwar ein Feature, das kaum jemand wahrnimmt oder gar aktiv benutzt, aber man sollte als SCCM-Administrator natürlich wissen, was es mit den Geschäftszeiten auf sich hat und wie diese z. B. die Installation von Software Updates beeinflussen.

Wartungsfenster

Ein Wartungsfenster bzw. Maintenance Window dient im SCCM-Umfeld dazu, den Zeitpunkt von Software- oder Update-Installationen zeitlich kontrollierbarer zu gestalten.

Ein Wartungsfenster wird im SCCM über Collections definiert, d. h. das Wartungsfenster ist eine Eigenschaft der Collection.

Das Wartungsfenster bestimmt sich über eine frei definierbare Startzeit, eine Dauer und ggf. ein Wiederholungsintervall. Außerdem kann festgelegt werden, ob das Wartungsfenster für alle Arten von Deployments, nur für Updates oder nur für Task Sequenzen gelten soll.

Wenn für ein Device ein Wartungsfenster definiert ist, werden Deployments (auch nach Erreichen der Deadline) so lange verzögert, bis der Startzeitpunkt des Wartungsfensters erreicht ist. Es gibt darüber hinaus einige weitere Faktoren, die das Installationsverhalten beeinflussen. Wenn, z. B. die Dauer des Wartungsfensters kürzer als die maximal erlaubte Installationsdauer ist, findet die Installation nicht statt, obwohl das Wartungsfenster erreicht worden ist. Die maximal erlaubte Installationsdauer kann bei einer Application im Deployment Type angegeben werden.

Bei einem Software Update Package gibt es diese Einstellmöglichkeit ebenfalls.

Mehrere Wartungsfenster

Was passiert nun, wenn für ein Device mehrere Wartungsfenster definiert sind? Dies kann vorkommen, wenn der Computer Mitglied einer Collection ist, für die mehrere Wartungsfenster definiert sind, oder wenn der Computer Mitglied in mehreren Collections ist, für die jeweils Wartungsfenster vorhanden sind. Hierbei muss man unterscheiden, ob sich die Wartungsfenster zeitlich überschneiden oder nicht. Falls sich die Wartungsfenster nicht überschneiden, gilt jedes Wartungsfenster unabhängig für sich betrachtet. Bei Überschneidungen wird ein einzelnes Wartungsfenster gebildet, das der Schnittmenge aller definierten Wartungsfenster entspricht, d. h. es wird das größtmögliche zeitliche Fenster definiert, dass allen Wartungsfenstern gerecht wird.

Wartungsfenster ignorieren beim Deployment?

Bei jedem Deployment kann sich der SCCM Administrator nochmals individuell entscheiden, ob er evtl. vorhandene Wartungsfenster überhaupt berücksichtigen möchte, oder nicht. Dies kann auf der Seite User Experience im Deployment Wizard bestimmt werden. Wenn, wie hier zu sehen, die Checkbox für Software update installation aktiviert ist, erfolgt nach Erreichen der Deadline die Update Installation auch außerhalb eines evtl. definierten Wartungsfensters. Mit dieser Einstellung lassen sich Wartungsfenster also de facto umgehen.

Geschäftszeiten / Business Hours

Was hat es nun mit den Geschäftszeiten auf sich, die jeder Benutzer auf seinem Gerät über das Software Center frei definieren kann?

Handelt es sich hierbei auch um ein Wartungsfenster? Die Antwort lautet: Ja, in gewisser Weise schon, allerdings hat dieses Wartungsfenster lediglich eine Bedeutung für den Zeitraum vor dem Erreichen der Deployment Deadline. Beim Erstellen eines Deployments kann der SCCM Administrator angeben, ab wann die Software auf dem Client erkennbar, also „Available“ sein soll.

Ab diesem Zeitpunkt bekommt der Benutzer die Installation der Software über Software Center angeboten und evtl. erscheint auch ein Meldungsfenster mit einer entsprechenden Ankündigung. Ob diese zusätzliche Meldung erscheinen soll oder nicht, wird auf der nächsten Seite des oben gezeigten Wizard festgelegt.

Ob nun die definierten Geschäftszeiten berücksichtigt werden oder nicht, hängt von der Wahl des Benutzers in dieser Benachrichtigung ab. Der Benutzer kann sich hier diesbezüglich entscheiden. Diese Wahlmöglichkeit ist allerdings nur solange gegeben, bis die Deployment Deadline erreicht ist. Der Zeitpunkt der Deployment Deadline wird vom SCCM-Administrator ebenfalls bei der Erstellung des Deployments festgelegt.

Mit Erreichen der Deadline finden die vom Benutzer definierten Geschäftszeiten keine Berücksichtigung mehr, wohl jedoch evtl. vorhandene Wartungsfenster, die über Collections definiert worden sind.

Der wichtigste Unterschied zwischen einem Wartungsfenster und den Geschäftszeiten eines Benutzers ist also der Zeitraum, in dem entweder das eine oder das andere seine Anwendbarkeit findet. Geschäftszeiten blockieren eine Installation vor Erreichen der Deadline, ein Wartungsfenster nach Erreichen der Deadline.

Gruß, Thomas Froitzheim…

Als sich das Telefonnetz gegen Ende des 19. Jahrhunderts in Deutschland ausbreitete, war  dies zunächst eine „analoge“ Revolution. Analoge Gesprächskanäle wurden über dedizierte Drähte (später auch frequenz-modulierte Multiplexerleitungen) geschaltet. Die Qualität der Gesprächskanäle war oft gering. Sie litten an Übersprechen, Echo und externen Störspannungen; oft wurde der Kanal mit zunehmender Länge immer schlechter. Einen wesentlichen Durchbruch stellte die Digitalisierung der Telekommunikation dar, die in Deutschland etwa ab den 1980er Jahren mit dem Aufbau des ISDN-Netzes vollzogen wurde. Gesprächskanäle konnten nun dank der Digitaltechnik quasi „störungsfrei“ geschaltet werden, so dass selbst bei Gesprächen über große Entfernungen eine hohe Verbindungsqualität erreicht wurde. Wie zuvor das analoge Telekommunikationsnetz wurde auch das ISDN-Netz unter dem Monopol der Deutschen Bundespost aufgebaut und betrieben.

Seit Ende der 1990er Jahre vollzieht sich nun ein nächster Evolutionsschritt: digitale Telekommunikation wird zunehmend über paketbasierte Netze (IP-Netze / Internet / VoIP) abgewickelt. Diese Entwicklung ist wirtschaftlich konsequent, da Datenverbindungen allgegenwärtig sind und die geringen Bandbreiten der Telekommunikation ohne weiteres mit übertragen können. Gleichzeitig geht das ursprüngliche Provider-Monopol der Deutschen Bundespost / Telekom in einen offenen Markt mit einer Vielzahl an Dienstanbietern über.

„Fott damit“. Ausrangiertes Faxgerät, gesehen an einer Straßenecke in Bad Schandau, Sachsen
Der Übergang vom analogen zum  digitalen (ISDN-)Netz bedeutete für Fax-Geräte ein „goldenes Zeitalter“: Selbst  wenn analoge Schnittstellen am Endgerät weiterverwendet wurden (Gruppe 3 Fax), bedeutete die gute Kanalqualität im monopolistischen, digitalen Telekom-Netz, dass Fehlerkorrektur­mechanismen wenig gefordert wurden und hohe Übertragungsraten möglich waren. Gruppe 3 Geräte, die für die Kompensierung von Echos, Rauschen oder anderen externen Störgeräuschen des Analognetzes optimiert waren, übertrugen die Daten im ISDN-Netz der Telekom mit sehr hoher Zuverlässigkeit. Es scheint im Nachhinein, dass die Entwicklung der Faxtechnik in den 1990er Jahren „einschlief“, einfach weil die Technik auf ihrem Zenit angelangt war.

Probleme mit Fax beim Übergang zu Voice-over-IP
Dann jedoch folgt die Ernüchterung: Der Übergang zu Voice-over-IP stellt für Fax-Geräte ganz neue Herausforderungen dar. VoIP ist zunächst auch eine digitale Übertragungstechnik und hat als solche weder mit Leitungsechos, Übersprechen oder externem Rauschen zu kämpfen. Es treten jedoch neue Probleme wie Delay und Jitter oder burstartige Verluste (Paketverluste) auf. Auch ist eine Vielzahl an Codecs entstanden, die zugunsten einer Minimierung der Übertragungsbandbreiten entsprechende Signalverzerrungen mit sich bringen. In Konsequenz arbeiten Fax-Geräte mit analogen Schnittstellen und veralteten Fehlerkorrekturmechanismen in VoIP-Umgebungen nicht mehr zuverlässig. Dokumente benötigen mehrere Anläufe für den Fax-Versand, längere Dokumente gehen teilweise gar nicht mehr ohne Fehler über die Leitung.

Das ITU hat für dieses Problemfeld die Empfehlung T.38 erarbeitet, gemäß der Faxe – also digitale Bilddaten - nicht mehr in Signaltöne gewandelt, digitalisiert und schließlich paketiert übertragen werden. Stattdessen soll eine TCP/IP-Verbindung die vollständig digitale Übertragung ohne Echtzeitcharakter ermöglichen; TCP stellt dabei die hochwertige digitale Fehlerkorrektur sicher.
Soweit so gut, wäre da nicht die Öffnung des Telekommunikations-Provider-Monopols: T.38 wird von SIP-Providern in Deutschland in der Regel nur „intern“ also zwischen Anschlüssen eines Providers angeboten. Provider-übergreifende Verbindungen wandeln beim Übergang dann ggf. doch die Daten wieder in den „analogen“ T.30-Standard um. Die Deutsche Telekom bietet T.38 an IP-Anschlüssen zurzeit gar nicht an. T.38 ist also keinesweigs ein flächendeckender Standard.

Wieso eigentlich Fax-Übertragung?
Noch einmal einen Schritt zurück: Warum liegt uns das Faxen eigentlich so am Herzen? Brauchen wir unsere Fax-Geräte eigentlich noch? Faxe hatten in ihren Glanzzeiten einige recht positive Eigenschaften: Es wurde kollektiv darauf vertraut, dass Abhören oder Manipulationen am Inhalt aufgrund der Echtzeitübertragung und monopolistischen Netzführung nahezu ausgeschlossen waren. Bei ausgeschalteter Rufnummern­unterdrückung konnte die Autentizität der Teilnehmer nachvollzogen werden. Die Empfangsquittung der Zielnummer wurde wie der Rückschein eines Einschreibens betrachtet: Sie schien zu beweisen, dass das Fax inhaltlich korrekt an den gewünschten Empfänger übertragen wurde und nun am Empfangsgerät als Ausdruck vorliegt. In vielen Geschäftsbeziehungen - teilweise aber auch im Umfeld von Behörden - wurden daher Faxe als juristisch bindende Schriftstücke akzeptiert.

Heute müssen wir erkennen, dass diese positiven Eigenschaften des Faxens spätestens mit dem Übergang zu VoIP unwiderbringlich verloren sind. VoIP macht auch Faxe genauso abhörbar und manipulierbar wie alle alle anderen unverschlüsselten Übertragungen in öffentlichen Netzen. T.38 lässt die Verschlüsselung lediglich optional zu. Die Rufnummern haben durch die Öffnung der Netze an „beliebige“ Provider und den Einzug von SIP ihren hohen Vertrauensgehalt verloren. Und eine Empfangsquittung von einem Endgerät mit Zwischenspeicher ist eben nicht mehr als Indiz. Wer kann sicherstellen, dass wirklich ein Ausdruck erfolgt ist? Selbst also wenn T.38 flächendeckend verfügbar wäre: ein juristisch bindender Charakter von Faxen wird auf Dauer nicht (mehr) aufrecht zu halten sein.

Die Zukunft ist digital signiert
Die Deutsche Bundesregierung hat schon in den 1990er Jahren erkannt, dass der klassische Post-Brief als Geschäftsgrundlage für die Wirtschaft (aber auch Behörden) zu langsam ist. Sie erarbeitete daher das Gesetz über Rahmenbedingungen für elektronische Signaturen (SigG, 1997). Dieses Gesetz definiert Verfahren, die ermöglichen, juristisch zweifelsfreie und damit verbindliche Kommunikation über öffentliche Datennetze (z.B. das Internet) abzuwickeln. Den technischen Kern stellen digitale Zertifikate (X.509) und nicht etwa Faxübertragungen dar. Bekannte Spielarten sind z.B. signierte & verschlüsselte E-Mails (SMIME) oder signierte & verschlüsselte Übertragungen von Steuerdaten an die Finanzbehörden (z.B. Elster).

Da die öffentliche Akzeptanz des SigG auch über 10 Jahre nach der Gesetzgebung immer noch sehr gering war, wurde um 2010 das De-Mail-Gesetz nachgeschoben. Dieses Gesetz soll eine konkrete Anwendungsform des SigG – den De-Mail-Dienst – erzwingen. Im De-Mail-Dienst sind alle vom Fax erwarteten Merkmale (Authentizität, Integrität, Vertraulichkeit, Quittungsbetrieb) integriert. Heute, ca. 5 Jahre nach Inkrafttreten des De-Mail-Gesetzes, ist auch für diesen Dienst noch keine wesentliche Marktdurchdringung zu erkennen. Dies mag an den hohen organisatorischen Bedingungen für die Zertifikatsbeantragung/-Ausstellung und die unübersichtliche Lage an zertifizierenden Stellen liegen. Es mag aber auch sein, dass dem Medium Fax immer noch eine führende Position unterstellt wird, so dass die Wirtschaft noch keinen Handlungsdruck sieht, ein neues Übertragungsverfahren zu adaptieren.

Fazit zur Problematik mit Fax-over-IP
Aus Sicht des Autors wird der Abbau des digitalen Telefonnetzes (ISDN) und der Übergang zu IP-basierten Telefonanschlüssen die Zuverlässigkeit der Übermittlung von Faxdokumenten in Zukunft deutlich einschränken. Technische Lösungen für dieses Problem sind innerhalb der Fax-Technologie selbst nicht in Sicht, zumindest nicht, solange T.38 nicht Ende-zu-Ende verfügbar ist. Es scheint heute keine Patentrezept für die juristisch belastbare Übertragung von Fax-over-IP zu geben, zumindest nicht wenn weiterhin Gruppe 3 Fax-Geräte ohne Signaturoptionen und Verschlüsselung eingesetzt werden. Es scheint daher nicht unwahrscheinlich, dass die Fax-Technologie mit dem IP-Umbau des Telefonnetzes ihren Rückzug aus dem Weltgeschehen antreten wird.

Dies bedeutet für viele Privatpersonen und Firmen, dass für die verbindliche Kommunikation, insbesondere für eilige, vertrauliche Nachrichten oder für Nachrichten, die mit Garantie (Empfangsquittung) und unverändert zugestellt werden sollen, andere Übermittlungsformen als das Fax gesucht werden müssen.

Zu beobachten ist, dass für viele Anwender E-Mails die Funktion von Faxen übernommen haben. Einer E-Mail wird instinktiv unterstellt, dass sie zuverlässig und verbindlich Informationen austauscht. Bedenkt man jedoch die Defizite von unverschlüsselten & unsignierten E-Mails hinsichtlich Authentizität, Vertraulichkeit und Integrität, kann eine solche E-Mail-Übertragung keinen juristisch verbindlichen Charakter haben. Verbindlich wird die E-Mail erst durch z.B. SMIME-Techniken (Verschlüsselung und Signatur) und einen Quittungsbetrieb – aber wer setzt diese Optionen schon ein (ausgenommen ggf. automatisierte Verfahren im EDI-Umfeld)?

Innerhalb von Deutschland könnte De-Mail ggf. zukünftig eine Alternative darstellen. Technisch sind die Voraussetzungen dafür gegeben, es müssten aber erheblich mehr Teilnehmer dieses Verfahren annehmen. In globalisierten Märkten müssen zudem wohl auch internationale Lösungen gesucht werden. Es bleibt abzuwarten, welche Verfahren sich in Zukunft durchsetzen. Über das Ende des Faxes nachdenken sollte man aber schon heute.

Beste Grüße, Harald Krause

ich bin seit 18 Jahren in der IT als Berater tätig und beschäftige mich jetzt einige Jahre davon mit dem Thema Client Management, dies insbesondere vor dem Hintergrund von Microsoft System Center Configuration Manager, allgemein SCCM, oder auch einfach Config Manager genannt. Des Öfteren werde ich von Kunden angefragt, um die Einführung von SCCM im Unternehmen zu begleiten und meine Erfahrung zu diesem Thema einzubringen. Meistens ist es dann so, dass Anforderungen wie Softwareverteilung, OS Deployment, Software- und Hardware Inventur im Vordergrund stehen. Wenn ich dann nachfrage, wie es mit dem Thema Software Update Verteilung und SCCM aussieht, höre ich oft als Antwort „nein danke, das machen wir seit Jahren mit WSUS, da sind wir gut mit bedient, dafür brauchen wir den SCCM nicht“. Wenn die neu aufgebaute SCCM Infrastruktur dann in den Betrieb übergegangen ist und der Kunde eine gewisse Sicherheit im Umgang mit der Materie erlangt hat, erregt das Thema Software Updates mit SCCM dann meist doch früher oder später noch mal das Interesse. In diesem Artikel möchte ich gerne die grundsätzliche Vorgehensweise im Umgang mit Software Updates unter SCCM erläutern und eine „Best Practice“ vorstellen, wie sich der Software Update Prozess unter SCCM praktisch organisieren lässt.

SCCM Software Update Infrastruktur

Manchmal höre ich bei meinen Kunden Sätze wie „Der SCCM benötigt doch für Updates intern sowieso den WSUS, dann können wir doch unseren bereits vorhandenen WSUS Server bestimmt für SCCM verwenden?“. Diese Frage offenbart einige Hoffnungen und Hintergedanken, z. B. dass man eine WSUS Infrastruktur nicht ein weiteres Mal neu aufbauen, den Plattenplatz zur Ablage der Updates nicht doppelt bereithalten muss oder gar WSUS im Parallelbetrieb zu SCCM weiterhin wie gewohnt verwenden kann. Leider lassen sich diese Hoffnungen nicht alle erfüllen. Richtig ist, dass SCCM zwar eine WSUS-Instanz benötigt, allerdings nur als „Ausführungsgehilfe“, nicht als gleichberechtigter Partner. Insbesondere ein Parallelbetrieb derselben WSUS-Instanz ist nicht erlaubt, bzw. wird vom Hersteller nicht unterstützt. Selbstverständlich kann man in seiner IT-Landschaft sowohl einen dedizierten WSUS als auch SCCM parallel betreiben, allerdings müssen dann die mit Updates zu versorgenden Clients aufgeteilt werden in solche, die von SCCM mit Updates versorgt werden und solchen, die weiterhin „klassisch“ per WSUS ihre Updates erhalten. In manchen Situationen kann eine solche Aufteilung durchaus Sinn ergeben. Um einen solchen Parallelbetrieb zu ermöglichen, benötigt man dann allerdings auch mindestens zwei WSUS-Instanzen im Unternehmen, wobei eine Instanz exklusiv für SCCM reserviert ist. Auf der Clientseite wird SCCM ebenfalls technisch durch den Windows Update Agent (der Client-Komponente von WSUS) bei der Installation und Inventur der Updates unterstützt. Entweder ist der Client unter der Hoheit von SCCM, oder der Client bezieht seine Updates von einem autarken WSUS Server, ein Mischbetrieb im Sinne von „einige Updates kommen von WSUS, andere von SCCM“ ist nicht möglich. Wohl ist es denkbar, dass ein Client dauerhaft durch SCCM mit Software Paketen versorgt wird, seine Windows Updates aber gleichzeitig durch WSUS und somit nicht durch SCCM erhält.

Um mit SCCM Software Updates verteilen zu können, muss mindestens ein Software Update Point in der SCCM Landschaft vorhanden sein, d. h. es muss einen SCCM Server geben, bei dem diese Rolle aktiviert ist. In kleineren und mittleren Umgebungen wird dieser Server meist zugleich der Primary Site Server, also umgangssprachlich „der SCCM Server“ sein, weil es hier oft ohnehin nur einen SCCM Server gibt, wenn man von den Distribution Points einmal absieht. Um die Rolle eines Software Update Point installieren zu können, muss auf dem System bereits eine lokale WSUS-Instanz vorhanden sein. Falls das noch nicht der Fall sein sollte, muss die WSUS Rolle im Betriebssystem zunächst aktiviert und eingerichtet werden. Der Software Update Point ist quasi das Bindeglied zwischen WSUS und SCCM. Nachdem der Software Update Point eingerichtet worden ist, braucht und sollte man sich für die zugrundeliegende WSUS Instanz nicht mehr weiter interessieren, da sie vollständig unter der Kontrolle des SCCM belassen werden und nicht z. B. für die Verteilung von Updates „an SCCM vorbei“ verwendet werden darf.

SCCM Software Update Point Installation

Wie im vorigen Abschnitt beschrieben, benötigt man zur Einrichtung eines Software Update Point unter SCCM als Voraussetzung zunächst eine lokale WSUS Instanz. Diese lässt sich recht einfach bereitstellen. Ich möchte hier nicht allzu detailliert auf die WSUS Installation eingehen, darüber ist sicherlich schon an anderer Stelle genug geschrieben worden.

Die WSUS Rolle benötigt zur Funktion eine Datenbank, die entweder in Form der Windows Internal Database oder als externe SQL Server Datenbank implementiert werden kann. Im Laufe der WSUS Installation muss man sich zwischen diesen beiden Varianten entscheiden:

Da man im Zusammenhang mit SCCM ohnehin eine SQL Server Instanz betreiben muss, empfehle ich hier, die externe Datenbankvariante zu wählen, insbesondere dann, wenn der SQL Server „co-located“ also auf demselben Server betrieben wird, wie auch der SCCM Server. Microsoft empfiehlt in diesem Fall, die WSUS Datenbank sogar auf einer separaten SQL Server Instanz zu betreiben. Dies mag aus z. B. Performancegründen sinnvoll sein, ich persönlich halte mich aber i. d. R. nicht an diese Empfehlung.

Wenn man die Vorgabe akzeptiert, Updates lokal zu speichern, muss man einen Pfad zu einem Verzeichnis angeben, wo diese abgelegt werden sollen. Hierbei ist es wichtig, dass dieses Verzeichnis zum Zeitpunkt der Installation bereits existiert, da die Einrichtung sonst scheitert. Es wäre nett, wenn der Assistent spätestens beim Verlassen der Dialogseite auf diesen Umstand aufmerksam machen würde, was aber leider nicht der Fall ist.

Falls man sich dazu entschlossen hat, eine externe SQL Server Datenbank zu verwenden, wird man auf der
nächsten Dialogseite nach dessen Server- und Instanznamen gefragt. Dass die Verbindung zu diesem Server getestet werden sollte - „Check connection“, versteht sich sicher von selbst.

Nach der Installation der WSUS Rolle wird man aufgefordert, die abschließende WSUS Konfiguration vorzunehmen. Dies ist allerdings in unserem speziellen Fall unnötig, da genau diese Konfiguration im Rahmen der Software Update Point Installation durch SCCM ohnehin durchgeführt wird.

Bevor es an die Installation des Software Update Point geht, sollte sichergestellt werden, dass das Windows Update KB 3095113 auf dem eingesetzten Server installiert ist. Fehlt dieses Update, kann es im Zusammenhang mit Updates für Windows 10 zu ärgerlichen Problemen mit der WSUS Datenbank kommen.

Nun können wir mit der eigentlichen Installation der Software Update Point Rolle auf dem SCCM Server beginnen. In der SCCM Konsole wechselt man in den Bereich Administration und hangelt sich im Menübaum nach Overview | Site Configuration | Servers and Site System Roles durch, markiert den Primary Site Server und wählt den Befehl Add Site System Roles:

Der Assistent Add Site System Roles öffnet sich:

Auf der ersten Seite akzeptiert man die Vorgaben und geht gleich zur zweiten Seite, wo es um die Proxy-Konfiguration geht. Falls in Ihrem Unternehmen ein Proxy verwendet werden muss, um eine Verbindung zum Internet herzustellen, müssen Sie auf dieser Dialogseite den Namen und den Port des Proxy Servers konfigurieren. Womöglich müssen Sie auch Benutzernamen und Passwort eines Users angeben, der sich gegenüber dem Proxy authentifizieren kann. Wenn dies der Fall sein sollte, wäre es an dieser Stelle sinnvoll, einen dedizierten User für diesen Zweck im Active Directory anzulegen.

Auf der folgenden Dialogseite wählt man die Rolle Software Update Point aus:

Auf der folgenden Dialogseite wird man gefragt, welche WSUS Ports verwendet werden sollen. Heute sollten dies (z. B. bei Verwendung von Windows Server 2012 R2) die Ports 8530 und 8531 sein. Bei älteren Windows Server Versionen kommt auch 80 und 443 in Frage.

Auf der nächsten Dialogseite kann man die Verwedung des Proxy Servers nochmals genauer festlegen. In meiner Testumgebung habe ich keinen Proxy Server, daher zeigt der Screenshot hier keine entsprechenden Einstellungen:

Auf der folgenden Dialogseite hat man die Möglichkeit, die Synchronisationsquelle zum Bezug der Updates zu konfigurieren. Üblicherweise wird man hier Synchronize from Microsoft Update auswählen. Es gäbe aber auch alternativ die Möglichkeit, einen bereits vorhandenen WSUS Server in ihrem Unternehmen als Update Quelle anzugeben:

Die nächste Dialogseite möchte wissen, mit welchem Intervall Updates synchronisiert, also „nach Updates gesucht“ werden soll. Hier dürfte die Vorgabe Run every 1 Days in den meisten Fällen passend sein und braucht daher nicht geändert zu werden:

Im nächsten Abschnitt geht es darum, wann genau Updates als expired eingestuft werden sollen. Ich bevorzuge hier die Standardeinstellung Immediately expire a superseeded software update. Hierbei werden solche Updates unmittelbar als expired eingestuft, sobald ein Update durch ein nachfolgendes Update abgelöst worden ist. In großen Unternehmen kann es sinnvoll sein, das ursprüngliche Update so lange zu behalten, bis man das nachfolgende Update gründlich getestet hat und solange das ursprüngliche Update weiterhin verteilen kann.
Der WSUS Cleanup Wizard ist sehr hilfreich, um den für Updates benötigten Plattenplatz nicht exorbitant anwachsen zu lassen, er sollte daher aktiviert bleiben.

Auf der nächsten Dialogseite gibt man an, welche Klassifikationen man bei der Suche nach Updates berücksichtigen möchte. In meiner Umgebung habe ich alles außer Feature Packs und Tools ausgewählt. Die Klassifikation Upgrades ist wichtig für Windows 10 OS Updates, sollte also aktiviert werden, falls Sie vorhaben, neue Windows 10 Builds mit SCCM zu verteilen. Wichtig ist hierbei, dass man vorher das weiter oben bereits erwähnte Update KB 3095113 installiert hat, weil sonst die WSUS Datenbank bei der ersten Updatesynchronisation in einen ungültigen Zustand gerät. Sollte das bereits passiert sein, bekommt man das aber auch wieder korrigiert, wie das geht, steht hier.

Die folgende Dialogseite fordert dazu auf, die Produkte auszuwählen, zu denen man Updates beziehen möchte. Hier sollte man wirklich nur die Produkte auswählen, die man benötigt, da sonst zum einen die Synchronisationsläufe unnötig lange dauern und man auch viel Plattenplatz bereithalten muss, es kommen im Laufe der Zeit doch eine ganze Menge an Updates zusammen.

Auf der vorletzten Dialogseite können noch die Sprachen ausgewählt werden. Auch hier sollte man sich darauf beschränken, was man wirklich braucht, obwohl die meisten Windows Updates sowieso „multilingual“ sind.

Mit Abschluss des Assistenten ist die Einrichtung des Software Update Point zunächst erledigt. Falls an der Konfiguration zu einem späteren Zeitpunkt Änderungen vorgenommen werden sollen, so kann dies im Bereich Administration über Overview |Site Configuration | Sites und dann Configure Site Components | Software Update Point erfolgen:

SCCM Client für Software Updates konfigurieren

Damit der SCCM Client überhaupt Software Updates anfragt und diese auch ggf. herunterlädt und installiert, müssen zunächst die Client Settings entsprechend angepasst werden. Hier empfiehlt es sich, nicht die Default Client Settings zu verändern, sondern ein neues Client Settings Objekt für diesen Zweck anzulegen:

Die einzig wichtige Einstellung, die uns hier zunächst interessiert, ist Enable Software Updates on Clients.

Um die so erstellten Client Settings wirksam
werden zu lassen, benötigen wir noch eine Collection, in der die Computer aufgenommen werden und letztendlich die zu verteilenden Updates erhalten sollen. Ich habe diese Collection in meiner Umgebung Computers receiving updates from SCCM genannt:

Auf diese Collection wendet man die zuvor erstellten Client Settings an, indem man ein entsprechendes Deployment für die Settings erstellt:

Zum Test empfiehlt es sich, nun, einen oder mehrere Testcomputer in die zuvor erstellte Collection aufzunehmen und auf dem Client die Aktion Computerrichtlinienabruf und Auswertungszyklus auszuführen:

Nach einer gewissen Wartezeit (Bei SCCM geht eigentlich immer alles mit „einer gewissen Wartezeit“ einher), sollte sich die Komponente Softwareupdate-Agent als Aktiviert zeigen:

Falls in Ihrer Umgebung auch Updates über den klassischen WSUS-Weg verteilt werden, ist zu beachten, dass diejenigen Computer, die ab jetzt Updates durch SCCM erhalten, nicht von den Domain Group Policies der WSUS Konfiguration erfasst werden, da diese sonst die SCCM-seitigen Client Einstellungen möglicherweise überschreiben und damit wirkungslos werden lassen.

Zur Kontrolle, ob die SCCM Client-Einstellungen greifen, kann der Inhalt des WSUS Client Registry Schlüssels

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

geprüft werden. Die dort vorgefundenen URLs müssen auf den SCCM Server verweisen, auf dem sich der Software Update Point befindet:

Es kann durchaus einige Minuten bis Stunden dauern, bis sich die erwarteten Einstellungen auf dem Client zeigen. SCCM ist eher ein LKW und kein Formel 1 Rennwagen.

Update Synchronisation

Nachdem nun alle vorläufig notwendigen Konfigurationen der SCCM-Infrastruktur abgeschlossen sind, können wir die erste Update Synchronisation durchführen. Zu diesem Zweck wechselt man in den Bereich Software Library und dort in den Menüordner Overview | Software Updates | All Software Updates:

Beim ersten Aufruf dieses Bereichs werden hier wahrscheinlich noch keine Updates angezeigt. Gemäß Schedule haben wir bei der Installation eingestellt, dass einmal täglich eine Update Synchronisation durchgeführt werden soll. Es ist aber jederzeit möglich eine ad hoc Synchronisation durchzuführen:

Die erste durchgeführte Synchronisation kann durchaus lange, mitunter Stunden dauern. Um sich einen Überblick über den aktuellen Status zu verschaffen, empfiehlt sich die Beobachtung der Logdatei wsyncmgr.log:

Man beachte, dass zu diesem Zeitpunkt noch keine Update-Inhalte heruntergeladen werden. Zu diesem Zeitpunkt geht es lediglich um das „Suchen nach Updates“. Hierbei werden die zuvor konfigurierten Klassifizierungen und Produkte berücksichtigt.

Nach Abschluss der Synchronisation werden alle aufgefundenen Updates in der Ansicht All Software Updates angezeigt:

Nach der ersten Synchronisation werden dies erfahrungsgemäß sehr viele Updates sein, je nach Anzahl der ausgewählten Produkte womöglich tausende. Um sich einen Überblick zu verschaffen, empfiehlt es sich, die Updates erst einmal nach Produkten zu gruppieren. Hierzu blendet man sich zunächst die Spalte Product in die Listenansicht ein, indem man mit der rechten Maustaste auf eine
beliebige Spaltenüberschrift klickt und aus dem Kontextmenü die entsprechende Spalte auswählt:

Durch erneuten Aufruf desselben Kontextmenüs lässt sich die Liste dann nach Produkten gruppieren:

Da man in der Regel nicht jedes Update einzeln verteilen möchte, empfiehlt es sich Update Groups zu verwenden. Eine Update Group bündelt quasi mehrere Updates zu einem logischen Paket. Microsoft empfiehlt allerdings, nicht mehr als 1000 Updates in eine Update Group aufzunehmen, was gerade für die Verarbeitung der “ersten Welle” von Updates mit SCCM ein gewisses Organisationstalent erfordert. Es gibt hier verschiedene Meinungen, wie man seine Update Groups einteilen sollte. Ich bevorzuge eine Einteilung in Produkte und Monate. D. h. jeden Monat bilde ich eine neue Update Group pro Produkt. Für die Verarbeitung der Updates, die bei der ersten Synchronisation eintreffen, möchte man sich natürlich diese Arbeit nicht machen, da die Updates ja u. U. aus sehr vielen vergangenen Monaten stammen. Hier bildet man am besten eine Gruppe pro Produkt und nimmt alle bis zum aktuellen Zeitpunkt aufgelaufenen Updates in diese Gruppe auf. Diese Gruppe nennt man dann z. B. Windows 7 Updates bis 07-2016. In den folgenden Monaten bildet man dann jeweils eine neue Gruppe und nennt diese dann z. B. Windows 7 Updates 08-2016, Windows 7 Updates 09-2016 usw.

Um eine Update Group zu erzeugen, markiert man diejenigen Updates, die eine Gruppe bilden sollen und wählt aus dem Kontextmenü den Befehl Create Software Update Group:

Nachdem man die gewünschten Update Groups gebildet hat, lassen sich alle Updates gruppenweise herunterladen und paketieren, wobei diese beiden Aktionen in einem Schritt geschehen. Um den Download einer Update Group zu starten, wechselt man in den Menüordner Software Update Groups, selektiert die gewünschte Update Group und wählt aus dem Kontextmenü den Befehl Download:

Der Dialog Download Software Updates Wizard öffnet sich:

Beim Download einer Update Group wird ein Deployment Package benötigt, das nun angelegt werden muss. Hierfür müssen ein Name und ein Pfad zu einem Ordner für das Package angegeben werden. Im Gegensatz zu der Anzahl von Updates innerhalb einer Update Group ist die Anzahl der möglichen Updates innerhalb dieses Deployment Package nicht eingeschränkt. Ich empfehle daher, pro Produkt ein Deployment Package anzulegen und dieses bei Neuerscheinen von weiteren Updates zu „recyclen“, d. h. de facto jeden Monat um weitere Updates zu ergänzen. Es ist nicht so, dass der Inhalt dieses Deployment Package bei der Update Installation jedes Mal komplett auf den Client heruntergeladen wird, wie dies bei einem klassischen Software Package der Fall wäre. Nur die Installationsdateien derjenigen Updates, die der Client aktuell benötigt, werden auch tatsächlich vom Distribution Point heruntergeladen.

Zur Ablage der Update Deployment Packages verwende ich folgende Ordnerstruktur:

\\<ServerName>\<ShareName>\
+- Updates
+- <Herstellername>
  +- <Produktname>

Wobei hier de facto als einziger Hersteller Microsoft auftaucht, theoretisch wären auch Updates anderer Hersteller, z. B. Adobe denkbar, die über System Center Updates Publisher 2011 importiert werden könnten.

Auf der folgenden Dialogseite wird man aufgefordert, einen Distribution Point für die Bereitstellung des Update Deployment Package zu wählen:

Auf der nächsten Seite können bei Bedarf noch Anpassungen an den Verteilungseinstellungen vorgenommen werden:

Anschießend hat man die Möglichkeit, die Herkunft der Updates zu bestimmen, falls man sie nicht aus dem Internet beziehen möchte bzw. kann:

Auf der nächsten Seite können die zu unterstützenden Sprachen ausgewählt werden, wobei heute die meisten Windows Updates sowieso „multilingual“ sind:

Nachdem man die Zusammenfassung mit Next bestätigt hat …

… erfolgt der eigentliche Download der Update-Installationsdateien. Eine der wenigen Stellen in SCCM, wo der Fortschritt tatsächlich „live“ mitverfolgt werden kann, ohne dass man hierfür in eine Logdatei schauen muss:

Update Verteilung

Nach all der Vorarbeit sind wir nun endlich in der Lage, die vorbereiteten Updates auszurollen. Dies kann entweder für jedes Update einzeln erfolgen, oder aber man verteilt die Update Group, letzteres ist natürlich die zu empfehlende Vorgehensweise. Um das Deployment anzulegen, startet man im Menüordner Software Update Groups, selektiert die zu verteilende Update Group und wählt den Befehl Deploy aus dem Kontextmenü:

Der Deploy Software Updates Wizard öffnet sich:

Im Wesentlichen muss man hier lediglich eine Collection auswählen, auf die die Updates verteilt werden sollen. Wir wählen hier die von uns zu diesem Zweck zuvor angelegte Collection:

Im Grunde könnte man für den Namen des Deployments die Vorgabe „Microsoft Software Updates …“ beibehalten. Ich übernehme für den Namen des Deployments immer den Namen der Software Update Group, aber das ist schließlich Geschmackssache:

Auf der Seite Deployment Settings kann festgelegt werden, ob das Deployment Required oder Available sein soll. Falls das Deployment für Client Computer, also „Nicht-Server“ Systeme vorgesehen ist, empfiehlt es sich, das Deployment als Required einzustufen. Falls das Deployment für Server Systeme eingestellt wird, ist es auf jeden Fall sinnvoll, ein optionales, also Available Deployment zu wählen, um den Zeitpunkt der Installation und ggf. Neustartes genau unter Kontrolle zu haben. Manche meiner Kunden verwenden SCCM zur Updateverteilung ausschließlich auf Client Systemen, Server Systeme werden dann „klassisch“ mit WSUS versorgt. Der Grund dafür ist oft, dass SCCM Lizenzen für Server erheblich teurer sind, als für Clientbetriebssysteme.

Auf der nächsten Dialogseite kann festgelegt werden, ab wann das Deployment starten soll und ab wann die „Deadline“ des Deployments erreicht sein soll. Spätestens bei Erreichen dieser Deadline, wird die Installation eines Required Deplyoments gestartet. Auch erforderliche Neustarts werden ggf. ab diesem Zeitpunkt erzwungen.

Auf der nächsten Dialogseite kann die User Experience der Update Installation beeinflusst werden. So kann der Grad der Benutzerbenachrichtigungen und die „Aufdringlichkeit“ der Installation eingestellt werden:

Manchen meiner Kunden bevorzugen es, hier sämtliche Benachrichtigungen zu unterdrücken, um „keine schlafenden Hunde zu wecken“. Ich persönlich bevorzuge es allerdings hier, sämtliche Benachrichtigungen anzuzeigen. Meiner praktischen Erfahrung nach ist es sinnvoll, den erzwungenen Neustart bei den Servern sowieso, aber insbesondere auch bei Workstations zu unterdrücken, da man es sonst häufig erlebt, dass sich Kollegen darüber beschweren, dass gerade in einem denkbar ungünstigen Moment ein Neustart erzwungen wird und wie man das „jetzt eben schnell in den kommenden Minuten doch noch unterbinden könnte“.

Auf der folgenden Dialogseite können diverse Alarmierungen, insbesondere im Zusammenhang mit System Center Operations Manager eingestellt werden, worauf ich hier aber nicht näher eingehen möchte.

Die nächste Dialogseite ermöglicht ein Feintuning des Downloadverhaltens. Ich empfehle hier, die Option Downlad software updates from distribution point and install zu aktivieren, die sich darauf bezieht, wie sich der SCCM Client verhalten soll, falls er sich in einer Network Boundary befindet, die als slow eingestuft ist. Falls diese Option nicht aktiviert ist, wenn also stattdessen die Einstellung Do not install software updates ausgewählt wird, kommt es auf dem Client im Softwarecenter zu dem Phänomen, dass die Software Updates zwar angezeigt und scheinbar auch heruntergeladen werden, der Downloadfortschritt jedoch dauerhaft bei „0 %“ hängen bleibt. Dieses Verhalten ist etwas unglücklich, es wäre mir lieber, wenn auf dem Client eine Meldung in der Art „Wird wegen langsamer Netzwerkverbindung nicht heruntergeladen“ angezeigt würde. Ein scheinbar hängengebliebener Downlaod führt an der Stelle immer wieder zu Verwirrung und erhöhtem Supportaufwand.

Ich persönlich wähle hier auch die Option, Software Updates im Zweifelsfall von Microsoft Updates aus dem Internet herunterzuladen, falls kein Distribution Point gefunden werden kann der das Update bereithält.

Nach Abschluss des Deploy Software Updates Wizard sind unsere Updates nun endlich auf den Weg gebracht:

Um bei der Menge an Updates halbwegs den Überblick zu bewahren, verschiebe ich diejenigen Updates, die bereits verteilt worden sind in einen Unterordner. Hierzu wechsle ich wieder in den Menüordner All Software Updates, markiere die erledigten Updates und wähle aus dem Kontextmenü den Befehl Move:

Der Archivordner muss natürlich zuvor bereits angelegt worden sein. Die auf diese Art verschobenen Updates verschwinden dann aus All Software Updates und geben den Blick auf diejenigen Updates frei, die noch nicht verteilt worden sind. Ich betrachte den Ordner All Software Updates quasi als meinen Posteingang für neue Updates, die verteilt werden müssen.

Monitoring und Reporting

Nachdem erklärt wurde, wie Updates mit SCCM verteilt werden können, möchte ich nun abschließend noch zeigen, wie man sich einen Überblick über den Verteilungsgrad der Updates verschaffen kann.

Einen ersten groben Überblick erhält man im Menüordner Software Update Groups. Durch Selektion derjenigen Update Group, deren Verteilungsgrad man ermitteln möchte, wird im Bereich Summary ein Diagramm angezeigt, das den Anteil der Clients darstellt, deren Zustand bgzl. Der Update Group Compliant, Non-Compliant oder Unknown ist:

Leider lässt sich die Frage, die sich hier unmittelbar aufdrängt, nicht beantworten, nämlich für welche Computer dieser Status gilt. Um dies zu erfahren kann man z. B. den Status des zugehörigen Deployments im Bereich Monitoring unter Overview | Deployments abrufen. Dazu muss man leider das zugehörige Deployment erneut heraussuchen. Hierbei hilft die zuvor empfohlene Gepflogenheit, das Deployment einer Update Group genauso zu benennen, wie die Update Group selbst:

Unter den Deployments werden die Diagramme pro Collection angezeigt, Unter den Software Update Groups wird der Status für alle Collections zusammengefasst dargestellt, dadurch ergeben sich in den beiden gezeigten Screenshots unterschiedliche Zahlenwerte. Durch Anklicken des Links View Status, können weitere Detailinformationen abgerufen werden:

Hier ist dann auch sichtbar, welche Computer sich in welchem Status befinden:

In den meisten Fällen dürfte dieses ad hoc Reporting schon ausreichend sein. Wenn man genauer hinsehen möchte, oder den genauen Status zu einem einzelnen Update erfahren möchte, kann sich einem der zahlreichen Reports bedienen, die zu diesem Zweck existieren. Wenn man z. B. den Verteilungszustand eines bestimmten Updates erfahren möchte, so merkt man sich de KB Artikelnummer des Updates und ruft den Report Software Updates – A Compliance | Compliance 2 – Specific software update auf:

Durch Auswahl einer Collection und Angabe der KB Artikelnummer (nur die Nummer, ohne „KB“ davor), erhält man einen ausführlichen Report zu genau diesem Update:

Durch Anklicken der im Reportergebnis angezeigten Hyperlinks lässt sich ein „Drilldown“ in die jeweils nächste Anzeigeebene durchführen:

Zusammenfassung

Niemand kommt um das Thema Update Deployment herum. Ob es sich lohnt, hierfür SCCM einzusetzen, oder ob man hierfür eine meist ohnehin schon vorhandene WSUS Infrastruktur nutzen soll, lässt sich nicht pauschal beantworten. Falls man aber SCCM bereits im Unternehmen eingeführt hat, lohnt es sich meiner Ansicht nach sehr wohl, über eine Update Verteilung mit SCCM nachzudenken, weil die Integration dieses Themas in SCCM sehr gut gelungen ist. Wer z. B. die Verteilung von Softwarepaketen im Zusammenhang mit SCCM bereits kennt, dem dürfte der Einstieg in die Updateverteilung nicht sonderlich schwerfallen, da die verwendeten Mechanismen untereinander sehr ähnlich sind.

Je nach Vertragsverhältnis, dass man mit Microsoft unterhält, kann es auch durchaus Sinn ergeben, einen gemischten Ansatz zu verfolgen, bei dem die Updateverteilung auf den Workstations mit SCCM erfolgt und die Verteilung auf Servern klassisch mit WSUS durchgeführt wird, insbesondere vor dem Hintergrund, dass SCCM Server Management Lizenzen deutlich teurer sind, als Client Lizenzen.

Das Thema Update Deployment mit SCCM lässt sich nicht nebenbei erklären oder erlernen, dass zeigt allein der Umfang dieses Blogbeitrags. Dabei wurden bisher gerade mal nur die Grundlagen gezeigt. Ich habe vor, weitere Fortsetzungen zu diesem Beitrag zu erstellen, wo ich auf Automatic Deployment Rules, Offline Servicing und Update Verteilung im Rahmen von OS Deployments mit SCCM eingehen möchte. Diese Features machen die Verteilung von Updates mit SCCM erst richtig spannend und bieten Möglichkeiten, die sich mit einer reinen WSUS Infrastruktur nicht ohne weiteres abbilden lassen.

Grüße,

Thomas Froitzheim…