Heute mal wieder eine kurze Powershell Zeile, um alle in Enteo hinterlegten PnP-IDs in den Driver Packages auszulesen und auszugeben.
Interessant kann diese Liste sein, um sie mit einer Enteo-externen Inventur zu vergleichen oder zu überprüfen, ob eine neue Hardware bereits unterstützt wird.
Zuerst wird in allen Software Paketen nach dem Typ PnPPackage gesucht. Aus diesen Ergebnissen werden alle Treiber ohne PnP Ids ausgefiltert. Das Ergebnis ist eine kommaseparierte Liste pro Treiber-Paket, die beim Komma getrennt wird. Am Ende steht eine Liste mit jeweils einer PnP Id pro Zeile:
Zentraler Punkt in dem Script ist die Erkennung in welchem status die Installation gerade ist. Folgende Status sind möglich:
Installation noch nicht eingeplant
Installation eingeplant aber noch nicht gestartet
Installation ist angelaufen aber noch nicht beendet
Installation ist durchgelaufen
Zur Ermittlung dierer Status greifen wir wieder auf das Auslesen von PolicyInstancen zurück. Dazu werden am Anfang einige Policy-IDs definiert, die die verschiedene Status beschreiben: Read more…
In diesem Blog-Post werden zwei weitere Komponenten des Scripts vorgestellt: Ping und somit den Status eines Rechners ermitteln und die Ermittlung ob ein Benutzer angemeldet ist.
Je nach dem Status des Systems kann ein Rechner sofort neuinstalliert werden (wenn er aus ist, oder er läuft aber an einem Client kein Benutzer angemeldet ist). Sollte ein Benutzer angemeldet sein, dann darf eine Neuinstallation nur nach einer gewissen Uhrzeit erzwungen werden (z.B. ausserhalb der normalen Arbeitszeit).
Hier die Funktion um die Erreichbarkeit eines Rechners zu ermitteln:
function doPing
{param([string]$name)
$ping = new-object System.Net.NetworkInformation.Ping
$ping.send($name)
}
Als Übergabeparameter wird der Rechnername benötigt. Dies kann alternativ auch die IP Adresse sein. Verwendet wird die NetworkInformation-Class “Ping”. Die Funktion gibt ein Objekt des Typs PingReply zurück. Vergleicht man dessen Eigenschaft mit Success, dann weiß man, ob der Rechner erreichbar ist oder nicht (Beispiel für nicht ereichbar: (doPing $strIP).status -ne “Success”).
Die zweite Funktion versucht remote auszulesen, welcher Benutzer aktuell angemeldet ist:
Auch hier wird als Parameter der Rechnername mitgegeben. Anstatt .Net/Powershell interne Funktionen zu nutzen, wird eine WMI Abfrage durchgeführt. Im Standard Win32_ComputerSystem Objekt existiert die Eigenschaft UserName. Darin ist der gerade interaktiv angemeldet Benutzer hinterlegt (Consolenbenutzer). Vergleicht man mittels if (-not $username), ob der Wert leer ist, dann kann man einfach feststellen, ob gerade ein Benutzer angemeldet ist.
Jetzt wo wir einen Rechner per Powershell aufwecken können kommt als nächstes die Funktion um eine Neuinstallation anzustossen und sie wieder abzubrechen.
Der Abbruch ist deswegen relevant, da u.U. das WoL nicht funktioniert. Startet der Benutzer am nächsten Morgen den PC wieder ganz normal an, so würde die Installation direkt startet und er könnte ein paar Stunden nicht arbeiten. Daher stoppt das Script die Installation automatisch, falls sie nicht innerhalb eines bestimmten Zeitfenster gestartet werden konnte.
Wie versprochen geht es weiter mit der Automatisierung von Enteo durch Powershell. In diesem Blog Eintrag nehme ich mir die Funktion für das Aufwecken eines PCs vor. Leider funktioniert hier die WoL Funktion von Enteo nicht immer. Das liegt u.a. daran, dass bei einem neuen PC nicht alle Informationen vorliegen. In den meisten Netzen wird ein normales WoL Paket (ein Broadcast Paket) nicht an alle Subnetze verteilt. Der Enteo Server und der zu weckende Client sind im Allgemeinen in unterschiedlichen Subnetzen beheimatet. Daher muss mit einem directed Broadcast gearbeitet werden. Dazu wird das Broadcast Paket direkt an die Broadcast Adresse des Zielsubnetzes geschickt. Dazu ist aber die IP Adresse und die Subnetzmaske zur Ermittlung der Broadcast Adresse notwendig. Diese Information liegt Enteo nicht immer vor und ich habe noch keinen Weg gefunden, diese Info beim Erstellen des Computerkontos mitzugeben.
Kommen wir nun zum dritten Teil der Powershell Beispiele. Nach diesem Teil haben wir alle wesentlichen Bausteine für die automatisierte Rechnervorbereitung zusammen.
In diesem Teil wird die Software zu dem neu angelegten Computer zugeordnet. Dabei wird davon ausgegangen, dass die Software über statische Gruppen verteilt wird.
Als Input wird das fertige Programm eine CSV Datei erhalten, in der pro Zeile ein Computer steht. In der letzten Spalte mit dem Namen Softwareliste steht eine Liste der zuzuordnenden Software, die wiederum per Komma getrennt ist.
In diesem Blog Post werde ich eine Funktion vorstellen, die anhand eines Abteilungsnamens eine Hierarchie von Organisationseinheiten in Enteo erstellt.
Nehmen wir an, dass die Abteilungen nach einem klaren Muster benannt sind. Jede Hierarchie wird durch einen Buchstaben dargestellt. Eine Abteilung ABC steht somit an dritter Stelle in der Hierarchie. Über ihr steht die Abteilung AB und darüber A.
Diese Hierarchie soll beim Provisionieren eines Computers nachgebildet werden. Der neu zu installierende PC aus der Abteilung ABC wird daher in die OU A\AB\ABC abgelegt werden.
Dies ermöglicht einen abteilungsweisen Rollout.
Die hier vorgestellte Funktion muss daher folgendes leisten:
Überprüfen ob die OU schon existiert
Falls nicht, den übergebenen Abteilungsnamen zeichenweise zerlegen und bei jeder übergeordneten Abteilung ebenfalls überprüfen, ob diese bereits existiert
Die neue OU unter der übergeordneten Abteilung anlegen
Im Rahmen eines aktuellen Projektes darf ich mich ein bisschen mit Enteo beschäftigen. Im Kern basiert Enteo V6 auf WebServices. Das ist leider auch die einzige Schnittstelle, die meines Wissens vom Hersteller für Automatisierungen angeboten wird.
Gerade in einem größeren Rollout Projekt ist Automatisierung überlebenswichtig (bzw. sinnvoll, damit man sich nicht zu sehr bei Drag&Drop langweilt). Zum Glück hat NWC Services diese Lücke erkannt und als Wrapper um die WebServices ein Powershell Modul erstellt.
Meine Testerfahrungen mit diesem Tool werde ich in diesem Blogeintrag und wahrscheinlich in ein paar weiteren anhand von Beispielen beschreiben. Read more…
Fedora bases upon Red Hat Enterprise linux which is supported by SCOM. Fedora Core 3 was the base of RHEL 4 and Fedora Core 6 RHEL 5. In this blog posts I will try to convince SCOM that the Fedora 4 based Asterisk telecom system is a RHEL 4.
First we have to install the RHEL4 scom agent manual onto the systems. In this case we had to install the OpenSSL library, too. Additional we add the scom user account to the system.
After that we sign the local created certificate by the scom server and replace it on the Fedora system.
Now we can test the connection from the SCOM server with this winrm command:
Ich arbeite als Systemingenieur in diversen Kundenprojekten bei der TechniData IT Service GmbH, die u.a. Standorte in Karlsruhe und Markdorf unterhält.
In diesem Blog-Post werden zwei weitere Komponenten des Scripts vorgestellt: Ping und somit den Status eines Rechners ermitteln und die Ermittlung ob ein Benutzer angemeldet ist.
Jetzt wo wir einen Rechner per Powershell aufwecken können kommt als nächstes die Funktion um eine Neuinstallation anzustossen und sie wieder abzubrechen.
In diesem Teil werden die Code Schnippchen zusammengebaut. Als Input benötigt das Script eine CSV Datei mit folgendem Header:
Kommen wir nun zum dritten Teil der Powershell Beispiele. Nach diesem Teil haben wir alle wesentlichen Bausteine für die automatisierte Rechnervorbereitung zusammen.
In diesem Blog Post werde ich eine Funktion vorstellen, die anhand eines Abteilungsnamens eine Hierarchie von Organisationseinheiten in Enteo erstellt.
Im Rahmen eines aktuellen Projektes darf ich mich ein bisschen mit Enteo beschäftigen. Im Kern basiert Enteo V6 auf WebServices. Das ist leider auch die einzige Schnittstelle, die meines Wissens vom Hersteller für Automatisierungen angeboten wird.
