TSM BA kliens upgrade PowerShell használatával

Bár a TSM egy bizonyos verzió szám fölött támogatja a kliensek automatikus frissítési lehetőségét, mégsem arról szeretnék írni. Igazság szerint nem is tudnék, mivel még ki sem próbáltam. Viszont nagy számú kliens esetén jó ha van olyan módszer, amivel valamennyire automatizálni lehet a frissítéseket.
A következő feltételeknek meg szerettem volna felelni:

• ne legyen szerver újraindítás
• az upgrade során minimalizáljuk a manuális munkát
• minden szerverre testre szabott, az adott szerveren futó beállításokat figyelembe vevő script készüljön

Az új telepítésekkel most nem akarok foglalkozni. Ott végül is nem túl bonyolult a feladat, hiszen a dokumentációk alapján könnyen össze lehet dobni egy scriptet, ami elvégzi a telepítést, létrehozza a szolgáltatásokat, esetleg be is másol egy előre elkészített dsm.opt file-t.
De mi a helyzet akkor, amikor már van egy futó kliens a gépen, és azt szeretnénk frissíteni? Főleg ha nem is egységesen történt a múltban a telepítés, hanem sok esetben esetleg a szerver gazdája telepítette, máskor a TSM admin, stb. Ennek megfelelően a szolgáltatások neve sem feltétlenül egységes, ezen kívül a verziók is széles skálán mozognak. És persze vannak 32 és 64 bites szerverek is, amik más és más telepítő készletet igényelnek.
Ilyen esetben úgy kell megírni a scriptet, hogy vegye figyelembe az egyes gépeken meglévő beállításokat. Ezen beállítások pedig megtalálhatóak a registry-ben. Mivel már sok más feladatra is használtam a PowerShell-t, ezért itt is kézenfekvőnek tűnt a használata.
Ahhoz, hogy a Registry-ből olvassunk, kellenek megfelelő függvények, amik sajnálatos módon hiányoznak a PowerShell-ből. Szerencsére ezeket már megírták mások, és az Interneten keresztül elérhetővé tették számunkra. Pl. ez: http://poshcode.org/2162
Az elképzelés a következő volt. Egy  szöveg file-ban megadott node nevek alapján a script minden egyes gép számára legyárt egy .cmd file-t, amit egyszerűen elküldök a szervergazdának, aki futtatja. Mivel nekem nincs adminisztrátori jogom a szervereken, ezért megkértem egy domain admint, hogy futtassa a scriptemet.
Az egyszerűség kedvéért csak olyan gépekkel foglalkoztam, amelyeken csak szimpla TSM BA kliens volt, semmilyen TDP nem futott rajta. Ez az én esetben kiteszi a gépek 90%-át. Az előkészítés során meghatároztam a node-ok listáját. Mivel a node név megegyezik nálunk a gép nevével, ez nem volt nehéz feladat. Ebből készült a nodelist.txt file. Ezt felhasználva a PowerShell script a lenti sorban látható módon elkezdi feldolgozni a file tartalmát. Nyílván a foreach blokkban történik a feldolgozás.

 

get-content -Path d:\tsm_ps\nodelist.txt|foreach-object {....}

A jobb olvashatóság kedvéért a blokkon belül a $_ változót beraktam a $aktserver változóba.

$aktserver=$_

Ezután meghatároztam a .cmd file-t, amibe a script majd írogatja a szükséges sorokat.

$cmdname="D:\tsm_ps\" + $aktserver + "_upgrade.cmd"

Ezután kell egy kicsit olvasni a Registry-ből. Igazából a node nevekre nincs szükség, hiszen feltételeztem, hogy a node név megegyezik a szerver nevével. Újabb kliensek esetében a node információk a következő helyen találhatóak ($p1), míg a régebbi 5.5 előtti kliensek esetében pedig itt ($p). Bár mint mondtam, ezt az információt nem fogom használni a következőkben.

$p = "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes"
$p1 = "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes"

Nézzük meg, hogy az adott gépen milyen szolgáltatások vannak definiálva. Ha az újraindítást el szeretnénk kerülni, akkor mindenképp le kell állítani a futó szolgáltatásokat az upgrade előtt. De mivel az én esetemben szerettem volna egységesíteni is a beállításokat, így nem csak leállítom, hanem majd törlöm is őket.

