Markus Bäker

Vor über einem Jahr habe ich angefangen meine SCCM Hilfsscripte hier zu veröffentlichen. Da ich noch eine ganze Reihe von diesen Batchdateien habe, kommen jetzt noch einige weitere Posts zu diesem Thema.

Im Teil 2 wurde die Batch und vbs Datei vorgestellt, um auf eine Reihe von Clients die Hardwareinventur anzustossen.

Dies geht genauso mit dem Computer Policy Update:

startmachineupdate.cmd

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Machine Policy Update %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000021}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

und die dazugehörige startmachineupdateall.cmd:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitename') do call %~dp0startmachineupdate.cmd %%i

Benötigt dazu wird findip.bat und getcomputer.vbs aus Teil 1 bzw. Teil 2.

In seltenen Fällen kommt es noch vor, dass man eine alte Software auf einem aktuellen Windows 7 installieren muss. Damals haben die Entwickler nicht mit einem neuen Betriebssystem gerechnet oder erwartet, dass man rechtzeitig neue Lizenzen kauft. Teilweise hängt an der Client Software entsprechende Backend-Systeme, die nicht so einfach aktualisierbar sind.

Hat man es somit mit einem MSI Paket zu tun, dass einem aufgrund von nichtunterstütztem Betriebssystem den Dienst verweigert (s. Bild),  so kann man verschiedene Wege wählen:

• Windows selber bietet die Möglichkeit an, die Kompatibilität zu korrigieren. Dazu wählte man im Kontextmenü des MSI-Pakets (“Rechter Mausklick”) den Punkt “Troubleshoot compatibility”. Genutzt wird dabei das Windows 7 eigene “Microsoft Diagnostic Tookit” (msdt.exe) mit dem Bereich PCWDiagnostic. Dieser wäre auch scriptbar. Weitere Informationen findet man unter http://technet.microsoft.com/de-de/library/ee424379%28WS.10%29.aspx und den entsprechenden weiterführenden Links.
• Elegant finde ich auch die Möglichkeit den entsprechenden Check direkt aus dem MSI File zu extrahieren. Dazu ist noch nicht einmal ein MSI Admin Studio oder ähnliches notwendig. Eine VBScript Datei und die Funktionalität des MSI Installers reichen aus. Zu finden ist dieses hilfreiche Skript unter http://lazynetworkadmin.com/content/view/20/1/

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.

Normaly you can only import a Virtual Machine (VM) into Hyper-V if you have exported it. If you lose your Hyper-V settings or have to import it into a new Hyper-V Server in case of a desaster recovery than you can use the steps descripted in this (and other) blog post: http://blogs.msdn.com/b/robertvi/archive/2008/12/19/howto-manually-add-a-vm-configuration-to-hyper-v.aspx

The problem is that you have to handle many long pathes and cryptical GUIDs. I had to do that for a bunch of different VMs and being chronical lacy I created three batch files for it:

1. importVM.cmd “GUID” “Path to Virtual Machine” creates the link and corrects the permissions on the link and the vm folder
2. importSnapshot.cmd “SnapshotGuid” “VMGuid” “Path to Snapshot” creates the snapshot link and the right permission.

Not very impressiv? Well, the third batch files combines this two scripts:

1. addMachine.cmd: Takes the basis path (the path where the sub-folder Virtual Machine, Snapshots exists) and extracts the VM-GUID, all Snapshots-GUIDs and the other pathes to automaticly create the links and permissions.

So with one simple command (addMachine.cmd C:\ClusterStorage\Volume4\VM1) you can import the complete VM.

— addMachine.cmd ——

Read more…

Es kann vorkommen, dass aufgrund eines Problems mit einer Zertifikatsvorlage alle Zertifikate davon auf den Clients gelöscht werden sollen, um einen sauberen Stand auf den Computern zu haben.

Dazu habe ich eine kleine Batchdatei geschrieben, das alle Zertifikate im Computerstore ausliest und anhand der Seriennummer die Vorlage des Zertifikates ermittelt. Stimmt der Name der Vorlage mit dem angegebenen Vorlagenname (hier Vorlagename) überein, dann wird es gelöscht.

