Lingering, lingering ….

Ilusad sõnad, tahaks peaaegu laulda, kui ei teaks nende sõnade halvamaigulist tähendus Active Directory kontekstis.

Lingering Objects – ehk siis jäänuk objektid (vabandust, pole õiget tõlget) on AD objektid mis on peamiselt tekkinud halvasti töötava replikatsiooni tagajärjel. Koos virtualiseerimise levikuga avanes veel üks võimalus – nn tagasikerimine, kus DC P2V muutmisel tehti vigu või DC taastati VM snapshotist  protseduure jälgimata.

Suurem tõenäosus jäänukobjekte kohata on suurtes AD implementatsioonides, mis hõlmavad paljusid DC sid ja paljusid ( sageli ebakindla Interneti VPN’iga) ühendatud andmekeskusi. Ja kui neid haldavad veel erinevad tiimid (erineva kompetentsi tasemega) siis …

Jäänukobjektide esimene avaldus on see, et AD ei taha enam replikeeruda – sellest saab mööda, kui lubada “non-strict” replikeerumisviis. KUID, see ei kõrvalda algpõhjust. Jäänukobjektide kõrvaldamine eeldas omajagu käsitööd ldp ja repadmin’ tööriistadega. See oli tüütu ja nõudis suurt täpsust.

Hiljuti sa MS AD team “valmis” (noh, betasse) SUUREPÄRASE tööriista – Lingering Object Liquidator (LOL) ‘i. Seda ei jagata veel päris avalikult ja selle kasutamine nõuab veel siiski teadmisi ( ja õigusi ) aga siiski on tegu suure sammuga edasi.

Tervet kasutusjuttu pole mõtete ümber rääkida. Härrad ja Prouad – see on tõeline kullafond.

Upgrademe DC’sid – Windows 2012 > Windows 2012 R2

image      Windows 2012 R2 on lahe, või noh, lahedam kui Windows 2012. Vaatamata hoolikale planeerimisel võib mingi hetk tekida ootamatu vajadus kiiresti upgradeda. Kes veel mäletab Windows 2003 upgradet 2003 R2’ ks – siis see oli maailma lihtsaim asi – pane CD sisse ja vajuta “upgrade”. Põhimõtteliselt kopeeriti peotäis faile ja valmis ta oligi. Ka siin on Microsoft teinud kõva tööd ja inplace upgrade on tehtud lihtsaks ja robustseks.  Kui muidu suhtutakse inplace upgrade teatava reservatsiooniga, siis juhul, kui Sul on korralik Windows 2012 DC julgen mina soovitada esimese järjekorras justnimelt inplace upgrade. Korraliku all mõtlen – et DC masinas on enam vähem ainult DC’ga seotud rollid. Teda pole kuskilt backupist taastatud või muidu häkitud, riistvara /VM on stabiilne ja piisava vaba kettaruumiga :).  Sellisel juhul säiluvad kõik* masina spetsiifilised sättungid ja Sa ei pea tegelema teenuste konfiguratsiooni üleviimisega. Ma ei puuduta siinjuures metsa/domeeni ettevalmistust R2 installiks – selle pead Sa ära tegema ennem esimes R2 DC installimist või koos sellega.

Upgrade protsess ise analüüsib ennem igasuguseid muutvaid tegevusi võimalike probleeme ja annab soovitusi. Hiljem on korduvalt võimalusi tagasi eelmise seisu juurde pöörduda.

Protsess ise on lihtne ja nõuab minimaalselt sekkumist  (eeldusel, et midagi ei lähe valesti) ja on täiesti tehtav ainult RDP accessiga.

  1. Windows Server 2012 R2 meedia kättesaadavaks.
  2. Setup käima ja peale mõningaid sissejuhatvaid ekraane valida Upgrade. Samuti saab valida Standard/Datacenter ja Core/GUI variantide vahel.
  3. Hakatakse faile kopeerima ja upgrade scripte ette valmistama. Peale seda tehakse restart ja nüüd lähevad teenused maha. Kulunud on umbes 10-15 minutit.
  4. Tehakse paar restarti , kusjuures alati on näha Boot menüü tagasiminekuvõimalustega, automaatselt jätkatakse peale väikest viivitust upgradega ( juhul kui sul on juurdepääs konsoolile, RDP on nüüd juba  maas)
  5. Umbes 20-25 minuti pärast hakkab võrk tööle ( masin vastab pingile) , kuid teenused pole veel häälestatud, selleks kulub ka umbes 5 minutit.
  6. Kui DNS/AD  teenused on kenasti käima saadud toimub viimane restart kus Bootmenüü on peidus ja masin läheb viivituseta R2 olekusse. Lühidalt kuvatakse Finalizing … ( alguses olev pilt) ja peale paari minutit ongi masin püsti ja sinna on võimalik ka lokaalselt sisse logida.