$service_list=get-remoteregkey $_ $p_key $property |get-member|where-object{$_.membertype -eq "NoteProperty"}|foreach-object{$_.name}

Itt a get-remoteregkey cmdlet-et használtam, de biztosan található másféle is a poshcode.org oldalon. Itt a három paraméter:

$_ - a gép neve
$p_key - "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Scheduler Service"
$property - "*"

Így a $service_list változóba megkapjuk a szolgáltatások nevét, amit nem csak a leállításra és törlése tudunk használni, hanem akár a szolgáltatások újbóli létrehozására is, ha az upgrade már lefutott.

Mostanra lett meg (majdnem) minden információ, így indulhat a parancs file gyártás. A jobb olvashatóság kedvéért a parancs file minden szekciója elő elhelyeztem egy információs sort. Pl. az első lépés esetén ez így néz ki:

 

"REM " |out-file $cmdname -encoding "Default" -append
"REM Stop TSM services----------------------" | out-file $cmdname -encoding "Default" -append
"REM " |out-file $cmdname -encoding "Default" -append

Első lépésben leállítom a szolgáltatásokat.

$service_list|foreach-object{"net stop " + '"' + $_+        '"'}|out-file $cmdname  -encoding "Default" -append

Majd utána törlöm is őket.

$service_list|foreach-object{"dsmcutil remove /name:" + '"' + $_+       '"'}|out-file $cmdname  -encoding "Default" -append

Mielőtt az upgrade kezdődne, meg kell adni a telepítő anyag elérhetőségét. Én ezt egy hálózati megosztással oldottam meg.

"net use i: \\szerver\dc |out-file $cmdname -encoding "Default" -append

Természetesen itt olyan betűt kell használnunk, amit a szerveren még nem létezik. Illetve arról is gondoskodni kell, hogy a megosztáshoz mindenkinek legyen meg az olvasási joga.

Az előbb azt mondtam, hogy majdnem minden információ megvan, de még egy fontos hiányzik. Mégpedig az, hogy 32 vagy 64 bites operációs rendszerről van-e szó. Ezt a WMI lekérdezésével lehet eldönteni.

$OS=get-wmiobject -class win32_operatingsystem -namespace "root\CIMV2" -computername $aktserver

Azért egy kicsit trükkös a dolog. Pontosabban én nem találtam olyan mezőt a lekérdezés eredményében, ami mindenféle operációs rendszer esetén egyértelműen megmondta volna, hogy 32 vagy 64 bitről van-e szó. Én pl. a következő sor alapján döntöttem el:

if (($OS.Caption.Contains("64") -eq $True) -or ($OS.Caption.Contains("2008 R2") -eq $True))

Ez így különben nem teljesen jó (64 bites Windows 2008 esetén nem jó eredményt ad), de egy kicsit összetettebb feltételrendszer használatával javítható.
Ezen a ponton a script kétfelé ágazik, hiszen eltérő install csomagot kell használni. És ez nem csak magának a BA kliensnek a telepítésére igaz, hanem a C++ 10 Redistributable telepítésére is, ami feltétele a BA használatának. Itt most minden magyarázat nélkül beillesztem a kétféle telepítéshez szükséges parancsokat előállító script részleteket.

64 bit:

$CppInstallstring="I:\TSM_BA_Client_x64\ISSetupPrerequisites\{270b0954-35ca-4324-bbc6-ba5db9072dad}\vcredist_x86.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring|out-file $cmdname -encoding "Default" -append   
$CppInstallstring_x64="I:\TSM_BA_Client_x64\ISSetupPrerequisites\{7f66a156-bc3b-479d-9703-65db354235cc}\vcredist_x64.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring_x64|out-file $cmdname -encoding "Default" -append   

 

