Networker jälle

 Ikka Networkeriga maadlemine. Kõik varukoopia tegemised üle võetud ja nüüd avastamist kui palju. Kui varem kloonimist ei kasutatud, siis nüüd vaatasin, et miks peaks nädalalõpus koopiat mõnest save set'ist pea kolm korda tegema. Regulaarne ehk igapäevane, nädalalõpu oma ja kuu lõpus kuu oma. Peale varukoopiate asja ülevõtmist hakkas see häirima ja uurisin kloonimise varianti ning leidsin, et parem see kasutusele võtta. Varukoopia käib nädala lõpuni tavaliselt ja viimastest nädala lõpus tehtavatest täisvarukoopiatest teen nädala lõpus hoopis klooni teistele lintidele. Ja kuu lõpus teen veel teise klooni samadest asjadest kolmandatele lintidele või siis klooni nädalalõpu kloonist. Kumb variant mugavam tundub.
-----------------------------------------------------------
  Märkus iseendale: paistab, et kloon kloonist variant on natuke lollikindlam ja võtab vähem aega. Sai just natuke hooletu oldud ning läks lintidele 3 save set'i topelt. Poleks probleemi polnud, kui nende save set'ide maht poleks kokku nii 1.8 TB . Ja kirjutamiskiirus lindile DD pealt on nii 40-80MB/sek versus üle 200 MB/sek, mis on lindilt lindile tegemise puhul.
mminfo query vajalike save set'ide jaoks:

mminfo -o n -q "pool=week clone,savetime>10/27/12,savetime<10/30/12" -r ssid,cloneid,name,totalsize | uniqln -

(uniqln sorteerib välja ainult unikaalsed read)
-----------------------------------------------------------

  Leidsin ka, et Networkeri GUI'st ei saa kloonimise protsesse ära katkestada, selleks peab hoopis  jobquery ja jobkill utiliite kasutama. Kasutades infot kohast http://nsrd.info/blog/2011/03/17/killing-scheduled-cloning-operations/

# jobquery
jobquery> show name:; job id:; job state:
jobquery> print type: clone job; job state: ACTIVE;
                      job id: 4929644;
                   job state: ACTIVE;
                        name: clone.linux clones;

jobquery> quit

# jobkill -j 4929644 

Ja tööle pandud kloonimise töö, mille jaoks linti ei saanud sise panna, saigi katkestatud.

  Sain ka DD voluumi osas targemaks. Hakkas teine täis saama ja peaaegu aasta vanad save set'id istusid peal ning ei kustutatud midagi ära. Algselt oli DD voluumi jaks pandud retention time aasta ning Recycling Auto. Sellise konfi juures ei saanud vanu save set'e Recycled staatusesse panna. Ühendasin DD voluumi lahti, Networkeri GUI's määrasin DD voluumi Recycle variandi Manual'iks ning sain hakata vanemaid save set'e Recycled olekusse panema. Kõigepealt sai 6 kuu vanused save set'id välja võetud. Esialgu ülevaatlik pilt:

mminfo -q "volume=ddvolume.001,savetime<6 months ago" -r savetime,ssid,client,name,level,state

Siis ainult SSID'd faili:

mminfo -q "volume=ddvolume.001,savetime<6 months ago" -r ssid > ssids.txt

Peale seda panin save set'id Recyclable olekusse(kuigi seda vist poleks vaja olnud):

for /f %i in (ssids.txt) do (nsrmm -o recyclable -S %i)

Järgnevalt kustutasin Networkeri andmebaasist save set'ide info ära:

for /f %i in (ssids.txt) do (nsrmm -dPy -S %i & nsrmm -dy -S %i)

Ning lõpuks DD voluumi pealt ruumi juurde:

nsrclone -P -W ddvolume.001

Kõige lõpuks siis DD enda peal filesys clean start ning ruumiprobleem selleks korraks lahendatud. Kuna save set'ide aegumine sai DD voluumi peal paika pandud, siis edaspidi saab asja cmd failiga atuomatiseerida, võttes mminfo'ga välja kõik 6 kuud vanad ja Recycled olekus olevad save set'id:

mminfo -q "volume=ddvoluum.001,ssrecycle,savetime<6 months ago" -r ssid > ssids.txt

SSD kettaste kasutusaeg

On kettakast ja SSD kettad sees. Kasutuses 3..4 kuud ja juba tunnistas kettakast ühe SSD ketta kõlbmatuks ning nõuab väljavahetamist. Esimese hooga paneb imestama, sest nii kiiresti pole veel ühtegi tavalist ketast kettakastis katki läinud, kuid tõenäoliselt on kettakastidel rangemad standardid ja ketas vahetatakse välja juba siis, kui on kahtlus, et see võib probleeme tekitada. Probleemne ketas otseselt katki ei olnud, aga oli tekkinud piisavalt palju (40) vigu nimega "Drive Recovered Error". Tegemist ei paista olevat "non recoverable" vigadega ja tõenäoliselt kodukasutuses olles laseks selle kettaga rahulikult edasi, aga nagu näha, kettakastile ei sobi enam. Standardid kõrged.

