NWC Services Blog
Um während der OSD Phase im Fehlerfall Log Files einsehen zu können, haben viele unserer Kunden entweder mehrere Boot Environments mit unterschiedlichen Optionen (z.B. "Debug Mode" oder "Extended Logging") in ihrer Umgebung zur Verfügung gestellt oder haben die von uns angebotene und frei verfügbare Erweiterung "Pimp my Boot Environment" in die bestehenden Boot Environments integriert.
Da es aktuell im HEAT Forum zu diesem Thema eine Diskussion gab, wie man in der OSD Phase im Fehlerfall an die Log Files im PE heran kommt, möchte ich heute kurz eine sehr einfache und wahrscheinlich genauso unbekannte Möglichkeit zeigen wie man sein aktuell zugewiesenes PE ohne große Anpassungen dazu bringen kann, beim Start oder im Fehlerfall des OSD Clients eine Eingabeaufforderung zu starten.
Wer viel mit ODS Variablen arbeitet wird sicherlich schon einmal an dem Punkt angekommen sein an dem man sich die Frage stellt wo eine bestimmte Variable überhaupt überall gesetzt wurde. Leider ist dieser Verwendungsort über die DSMC nicht wirklich ersichtlich.
In folgendem Beitrag möchte ich einen Codeschnippsel erläutern, mit dem Sie die Zuweisungen der ODS Variable auslesen können.
Kürzlich kam einer unserer Kunden auf mich zu mit dem Anliegen, dass er die bestehende ODS-Struktur seiner DSM-Produktionsumgebung auf eine Testumgebung übertragen möchte. Grundsätzlich ist es ja eine gute Idee, Test- und Produktionsumgebung möglichst identisch oder zumindest nahezu identisch zu halten und somit besteht die Notwendigkeit, diese Anforderung mit möglichst geringem Aufwand umzusetzen. Ein manuelle "Synchronisation" schied daher von vorneherein aus.
Die Vorstellung des Kunden war, sowohl die Domain- und OU-Struktur, sowie die statischen und dynamischen Gruppen zu übertragen. Als Kunde der PowerShell Extensions lag natürlich nahe, diese Aufgabe mittels eines PSX-basierten Scripts zu erledigen. Insbesondere bei der Übertragung der hierarchisch organisierten dynamischen Gruppen tat sich der Kunde jedoch schwer, und kam mit der Bitte um den ein oder anderen Tipp auf mich zu.
Da es sich um eine interessante und durchaus auch für andere Kunden relevante Aufgabenstellung handelt, möchte ich in diesem Artikel einen möglichen Ansatz bzw. eine einfach gehaltene Lösung zur Umsetzung dieser Anforderung vorstellen.
Jeder kennt die Arbeit, die auf einen zukommt, wenn in der DSM eine neue Revision eines Bootenvironments ansteht. Es müssen ggf. Folgerevisionen von Paketen und OS-Installation Sets angelegt werden.
Mit der DSM 7.1 wird diese Arbeit ganz erheblich vereinfacht. Für jeden Client ist jetzt individuell konfigurierbar, welches Bootenvironment in welcher Revision verwendet werden soll.