Editarea grupurilor SCOM in XML


scom-gsx-solutions

Cateodata avem nevoie sa cream anumite view-uri care sa contina informatiile necesare pentru clienti. Se pare ca cei de la Microsoft s-au grabit putin cand au scos management pack-ul pentru Hyper-V 2012. Acest MP nu contine un grup cu obiectele de tip Windows Computers asa cum au majoritatea MP-urilor.

Din acest motiv va trebui sa cream un grup nou editand direct XML-ul fiindca editorul din GUI nu ne este util in acest caz.

Primul lucru pe care trebuie sa il facem este sa cream un grup nou si sa il salvam intr-un management pack.

Hyper-V Computers Group

Exportam MP-ul fie din Consola fie din powershell.

Cautam grupul creat dupa Display Name. Vom gasi numele in tagul de DisplayStrings.

Verificam ca avem referintele necesare pentru Windows Computer si Hyper-V Role, daca nu, le copiem din alt MP.

References

Luam ID-ul pentru Discovery si cautam din nou. Asa va arata un Grup gol in XML.

Default XML

Vom face cateva modificari acestui grup pentru a contine instantele care ne intereseaza. Inlocuim clasa default: <MonitoringClass>$MPElement[Name=”SystemCenter!Microsoft.SystemCenter.AllComputersGroup”]$</MonitoringClass>

Cu urmatoarea: <MonitoringClass>$MPElement[Name=”Windows!Microsoft.Windows.Computer”]$</MonitoringClass>

Stergem continutul tagurilor <Expression>. Stergem si commentul din dreptul tagului de deschidere din <MembershipRule>.

Clean Expression

Adaugam operatorul Contains si clasa respectiva, in acest caz Hyper-V.

Relatia dintre clasele Windows.Computer si HyperV.ServerRole este una parent-child. Practic spunem in expresia noastra ca vrem un grup cu toate obiectele de tip Windows Computer ce gazduiesc si clasa de HyperV.Role.

La sfarsit va arata asa.

finished

Importam management pack-ul inapoi. Inainte de a se importa se va face validarea MP-ului asa ca daca sunt gresezi de sintaxa nu se va importa.

Asteptam ca procesul de group calculation sa se termine, apoi putem folosi grupul pentru view-uri, overrides, etc.

Enjoy.

 

Referinte:

https://msdn.microsoft.com/en-us/library/ff472337.aspx

Operations Manager Failed to Access the Windows Event Log – Hyper-V 2008/2012


scom-gsx-solutions

A trecut ceva timp de cand nu am mai pus ceva pe Blog dar astazi se schimba lucrurile. O sa scriu despre o problema care apare atunci cand avem un management pack pentru Hyper-V 2008 si importam si versiunea pentru Hyper-V 2012, side by side. Problema este generata de faptul ca management pack-ul de HV 2008 targeteaza incorect clase de HV abstracte (clase generale) care se aplica implicit si la management pack-ul de HV 2012. Mai exact are cateva monitoare definite sa afle Health State-ul anumitor componente. Si face asta verificad event log-ul pe targetul respectiv. Problema este ca la Hyper-V 2012 acele loguri un exista.

In acest caz avem 2 solutii la indemana. Fie dezactivam monitoarele respective pentru serverele ce ruleaza 2012, fie cream niste ‘dummy event logs’ pe serverele afectate. Mie personal nu imi place varianta B cu toate ca este perfect valida.

Alertele generate vor fi:

HV_1

In cazul de mai sus vedem ca verifica Log-ul imaginar ‘Microsoft-Windows-Hyper-V-Network-Admin’ dar vor fi si alte alerte generate de acelasi monitor ‘Microsoft-Windows-Hyper-V-Image-Management-Service-Admin’.

Acum avem ceva informatii. Now we have to see which Monitors look for those Event Logs. Pentru asta folosim powershell:

$HyperVLibraryMP = Get-SCOMManagementPack -DisplayName ‘Microsoft Windows Hyper-V 2008 Monitoring’

$Hyper2008Mon = Get-SCOMMonitor -ManagementPack $HyperVLibraryMP

$AlertImage = $Hyper2008Mon | Where-Object {$_.Configuration -match ‘Microsoft-Windows-Hyper-V-Image-Management-Service-Admin’}

$AlertImage | fl name, displayname

$AlertNetwork = $Hyper2008Mon | Where-Object {$_.Configuration -match ‘Microsoft-Windows-Hyper-V-Network-Admin’}

