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.

Batch

Der Klassiker schlechthin unter den Loginscripts. Die Befehle funktionieren seit ich IT-denken kann und sie machen was sie sollen.

Für einfachste Umgebungen sicherlich eine gute Wahl.

Der grösste Nachteil ist dem Alter geschuldeten schwachen Leistungsumfang. Solange z.B. alle Benutzer die gleichen Laufwerke benötigen funktioniert es tadellos. Sobald aber Gruppenmitgliedschaften geprüft werden müssen, kommt es schon langsam an seine Grenzen.

PowerShell

PowerShell bietet in seiner Fülle an Modulen und Befehlen viele Möglichkeiten und dies auch bei der Anmeldung.

Wenn man jedoch den Ursprung von PowerShell kennt wird einem schnell klar, dass die Sprache nicht auf Performance aus ist. PowerShell wurde entwickelt um den Administratoren eine Möglichkeit der Verwaltung und der Automatisierung zu bieten. Bei diesen Aufgaben kommt es sehr oft nicht auf die (Milli)Sekunden an und das bringt uns zum grossen Nachteil der Scriptsprache für den Anmeldeprozess. Je komplexer die Aufgaben des Loginscriptes sind, desto langsamer wird es und das spürt die Benutzerin/der Benutzer.

Ich hatte einen Kunden im Schulbereich mit einem Skript, welches mit rund 350 Zeilen die komplette Umgebung eines Benutzers eingerichtet hat. Vom Laufwerk, über die Drucker bis hin zu applikatorischen Einstellungen. Das Skript hat gemacht was es soll, es dauerte einfach jeweils zwischen 3 bis 4 Minuten pro Anmeldung!

Ein weiterer Nachteil kann sein, dass auf den Clients die PowerShell Versionen nachgepflegt werden müssen, je nach eingesetzten Befehlen.

VBScript (VBS)

VBScript ist für viele Systemtechniker erst einmal ein Buch mit sieben Siegeln. Es ist definitiv nicht so intuitiv wie Batch oder PowerShell, bietet jedoch auch eine Fülle von Möglichkeiten, wenn auch mit teils nicht verständlichen Einschränkungen.

Vor Jahren habe ich mich mit VBS auseinander gesetzt (auch geschuldet der Ausbildung) und es ist mittlerweile mein Favorit unter den Skriptsprachen aus folgenden Gründen:

• Performance: VBS wird schnell abgearbeitet. Teilweise sogar zu schnell für das Windows, so dass bewusste Pausen eingepflegt werden müssen.
  Das vorher erwähnte PowerShell Skript wurde durch VBS abgelöst und benötigte nur noch 45 Sekunden statt mehrere Minuten.
• Modular: Sauber geschrieben kann ein VBS basiertes Skript sehr modular aufgebaut werden.
• OS integriert: VBS wird von sämtlichen aktuellen Windows Betriebssystemen unterstützt.

Die Skriptsprache hat auch seine Nachteile, über welche ich dank den Vorteilen hinweg sehen kann:

• Fehlende Vereinfachung: Gewisse Aktionen können nicht einfach mit einer oder zwei Zeilen erledigt werden, sondern bedürfen um ein Vielfaches. So hatte nach der Ablösung des obigen genannten PowerShell Skriptes das neue VBS basierte nicht mehr rund 350 sondern über 3000 Zeilen.
• Fehlende Funktionen: Verschachtelte Gruppenmitgliedschaften können z.B. nicht einfach ausgelesen werden. Für solche Fälle ist es jedoch möglich für diese eine Abfrage gezielt z.B. auf PowerShell auszuweichen.

KiXtart (aka KIX)

KIX ist eine weitere oft eingesetzte Skriptsprache. Auch diese ist einfach zu erlernen und anzuwenden. Sie bietet die Standardfunktionen, welche man üblicherweise benötigt. Vereinzelt habe ich diese schon vorgefunden, jedoch für mich hat sie folgenden erheblichen Nachteil:

• Proprietär: benötigt zusätzliche Programmdateien (via NETLOGON) und ist in den letzten Jahren in der Community kaum mehr aktualisiert worden.

Ich würde somit KIX als umfangreicher wie Batch jedoch schwächer wie VBS/PowerShell einordnen.

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.

Loginscripte

Irgendwelche Skripte welche während der Benutzeranmeldung Laufwerke und Drucker verbinden, Dateien kopieren, etc. gibt es schon seit eh und je. Oder zumindest kenne ich diese seit dem Beginn meiner IT Karriere (Windows 3.11, Windows 95, Windows NT).

Diese funktionieren in der Regel gut und schnell. Die Administratoren müssen sich lediglich mit der entsprechenden Skriptsprache auskennen und man kann loslegen.

Group Policy Preferences (GPP)

Mit Windows 2008/Windows Vista wurden die seit Windows 2000 bekannten Gruppenrichtlinien durch die „Group Policy Preferences“ (exakte Übersetzung mir nicht bekannt) erweitert. Diese kombiniert mit den dazu benötigten Clientseitigen Erweiterungen bieten eine einfach verständliche grafische Oberfläche für die gewünschten Aktionen, welche bei der Anmeldung eines Active-Directory Benutzers ausgeführt werden.

Die GPP sind wirklich intuitiv in der Handhabung und in einem einfachen Server-/Client-Netzwerk eine gute Wahl. Meiner Erfahrung und Meinung nach gibt es jedoch gerade im Citrix Virtual Apps and Desktop (oder DaaS) Umfeld zwei entscheidende Nachteile:

• Performance: die Abarbeitung der GPP ist z.B. im Vergleich mit einem klassischen VBScript um einiges langsamer, was sich in der (negativen) Zufriedenheit der Benutzer widerspiegelt. Wenn dann noch viele Filter (WMI, Item-level Targeting, etc.) verwendet werden, wird es umso träger.
• Abhängigkeiten: es gibt div. Applikationen, welche beim Start vollständig verbundene Laufwerke und Drucker erwarten. Die GPP werden jedoch im Hintergrund ausgeführt und dabei kann es vorkommen, dass beim Start einer veröffentlichten Applikation die erwarteten Laufwerke und Drucker fehlen und es so zu anderen Problemen kommt.

3rd Party

Es gibt auf dem Markt div. Dritthersteller, welche sich der einfachen Verwaltung und der optimierten Anmeldeleistung verschrieben haben. In der Regel machen diese auch ihren Job, jedoch gibt es dabei für mich folgende Punkte zu bedenken:

• Kosten: Dritthersteller schenken in der Regel nichts, also muss eine saubere Kosten-/Nutzen-Rechnung gemacht werden.
• Abhängigkeiten: Normalerweise bringt jedes Dritthersteller-Produkt seine eigenen Komponenten mit. Diese müssen implementiert und gepflegt werden. In der Fehlersuche hat man diese zusätzlich zu berücksichtigen.
• Betrieb: Als Consultant und/oder Engineer versuche ich Umgebungen immer so aufzubauen, dass sie später auch im Support nicht zu komplex werden. Je mehr man sich an die integrierten Mittel hält, umso einfacher ist in der Regel auch die Wissensvermittlung an Betriebsteams. Jede Komponente mehr macht den Support in der Regel nicht einfacher sondern eher umgekehrt.

Tabellarische Gegenüberstellung

Persönliche Präferenz

Die beste Erfahrung habe ich mit dem klassischsten gemacht: den Loginscripten. Diese sind je nach eingesetzter Sprache und Komplexität der Kunden-/Benutzerwünsche teils langwierig in der Entwicklung, aber danach laufen die Scripte normalerweise in der gewünschten Leistung.

Schlussendlich muss jeder für sich die richtige Lösung finden. Meiner Meinung nach am wichtigsten dabei ist, dass in einer Umgebung nur eine Lösung eingesetzt wird und nicht x verschiedene. Das Leben des IT-Personals ist meist schon kompliziert genug.

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?

Ich ging nun von folgenden Voraussetzungen aus:

1. Der WSUS soll dediziert für MDT genutzt werden mit sparsamen Ressourcenverbrauch
2. Die eingesetzten Produkte sind bekannt
3. Die Client melden regelmässig den Patch-Level
4. Updates werden freigegeben sobald verfügbar und benötigt

   • Die Tests finden bei der Abnahme der Citrix Worker statt

Die Installation eines WSUS ist im Internet bestens dokumentiert, ansonsten verweise ich auch gerne auf https://www.wsus.de/

Für die Automatisierung des WSUS habe ich bereits eine kleine Serie verfasst mit folgenden Artikeln:

• WSUS – Automatisiertes Update Management (1,2,4)
• WSUS – Clients zum Update Report zwingen (3,4)
• WSUS – Cleanup automatisieren (1)

Die Nummern in der Klammern referenzieren auf die entsprechenden Voraussetzungen.

Durch die Kombination der verschiedenen Automatisierungen läuft der WSUS nun soweit autonom und benötigt kaum mehr manuelle Pflege. :-)

Viel Spass beim Nachbauen.

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.

Als erstes fangen wir einmal ganz zu Beginn an…

Beim Einrichten des WSUS wird man ja schön durch den Assistenten geführt mit der Frage nach den Produkten, Klassifizierungen, etc. und zu guter Letzt wird in der Regel die erste Synchronisation durchgeführt. Ist diese beendet würde man am liebsten schon die automatischen Freigaben konfigurieren… STOP!

Ersetzte Updates automatisch ablehnen

Leider schafft es Microsoft bis heute nicht, dass bereits ersetzte Updates gar nicht mehr auf alle WSUS in dieser Welt synchronisiert werden. Bei mir sah es zum Beispiel so aus, nachdem ich in meinem Lab die Windows 10 und Office 2016 Updates hinzugefügt hatte:

