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.

In diesem Teil werden die Code Schnippchen zusammengebaut. Als Input benötigt das Script eine CSV Datei mit folgendem Header:

client,OU,User,Mac,OS,Softwareliste

• Client: Name des neuen Computers
• OU: Abteilungsname (wird als OrganisationalUnit abgebildet)
• User: Benutzername (wird in Description hinterlegt)
• Mac: MAC-Adresse des Computers (wird in InitialMacAddress hinterlegt)
• OS: Gruppe, in der der Computer für die OS-Installation eingeordnet werden muss
• Softwareliste: CSV Liste der zuzuordnenden Software (muss in ” stehen)

Somit sieht das Powershell Script so aus:

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:

1. Überprüfen ob die OU schon existiert
2. Falls nicht, den übergebenen Abteilungsnamen zeichenweise zerlegen und bei jeder übergeordneten Abteilung ebenfalls überprüfen, ob diese bereits existiert
3. Die neue OU unter der übergeordneten Abteilung anlegen
4. Die Abteilungs-OU wieder zurückgeben.

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.

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:

winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx -username:scomuser -password:yourpassword -r:https://your.fedora.system:1270/wsman -auth:basic -encoding:UTF-8

The output shows detail information about the OS:

Wenn man am PC ein so ungeduldiger Mensch wie ich ist, dann möchte man bei einer Storage Migration mit dem SCVMM irgendwann mehr sehen, als nur die (bereits relativ detaillierte) Statusanzeige des Jobs in der System Center Virtual Machine Manager (SCVMM)  Konsole.

Der längste Teil des Verschiebens ist im allgemeinen das Kopieren der VHD Dateien. SCVMM verwendet dazu den Bits Agent auf dem Hyper-V Server. Das hat den Vorteil, dass dieser nur die zur Verfügung stehende Bandbreite nutzt und somit nicht den normalen Produktionsverkehr stört.

Zeitweise stieg die Datenbankgröße des OpsMgr extrem schnell an. Um herauszufinden, woher dieses ungewöhnliche Verhalten kam, wollte ich ein Liste aller Alerts mit deren Summe des Auftretens erstellen. Früher wäre ich dafür direkt in die Datenbank gegangen. Heute gibt es dafür Powershell. Das ist einfacher und supported.

Die Liste lässt sich mit folgendem Einzeiler erstellen:

get-alert | group-object -property Name | sort-object count<br />
Der Aufbau ist recht einfach: Zuerst alle Alerts ausgeben (inklusiv der bereits geschlossenen). Diese Liste gruppieren nach der Eigenschaft Name. Als letztes die Ausgabe nach der Anzahl des Auftretens sortieren.