$AlertNetwork | fl name, displayname

Rezultatele vor fi urmatoarele:

HV_2

Acum stim ce monitoare trebuiesc dezactivate. Pasii sunt urmatorii:

  1. Authoring > Change ScopeHV_3
  2. Cautam dupa ‘hyper-v virtual’ > Selectam clasele de mai sus > OK.HV_4
  3. Expandam pana ajungem la monitoare.
  4. Mai sus vedem monitoarele ce trebuiesc dezactivate.
  5. Deschidem Properties pentru primul monitor si confirmam ca incearca sa verifice Log-ul respectiv.HV_5
  6. Facem Overrides > Disable Override > For all objects of another class.HV_6
  7. Cautam dupa ‘Hyper-v’ si selectam clasa de Hyper-V 2012 de mai sus.
  8. Repetam acelasi process pentru celelalte 5 monitoare ramase. Mai jos cateva screenshot-uri.HV_8HV_9

Dupa ce am dezactivat monitoarele, trebuie sa facem Reset Health State pentru serverele afectate. In cazul meu au fost multe.

Am scris un script simplu care face reset pe monitoarele afectate.

HV_10

Accepta ca parametrii numele alertei care in cazul nostru este ‘Operations Manager Failed to Access the Windows Event Log’ si Resolution state-ul care in cazul meu este 0 (New). Poate fi orcare din codurile aferente de exemplu Closed 255.

Output-ul arata cam asa in ISE:

HV_11

Dupa ce am resetat monitoarele nu mai avem alerte. Script-ul in format text mai jos:

Import-Module OperationsManager

$AlertNameInput = Read-Host -Prompt “Please enter the alert name”

$AlertReolutionInput = Read-Host -Prompt “Please enter the alert resolution state”

$Alerts = Get-SCOMAlert -Name $AlertNameInput -ResolutionState $AlertReolutionInput

if ($Alerts){

Write-Host -BackgroundColor Yellow -ForegroundColor Black “Below are the alerts found:”

$i=0;$n=0;

$Alerts | % {$i++;Write-Host -ForegroundColor Yellow “$i`t`t$($_.TimeRaised)`t`t$($_.Name)”}

Write-Host -BackgroundColor Yellow -ForegroundColor Black “Below are the Monitors identified:”

foreach ($Alert in $Alerts){

$Monitor = $Alert.MonitoringRuleId | Get-SCOMMonitor

if($Monitor){

$n++;Write-Host -ForegroundColor Yellow “$n`t$($Monitor.DisplayName)`t$($Monitor.GetManagementPack())”

$Instance = Get-SCOMClassInstance -Id $($Alert.MonitoringObjectId)

Write-Host -ForegroundColor Yellow “Resetting the `’$($Monitor.DisplayName)`’ for $($Instance.DisplayName)”

$Instance.ResetMonitoringState($Monitor) | Select-Object -ExpandProperty Status | Format-Table -AutoSize

Write-Host -ForegroundColor Yellow “Done”

}

}

}

else{Write-Host -ForegroundColor Yellow “No alerts were found using the inputted criterion”}

AD Initial Sync Requirement


Active-Directory-logo

AD Initial Sync Requirement

Am observat ca acest comportament nu este cunoscut de multi administratori, asa ca m-am gandit sa scriu ceva despre asta. Pentru cei ce stiu la ce se refera va fi doar un refresher.

Acest comportament este mai comun in mediile de testare deoarece DC-urile si topologia sunt modificate in mod frecvent. Intr-un mediu de productie unde un DC are mai multi parteneri de replicare de unde se poate replica, este mai putin probabil dar nu imposibil.

‘Initial Sync Requirement’ este o functionalitate utila, implementata pentru a se asigura functionalitatea rolurilor FSMO. Nu voi mai descrie ce face fiecare in parte, asta puteti afla aici: http://technet.microsoft.com/en-us/library/cc961939.aspx

Ce inseamna asta. Inseamna ca intr-un domeniu in care avem cel putin 2 domain controllere, in momentul cand porneste un DC care tine un rol FSMO, acel domain controller nu poate oferi serviciile specific rolurilor FSMO pana nu se replica naming contextul ce hosteaza acel rol FSMO.

De exemplu, sa presupunem ca rolul de PDC este tinut de DC1.

DC1 DC2 DC3  DC4

Atat timp cat nu se replica cu nici un partener, orice functionalitate legata de rolul de PDC nu va putea fi efectuata.

