Markus Bäker

Gestern habe ich noch gefragt, ob es schon einen Agent für RHEL6 gibt. Heute stoße ich über den Hinweis, dass das Cumulativ Update 5 (CU5) schon seit 3 Tagen verfügbar ist!

Es korrigiert einen recht störenden Agent Update Bug im CU4 (beim Update des Agents, der normalerweise kein Neustart des Servers benötigt wurden automatisch andere Dienste neugestartet und hat somit zu Serviceunterbrechungen geführt) und ein paar andere Fehler. Zusätzlich beinhaltet es den Agent für Red Hat 6.

Zu finden ist es unter http://support.microsoft.com/kb/2495674.

Eine häufig bemängelte Einschränkung des SCCM 2007 ist es, dass die darin enthaltene Updateverteilung keine Updates automatisch freigeben kann. In größeren Umgebungen ist dies im Allgemeinen auch nicht wünschenswert, da neue Microsoft Updates zuerst getestet und dann erst verteilt werden sollten.

Bei Antivirendefinitionen macht ein solches Vorgehen keinen Sinn. Tests gegen alte und neue Viren oder gegen bestimmte Clients, um False-Positives zu erkennen kann man ein paar Mal machen, sobald Updates mehrfach am Tag kommen ist dies nicht mehr sinnvoll.

Forefront Client Security 2010 integriert sich so tief in den SCCM, dass auch für die Definitionsverteilung der SCCM genutzt werden kann. Hat dieser keine aktuellen Definitionen, so kann der Client auf eine Freigabe (UNC-Pfad), einen WSUS oder Microsoft Updates ausweichen. Als WSUS wird natürlich der auf dem Client hinterlegte verwendet, der bei einem SCCM Client immer der vom Server gemanagte WSUS sein muss.

Daher wäre es wünschenswert, wenn dieser die Definitionsupdates automatisch freigibt. Generell ist es nicht empfehlenswert in einen vom SCCM verwalteten WSUS einzugreifen. In diesem Szenario ist es die einzige sinnvolle Lösung.

Um das (von mir ebenfalls schon umgesetzte) Verfahren nicht erneut beschreiben zu müssen, verlinke ich einfach auf den nachfolgenden Blog Post:

Approve updates for Forefront Endpoint Protection 2010

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:

function getUser
{param([string]$pc)
   ((Gwmi -class Win32_ComputerSystem -ComputerName $pc)| select-object username).username
}

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.

Read more…

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.

Read more…

Bei einigen Automatisierungen ist es notwendig den Profilpfad eines Benutzers auszulesen und einen eventuellen DFS Pfad in einen physikalischen Pfad aufzulösen.

Hierfür habe ich eine kleine Batch-Datei geschrieben:

@echo off
set samaccountname=%~1
for /f "tokens=* usebackq" %%a in (`AdFind.exe -f "samaccountname=%samaccountname%" profilePath /list`) do (
set profilePath=%%a
)

for /f "delims=<> usebackq tokens=1,2,3,4,5" %%a in (`dfsutil diag viewdfspath %profilepath%`) do (
     if NOT %%e.==. set profilePath=%%e
)

echo %profilePath%

Der Profilpfad wird in Zeile 3 mit Hilfe von adfind anhand des Benutzernamens ermittelt, per for ausgewertet und an eine Umgebungsvariable übergeben.
Diese wird in Zeile 7 an dfsutil übergeben, dass mit dem Befehl diag den physikalischen Pfad anzeigt (ermittelt mit dem aktuellen Standort). Die Ausgabe wird erneut mittels for ausgewertet, wobei die Zeilen an den Größer- und Kleinerzeichen getrennt werden. An fünfter Stelle steht dabei der physikalische Pfad. Handelt es sich bei dem Profilpfad um keinen DFS basierten, dann ist die fünfte Stelle leer und wird daher nicht an die Variable übergeben.

Innerhalb einer anderen Batch-Datei kann diese einfach per call getprofilepath.cmd SAMACCOUNTNAME aufgerufen und die Variable profilePath später weiterverwendet werden.

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.

Read more…

Dieser Blog beschäftigt sich hauptsächlich mit technischen Aspekten von Systemen und im Speziellen mit den Microsoft System Center Produkten.

Gerade bei der Einführung neuer Produkte ist der ROI (return of investment) und somit betriebswirtschaftliche Aspekte nicht unwichtig.

Daher hier ein paar Punkte, die mit dem Ersetzen von einem anderen Softwareverteilungstool durch SCCM Einsparungen bringen kann:

• Schnellere Paketierung durch App-V, da weniger wechselseitige Abhängigkeiten überprüft werden müssen
• Weniger Wartezeit für den Anwender durch App-V: Auch wenn er seinen Arbeitsplatz wechselt steht seine Software ihm zur Verfügung, da diese ihm folgt und nur ihm an diesem Rechner angeboten wird.
• Schnellerer Hardware-Modellwechsel durch OSD von SCCM: Treiber werden bei der OS-Installation dynamisch nachgeladen. Ein neues Modell kann so im Idealfall nur einfaches einbinden der noch fehlenden Treiber integriert werden.
• Schnellere Neuinstallation: Je nach Supportpolicy steht im Fehlerfall irgendwann eine Neuinstallation des Rechners an. Gerade wenn dem Benutzer kein anderer PC zur Verfügung steht, sollte diese Installation so schnell wie möglich sein. SCCM verwendet hier ein imagebasiertes Rollout und ermöglicht durch Multi-Cast eine sehr schnelle Installation auch an mehrere Ziele parallel.
• Patch-, Softwareinstallationen und OS-Neuinstallation in der Nacht: Der Benutzer wird während seiner Arbeitszeit nicht gestört. Die Rechner werden per integriertem Wake-on-Lan (WOL) abends gestartet und nach Abschluss der Installationen wieder heruntergefahren
• Powermanagement: einigen Anwendern ist die Boot-Zeit zu lange, daher lassen sie den Rechner über Nacht durchlaufen. Dies erhöht die Stromkosten und erhöht das Brandrisiko in den Büroräumen. SCCM beinhaltet ab SCCM 2007 R3 ein Powermanagement und kann so konfiguriert werden, dass sie Rechner in den Abendstunden schneller schlafen legen. Um dem Anwender trotzdem ein schnellen Start am Morgen zu ermöglichen ist ein WOL am morgen möglich

Dies stellt nur ein Auszug von möglichen Einsparungspotentialen dar. Gerade durch das Powermanagement kann ein Betrieb viel Geld einsparen. Für genauere Berechnungen anhand von Excel Tabellen stehe ich und mein Arbeitgeber gerne zur Verfügung

Vor einigen Tagen hat Microsoft den System Center Updates Publisher (SCUP) in der Version 2011 veröffentlicht.  Er beinhaltet einige interessante Neuerungen:

• Automatic Updates mit SCCM: zuerst wird ein Update nur als metadata veröffentlicht ohne das eigentliche Update herunterzuladen. Bei einer späteren Synchronisation ließt der SCUP aus dem SCCM (System Center Configuration Manager 2007 oder höher) aus, ob Clients dieses update benötigen. Ist dies der Fall, dann lädt er das komplette Update herunter und stellt es in den WSUS zur Verteilung bereit
• Software update Cleanup Wizard: Ermöglicht es nicht mehr benötigte Updates zu bereinigen, indem sie auf expired gesetzt werden
• …

Herunterzuladen ist das Tool unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=083f45ca-1ede-4f7a-be74-77854c3a9b01.

Eine gute Installationsanleitung ist hier zu finden: http://blogs.technet.com/b/jasonlewis/archive/2011/05/24/getting-started-with-updates-publisher-2011.aspx (Keine Bilder, aber dafür alle wesentlichen Punkte enthalten, ich konnte problemlos nach ein “Upgrade” machen, daher werde ich es nicht nochmal hier beschreiben)

Meine Vorgehensweise zum Publizieren von Updates (nachdem die Konfiguration inkl. WSUS und SCCM abgeschlossen ist):

• Importieren der ausgewählten Kataloge
• Auswahl aller Updates auf oberster Ebene
• Publish drücken und dabei Automatic auswählen
• WSUS Sync in der SCCM Konsole anstoßen
• etwas warten, damit Clients einen Scan mit dem neuen Katalog ausgeführt haben (oder einen Scan auf einem oder mehreren Clients manuell starten)
• Erneuten Sync im SCUP mit Automatic: jetzt lädt er die benötigten Updates herunter
• Verteilung der benötigten Updates im SCCM wie normale Windows Updates

Insgesamt eine wirklich gelungene Aktualisierung mit der der SCUP endlich erwachsen wird.

Kann mir einer das mal erklären? Löscht man in Hyper-V eine VM, die Snapshots hat, dann werden erst alle Snapshots gelöscht, also in das Hauptfile zurückgeschrieben und dann die entsprechende Disk. Was für einen Sinn macht das?

Besonders extrem wird es, wenn man ein Storage Migration mit SCVMM (System Center Virtual Machine Manager 2012) macht. Dabei wird eine neue VM angelegt, die Disks kopiert und dann die alte VM mit den Disks gelöscht. Was dann bei einer VM mit Snapshots passiert kann man sich denken:

Ansicht des Jobs im SCVMM 2012:

Wie man sieht wurden die Disks innerhalb 3 Minuten kopiert und jetzt (ca. 14:05) hängt er immer noch beim Entfernen der VM.

In der Hyper-V Konsole sieht es zu dem Zeitpunkt so aus:

Destroying ist bei 25%

Ich kann mir den Sinn davon nicht erklären. Vielleicht irgendein anderer hier??