Viimasel paaril nädalal on üsna palju aega võtnud Networker, Networker, Networker ja jälle Networker. Varukoopiate ajastatuse paikapanek, lintide pool'id, mida kirjutada lintidele, mida DataDomain'i peale, kloonid, varukoopiate tegemiste jälgimine jne. Ja muidugi dokumenteerimine, mis kuidas töötab ja kuhu läheb. Mis veel nikerdamist vajab on igasugune raportite saatmine ja et tulemustest oleks hea ülevaade.

Tarkvara bugid rõõmustavad jälle, teevad igapäevase töö huvitavamaks. Oli vaja Exchange 2010 saada varundama Datadomain seadme peale. Varukoopia tegemiseks on Networker 7.6 SP3 ja Networker Module For Microsoft Applications. Viimasest hetkel kasutuses versioon 2.3. Kõik Networkeri kliendid/grupid/DD seadmed/poolid jne paigas ja konfigureeritud, aga varukoopiat ei toimu. Niisama failidest veel tehti varukoopiat, aga "APPLICATIONS:\Microsoft Exchange 2010" save set ei toiminud kuidagi. Sai siis igasugustes logides tuhnitud kuni jõudsin failin nmm.raw log failini Exchange serveril, mis ütles niipalju et:

An error occurred while checking the event log for data corruption errors. RM was unable to read the event log. 
Additional info: Cannot open log Application on machine .. Windows has not provided an error code..

Nagu windowsi puhul ikka, sai restarti proovitud, kuid kuna see ei aidanud, läksin ja vaatasin EMC lehelt, mis infot sealt leiab. Ja leidsin, et neil "Cumulative Fix package" 2.3 jaoks väljas ja ka uus 2.4 versioon olemas. 2.3 paranduste readme fail vihjas, et tegemist võib olla tarkvara veaga.

NW135291 - Exchange 2010 backup fails if there are any old JET errors in the event viewer

Eeldasin, et 2.4's on samad parandused sees ja installisin uue versiooni ning peale uut serveri restarti hakkas varukoopia ilma probleemideta tööle. Vähem linti kirjutamist jälle igapäevaselt.

 Vahepeal sai veel üks tüütu probleem lahenduse. Tahtsin kunagi 2011 alguses Windows 2008 ja Exchange 2010 serveris Scheduled Task'i tööle panna, seda aga mitte admin õigustes vaid limiteeritud kasutaja õigustes, kes ei ole admin ja omab teatud Exchange rolel ainult. Ei tulnud välja ainult. Admin õigustes Scheduled task'ina või konsoolist Interaktiivse kasutajana töötas ideaalselt, kuid  muu kasutajana Scheduled Task'ide alt tööle pannes jäi logi maha teade:

New-PSSession : An internal error occurred. 
+ $s = New-PSSession <<<<  -ComputerName myserver
    + CategoryInfo          : InvalidOperation: (:) [New-PSSession], PSInvalid OperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.NewPSSessionCommand

Igasuguste cmdlet'idega, mis olid Wsman' asjadega seotud sai piiratud kontoga scheduled taski alt vastu näppe. Küsisin ka MS foorumist , kuid erilist abi polnud, kuni lõpuks selle aasta juulis postitas keegi lahenduse - http://connect.microsoft.com/PowerShell/feedback/details/536492/powershell-remoting-fails-from-asp-net-web-site . Lühidalt oli probleem selles, et WinRM püüdis suhelda teenustega, millele varem olid õigused ka "Authenticated users" grupil. Nüüd aga ainult Administrators ja Interactive users gruppidel. Lisaks saab õigusi anda veel ainuld command promptis ning SYSTEM kasutaja õigustes. Sysinternals'i psexec aitab hädast välja - psexec -s cmd
 Ja teenused, mille õigused vajasid kohendamist olid scmanager ja gpsvc. Kui ma hiljem tahtsin ka Get-Mailbox cmdlet'i kasutada, siis selgus, et ka www teenuse(w3svc) õigusi tuleb vastavalt kohendada.
 Kui lahenduse lingi kuupäeva vaadata, siis on näha, et lahendus ka 2011 alguses kirja pandud, aga millegipärast ei leidnud ise seda üles, kui otsisin ja nii tuligi oma poolteist aastat oodata, kuni keegi lingi mulle postitas.

SCCM 2007 SQL baaside kolimine teise SQL serveri peale ja raportite üleviimine SQL Reporting Services peale

 Sain vist hakkama. Ei ole nagu raske ülesanne, kuid igasiguseid pisiasju konfiguratsiooniga ja õigustega tuli ette, mis venitasid asja koos igasuguse muu igapäevatööga nii nädalapikkuseks tegemiseks. Kõigepealt muidugi natuke lugemist, üldinfo jmt.
Reporting in SCCM
Administrator Checklist for SQL Reporting Services