In versiunea originala de Windows Server 2003, dupa ce se restarta un DC, acesta incerca sa replice naming contextual de la un DC aflat in acelasi site cu el. Daca nu exista un DC care era in acel site, astepta pana se consuma intervalul de replicare specificat pe connection objectul cu site-ul respectiv (min 15 min), timp in care serviciile FSMO nu puteau fi utilizate.

In Windows Server 2003 SP1, s-a schimbat procesul, si atunci cand un DC porneste incearca sa replice de la orice partener de replicare disponibil, indifferent daca se afla in acelasi site sau nu.

Exista un override in registry care poate dezactiva ‘initial sync requirement’ pe care il puteti folosi daca stiti cu siguranta ca partenerii de replicare nu mai sunt disponibili. De exemplu DC-urile cu care se replica erau VM-uri si au fost inchise fara metadata cleanup, si acum am ramas cu un DC disponibil. Mai jos aveti cheia, valorile fiind 0 sau 1.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]

“Repl Perform Initial Synchronizations”=dword:00000000

Referinte:

http://support.microsoft.com/kb/305476

http://support.microsoft.com/kb/910202

 

 

 

Error installing SQL 2012 on Windows Server 2008 R2 Core Edition


sql2012 logo

Error installing SQL 2012 on Windows Server 2008 R2 Core Edition

Am incercat urmez pasii din cartea de la Microsoft 70-462 pentru instalarea de SQL 2012 pe un Windows Server Ccore 2008 R2.

Pe scurt montezi imaginea cu SQL 2012, si din CMD se ruleaza setup.exe cu ceva parametrii.

Pentru toate optiunile consultati http://msdn.microsoft.com/en-us/library/ms144259.aspx#Install – Install SQL Server 2012 from the Command Prompt.

Comanda arata ceva de genul:

Setup.exe /qs /action=install /features=sqlengine,is,conn /instancename=mssqlserver /updateenabled=False /sqlsysadminaccounts="Contoso\Kim_Akers" /Iacceptsqlserverlicenseterms

SQL 2012 poate fi instalat folosind linia de comanda dar pe un server core este obligatoriu folosirea parametrului ‘/qs’ (quiet simple).

Dupa cum spuneam foloseam un mediu de testare si nu am stat sa fac toate update-urile asa ca nu stiu daca acest comportament se intampla si pe o masina patch-uita la zi.

Versiunea de OS folosita:

SQLCore version

Dupa ce rulam comanda imi afisa eroarea de mai jos:

SQLCore 2

Calea catre log este %ProgramFiles%\Microsoft SQL Server\110\Setup Bootstrap\Log

SQLCore error

Nici logul acesta nu a fost de ajutor. Raspunsul l-am gasit pe forumuri mai exact aici.

Se pare ca problema ar fi din cauza ca lipseste o cheie din registrii care in mod normal ar fi prezenta. Cheia in cauza este ‘Uninstall’. Dupa ce am verificat, intradevar lipsea.

SQLCore reg

Imediat dupa ce am creat cheia respective am rulat din nou setup-ul si a mers fara probleme.

SQLCore 1

the end.

 

 

Lync 2013 Windows Fabric Quorum Model


lync-logo2013

Lync 2013 Windows Fabric Quorum Model

First off, in Lync 2013 s-au produs câteva modificări semnificative referitor la modul cum funcționează comunicarea intre serverele de Front End si cele de Back End. Microsoft recomanda mai nou ca Front-End Pool-ul sa conțină minim 3 servere de Front End. Care ar fi motivul pentru aceasta recomandare? Răspunsul este Windows Fabric.

Info: Acest serviciu se instalează automat cu setup-ul de Lync 2013. Exista un pachet care se găsește pe kitul de Lync 2013 in /Setup/amd64/Windowsfabric.msi .

Windows Fabric este un concept relativ nou, introdus cu 2008 R2 aducând numeroase îmbunătățiri de scalabilitate si cel mai important lucru de menționat in contextul serverelor de Lync – este folosit la replicarea informațiilor intre serverele Front End si menținerea copiilor de User Groups. Ce reprezintă User Groups? Este un concept nou introdus odată cu Lync 2013 si funcționează împreună cu Windows Fabric oferind copii pe celelalte Front-End-uri. Procesul este denumit „Brick Model” si a permis posibilitatea adăugării unui număr de 12 servere FE intr-un Front-End Pool fata de 10 servere cat era limita la Lync 2010 si a eliminat scenariile de „bottleneck” pe serverul de Back-End. Mai multe detalii despre Windows fabric http://msdn.microsoft.com/en-us/library/ee790974(v=azure.10).aspx.