$installstring = "msiexec /i " + '"' + "i:\TSM_BA_Client_x64\IBM Tivoli Storage Manager Client.msi" + '"' + " RebootYesNo=" + '"' + "No" + '"' + " REBOOT=" + '"' + "Supress" + '"' + " ALLUSERS=1 INSTALLDIR="
$installstring=$installstring + '"' + "c:\program files\tivoli\tsm" + '"' + " ADDLOCAL=" + '"' + "BackupArchiveGUI,BackupArchiveWeb,Api32Runtime,Api64Runtime" + '"'
$installstring=$installstring + " TRANSFORMS=1033.mst /qn /l*v " + '"' + "c:\tsminstall_baclient_log.txt" + '"'
$installstring|out-file $cmdname -encoding "Default" -append

32 bit:
 

$CppInstallstring="I:\TSM_BA_Client\ISSetupPrerequisites\{270b0954-35ca-4324-bbc6-ba5db9072dad}\vcredist_x86.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring|out-file $cmdname -encoding "Default" -append

$installstring="msiexec /i " + '"' + "i:\TSM_BA_Client\IBM Tivoli Storage Manager Client.msi" + '"' + " RebootYesNo=" + '"' + "No" + '"' + " REBOOT=" + '"' + "Supress" + '"' + " ALLUSERS=1 INSTALLDIR="
$installstring=$installstring + '"' + "c:\program files\tivoli\tsm" + '"' + " ADDLOCAL=" + '"' + "BackupArchiveGUI,BackupArchiveWeb,ApiRuntime" + '"'
$installstring=$installstring + " TRANSFORMS=1033.mst /qn /l*v " + '"' + "c:\tsminstall_baclient_log.txt" + '"'
$installstring|out-file $cmdname -encoding "Default" -append

A TSM BA kliens telepítő paraméterezését összeállító kódban azért van több sorba szétszedve a $installstring változó összerakása, mert egyébként igen hosszú sorokat kaptam volna, ami nehezítette volna az olvasását. A fenti sorok megírása elég nagy odafigyelést igényelt.

Az ezután következő részek már megint egységesek, hiszen ha fut az eddig megírt parancs file, akkor már eljutunk odáig, hogy a BA kliens telepítve van, már csak a szolgáltatásokat kell létrehozni, elindítani.

Mint írtam korábban, most fel lehetne használni a $service_list változót, hiszen abban letároltuk az előző verzió által használt szolgáltatásokat. De én most mégsem ezt használtam. Az okot már említettem, nem volt egységes eddig a telepítés, ezután pedig azt szerettem volna elérni, hogy minden szerveren azonos neve legyen a Scheduler service-nek és a CAD-nek. Ezért inkább egyszerűen létrehoztam a szolgáltatásokat. Előbb a scheduler-t.

$Schedulerstring="dsmcutil install scheduler /name:" + '"' + "TSM Scheduler Service" + '"' + " /clientdir:c:\progra~1\tivoli\tsm\baclient /optfile:c:\progra~1\tivoli\tsm\baclient\dsm.opt /node:" + $aktserver + " /password:adsm /validate:no /autostart:no"
$Schedulerstring| out-file $cmdname -encoding "Default" -append

Majd a Client Acceptor-t.

$CADString="dsmcutil install CAD /name:" + '"' + "TSM Client Acceptor" + '"' + " /cadschedname:" + '"' + "TSM Scheduler Service" +'"' +" /node:" + $aktserver + " /password:adsm /autostart:yes /validate:no"
$CADString| out-file $cmdname -encoding "Default" -append

Most már csak két lépés van hátra. Előbb megszüntetem az ideiglenesen felcsatolt hálózati meghajtót.

"net use i: /delete" |out-file $cmdname -encoding "Default" -append

Majd pedig elindítom a CAD service-t.

"net start " + '"' + "TSM Client Acceptor" +'"'|out-file $cmdname -encoding "Default" -append

És készen is vagyunk:)

Természetesen a teljes script tartalmaz némi log írást, hibakezelést, illetve a meghívatkozott Registry kezelő eljárásokat is.

A végeredmény pedig egy közönséges .cmd file, amit csak futtatnunk kell admin joggal az adott szerveren.

A hosszabb kód részek elég nehezen olvashatóak, de ha kimásoljátok valamilyen szerkesztőbe, akkor áttekinthetőbb lesz.

Ha valakinek kérdése van ezzel kapcsolatban, segítek ha tudok.