Kogu selle tegevuse peale kulub umbes 30 – 40 minutit. Sõltuvalt masina võimsusest, teenuste hulgast ja installatsiooni variandist ( Core/GUI – mõlemil juhul näeb upgrade välja täpselt sama).

Sõltuvalt masina võimsusest võib masin olla vahetult peale upgrade mõne aja natuke aeglasem. Näiteks prekompileeritakse uuesti .NET assemblyd (mscorsw protsess, võib taustal võtta umbes alla tunnikese). WMI repodele tehakse check ja recompile (see tähendab väikest viivitust ka teenustele mis aktiivselt WMI’d kasutavad). Juhul kui Sul on masinas MS SCOM agent võib see vajada repairi (või eelnevat uninstalli ja reinstalli). Soovitav on vastav teenus ennem upgrade disableda, muidu hakatakse massivselt evente läbi protsessima ja enamus käivitatavaid monitore (scripte)  saab lihtsalt time-out’i.

Veendu et teenused töötavad kenasti – näiteks  AD tööriistada ühenduvad värske DC külge, AD masterid toimivad, DNS lahendab nimesid. AD replikatsioon töötab (dcdiag)

 

* Kõik – mulle ei meeldi kasutada nii ultimatiivset väljendit, kuna “kõik” või 100% on reaalelus praktiliselt võimatu. Ehk siis mõitame kui – “enamus”.

Monitooritud Serveri eemaldamine SCOM’ist ja Specified cast is not Valid viga.

Oletame, et server mis on SCOM agendiga monitooringu all lõpetab oma eksitentsi ja ta lülitatakse välja või VM kustutatakse. Nüüd ( parem eelnevalt) tuleks SCOMis tegelikult teha ports tegevusi, mis sõltuvad kas jõudlus/event jms andmeid on tulevikus vaja või mitte.

Kõige lihtsam on Agent Delete, KUID siin tekivad järgmised probleemid:

* Server  või mõni tema objektidest võib olla osake Distributed Application’ist. Ehk – viisakas on üle käia ka seotud DA ja parandada disain.

* Palju suurem probleem ( mille kohta on ka MS Bugi ja mis pole ka veel 2012 R2 CU2’s ära parandatud) on siis kui eemaldad mõne SQL serveri ja Sul on kasutuses SQL Action accoundid ja need accoundid on levitatud AINULT valitud SQL serveritele (mille hulka kuulub siis kustutatud server).

Avaldub bugi sel hetkel,  kui soovid kontot muuta/vaadata. Specified Cast is not valid.

image

Edasi töötades näed, et levitusloend on tühi.

image

 

Olukorrast lahendamiseks hetkel head lahendust pole.

Tuleks:

1 – Nimetada SCOM konsoolis “vigane”  Run As Account ümber.

2- Luua uus SQL Action Account sama nimega nagu ennem oli  ja kasutada sama AD kasutajanime parooli.

3- Levitada see vajalikele SQL serveritele.

4- Asendada Run As Profiles  SQL’iga seotud profiilides (või kus see kasutuses oli) vana konto uuesti loodud kontoga.

5- Kustutada vana Run As Account konto.

 

Juhul, KUI SCOM’ist eemaldatud server on võimalik veel korraks tööle panna ja lasta ennast uuesti ära registreerida, siis on võimalik eemaldada ta viisakalt Run As Account’i levitamis listist.

TallPaulF on kirjutanud selliseks eeltööks mõnusa PS scripti:

param (
[parameter(mandatory=$true)]$TargetName,
[switch]$WhatIf
)
Import-Module -Name OperationsManager
Write-Host
$Accounts=0
Get-SCOMRunAsAccount |
%{
$Acct=$_
try {
$Dist = Get-SCOMRunAsDistribution -RunAsAccount $Acct
}
catch {
Write-Host -f yellow $('WARNING: RunAsAccount "{0}" has a corrupt RunAs Distribution!' -f $Acct.Name)
}
if ($Dist.Security -eq 'MoreSecure')
{
$FoundTarget = $false
$Dist.SecureDistribution = @($Dist.SecureDistribution | %{ if ($_.DisplayName -eq $TargetName) { $foundTarget = $true } else { $_ } } )
if ($foundTarget)
{
$Accounts++
$Dist | Set-SCOMRunAsDistribution -RunAsAccount $Acct -WhatIf:$WhatIf -Verbose
}
}
}
Write-Host
if ($Accounts -gt 0)
{
if ($WhatIf)
{
Write-Host -ForegroundColor green $("$TargetName would be removed from {0} RunAsAccount secure distribution lists" -f $Accounts)
} else {
Write-Host -ForegroundColor green $("$TargetName removed from {0} RunAsAccount secure distribution lists" -f $Accounts)
}
} else {
Write-Host -ForegroundColor cyan "$TargetName was not found in any RunAsAccount secure distribution lists"
}