In Lync 2010 toate schimbările făcute de un Lync User (schimbarea statusului, contactelor, Meeting-urilor, etc.) conduceau la actualizarea bazelor respective pe serverul de Back-End, care puneau serverul sub o încărcare considerabila. In Lync 2013 mai nou aceste informații sunt actualizate in real-time pe un Front-End server desemnat ca ‚Primary’ pentru copiile de User Groups si se actualizează si pe serverul de Back-End ca si backup, prin procesul de scriere Lazy Write.

PoolComparison

Pe orice server Front End de Lync 2013 exista acum 2 instanțe SQL RTCLOCAL si LYNCLOCAL, fata de singura instanța RTCLOCAL pe Lync 2010. Noua instanța LYNCLOCAL conține baza de date LYSS care este folosita de către serviciul Lync Storage Service (LYSS).

Info: Pe edițiile de Lync 2013 Standard instanța se numește RTC, doar pe Enterprise se numește RTCLOCAL.

Lync Databases

Lync Databases2

Info: Exista o comanda noua in Lync 2013 (Get-CSPoolFabricState) care se poate folosi pentru a afla mai multe detalii referitor la cele de mai sus. Descriere comenzii spune totul: „Returns the Windows Fabric state for a Lync Server 2013 pool. Windows Fabric is a Microsoft technology used for creating highly reliable, distributable, and scalable applications. This cmdlet was introduced in Lync Server 2013.

By default sunt definite Data Collector Sets pentru urmărirea tuturor tranzacțiilor efectuate de către Windows Fabric.

LyncDataCollector

Acestea pot fi administrate folosind fișierele .bat de mai jos sau direct din Performance Monitor. Recomandat ar fi sa nu avem nevoie sa umblam la aceste setări dar este bine sa știm ca exista.

LyncFabricTrace

LyncFabricTrace1

LyncFabricTrace2

Revenind la Lync 2013, mai exact la Quorum, atunci când avem 3 Front-End-uri intr-un Pool, si unul devine indisponibil, atunci cele doua preiau încărcarea (folosind un load balancer) iar daca cel indisponibil era desemnat ca Primary in acel pool, urmatorul ii va lua locul in funcție de ordinea stabilita. Atunci când 2 din cele 3 servere devin indisponibile vom avea o problema. Exista un tabel făcut de Microsoft care arata cate Front-End-uri trebuie sa rămână disponibile într-un Pool pentru a putea deservi clienții in mod normal.

Numărul   total de Front-End-uri in Pool Numărul de   Front-End-uri care trebuiesc sa fie funcționale
1-2 1
3-4 2
5-6 3
7-8 4
9-10 5
11-12 6

Daca numărul serverelor scade sub cel de la menționat mai sus atunci serverele care rămân  „up” vor intra in Survivability Mode si se va vedea următorul event in Lync Log pe acele servere de Front End.

LyncEvent32163

Info: Eventurile care se refera la Windows Fabric sunt 32163, 32170 si 32173.

In cazul de mai sus trebuie rulata comanda menționata si in log, respectiv:

Reset-CSPoolRegistrarState

Daca nu se menționează alți parametrii, ceasta comanda resetează serviciul Windows Fabric Service (FabricHostSvc) si serviciul de Lync Registrar (RtcSrv). Același lucru cu

Reset-CSPoolRegistrarState –ResetType ServiceReset

Mai sunt trei tipuri de ‚reset’:  QuorumLossRecovery, FullReset, MachineStateRemoved.

QuorumLossRecovery – încarcă informațiile de pe serverul de Back-End.

FullReset – încarcă informațiile de pe serverul de Back-End si reconstituii bazele de pe serverele de Front-End. Acest tip de reset poate dura ceva timp si va avea un impact semnificativ asupra resurselor.

MachineStateRemoved – pentru a rula tipul acesta de reset este nevoie de un parametru adițional –MachineFqdn, care practic scoate un server de Front End din Pool atunci când serverul este într-o stare iremediabila.

In cazul in care avem doar 2 severe intr-un Pool se recomanda următorii pași:

Daca trebuie sa opriți ambele servere de Front End, se recomanda repornirea simultana a ambelor servere. Când se pornesc, din nou trebuie pornite simultan. Daca nu pot fi pornite simultan se recomanda pornirea in ordinea inversa fata de ordinea de oprire.