Hier kommt nun ein erstes Script in meiner Umgebung ins Spiel, welche ich bei Microsoft Learn gefunden habe. Das genannte Script habe ich für mich lediglich noch so modifiziert, dass ein eigener Pfad für die Logdateien genutzt werden kann, anstatt ein Unterordner vom Script-Pfad.

Das Script läuft bei mir als geplanter Task nach der WSUS Synchronisation und lehnt per se ersetzte Updates gleich einmal ab. So verhindere ich, dass die Update-Dateien später überhaupt heruntergeladen werden.

Voraussetzungen und Parameter für den ersten Task:
– Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft)
– Programm: PowerShell.exe
– Parameter: -ExecutionPolicy Bypass <Pfad>\Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port PORT#

Nachdem dieser Task ausgeführt wurde, sieht die Statistik schon ein erstes Mal aufgeräumter aus:

Nicht benötigte Updates automatisch ablehnen

Nun gibt es aber immer noch viele Updates, welche ich in meiner Umgebung nie benötigen werde. Ich habe mir deshalb ein Script aufgebaut, in welchem ich als erstes Ausschlüsse definiere wie z.B. Prozessortypen, Windows Editionen und Sprachen. Das Script wird ebenfalls in einem geplanten Task ausgeführt, nachdem die ersetzten Updates bereits bereinigt sind:

Voraussetzungen und Parameter für den ersten Task:
– Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft)
– Programm: PowerShell.exe
– Parameter: -ExecutionPolicy Bypass <Script-Pfad>

Vergleicht man nun auch noch diese Statistik, so sieht es schon sehr viel aufgeräumter aus:

Benötigte Updates automatisch freigeben

Nun wollte ich in meiner Lab-Umgebung darauf verzichten mittels automatischer Freigabe einfach Updates freizugeben und herunter zu laden, obwohl ich sie wahrscheinlich nie benötige. Im vorherigen Artikel habe ich beschrieben, wie man die Clients dazu bringt einen regelmässigen Report zu erstellen. Diese Informationen nutze ich im dritten und letzten Script um angeforderte Updates automatisch freizugeben. Damit kann z.B. sichergestellt werden, dass beim nächsten Lauf einer MDT Tasksequenz der frisch aufgesetzte Rechner die aktuellsten Updates installiert hat.

Dieses Script lasse ich ebenfalls als geplanten Task nach den Bereinigungen ausführen:

Voraussetzungen und Parameter für den ersten Task:
– Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft)
– Programm: PowerShell.exe
– Parameter: -ExecutionPolicy Bypass <Script-Pfad>

Hinweis: Dieses Script sollte natürlich NICHT in einer Umgebung eingesetzt werden, in welcher auch sämtliche Windows Updates einer Change- und Test-Prozedur unterstehen.

Viel Spass beim Nachbauen. :-)

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. :-)

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

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
$LanguagePacks

Die Ausgabe sieht dann wie folgt aus:

Viel Spass beim Nachbauen :-)

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. :-)

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?

Wer schon mit dem ADC gearbeitet hat weiss, dass dieser Access Control List (ACL) als Funktion bietet, jedoch ist die Konfiguration dieser eher statisch als dynamisch. Ich arbeite jedoch in einem Umfeld, in welchem die zugelassenen Server immer wieder mal ändern können (bei über 1000 Servern kein Wunder). Daher habe ich ein wenig Recherchiert und bin auf einen Lösungsansatz mittels Responder Policies gestossen, welchen ich hier dokumentiere.

Als erstes muss das Loadbalancing für den SMTP Relay konfiguriert werden. Ich nehme dazu als Basis den letzten Artikel und schmücke diesen mit ein wenig mehr Backend-Servern aus:

add server pitex01 192.168.100.31
add server pitex02 192.168.100.32
add service svc-smtp-pitex01 pitex01 TCP 25
add service svc-smtp-pitex02 pitex02 TCP 25
add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType SOURCEIP -timeout 10 -netprofile NP-192.168.100.12
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex02

Nun bauen wir unsere Responder Policy. Damit die Pflege der Quell IPs ein wenig einfacher ist, nutzen wir dazu die sogenannten Data Sets (ähnlich wie Pattern Sets, jedoch für Daten wie IP Adressen) und verweisen in unserer Policy darauf. Als Aktion nehmen wir die vordefinierten „RESET“ Aktion.

add policy dataset DS_MailRelay ipv4
bind policy dataset DS_MailRelay 192.168.100.21 -index 1
bind policy dataset DS_MailRelay 192.168.100.22 -index 2
add responder policy rs_pol_ACLMailRelay "CLIENT.IP.SRC.TYPECAST_TEXT_T.CONTAINS_ANY(\"DS_MailRelay\").NOT" RESET

Schlussendlich müssen wir nur doch die neu erstellte Policy dem SMTP Relay Loadbalancer zuweisen und ab sofort nimmt dieser nur noch Anfragen von IPs an, welche im Data Set „DS_MailRelay“ definiert sind.

bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -policyName rs_pol_ACLMailRelay -priority 100 -gotoPriorityExpression END -type REQUEST

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)