SCCM baaside jaoks tegin eraldi instanc'i ja hakkasin SCCM baaside tõstmisega tegelema. Nendega oli asi suhteliselt lihtne, detach , kopeerime uude kohta, attach, vaatame õigused üle ja muudame mõningaid asetusi. WSUS puhul registry's ja SCCM puhul setup'iga. Abi sain kohtadest
Migrate from Windows Internal Database to SQL Server
How to Move the WSUS Database

SQL instance'l oli vaja lisada veel CLR intergration

sp_configure 'clr enabled', 1
GO
RECONFIGURE
GO

SCCM serveri arvutikonto pidin panema SQL serveris lokaalsesse Administrators gruppi. Muidu ei toiminud SCCM'is Site backup ülesanne, mis tegi ka SQL serveris olevast andmebaasist SQL serveri kõvakettale varukoopia. Võibolla saaks ka ilma admin õigusteta hakkama, aga ei olnud niipalju aega, et seda välja uurida.

Leidsin veel lisaks, et SCCM serveris oli ODBC all System DSN konfigureeritud. Muutsin ka seal SQL serveri nime ära, kuigi asjad töötasid ka ilma muutmata. Kuskil oli mainitud, et see System DSN on konfigureeritud seal SMS Provideri ja SQL serveri vaheliseks suhtluseks. Hlaba see muutus igatahes ei teinud.

Baasid uue SQL serveri peal ja nüüd sai raportite kofigureerimise/ümbertõstmise kallale asuda. Reporting Services oli SCCM baaside instance'i jaoks eelnevalt ära installeeritud, vaikeasetustega. Vaatasin konfiguratsiooni üle, panin vajalikud asetused paika.
SCCM serveris lisasin "Site Systems" all uue serveri(SQL server, kus SCCM baasid sai pandud) ja installeerisin sellele serverile "Reporting Services point" rolli - How to Create a Reporting Services Point for SQL Reporting Services . Kuna asi ei hakanud  tööle, SCCM konsoolis "Reporting Services" all näitas serveri properties ainult seda, et SQL serveriga ei saada ühendust, siis tuli hakata netis tuhnima ja infot otsima.
Proovisin panna juurde ka lihtsalt "Reporting point" rolli SQL serveri jaoks, see aga tahtis IIS'i, mida SQL serveri polnud. Jõudsin ka selle sinna installeerida, kuid ei läinud midagi paremaks. Vahepeal aga leidsin, et SQL 2008 Reporting Services jaoks pole IIS'i üldse vaja (http://www.myitforum.com/forums/SCCM-R2-SQL-2008-m192259.aspx). Kindlasti oli see ka kuskil dokumentatsioonis kirjas, aga jäi kahe silma vahele. Võtsin seega IIS'i maha jälle. Võtsin veel SQL serverile sertifikaadi(enda PKI on paigas) ja konfigureerisin Reporting Services konfiguratsiooni all SSL'i ära. Lisaks tuli välja, et kui SQL serveri Reporting Services on teises serveris, siis toetatakse ainult default instance'i (6's punkt). Seega ei aidanud see, et ma SCCM baaside Reporting Services osa ära konfigureerisin, vaid ära tuli konfigureerida hoopis default instance(MSSQLSERVER) reporting osa. See tähendab muidugi seda, et SCCM baasid on ühe instance peal ja SCCM raportid on teise instance Reporting Services peal. Kahtlane konfiguratsion...

Kui nüüd SSL oli juurde lisatud, default instance reporting osa konfigureeritud ja SQL serverile restart tehtud, siis sai lõpuks ka SCCM konsoolis "Reporting - Rerpoting Services" all oleva SQL serveri asetusi paika panna. "Data Source Authentication" tab'i all määrasin ära, et kasutatakse "Windows integrated security".

Nüüd sain raportid SCCM konsoolis SQL peale kopeerida. Lisasin ka Power Management raportid.
Admin õigustega konto alt oli kõik korras, aga millegipärast ei ole kõigil igal pool admin õigusi. Ei tea küll miks... Seega tuli veel paika panna õigused teiste kasutajate jaoks. Lihtsalt raportite vaatamiseks ja SCCM admin'idele. Abiks jälle dokumentatsioon - Configure a Report Server for Remote Administration .https://sqlserver/Reports tuli samuti õigused paika panna. Peale seda paistis, et niisama kasutajad näevad raporteid ja SCCM admin sai SCCM konsoolist oma asjadega tegeleda.

Nüüd tuleb edasi veel SCUP 2011 tööle saada korralikult.

Märkus(30 oktoober 2012): 
Power Managemet raportite vaatamisel said kasutajad vigu:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DataSet2'. (rsErrorExecutingCommand)

Selgus, et raportite vaatajatel peab SMS baasis olema veel roll - smsschm_users
Lisasin rolli juurde ja saigi probleem lahendatud. Infot leiddsin kohast http://blog.coretech.dk/kea/modifying-the-dataset-execution-account-after-installing-configuraiton-manager-r3/