Referințe:

Lync Server 2013: Brick Model – http://windowsitpro.com/lync/lync-server-2013-brick-model

Lync Server 2013: Windows Fabric & User Groups – http://windowsitpro.com/lync/lync-server-2013-windows-fabric-user-groups

Topologies and Components for Front End Servers, Instant Messaging, and Presence – http://technet.microsoft.com/en-us/library/gg412996.aspx

ACS – ‘The operation has timed out’


scom-gsx-solutions

ACS – ‘The operation has timed out’

Daca se intampla sa avem o baza de date ACS mai mare uneori la executarea anumitor raporte se poate primi un mesaj de time out.

TheOperationTimedOut

parametrii implicate pentru modificarea intervalului nu se pot administra din SCOM ci din Reporting Services, mai exact din fisierele de configurare sau individual pe raport.

Mesajul de timeout poate fi generat de mai multi factori pe care am sa-i descriu pe scurt.

Un server de Reporting Services are doua valori pentru timeout, respective un ‘Query timeout’ si ‘Report Execution timeout’.

Query timeout

Reprezinta timpul (numarul de secunde) de asteptare al serverului de RS pana primeste un raspuns de la baza de date interogata.

Report Execution timeout

Reprezinta numarul maxim de secunde de procesare al raportului inainte ca acesta sa fie oprit.

In majoritatea cazurilor problema este legata de timpul de asteptare pentru a primi raspunsul la un query, deci primul caz. Daca se modifica intervalul de ‘query timeout’ atunci trebuie sa ne asiguram ca intervalul generarii raportului este mai mare.

Ca sa modificam setarile de mai sus trebuie sa navigam in folderul de RS. Calea default :

\Program Files\Microsoft SQL Server\MSRS1111.MSSQLSERVER\Reporting Services\ReportServer

Acolo vom avea un fisier rsreportserver.config pe care il deschidem cu un editor. Cheia care ne intereseaza este  <Add Key=”DatabaseQueryTimeout” Value=”120″ />. Aceasta este valoarea default, 120 de secunde. Daca punem valoarea 0 atunci niciodata nu va da time-out, ceea ce nu este recomandat.

O lista completa cu parametrii si valorile se gaseste pe http://technet.microsoft.com/en-us/library/ms157273.aspx .

Dupa ce se modifica parametrul de mai sus faceti restart la serviciul SQL Server Reporting Services (MSSQLSERVER) pentru a se aplica modificarile.

In acceasi locatie mai avem un fisier web.config. Cheia pe care o cautam se numeste <httpRuntime executionTimeout=”9000″ /> si reprezinta timpul de executare al raportului dupa care va da time out (2.5 ore).

executionTimeout=”9000″ este un parametru in cheia httpRuntime la care se pot adauga si alti parametrii cum ar fi:

<httpRuntime
   apartmentThreading = "[True|False]"
   appRequestQueueLimit = "number"
   delayNotificationTimeout = "number"
   enable = "[True|False]" 
   enableHeaderChecking = "[True|False]" 
   enableKernelOutputCache = "[True|False]" 
   enableVersionHeader = "[True|False]" 
   encoderType = "string"
   executionTimeout = "number" 
   maxQueryStringLength = "number"
   maxRequestLength = "number" 
   maxUrlLength = "number"
   maxWaitChangeNotification = "number" 
   minFreeThreads = "number" 
   minLocalRequestFreeThreads = "number" 
   relaxedUrlToFileSystemMapping = "[True|False]"
   requestLengthDiskThreshold = "number" 
   requestPathInvalidCharacters = "string"
   requestValidationMode = "[2.0|4.0]"
   requestValidationType = "string"
   requireRootedSaveAsPath = "[True|False]"
   sendCacheControlHeader = "[True|False]" 
   shutdownTimeout = "number"
   useFullyQualifiedRedirectUrl = "[True|False]" 
   waitChangeNotification = "number" />

Lista completa cu parametrii si descrierea lor aici: http://msdn.microsoft.com/en-us/library/vstudio/e1f13641(v=vs.100).aspx

Dupa ce se modifica parametrul de mai sus da-ti un restart la serviciul SQL Server Reporting Services (MSSQLSERVER) pentru a se aplica modificarile.

Se mai pot modifica intervalele individual (per raport) folosind Report Builder.

reportbuilder1

Deschidem raportul respective si vedem proprietatile de pe DataSet.Timeout

—Marius Ene