Kas 2012 (ja R2) hakkab rohkem valmis saama?

 

1401_admt1_png-550x0       See võib esmapilgul tunduda kohatu küsimusena, sest esimese GA’st möödub sügisel kaks aastat ja R2 on tsipake üle aasta noorem. Aga jah, kui Sinu infra on lihtne ja Sul pole tekkinud aastatega mingit kentsakat taaka vajadustest ja seostest teiste tarkvaratoodetega siis ei ole üldiselt probleeme juba esimesel päeval. Ainuke probleem võib-olla internetis leiduva dokumentatsioni ja teadmuste vähesuses. Sest, üldiselt on tehtud head tööd ta töötab.

Paraku võib-olla suuremate organisatsioonide juures vaja kasutada mingeid erifunktsionaalsusi või tööriistu, mis on disainitud eelmiste põlvkondade jaoks ja mis lihtsalt keelduvad uuel versioonil töötmast.  Üheks selliseks oli ADMT ( ehk Active Directory Migration Toolkit). ADMT on mõeldud AD objektide liigutamiseks metsade/domeenide vahel. Kõige lihtsam näide – Sinu töötaja Brasiiliast kolib Itaaliasse ja vaja liigutada tema kasutaja ja arvutiobjekt, nii et õigused ja ajalugu paika jääks. Või on vaja liita uus värskelt ostetud organistatsioon korporatsiooni AD’ga.

ADMT eelmine versioon töötas suurepäraselt senikaua, kuni domeen polnud uuendatud 2012 tasemele. Oli olemas ka hullumeelne variant migreerimise ajaks lisada 2008 Server ja domeeni taset PS abil madalamaks kruttida. See võib olla OK ühekordse migratsiooni puhul, aga igapäevaseks või sageli korduvaks tegevuseks see päris OK ei ole.

Nüüd juunis saadi siis valmis uus ADMT versioon (mis tegelikult ikka kannab 3.2 numbrit, kuna funktsionaalsus jäi samaks) mis toetab ka suurema keemiata uusi serveriversioone ja domeenitasemeid. Binaarid on otse loomulikult uued.

Dok – seal – http://www.microsoft.com/en-us/download/details.aspx?id=19188

Ja download ise  – http://connect.microsoft.com/site1164/content/content.aspx?ContentID=22983

Microsoft Message Analyzer – WoW!

image

  Nädala alguses ühte kentsakat võrguprobleemi lahendadedes komistasin juhuslikult ühe järjekordse põneva ja paljulubava tööriista otsa. Palun- tutvuge -  hardcore administraatori uus mängukaaslane – Microsoft Message Analyzer.

Alla laadida saab SIIT ja tootegrupi blogi on SIIN.

 

Ehk siis lühidalt on tegemist Network Monitori, WireSharki edasiarendusega. Ehk siis võrguliikluse (mitte ainult!)  koguja ja anlüsaatoriga. Lihtsaid võrguliikluse kogujaid on internetis saadaval ilmselt kümmneid, kuid kui sinu igapäevatöö pole just hommikust õhtuni võrgutasemel mudistamine, siis võib kogutud info reaalne sisu natuke hägusaks jääda. Network Monitori puhul aitasid välja laienduspakkidena jagatud “Eksperdid” , Message Analyseril on seda ideoloogiat edasi arendatud ja neid kutsutakse OPN Parseriteks.

Süvenedes võimalustesse on MMA ikka täiesti järgmise põlvkonna toode.

Lühidalt on MMA  järgmiste võimalustega:

  • võrgupakettide ja sündmuste (Windows event) reaalajas salvestamine
  • pakettide ja sõnumite töötlemine ja valideerimine
  • ETW sündmuste kogumine ja töötlemine
  • kirjeldavad graafikud (sügavuti mineku võimalusega)
  • sõnumite automaatne grupeerimine vestlusteks
  • erinevate logitüüpide toetamine
  • pakettide sisu (payload) renderdamine
  • stenaariumite tugi (komplekteerid just Sulle vajaminevad allikad, logid, vaated jne)
  • hullumeelselt parandatud Filtrite loogika ( + InteliSense UI)
  • Remote capture

 

