In der NetInstall 5.x-Welt war es ja so, dass der Client vollständig selbst entschieden hat, welche Projekte ausgeführt sollen und welche nicht (Assign&Delegate lassen wir jetzt mal außen vor ;-).

Das heißt, der Client hat die Registry unter HKEY_LOCAL_MACHINE\Software\NetSupport\NetInstall\InstalledApps, beziehungsweise im gleichen Pfad unter HKEY_CURRENT_USER, geprüft. Jedes dort registrierte Projekt – für jedes Projekt gab es einen Unterschlüssel, dessen Name die GUID des Projekts war – galt als installiert, jedes dort nicht erfasste Projekt, wurde als nicht installiert betrachtet.

Unter Enteo v6 ging diese Funktionalität verloren, da die "Intelligenz" vom Client auf den Business Logic Server verlagert wurde. Das führte dazu, dass der BLS zum Beispiel nach dem Zurücksetzen eines Snapshots einer virtuellen Maschine, dem Client die Info gab, es wäre nichts zu installlieren, da alle Policy-Instanzen den Status "compliant" hätten – und der Client hielt sich sklavisch daran, obwohl womöglich etliche Pakete hätten installiert werden müssen, um die Compliance herzustellen.

Mit DSM 7 gibt es nun erneut eine Veränderung im Verhalten...

Hallo zusammen!

in diesem Blog möchte ich in kurzen Schritten beschreiben, wie man mit Enteo v6 oder DSM 7 bei einer Neuinstallation eines Computers, dessen CD-DVD Laufwerk einem anderem Laufwerksbuchstaben zuordnen kann.