Die Batchdatei kann man mit Hilfe einer Gruppenrichtlinie oder einer Softwareverteilung an die Clients verteilen.

————————– hier ausschneiden ——————————

@echo off

setlocal ENABLEDELAYEDEXPANSION

rem Aktuelle Zertifikate im My-Store ausgeben (beinhaltet auch den COmputer Store)

certutil -store my > %temp%\store.tmp

rem durch das ergebnis durchgehen

for /f "delims=: tokens=1,*" %%a in (%temp%\store.tmp) do (

  rem seriennummer des aktuellen zertifikates zwischenspeichern

  if %%a.==Seriennummer. (

    set seriennummer=%%b

  )

  rem anhand ausgabe der vorlage erkennen ob es eine bestimmte Vorlage hat

  if %%a.==Vorlage. (

    echo %%a | findstr /i "Vorlagenname"

    if ERRORLEVEL 0 (

       certutil -delstore my !seriennummer!     

    )

    set seriennummer=

  )

)

del %temp%\store.tmp

Endlocal

————————– bis hier ausschneiden ——————————

Manchmal möchte man die SCOM Konsole direkt mit einer bestimmten Ansicht/View starten. Dies ist zum Beispiel interessant, wenn man die Konsole nutzt, um den aktuellen Systemzustand auf einem großen Monitor dazustellen.

Dazu gibt es einen alten, aber immer noch zutreffenden Blogartikel: http://myitforum.com/cs2/blogs/dhite/archive/2007/12/16/starting-the-opsmgr-2007-operations-console-from-the-command-line.aspx

Dabei ist zu beachten, dass der Viewname der interne Name der Sicht ist. Diesen bekommt man teilweise nur heraus, wenn das Management Pack in de Authoring Console öffnet.

Alternativ kann man auch per AutoIT eine kleine EXE kompilieren, die die Konsole öffnet und per simulierte Tastendrücke die entsprechende Sicht öffnet.

Ein Beispielskipt kann so aussehen:

Run(@ProgramFilesDir & "\System Center Operations Manager 2007\Microsoft.MOM.UI.Console.exe")
WinWaitActive("System Center Operations Manager 2007 – SITENAME")
Sleep(5000) ;five seconds
WinActivate("System Center Operations Manager 2007 – SITENAME")
send("Overv")
send("+")
sleep(2000)
send("{DOWN}")
sleep(5000)
send("{DOWN}")
send("{APPSKEY}")
send("{DOWN}{DOWN}{DOWN}")
send("{ENTER}")
WinWaitActive("Service Overview")
Sleep(5000)
send("^T") ;send controll t (action pane ausblenden)
WinSetState("Service Overview","",@SW_MAXIMIZE)

Kurze Erklärung: Zuerst die Konsole öffnen (mit Variable, um möglichst sprachunabhängig zu sein), warten bis die Konsole aktiv ist (hier wird nach dem Titel des Fensters geschaut, in dem auch der Name de Site enthalten ist!), das Fenster sicherheitshalber nochmal aktivieren, Die ersten Buchstaben des Ordners eintippen (in diesem Beispiel Overview), per + aufklappen, zur zweiten Sicht im Ordner gehen, Kontextmenü öffnen, dort Öffnen in neuem Fenste auswählen, warten bis diese Sicht offen ist, die Actionpane ausblenden und am Ende nochmals das Sichtfenster maximieren.

Im letzten Teil habe ich beschrieben, wie man mit einer einfachen Batchdatei remote eine Hardwareinventur anstoßen kann. Was ist aber, wenn man dies auf mehreren PCs gleichzeitig machen will? Z.B. bei allen PCs, die eine bestimmte Software angeboten bekommen und somit in einer SCCM Collection sind?

Auch da hilft eine kleine Batchdatei:

starthinvall.cmd

for /F %%i in (‘cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 siteserver sitename’) do call %~dp0starthinv.cmd %%i

