Steht die Fax-Technologie vor dem Aus?

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.

Werbetext Deutsche Telekom (Quelle geschaeftskunden.telekom.de)

Faxübertragung über das Telefonnetz: ein alter Hut.
Techniken, die Schriftstücke über das Telekommunikationsnetz übertragen, wurden zeitlich fast parallel mit der eigentlichen Fernsprechtechnik entwickelt, die Marktreife dauerte jedoch hier deutlich länger. Etwa Mitte der 1960er Jahre setzte Xerox den ersten De-Facto-Standard in Sachen Fax. Waren erste Fax-Geräte noch langsam (Gruppe 1), kam die nächste Generation (Gruppe 2) trotz analoger Übertragungstechnik auf bessere Übertragungsergebnisse (höhere Auflösung) und schnellere Übertragungsraten. Der wahrscheinlich am weitesten verbreitete Fax-Standard wird als Fax Gruppe 3 bezeichnet. Gruppe 3 Geräte setzen eine digitale Kompression und Fehlerkorrektur ein, übertragen dann aber die Daten über analoge Schnittstellen und Netze. Erst Fax-Geräte der Gruppe 4 verwendet durchgängig Digitaltechnik, also auch z.B. digitale ISDN S0-Schnittstellen. Geräte der Gruppe 4 sind trotz der besten Übertragungsqualität und schnellsten Geschwindigkeit eher selten vorzufinden.
 

„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.

Bild: Leistungsmerkmale von De-Mail (Quelle: www.cio.bund.de)

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Update Deployment mit SCCM

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.

clip_image002

clip_image004

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:

clip_image006

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.

clip_image008

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.

clip_image010

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.

clip_image012

clip_image014

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:

clip_image016

Der Assistent Add Site System Roles öffnet sich:

clip_image018

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.

clip_image020

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

clip_image022

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.

clip_image024

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:

clip_image026

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:

clip_image028

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:

clip_image030

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.

clip_image032

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.

clip_image034

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.

clip_image036

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.

clip_image038

clip_image040

clip_image042

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:

clip_image044

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:

clip_image046

clip_image048

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

clip_image050

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:

clip_image052

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

clip_image054

clip_image056

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:

clip_image058

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

clip_image060

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:

clip_image062

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:

clip_image064

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:

SNAGHTML5193ba

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:

clip_image068

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:

clip_image070

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:

SNAGHTML90444f

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

SNAGHTML528fec

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:

SNAGHTML55d321

SNAGHTML561c30

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:

SNAGHTML56a95d

Der Dialog Download Software Updates Wizard öffnet sich:

clip_image082

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>

image

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:

clip_image086

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

clip_image088

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:

clip_image090

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

clip_image092

Nachdem man die Zusammenfassung mit Next bestätigt hat …

clip_image094

… 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:

clip_image096

clip_image098

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ü:

clip_image100

Der Deploy Software Updates Wizard öffnet sich:

clip_image102

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:

clip_image104

clip_image106

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:

clip_image108

clip_image110

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.

clip_image112

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:

clip_image114

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.

clip_image116

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.

clip_image118

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.

clip_image120

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

clip_image122

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:

clip_image124

clip_image126

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:

clip_image128

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:

clip_image130

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:

clip_image132

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

clip_image134clip_image136

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:

clip_image138

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:

clip_image140

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

SNAGHTML75b83b

SNAGHTML8d3bc3

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…

MFA 7.1.2.1 Portal Error nach Update…