Leider ist es nicht mehr ohne weiteres möglich, den RDP Client in der Version 7 auf einem Windows Server 2003 zu installieren, da der Installer (http://www.microsoft.com/downloads/en/details.aspx?FamilyId=72158b4e-b527-45e4-af24-d02938a95683&displaylang=en) dies aktiv verhindert. Es erscheint beim Aufruf die Meldung: "The version of windows you have installed does not match the update you are trying to install".

Leider ist die Modifikation der update.inf Datei, die die aktuelle OS Version prüft, nicht ohne weiteres möglich, da das Setup im Falle einer manuellen Änderung meldet, dass die Integrität der inf Datei nicht festgestellt werden kann. Glücklicherweise wird die Integritätsprüfung aber nur einmal beim Aufruf des Setups durchgeführt.

Nachdem dieses Tatsache einmal verstanden ist, kann dieses Verhalten wie folgt umgangen werden:

Im heutigen (recht kurzen) Blogeintrag soll es nun um das noch nicht beschriebene Cmdlet Get-NiInstParam gehen.

Mit diesem Cmdlet wird nicht – wie man anhand des Namens womöglich vermuten könnte (und wovon ich bei meinen ersten Tests auch ausgegangen bin) – der Wert eines für das entsprechende Paket definierten Installations-Parameters ermittelt...

Unsere allseits beliebten PowerShell Extensions für Enteo v6 / DSM 7 benötigen ja ein Lizenzfile, um ihre Arbeit aufzunehmen. Dieses wird in der Regel im Rahmen der Installation mit in das Installationsverzeichnis kopiert und somit von dem Snap-In auch automatisch gefunden.

Es gibt jedoch einige Kunden, die das Snap-In auf allen Client-Rechnern installieren, um von jedem Rechner aus PowerShell Scripts ausführen zu können und so beispielsweise Reinstallationen dezentral anzustoßen, Policy-Instanzen zurückzusetzen oder ähnliches.

In einem solchen Szenario ist es natürlich relativ aufwändig, z.B. nach einer Aufstockung der Lizenzen (der Kunde erhält ja dann ein neues Lizenzfile), die neue Lizenz zu verteilen. Natürlich lässt sich das mit einem einfachen NetInstall-Paket realisieren, aber gemacht werden muss es trotzdem.

Eine wenig bis garnicht bekannte Möglichkeit (mangels Dokumentation - mea culpa), ist die zentrale Ablage der Lizenzdatei. Diese Möglichkeit besteht seit PSX Version 1.1.

Grundsätzlich ist die Aussage von FrontRange, dass sowohl die Distribution als auch die Softwareverteilung zum Client über http implementiert ist.

Diese Aussage stimmt zwar grundsätzlich, allerdings gibt es einige Stolpersteine, die einem die Einrichtung eines Depots in diesem Szenario zum persönlichen Jakobs-Weg machen. Daher nun folgend eine kleine Schritt-für-Schritt Anleitung als Abkürzung.

Hinweis: dieser Artikel setzt tiefgehende Kenntnisse über die DSM Infrastruktur, die Distribution, IP und DNS voraus. Sollten Sie unsicher in einem dieser Bereiche sein, nutzen Sie bitte die Unterstützung eines Consultants. 

Zielsetzung

Grundsätzliches Ziel dieses Artikels ist der Aufbau eines Depots in einer Außenstelle, das per Pull-Distribution über einen http-Port mit einem zentralen Depot abgeglichen wird. SMB ist dabei zwischen den beiden Lokationen nicht verfügbar.

In diesem Teil der Artikelserie über die PowerShell Scriptingmöglichkeiten in DSM 7 soll es nun um die konkrete Anwendung gehen.

Wie beim Scripting-Support für VBScript, JScript und Perl-Scripts, besteht auch für PowerShell-Scripts die Möglichkeit, lesend auf NetInstall-Variablen zuzugreifen oder die Werte von NetInstall-Variablen zu setzen. Dazu werden über das PowerShell-Modul Enteo.Powershell.ScriptCmdlet.dll, das Teil des DSM 7 Clients ist, folgende Cmdlets zur Verfügung gestellt:

• Get-NIVar
• Set-NIVar
• Write-NIReport
• Set-NIError
• Get-NiInstParam

Eine der wenig bekannten (und noch schlechter dokumentierten) Neuerungen in DSM 7, ist die Unterstützung von PowerShell innerhalb von DSM 7 Scripts.

Da sich PowerShell und die PowerShell-Scriptsprache ja mehr und mehr als die Automatisierungs-Schnittstelle im Windows-Umfeld herauskristallisieren, ist diese Unterstützung ein wichtiger Baustein im Gesamtkonzept einer LifeCycle-Management Strategie.

Dieser Artikel ist der erste einer kleinen Serie  von Posts, in der die neuen Möglichkeiten aufgezeigt werden sollen...

Vermutlich jeder NetInstall- / Enteo v6- / DSM 7-Administrator hat sich schonmal die Registry auf den gemanageten Clients unterhalb von Software\NetSupport\NetInstall\Installed Apps angeschaut, weil ja dort die ganzen Infos über die auf dieser Maschine bzw. für einen Benutzer ausgeführten Pakete hinterlegt sind.

Unter anderem gibt's dort auch einen Value LastInstallTime, in dem der Zeitpunkt der letzten Installation des jeweiligen Paketes hinterlegt ist. Allerdings ist dieser Wert vom Typ "Time_t" und wird in einem Byte-Array gespeichert, das die Anzahl der Sekunden seit dem 01.01.1970 angibt und ist damit für den durchschnittlich begabten Systemadministrator (oder Consultant – wie mich) eher nicht lesbar... ;-)

Was verbindet viele große Multinationale Konzerne mit Paketierern an verschiedenen Standorten, mit ebenso vielen Mittelständischen Unternehmen in denen die Paketierleistung durch ein kleines 2-Mann Team gestemmt wird? Es passieren Fehler. Es wird wenig bis gar nichts dokumentiert. Übergaben funktionieren oft nicht. Abteilungsübergreifendes Arbeiten an Paketen erinnert mehr an Krieg als an Zusammenarbeit, Testprozesse (nur der User weiß, wie die Anwendung funktionieren muss) ist eine Farce. Natürlich ist dies nicht die Regel, aber einige der genannten Punkte sind sicherlich in fast jedem Unternehmen wiederzufinden.