Seit ein paar Tagen steht er fest – der Name des nächsten Windows Servers. Und wenig überraschend lautet er Windows Server 2022. Dieses ist nun als öffentlich zugängliche Preview verfügbar, sowohl als Image zum Download für lokalen Einsatz, als auch als Marketplace-Image in Azure.
Sicherlich ist den Meisten bekannt, dass Windows seit vielen Generationen out-of-the-box als NTP-Client genutzt werden kann – also die Uhrzeit von einem NTP-Server beziehen kann. Aber dass sowohl Windows Server (seit WS2003) als auch Windows Client (seit Win XP) auch mit Bordmitteln als NTP-Server genutzt werden können, dürfte weitgehend unbekannt sein. Das Ganze lässt sich in einigen wenigen Schritten erreichen:
Windows Zeitdienst W32Time auf automatischen Start setzen
W32Time als NTP-Server konfigurieren (Registrierungsschlüssel)
W32Time Dienst neustarten
Firewall auf udp/123 für Verbindungen von außen öffnen
Natürlich kann man das sehr effizient mittels PowerShell erledigen. Dazu habe ich ein einfaches Script geschrieben:
# This script makes a Windows 10 PC acting as a NTP server #Enable autostart for W32Time ServiceSet-Service-Name W32Time -StartupType Automatic
# Configure W32Time Service to act as a NTP serverSet-ItemProperty-Path HKLM:\System\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer -Name Enabled -Value1# Update W32Time service
w32tm.exe /config /update
# Restart W32Time serviceRestart-Service-Name W32Time
# Check configuration - VMICTimeProvider / Enabled should be "1" now
w32tm.exe /query /configuration
# Create an inbound rule for the Windows Firewall
New-NetFirewallRule -DisplayName"Allow NTP UDP/123 Incomming"-Profile Any -Action Allow -Direction Inbound -LocalPort 123-Protocol udp -Enabled true
# This script makes a Windows 10 PC acting as a NTP server
#Enable autostart for W32Time Service
Set-Service -Name W32Time -StartupType Automatic
# Configure W32Time Service to act as a NTP server
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer -Name Enabled -Value 1
# Update W32Time service
w32tm.exe /config /update
# Restart W32Time service
Restart-Service -Name W32Time
# Check configuration - VMICTimeProvider / Enabled should be "1" now
w32tm.exe /query /configuration
# Create an inbound rule for the Windows Firewall
New-NetFirewallRule -DisplayName "Allow NTP UDP/123 Incomming" -Profile Any -Action Allow -Direction Inbound -LocalPort 123 -Protocol udp -Enabled true
Seit einer Weile enthält Windows das “Subsystem für Linux” (WSL). Damit kann man Linux-Code nativ unter Windows ausführen, ohne dafür erst eine VM starten zu müssen oder ähnliches. Di Installation ist super einfach:
Am besten und einfachsten geht es per PowerShell (womit auch sonst? )
Microsoft hat vor wenigen Stunden in einem längeren Blogartikel (siehe Link) viele Details zum nächsten Windows Server veröffentlicht. Dieser wird „Windows Server 2019“ heißen und bereits in der zweiten Jahreshälfte diesen Jahres erscheinen. Über das Insider-Programm kann bereits eine Preview heruntergeladen und genutzt (natürlich nur zu Testzwecken!) werden:
Nach Aussage von Microsoft soll der neue Server vor allem 4 Hauptthemen adressieren:
Hybrid,
Security,
Application Platform und
Hyper-converged Infrastructure
Der neue Windows Server wird das nächste Release im LTSC (Long term servicing channel sein). In diesem wird es wieder eine GUI-Installationsoption sowie den Core-Server geben. Für den Semi-Annual-Channel (eher nicht für klassische Server-Szenarien geeignet) gibt es nur Core- und Nano-Server-Installationen.
Die Lizensierung des Server 2019 wird genau so wie bei 2016 organisiert sein. Microsoft kündigt aber eine Erhöhung der Preise für CALs an.
Bei der Frage, ob ein Server (oder auch Client) noch etwas mehr RAM vertragen kann, stellt sich oft die Frage, wieviel RAM dann aktuell in wie vielen Modulen verbaut ist und wieviele Slots noch frei sind. Natürlich gibt es dazu auch bereits grafische Werkzeuge, die das können, aber spätestens, wenn mehrere Maschinen (ggf. auch Core-Server ohne GUI) abgefragt werden sollen, kann die PowerShell ihre Stärken ausspielen. Daher habe ich ein kleines Skript gebaut, welches diese Aufgabe erfüllt:
Auf den bisher drei Treffen der in 2016 neu gegründeten Windows Server Usergroup Leipzig (WSUG L.E. – organisiert über Meetup unter meetup.com/de-DE/wsugle/) haben bereits diverse Leute Vorträge gehalten, darunter auch einige MVPs.
Hier möchte ich eine kurze Übersicht der Video geben, die ihr dann ganz bequem von zuhause anschauen könnt. Die Qualität der Videos variiert leider recht stark – seid also bitte nicht gleich abgeschreckt, wenn das erste Video das ihr euch zum Anschauen ausgewählt habt nicht so toll ist. Danke!
Seit Windows 8 gibt es die Möglichkeit, eine WLAN- oder WWAN-Verbindung als “getaktet” (metered) festzulegen. Das hat Auswirkungen auf die Nutzung dieser Verbindung. Ziel ist es dabei, eine Verbindung mit beschränktem Datenvolumen oder Kosten pro kB/MB, möglichst wenig mit Dingen zu belasten, die man später auch über unbeschränkte Datenverbindungen machen kann, z.B. das Herunterladen von Windows Updates oder die Bereitstellung neuer Software, die erst aus dem Netzwerk geladen werden muss.
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:
Insbesondere auf Servern kann es schnell vorkommen, dass hier sehr viele Gepante Tasks („Aufgaben“) vorhanden sind, die aber über viele Ordner im Taskplaner verteilt sind:
Wenn man nun einen bestimmten Task sucht oder einfach wissen möchte, was so an Aufgaben alles geplant ist, dann ist die GUI hier leider keine große Hilfe. Aber mit der PowerShell bekommt man schnell das Gewünscht:
Kürzlich stand ich vor der Aufgabe, altes Fotomaterial aufzuarbeiten um dabei insbesondere Schäden an den Fotos und andere Bildfehler zu korrigieren. Für derartige Aufgaben nutze ich sehr gern Photoshop Elements. Für einen schmalen Taler bekommt man viele Funktionen (natürlich nicht so viel wie beim “richtigen” Photoshop, aber das kostet fast 10x soviel). Das von mir sonst benutzte Adobe Lightroom kann das leider nicht oder nur mit riesigem Aufwand.
Nachdem ich das erste Bild bearbeitet hatte, kam mir die Idee, auf meinem Surface Pro weiter zu machen, da dieses ja über einen Digitizer verfügt und mir somit das Arbeiten mit einem Stift ermöglicht hätte. Ein Grafiktablet ala Wacom o.ä. habe ich leider nicht, bin davon aber auch nicht so überzeugt. Bei den halbwegs bezahlbaren ist kein Display enthalten, so dass man auf dem Tablet nur arbeitet, das Ergebnis aber auf dem Monitor zu sehen ist. Beim Surface hingegen kann ich mit dem Stift direkt “im Bild” arbeiten.
Nun hatte ich aber kein Photoshop Elements auf dem Surface und mangels DVD-Laufwerk hätte ich erst die DVD auf USB.-Stick kopieren müssen. Also habe ich nach einer Möglichkeit gesucht, das Surface einfach nur als zweiten Bildschirm an meinem “Haupt-PC” (wo das Photoshop läuft) zu benutzen – und ich wurde fündig. Die Lösung nennt sich “Splashtop”. Wie das genau funktioniert, seht ihr in einem meiner YouTube-Videos:
Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.
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:
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):
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:
