Seit geraumer Zeit besteht in DSM die Möglichkeit, eine ODS Variable vom Typ "Zeitplan" zu erstellen. Da diese Variable im eScript über die "If"-Anweisung "IsInTimeframe" geprüft werden kann, ergeben sich hieraus gerade für Installationen viele neue Möglichkeiten. Somit wäre es denkbar einen Softwarerollout in mehrere "dynamische Phasen" (führe Aktion 1 aus wenn innerhalb Wartungszeitfenster und Aktion 2 wenn nicht) zu unterteilen, ohne das der DSM Administrator weitere Änderungen am eScript oder der Policy vornehmen muss, wie es oft bei der Verteilung von Patchen oder z.B. auch einer schleichenden Windows 10 Migration gewünscht ist. Ein "Aufschieben" oder "Erweitern" des Zeitplanes greift bei Ausführung des eScripts sofort.

Möchte man nun im eScript den "Beginn" oder das "Ende" des Wartungszeitplans herausfinden, gibt es für den Builtin DSM Wartungszeitplan den eScript Befehl "GetMaintenanceTimes". Leider ist es über diesen Befehl aber zum jetzigen Zeitpunkt nicht möglich einen eigenen Wartungsplan auszulesen um die gewünschten Informationen zu erhalten. Weist man den Wartungsplan einer DSM Variablen zu und lässt sich den Inhalt ausgeben, erscheint die Interpretation dieses codierten Strings auf den ersten Blick relativ schwierig.

Hier ein Custom Wartungszeitplan und der Inhalt der ODS Variablen als String:

1;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgP///z8AAAAA

In diesem Artikel möchte ich zeigen, wie der angezeigte String per PowerShell interpretiert und die darin enthaltene Information in DSM weiterverarbeitet werden kann. Dies würde sich sowohl mit als auch ohne PSX realisieren lassen.

Viele Kunden die DSM oder natürlich auch andere Applikationen über eigene Websites/Tools steuern, stehen spätestens immer wieder bei Updates vor der Situation, dass die Funktionen der Websites für den Zeitraum des Updates nicht verfügbar sind.

Hat man beispielsweise ein PSX basiertes Webinterface als Steuerungstool für DSM Funktionen, so wird das Webinterface solange nicht erreichbar sein, solange die Verbindung per PSX zum BLS nicht aufgebaut werden kann. Dies würde nicht nur bedeuten bis das Update abgeschloßen ist, sondern erfordert evtl. auch noch die Aktualisierung zusätzlicher Komponenten oder Module wie PSX und/oder der verwendeten Scripte. Versucht ein Anwender nun während der Downtime auf die Website zuzugreifen, erhält dieser unter Umständen Verbindungsfehler oder andere Meldungen, mit denen er wenig anfangen kann.

Ich möchte in diesem Artikel zwei einfache Möglichkeiten zeigen, wie Sie an Ihrem IIS entweder einer einzelnen Web Applikation oder einer kompletten Site eine "Wartungswebsite" vorschalten können.