Im letzten Artikel habe ich verschiedene Mechanismen für die Abarbeitung von Laufwerksverbindungen etc. gegenüber gestellt. Meine persönliche Präferenz dabei sind die klassichen Loginscripte und hier möchte ich ein wenig die verschiedenen Scriptsprachen gegenüberstellen, mit welchen ich schon hab Erfahrungen sammeln dürfen.
Microsoft
Windows Loginscripte & Co.
Ich denke jeder Windows Admin kennt es. Die Benutzer möchten ihre Laufwerke gemappt und am liebsten auch gleich die Drucker verbunden haben. Ich möchte an dieser Stelle meine Sicht auf verschiedene Mechanismen werfen immer auch mit dem Fokus eines Citrix Admins.
WSUS – Konfiguration für MDT Umgebung
Ich habe mich in letzter Zeit mit MDT (Microsoft Deployment Toolkit) beschäftigt und mir da auch Gedanken zum WSUS gemacht. In meinem Umfeld wird MDT vor allem für die Installation/Wartung von Citrix Workern (Terminalserver und VDI) genutzt. Diese sind sehr oft auch aus dem Internet zugänglich und sollten daher auch auf einem zeitnahen Patch-Stand sein. Nur wie löst man dies am einfachsten?
WSUS – Automatisiertes Update Management
So cool WSUS (Windows Server Update Service) auch ist, so hat er sich leider seit dem Erscheinen mit Windows Server 2003 nicht wirklich weiter entwickelt. Im Bereich der Update-Pflege (Freigabe, Ablehnung, etc.) ist mir der WSUS noch immer nicht flexibel genug. Glücklicherweise kann man hier aber mit PowerShell Abhilfe schaffen und dafür habe ich in meinem Lab mehrere Scripte integriert.
WSUS – Clients zum Update Report zwingen
Wahrscheinlich kennt jeder Administrator, welcher auch WSUS im Einsatz hat die Thematik, dass die Clients mit den Reports auf sich warten lassen.
Nach ein wenig Recherche bin ich bei div. Blogs auf Scripts gestossen, welche den WU Client dazu bringen, dem WSUS sofort einen entsprechenden Report zu senden. Genanntes Script habe ich für mich so modifiziert, dass es nicht vom WSUS aus mittels „Invoke“ sondern direkt auf dem Client (Desktop OS wie auch Server OS) ausgeführt wird.
Voraussetzung ist natürlich, dass die entsprechenden GPO Einstellungen für die WSUS Kommunikation eingerichtet und funktionell sind. ;-)
Das unten verfügbare Script kann dann mittels geplantem Task als „SYSTEM“ regelmässig ausgeführt werden, damit der WSUS auch stets den aktuellen Patch-Stand seiner Zielcomputer weiss.
Parameter für den geplanten Task:
– Programm: PowerShell.exe
– Parameter: -ExecutionPolicy Bypass <Pfad zum Script>
Viel Spass beim Nachbauen. :-)
Installierte .NET Framework Version prüfen
Disclaimer: Bei diesem Artikel handelt es sich definitiv nicht um eine eigene „Entwicklung“.
Nicht selten setzen Programme eine bestimmte .NET Version voraus. Windows bietet leider keine einfache Möglichkeit um diese herauszufinden. Einzig der definierte Registry Wert gibt uns einen Aufschluss auf die interne Build-Nummer, aber nicht auf die konkrete Version.
Ich bin bei Microsoft selbst auf ein Skript gestossen, welches ich seither auf mit der entsprechenden Build Tabelle nachgeführt habe:
$dotNet4Builds = @{
'30319' = @{ Version = [System.Version]'4.0' }
'378389' = @{ Version = [System.Version]'4.5' }
'378675' = @{ Version = [System.Version]'4.5.1' ; Comment = '(8.1/2012R2)' }
'378758' = @{ Version = [System.Version]'4.5.1' ; Comment = '(8/7 SP1/Vista SP2)' }
'379893' = @{ Version = [System.Version]'4.5.2' ; Comment = '(all Windows OS)' }
'380042' = @{ Version = [System.Version]'4.5' ; Comment = 'and later with KB3168275 rollup' }
'393295' = @{ Version = [System.Version]'4.6' ; Comment = '(Windows 10)' }
'393297' = @{ Version = [System.Version]'4.6' ; Comment = '(NON Windows 10)' }
'394254' = @{ Version = [System.Version]'4.6.1' ; Comment = '(Windows 10)' }
'394271' = @{ Version = [System.Version]'4.6.1' ; Comment = '(NON Windows 10)' }
'394802' = @{ Version = [System.Version]'4.6.2' ; Comment = '(Windows 10 Anniversary Update)' }
'394806' = @{ Version = [System.Version]'4.6.2' ; Comment = '(NON Windows 10)' }
'460798' = @{ Version = [System.Version]'4.7' ; Comment = '(Windows 10 Creators Update)' }
'460805' = @{ Version = [System.Version]'4.7' ; Comment = '(NON Windows 10)' }
'461308' = @{ Version = [System.Version]'4.7.1' ; Comment = '(Windows 10 Fall Creators Update)' }
'461310' = @{ Version = [System.Version]'4.7.1' ; Comment = '(NON Windows 10)' }
'461808' = @{ Version = [System.Version]'4.7.2' ; Comment = '(Windows 10 / 1803)' }
'461814' = @{ Version = [System.Version]'4.7.2' ; Comment = '(other OS than Windows 10 1803)' }
'528040' = @{ Version = [System.Version]'4.8' ; Comment = '(Windows 10 / 1905 & 1911)' }
'528372' = @{ Version = [System.Version]'4.8' ; Comment = '(Windows 10 / 2005 & 2010 & 2105)' }
'528449' = @{ Version = [System.Version]'4.8' ; Comment = '(Windows 11 / Server 2022)' }
'528049' = @{ Version = [System.Version]'4.8' ; Comment = '(other OS or Windows 10 builds)' }
'533320' = @{ Version = [System.Version]'4.8.1' ; Comment = '(Windows 11 / 2022)' }
'533325' = @{ Version = [System.Version]'4.8.1' ; Comment = '(other OS or Windows 10 builds)' }
}Die Ausführung sieht dann wie folgt aus:
Ich denke mit diesen Informationen kann man mehr anfangen als den reinen Build Nummern. ;-)
Viel Spass beim Nachbauen :-)
Installierte Windows Sprachpakete prüfen
In unseren Terminalservern und VDIs wollten wir mittels Scripten die Benutzer die OS Sprache ändern lassen. Die Aufbereitung des Images mittels Citrix AppLayering hatte so seine Tücken und für eine einfache Prüfung, ob und welche Sprachen zur Auswahl stehen, habe ich folgendes kleines Skript erstellt.
Es liest über WMI die OS Parameter aus und listet diese im Anschluss in der PowerShell Ausgabe:
$OSInfo = Get-WmiObject -Class Win32_OperatingSystem
$LanguagePacks = $OSInfo.MUILanguages
$LanguagePacksDie Ausgabe sieht dann wie folgt aus:
Viel Spass beim Nachbauen :-)
M365 JSON lesbar machen
Es gibt Szenarien in denen der Zugriff für M365 Clouddienste gesondert behandelt werden müssen. Zum Beispiel in einer Citrix ADC/NetScaler Konfiguration in einer hybriden Exchange Konfiguration. Microsoft stellt dafür ein JSON zur Verfügung, mit welchem z.B. eine Palo Alto Firewall automatisch die Firewall Regeln pflegen kann:
Leider ist dies nicht überall möglich, wie in meinem Fall mit dem Citrix ADC/NetScaler. Und wenn wir uns die JSON anschauen, sind in den x Zeilen sämtliche Quell IP Adressen gelistet, aber nicht praktikabel um weiter zu verwenden.
Ich habe mir deshalb die Zeit genommen und ein kleines Script erstellt, welches:
- Die JSON in eine lokale, temporäre Datei schreibt
- Diese Datei ausliest
- Die IPv4 Adressen sortiert und ohne Duplikate in eine CSV Datei schreibt
Aus dieser Datei können nun die IP Adressen relativ einfach herauskopiert und weiter verwendet werden.
Ich hoffe dies hilft dem einen oder anderen IT Guy weiter. :-)
SMTP Relay mit ACL auf Citrix ADC konfigurieren
Vor knapp zwei Jahren erstellte ich hier einen Artikel, wie man grundsätzlich einen SMTP Relay mit NetScaler konfigurieren kann (hier). Im Rahmen einer Datacenter Migration kam das Thema ACL für diesen Relay auf. Im genannten Artikel wurde sauber beschrieben, wie man den Exchange auf den ADC als Quelle konfigurieren kann. Wie kann man nun aber die Quellen seitens Loadbalancer einschränken?
Exchange 2016 – Dienste wiederherstellen
alias „Restore-Exchange-Services-After-Failed-Update-Skript“
Bei einer Installation von Exchange Updates deaktiviert das Setup als erstes die relevanten Dienste und stoppt diese um das System zu schützen. Bei einem Fehlschlag der Installation kann dies jedoch dazu führen, dass danach alle Dienste deaktiviert bleiben. Passiert schon nicht? Leider habe ich dies schon auf einem Kunden- sowie auf meinem Testsystem gesehen.
Microsoft bietet einen entsprechenden KB-Artikel, in welchem alle Dienste inkl. dem Standard-Startmodus aufgeführt sind. Man kann nun die Liste akribisch durchgehen und anschliessend die Dienste starten, oder aber man nutzt ein Skript.
Ich habe mit meinen bisher noch kleinen PowerShell Kenntnissen ein kleines Skript zusammengestellt, welches folgendes durchführt:
- benötigte Windows Dienste auf „Automatisch“ stellen und gleich starten
- vorausgesetzte Exchange Dienste auf „Automatisch“ stellen und gleich starten
- restliche Exchange Dienste gem. Microsoft Standard konfigurieren
- Alle Dienste, welche auf „Automatisch“ stehen kontrollieren und starten, falls diese gestoppt sind (Ausnahme: Software Protection)