Tag Archives: SCOM 2012

The Health Service cannot verify the future validity of the RunAs account

The Health Service cannot verify the future validity of the RunAs account DOMAIN\account for management group MG due to an error retrieving information from Active Directory (for Domain Accounts) or the local security authority (for Local Accounts). The error is The network path was not found.(0x80070035).

How many times we’ve see this error?


Sometimes with multiple domains you will see something like the RPC server is unavailable and you will probably try to find if there is any active directory communication issue.

Don’t waste your time. All you need to do is make sure that you have configured the correct DNS Suffixes on the virtual network card.


Either one of the highlighted options work fine. Just have to make sure that you append the correct DNS suffix on that Health Service.

After doing the change, restart the Microsoft Monitoring Agent and check the Operations Manager log for the following event:



Putting SCOM instances in maintenance mode via PowerShell

Sometimes you don’t want to put the whole server object in maintenance mode and you just need the child component that you are working on.

There are a couple of ways to do this from the SCOM console.

You can open a view that is targeting that specific class, for example the SQL DB class, and simply right click and set the maintenance mode.


After doing so, if you navigate back to the Database Engine view, you will see those components put into maintenance mode while the DB Engine itself is being monitored as usual.


If you to put in maintenance mode a class that is not exposed through any built in views you can use the Discovery Inventory to search for objects of a specific class.

For demonstration purposes in the following screenshot we look for the SQL database class.


There is also another way to configure maintenance mode via scripting. Here is how you can do this via PowerShell:

Import-Module OperationsManager

$SCOMCredentials = Get-Credential -Message  “Input your SCOM credentials”

New-SCOMManagementGroupConnection -ComputerName SCOM01.mariusene.com -Verbose

$DBclass = Get-SCOMClass | Out-GridView -PassThru -Title “Select the SCOM class”

$DBInstances = Get-SCOMClassInstance -Class $DBclass | Out-GridView -PassThru -Title “Select the instances to enable Maintenance Mode”

Start-SCOMMaintenanceMode -Instance $DBInstances -EndTime (Get-Date).AddDays(1) -Comment “Maintenance mode set by PowerShell script” -Reason PlannedOther -Verbose


In the above code, be sure to replace SCOM01.mariusene.com with your SCOM management server. After running the above code, you will be prompted for credentials. After that you will see a window that shows all classes.

Use the Filter to look for the correct class and click OK.


Next, we select the instances by multi-select then clicking OK.


After selecting OK, you will see that the Objects have been put in Maintenance Mode.



Now in order to remove from maintenance mode via PowerShell you can use something similar:

$MMInstances = Get-SCOMMaintenanceMode  | select * | Out-GridView -PassThru

$MMInstances | % { Get-SCOMMaintenanceMode | ? {$_.MonitoringObjectId -eq $_.MonitoringObjectId} | Set-SCOMMaintenanceMode -EndTime (Get-Date) -Verbose  }

After running the code, you will see a window with the instances that are in maintenance mode. Select the ones that you want to remove from maintenance mode.


The output will be like this:


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


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:


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:


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.


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:


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:”


$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


$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”}

Instalarea agentilor SCOM in reteaua DMZ


Instalarea agentilor SCOM in reteaua DMZ

Pentru a avea o imagine de ansamblu cat mai completa a unei ‘aplicatii distribuite’ cum ar fi Exchange sau Lync, atunci trebuie sa avem posibilitatea de a monitoriza si serverele aflate in DMZ, acestea de obicei ruland roluri de Edge.