Aufgerufen wird die Batchdatei mit den Namen der Collection, in der die Zielclients sind. Das passende getcomputer.vbs verbindet sich dann mit dem hinterlegten Siteserver und fragt in der angegebenen Site (sitename) die in der Collection hinterlegten Computer ab. Die Ausgabe (ein Computer pro Zeile) wird von der For Schleife abgefangen und an die starthinv.cmd weitergegeben.

getcomputer.vbs basiert weitestgehend auf einem Script von www.myitforum.com und wurde nur von der Ausgabe und Weiterverarbeitung angepasst.

Hier nochmal die Files als Download:

• starthinvall.cmd (261)
• getComputer.vbs (321)

Ich werde hier ab jetzt regelmäßig ein paar kleine Skripte rund um den System Center Configuration Manager (SCCM) bereitstellen. Geschrieben sind sie teilweise schon für SMS 2003 und funktionieren auch noch mit 2007.

Als erstes ein kleines Skript, um remote auf einem Client die Hardwareinventur anzustoßen:

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Hardware Inventur %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000001}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

Diese Batchdatei kann direkt mit dem Rechnernamen als Parameter aufgerufen werden. Wird nichts übergeben, dann fragt er nach dem Namen. Als erstes wird überprüft, ob der Rechner anpingbar und somit am Netzwerk ist. Dafür wird eine weitere Batchdatei aufgerufen, die ich nachfolgend anhängen werde. Danach wird ein VBScript aus dem SMS 2003 Toolkit 2 (http://technet.microsoft.com/en-us/sms/bb676787.aspx). Das Script sendet eine Nachricht per WMI an den Client. Jede Aktion eines Clients sind als Schedules bzw. Actions hinterlegt. Kennt man den entsprechenden Code, dann kann man diese sofort starten. In diesem Fall steht {00000000-0000-0000-0000-000000000001} für die Hardwareinventur.

Die findip.bat Datei sieht so aus:

@echo off
set ip=
set tempip=%temp%\%1.ip
ping %1 -n 1 |find /i “Antwort von” > “%tempip%”
for /F “eol=: tokens=3,* delims=: ” %%i in (%tempip%) do @set ip=%%i

if %ip%.==. goto englisch

goto ende

:englisch
ping %1 -n 1 |find /i “Reply from”>”%tempip%”
for /F “eol=: tokens=3,* delims=: ” %%i in (%tempip%) do @set ip=%%i

:ende
del %tempip%

Da die Quotes hier im Blog ziemlich verändert sind, habe ich die beiden Batchdateien noch als Download angehängt. Bitte Dateiendung entsprechend korrigieren:

• starthinv.cmd (297)
• findip.cmd (291)

Ein kleines Skript um 2000 User und 20 OUs mit jeweils weiteren 10 OUs anzulegen:

setlocal ENABLEDELAYEDEXPANSION
set basedn=OU=Test-OUs,dc=bktest,dc=intern

dsadd ou %basedn%

for /L %%i in (1,1,20) DO (
dsadd ou “OU=Test%%i,%basedn%”
FOR /L %%a in (1,1,10) do (
dsadd ou “OU=Test%%a,OU=Test%%i,%basedn%”
for /L %%e in (1,1,10) do (
dsadd user “CN=User%%i-%%a-%%e,OU=Test%%a,OU=Test%%i,%basedn%” -samid User%%i-%%a-%%e -fn Test%%a -ln User%%i%%e -pwd T%%i-%%a-%%eest
)
)
)
endlocal

Die Variable BaseDN muss entsprechend des eigenen ADDS Aufbaus angepasst werden.

Im Artikel “Don’t Panik – was tun wenn die vmdk Datei weg ist” habe ich beschrieben, wie man eine VMDK Header Datei auf Basis der letzten Logs rekonstruieren kann.

Jetzt wurde im NetApp Forum ein Tool bereitgestellt mit dem man dies automatisiert durchführen kann. Darüber hinaus ist es möglich bestehende Header Dateien zu überprüfen. Zu finden ist das Skript unter http://communities.netapp.com/docs/DOC-2735.

Gefunden habe ich den Verweis im Blog-Post http://www.yellow-bricks.com/2009/04/03/repairing-your-vmdk-header-files/.