…mir ist aufgefallen, dass ich noch gar nicht dazu gekommen bin mal einen Artikel zu MFA zu bloggen. Seitdem Microsoft Azure Multi-Factor Authentication als zweiten Authentifizierungsfaktor mit im Programm hat (https://azure.microsoft.com/de-de/services/multi-factor-authentication/) bin ich fleißig dabei dies bei unseren Kunden zu implementieren. Natürlich nehme ich jede neue Version “dankbar” entgegen und teste/implementiere diese.

So war ich sehr froh über die Tatsache, dass modifizierte web.configs ab einer MFA-Version nicht mehr überschrieben und auf Null gesetzt worden. Für das MFA Portal und den MFA Mobile App Web Service sind diese modifizierten Konfigurations-Files essentiell notwendig: https://azure.microsoft.com/de-de/documentation/articles/multi-factor-authentication-get-started-portal/

Letzte Woche wurde mir nun das Update auf die MFA Version 7.1.2.1 angeboten. Installiert hatte ich auf unseren Servern die Version 7.0.2.1. Auf unserem Test-HA-MFA-Array pflegte ich nun die neuen Bits ein und siehe da, seitdem war die Portal-Komponente nicht mehr nutzbar, ein netter Fehler schmeichelte den Browsern:

image

Nachdem ich ein paar weitere graue Haare (und Stunden der Fehlersuche) investiert habe starrte ich entgeistert auf den Leitsatz der Fehlermeldung:

The key WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_
THUMBPRINT does not exist in the appSettings configuration section.

Tja, was soll ich sagen: der Satz ist schon eindeutig! Es fehlt genau dieser oben erwähnte Part – und zwar in der oben erwähnten web.config. Genau diese web.config, die ja nun nicht mehr durch Updates überschrieben und somit auch nicht automatisch um neue Ideen/Features/Texpassagen erweitert wird. Somit wurde aus Segen ein Fluch, wie ich nach Validierung auf einem weiteren Testserver feststellen durfte. Hier im direkten Vergleich sichtbar:

image

Aufgefallen ist mir dieser Fehler zunächst bei dem MFA Portal. Unnötig zu erwähnen, das natürlich auch der MFA Mobile App Web Service ein neues Feld in der web.config hat. Smiley Die fehlenden Konfigurationspassagen können natürlich nachgepflegt werden und dann klappt’s auch wieder mit dem Nachbar Portal.

Insofern, wie heißt es so schön beim Spielen mit Updates auf dem Computer: Save early, save often!

Gruß,

Karsten Hentrup…

|<-|

Security by Microsoft: Advanced Threat Analytics (ATA)

Zur Ignite im Mai 2015 hat Microsoft ein Security Produkt namens ATA angekündigt. Wir waren schwer erstaunt, vor allem da Microsoft vor einiger Zeit ihre eigene Security-Schiene (Forefront) leider nahezu komplett eingestampft hat.

https://channel9.msdn.com/Events/Ignite/2015/BRK3870

Microsoft Advanced Threat Analytics (ATA) wurde somit eines meiner neuen Spielzeuge. Entwickelt seitens Aorato, eine Firma welche Ende 2014 bei Microsoft eingemeindet wurde:

http://blogs.microsoft.com/blog/2014/11/13/microsoft-acquires-aorato-give-enterprise-customers-better-defense-digital-intruders-hybrid-cloud-world/

Seit Ende August 2015 ist ATA nun in finaler Version verfügbar. Die Phase von der Technical Preview zur finalen Version war (zumindest für mich) recht kurz, weshalb ich das Produkt direkt mit den RTM-Bits aufbauen konnte. Belohnt wurde ich schon wenige Tage nach Aufbau des ersten Gateways. Ein Kollege von mir beglückte mich mit einem Identitätsdiebstahl:

2015-11-09_1658051[1]

Dies Problem ließ sich schnell lösen, mein Arbeitgeber muss jetzt einen Arbeitnehmer weniger füttern. 😉

Quatsch beiseite, dem Kollegen geht’s hervorragend und die Ursache war recht harmlos. Trotzdem interessant, auch nachdem ein weiterer Kollege seine Zauberkünste in der PowerHell [sic!] vorführte:

image

Ein gutes Jahr nach Produktrelease ist ATA nun auf die Versionsnummer 1.6 geklettert. Ich werde auf diesem Blog einige Erfahrungen rund um das Thema ATA zusammenfassen, bzw. berichten wie der Aufbau von ATA funktioniert.

Auch noch ein Jahr nach Produktrelease bin ich sehr zufrieden und schwer begeistert von dem Produkt! Ein interessantes Detail: ATA ist unter anderem in der Enterprise Mobility Suite enthalten.

Die Produktwebsite ist hier zu finden:

www.microsoft.com/ata

Gruß und bis dahin,
Karsten Hentrup…

|<-|

iteracon bloggt…

…Ich freue mich hier ankündigen zu dürfen, dass wir von der iteracon GmbH nun ein eigenes Blog hegen und pflegen. Wir werden hier über unsere Erfahrungen zu verschiedensten Microsoft-Produkten, deren Implementation und Betrieb berichten.

Unsere aktuellen thematischen Highlights sind die Managed Services rund um Microsoft Azure und Office 365, Consulting zum modernen effizienten Arbeiten rund um Windows 10, Office 2016, und Skype for Business. Darüber hinaus beschäftigen wir uns mit einigen Spezialthemen wie Multi-Factor Authentication, DirectAccess und Active Directory Security mit Advanced Threat Analytics.

Natürlich wird sich hier auch das eine oder andere “klassische” Microsoft Thema wiederfinden wie die System Center Suite, Exchange, Active Directory, Hyper-V, PKI, etc.

Wir lesen uns!

Gruß, Karsten Hentrup…

|<-|