In Scom 2012 schimbul de informatii dintre serverul de management (scom) si agenti (sistemele monitorizate) trebuie sa se faca intr-un context securizat folosind Mutual Authentication (http://technet.microsoft.com/en-us/library/cc961730.aspx). Atunci cand si serverul de monitorizare si sistemele se afla in acelasi domeniu sau forest procesul este nativ folosind autentificare Kerberos V5. Cand serverul si sistemul nu sunt in acelsi domeniu/forest/trusted realm trebuie folosit un alt sistem care utilizeaza mutual authentication. Varianta ‘oficiala’ si cea mai eleganta ar fi folosirea unui server Gateway (http://technet.microsoft.com/en-us/library/hh212823.aspx). Dar daca nu avem trebuie sa ne descurcam si fara.

Vom folosi certificate  TLS si astfel procesul de autentificare se va efectua prin MTLS.

Cum facem…

Ne asiguram ca si serverul de management (SCOM) cat si sistemul sau sistemele monitorizate folosesc acelasi Root Certificate Authority. Importam certificatele Root CA pe server si sistemele ce urmeaza sa fie monitorizate. Pe serverul de RMS (2007) sau/si serverele MS (2012) navigam la pagina certsrv a autoritatii configurate sa emita certificate in domeniul respectiv. Selectam Download a CA certificate, certificate chain, or CRL, apoi Download a CA certificate, certificate chain. Va descarca automat un certificat certnew.p7b pe care il salvam intr-o locatie la alegere (ex. Desktop).

Odata salvat, deschidem un MMC si importam snapin-ul pentru Certificates (Local Computer), navigam la Trusted Root Authorities si dam import certificatului salvat anterior.

So far so good…

Acum trebuie configurata Autoritatea de Certificate (issuing CA) sa suporte certificate pentru SCOM. Mai exact sa facem un template pentru emiterea unui certificat compatibil cu “nevoile” serverului de scom pentru a comunica cu agentii.

Ne logam cu credentialele necesare pe autoritatea de certificate (enterprise CA) si dechidem mmc pentru Certificate Templates. Duplicam template-ul pentru Computer si denumim corespunzator template-ul. Selectati 2008 (V3) dar ca sa fiti siguri de functionalitate mergeti pe variant de 2003 (V2). Ajustati validiatatea certificatului, la Request Handling bifati Allow private key to be exported. Poi apasam tabul de Subject Name si selectam Supply in the request pentru a introduce datele manual cand facem cererea. Va aparea un mesaj de Warrning, il puteti ignora, vom modifica ACL-ul pe Template imediat. Apasam tabul de Security, si permiteti Enroll si Autoenroll pentru urmatorii UPNs Authenticated users, Domain Admins, Domain Computers, Enterprise Admins. Apply si OK.

In certsrv.msc expandam Certificate Templates, click dreapta, New, Cetificate Template to issue si selectam Template-ul corespunzator. Ne asiguram ca informatia (noul template disponibil) s-a replicat pe toate DC-urile si folosim Gpupdate /force sa aplicam noile configurari.

De pe serverul de management verificam ca template-ul este disponibil. Navigam la pagina certsrv a autoritatii emitente, selectam Advanced Certificate Request si vedem daca apare si noul template.

Daca nu aveti SSL configurat pe pagina de certsrv si va apare mesajul urmator:

In mod normal trebuie configurat accesul SSL pe pagina respectiva, dar daca sunteti mai ‘lazy’ ….

Exista un workaround pentru asta, destul de rapid. Adaugati site-ul certsrv la Trusted sites. Selectati Custom Level si faceti Enable la setarea de mai jos:


Data viitoare cand accesati pagina o sa va intampine o casuta de dialog, apasati Yes.

Acum ca nu mai apare eroarea respectiva putem sa cerem certificatul selectand template-ul corespunzator.

In campurile Name si Friendly Nname completam FQDN-ul serverului de management, si selectam Mark key as exportable (foarte important).

Acelasi lucru facem si pe serverul aflat in DMZ, doar in dreptul campurilor Name si Friendly Name completam numele serverului FQDN .

Ca sa verificam ca importul este correct, deschidem MMC, User Certificatets, personal si acolo ar trebui sa fie un certificate emis. Deschidem proprietatile certificatului si verificam tabul Certification Path ca toata ierarhia de certificate sa fie in regula (trusted).

Urmatorii pasi trebuiesc facuti pe serverele de management si sistemele din DMZ.

MMC, Certificates, User Certificates, Personal, Certificates si da-ti export pe noul certificat instalat. Selectati sa exportati cheia privata. Nu bifati nimic in urmatoarea fereastra, next, setati o parola si salvati sub un nume corespunzator sub extensia .pfx.

Instalam manual agentii de scom pe serverele din DMZ. Verificam ca serverul scom sacomunice cu agentii din afara domeniului (Administration, Settings, Security sa nu fie reject selectat)


Acum trebuie folosit un tool MomCertImport.exe care se gaseste in \SUPPORTTOOLS\AMD64 de pe imaginea installerului SCOM 2012. Acest tool trebuie fie copiat local pe fiecare server fie facut acesibil in retea pentru a fi utilizat. Rulam aplicatia iar ca parametrii specificam calea catre .pfx.


Dupa ce am executat comanda restartam serviciul de management scom pe fiecare masina inclusive pe serverele SCOM (net stop healthservice && net start healthservice).

Asteptati cateva minute (3-10). Daca in logul OperationsManager nu apare ca fiind stabilita comunicarea, mai restartati odata serviciul de health dar doar de pe serverele care trebuiesc monitorizate.

Daca apare aceasta eroare, trebuie sa dati ‘approve’ agentului in scom.


Verificati in Administration>Device Management>Pending Management si dati ‘approve’ agentului.

Dupa ce ati dat ‘approve’ verificati din nou Event Log-ul .


SCOM Event ID 10830, Health Service Modules error


SCOM Event ID 10830, Health Service Modules error

Acum câteva săptămâni m-am lovit de o problema care mi-a dat ceva de furca… O eroare care apare din minut in minut.

Poate au mai întâlnit-o si alții, dar din ce soluții am găsit pe net majoritatea ziceau sa refaci baza, restore, flush cache, etc,  si alte povesti de genul asta.

Abia acum scriu despre asta pentru ca am așteptat sa vad daca reapare problema dar totul este in regula acum.

Eroarea respectiva arata cam așa:


Ok , deci avem un ID pentru regula de colectare, numele bazei afectate, tabelul, coloana si de la ce e conflictul, adică ‚FOREIGN KEY constraint’.

Prima data sa vedem ce este afectat. Trebuie sa identificam regula menționata in mesaj. Deschidem o consola de PS cu modulul de SCOM importat.

Get-SCOMRule -Id 4fc013b2-aa11-b2d2-ec51-b198640fae00 | fl name, id, displayname


OK, deci acum știam ce este afectat de aceasta eroare.

Mai departe sa vedem in baza de date mai multe detalii. Navigam ‚bătrânește’ in baza operaționala  OperationsManager, tabelul dbo.BaseManagedEntity, coloana BaseManagedEntityId, asa cum scria in mesajul de eroare


Facem click dreapta pe dbo.BaseManagedEntity si selectam Design. Apoi selectam Relationships.


Apare fereastra de Foreign Key Relationships si verificam sa fie selectata rubrica care ne interesează, in acest caz FK_AlertBasedManagedEntity. Apoi deselectam FK constraint după care salvam.


Pe scurt Foreign Key constraint asigura relaționarea intre tabele, coloane, grupuri de coloane etc.\

Mai multe detalii despre Foreign Key constraint :


Atenție! Acest mod de funcționare nu este recomandat in producție pentru ca nu se mai asigura consistenta datelor, dar având in vedere ca știam despre ce date este vorba si ce presupunea modificarea respectiva am ales sa o configurez astfel.

După dezactivarea setării de foregin Key constraint normal ca datele (alertele) au putut f introduse baza de date.

După o perioada de aproximativ 15 minute am reactivat opțiunea de FK constraint si workflow-ul a revenit la normal.

Pana in prezent nu a mai apărut aceasta eroare.


Eroare la importarea fisierului .adm ( Error 51 : Unexpected keyword )


ADM import fail (The file cannot be loaded)

O chestie de care m-am lovit la un moment dat cu SCOM 2007 R3 speram sa se fi rezolvat pentru SCOM 2012/SP1. Se pare ca nu.

Ideea este ca dupa ce urmezi Wizard-ul de Configure Client Monitoring, adica ‘asta’…


..totul merge ok si iti configureaza share-ul unde sa tina rapoartele si informatiile cu erorile de pe clienti, si iti exporta un template de Group Policy adm (nu ADMX desi se poate converti folosind ADMX Migrator sau altceva…).

Acest template se importa pe domain controller pentru a configura setarile de ‘error reporting’ pe clienti prin Group Policy. Acest tip de configuratie se numeste AEM (‘agentless exception monitoring‘) deci nu foloseste agenti. Acest tip de configuratie consuma mai multe resurse decat ‘agent based’ monitoring.

Si iau frumos fisieru, intru pe DC, scriu gpedit.msc, click dreapta pe Administrative Templates si …..


Urat …


Instalati un utilitar de genul Notepad++ , editati fisierul adm, mergeti la liniile respective, si veti gasi calea cate serverul de SCOM este scrisa pur si simplu, fara ghilimele. Sunt cam patru linii unde trebuie incadrata calea in ghilimele si asta este tot.


Apoi o sa gasiti setarile urmatoare in GPO pe orice domain controller dupa ce replicarea a ajuns la convergenta…


Iar in SCOM in tab-ul de Monitoring , Agentless Exception Monitoring…