Samas on ka mõned puudused:

  • ei tööta Vista põlvkonnast vanemate OS’ide peal.
  • puudub tugi võrgukaardi promiscuous modele (Kui seda on vaja siis võib logida NM abil ja analüüsida MA abil)

Jauramine SCCM Compliance Settings’itega (vol. 2)

Vahepeal lisandus eelmisele tegutsemisele veel informatsiooni.

Kui sealtoodud fiksid üldiselt lahendavad probleemid, siis hetkeks on välja koorunud üks konkreetne OS – kus ei aita ei ussi-ega-püssirohi.

Nimelt, Windows Server 2008 64-bit SP2.  Visalt tuleb evaluaatori vastus “Non-Compliant”. Sul võib olla WinRM 2 või 3, SCCM kliendi versioon misiganes, kuid tulemust pole.

Hetkelise (näiva) lahenduse annab WMI komponentide uuesti registreerimine , repositooriumi repair ja teised sarnased tegevused, kuid peale lühikest olukorra settimist on tulemus vana.

 

Tundub, et TÄPSELT sama viga on teadvustatud Windows Serve 2003/XP korral ja isegi vastav KB üllitatud (http://support.microsoft.com/kb/923850) kuid samasugust Windows 2008 / Vista põlvkonnale pole minul õnnestunud leida. Kuigi selle artiklis toodud dll’i versioonist midagi ei sõltu.

Nii et siin ka üks põhjus selle põlvkonna OS’idest loobumiseks.

Jauramine SCCM Compliance Settings’itega

Compliance settings (vana nimetusega Desired Configuration Management ehk DCM selelst ka palju viiteid “DC”le ) on suurepärane vahend auditeerimaks, et igasugused süsteemi häälestused, installatsioonid ja parameetrid on täpselt nii, nagu IT turva-, haldus- või auditi meeskond soovib. Mõningal määral saab seda teha ka Group Policy objektidega, kuid sel juhul jääb puudu võimas raportikeskkond. SCCM reportserverist võid kasvõi iga päev vastvad raportid automaatselt teele panna.

Ehk jah, CS on tööriist, mis on mõttekas endale selgeks teha ja kasutada.

Hiljuti komistasin naljaka kõrvalefekti otsa – mõningad Configuration Item’id annavad teatud juhtudel vigu. Tegemist ei olnud mingi keerulise päringu või skriptiga – lihtsalt võeti registryst teatud võtmeid ja kontrolliti nende olemasolu või vastavust etteantud väärtustele. Hmmm. uurimise käigus selgus, et Complianciga pole valesti midagi, ehk – reaallselt on vastvad registry võtmed täiesti olemas ja päritavad. REG utiliidiga käsurealt käitus päring täpselt nii nagu oodatud, kuid – SCCM klient andis visalt tulemuseks “Non-Compliant”.

Egas midagi – SCCM klient logib ohjeldamatult ( no õnneks siiski mitte ketast täitvalt) ja täpselt. Compliance Setting’u  kontrollimise sammud salvestuvad järgmistes logifaildes:

DcmWmiProvider.log , DCMReporting.log, StateMessageProvider.Log. Tegelikult on CS’iga seotud veel mõned logifailid kuid need ei paku hetkel huvi.

DCMReportingust loeme välja et Registry väärtuste lugemisel kasutatakse WMI instrumentaariumi. OK. WMI on selline asi, mis tikub omama 1001 bugi ja pidevalt katki olema. Samas eventLogis starditakse WMI ja käivitatakse päring probleemideta.

Ehk siis – proovime uuemat WMI – http://www.microsoft.com/en-us/download/details.aspx?id=34595

Selle peale teeb SCCM klient repairi ja SC Baseline muutub hetkeks ( tegelikult siis seniks kuniks pole toimunud uus kontroll)  kompatiibliks. Hmm..

Ehk siis võiks arvata et kliendis on mingi bugi – vahepeal on valja tulnud ka SCCM 2012 R2 Sp1 CU 4 -  mis küll serveritel peal, kuid kliendid pole veel kõikjal uuendatud.

Pane uuema kliendi paiga ka peale ja voilaa – Compliance jääb samuti rahule.

 

CS CI’d  isenesest laetakse  XML failidena C:\Windows\CCM\CIDownloader\DigestStore kausta.  Nende kohalejõudmise kiirendamiseks tee “Machine Policy Rretrieval and evalution” tegevusel käivitus. Sealt saab vaadata kas masinas ikka on sama sisuga CI kui serveris tehtud.

 

 

Keywords: DCM , non-compliant, registry, value.