Wenn man nun z.B. in einer kleinen Außenstelle, auf einer Baustelle oder sonst wo einen LTE- oder UMTS-Hotspot bereitstellt, damit einige Mitarbeiter darüber arbeiten können, dann haben diese Verbindungen in der Regel ein Datenlimit pro Monat, nach dessen Erreichen die Geschwindigkeit massiv gedrosselt wird, z.B. 3, 5 oder 10GB. Will man nun für diese Mitarbeiter erreichen, dass z.B. keine Windows-Updates über diese Verbindung geladen werden, dann kommen die getakteten Verbindungen zum Einsatz und es wäre wünschenswert, das entsprechende WLAN per Gruppenrichtlinie als “getaktet” zu bestimmen.

Das Problem dabei:

In den GPOs lassen sich zwar die Kosten für WLAN festlegen (es gibt dabei 3 Stufen, “unrestricted”, “fixed” und “variable”, wobei “fixed” bedeutet, dass die Kosten pro übertragenem Kilo- oder Megabyte entstehen und “variable” für ein monatliches Limit steht), dies gilt dann aber für ALLE WLAN-Verbindungen:

Als Alternative kann man nun aber das gute, alte “netsh” benutzen. Damit lassen sich Verbindungsdetails zeigen:

Der Befehl dazu lautet:

netsh wlan show profile WLANSSID

Will man nun für eine Verbindung die Kosten verändern, so geht dies folgendermaßen:

Der Befehl dazu lautet:

netsh wlan set profileparameter name=WLANSSID cost=variable  (oder alternativ “fixed”)

Daraus braucht man nun nur noch ein passendes kleines Script basteln und dieses per GPO wirken lassen:

Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!

Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!

Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).

Installation SCUP

Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:

https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx

bzw.

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940

Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:

Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:

Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!

Konfiguration WSUS-Berechtigungen

Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):

https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

Folgende Schritte sind im Wesentlichen nötig:

Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):

Einrichtung SCUP

Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.

Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:

Als erstes sind die Optionen zu öffnen:

Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):

Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:

Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:

Zertifikat passend einbinden

Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:

Updates über SCUP an den WSUS veröffentlichen

Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:

Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:

Danach können die Updates aus diesem Katalog in den SCUP importiert werden:

Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:

Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.

Dabei sollten die Updates vom SCUP signiert werden:

Updates über SCCM verteilen

Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:

Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:

Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:

Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.

Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.

Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:

Viel Spaß damit!

Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.

Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]

[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]

[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]

Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.

Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.

Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx 

Das Problem: Wenn es um Arbeitsspeicher geht, verhält sich die WID wie ein „großer“ SQL-Server – sie nimmt was sie bekommen kann.

Dieses Verhalten lässt sich beim regulären SQL-Server u.a. mit dem SQL Server Management Studio beeinflussen. Dieses Programm ist allerdings nicht Bestandteil der WID-Installation.

Die Lösung: Das frei erhältliche SQL Management Studio Express bietet genau diese Möglichkeiten.

Vorgehensweise:

1. SQL Management Studio Express downoaden

http://www.microsoft.com/de-de/download/details.aspx?id=8961

2. SQL Management Studio Express installieren

Ist nicht weiter schwer, einfach den Setup-Assistenten benutzen…

3. Verbindung zur WID aufbauen

Dazu muss das Management Studio u.U. als Administrator ausgeführt werden. Als Verbindungsziel wird

\\.\pipe\mssql$microsoft##ssee\sql\query

verwendet.

4a. Konfiguration mittels T-SQL

Nun müssen folgende beiden T-SQL Abfragen ausgeführt werden:

sp_configure ’show advanced options‘, 1;
reconfigure;
go

„Ausführen“ anklicken

sp_configure ‚max server memory‘, 256;
reconfigure;
go

(Den Wert 256 durch das gewünschte Maximum ersetzen )

„Ausführen“ anklicken

4b. Konfiguration mittels GUI

Rechtsklick auf den obersten Eintrag im Objekt-Explorer, im Kontextmenü „Eigenschaften“ auswählen

Im neu geöffneten Fenster den Bereich „Arbeitsspeicher“ wählen und dort den minimalen und den maximalen Speicherwert eintragen.

Das war es schon gewesen. Evtl. muss die Datenbank neu gestartet werden…