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


Editarea grupurilor SCOM in XML


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.


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.


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.




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

ACS – ‘The operation has timed out’


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.


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 .

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:

   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:

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.


Deschidem raportul respective si vedem proprietatile de pe DataSet.Timeout

—Marius Ene

ACS query – Access Denied


ACS query – Access Denied

Daca vrem sa configuram Audit Collection Services de la System Center Operations Manager 2012 (R2 included) va trebui sa configuram un filtru (collector side filter) pentru a izola evenimentele care ne intereseaza versus evenimentele care nu prezinta interes (nosie events). Aceste query-uri sunt customizate in functie de necesitati. De exemplu pentru a pune la punct un deployment optimizat pentru ACS ar trebui identificate exact eventurile ce prezinta interes in urma unui audit de securitate, precum si perioada de retentive si rezilienta sistemului de colectare (serverul de management pe care ruleaza ACS). Mai trebuiesc luate in considerare aspecte pe care nu le voi mentiona aici. De exemplu, numarul serverelor monitorizate, incarcarea pe servere, CPU/IOPS/storage, redundanta, etc.

Daca instalam ACS pe serverele de management iar baza de date (OperationsManagerAC) nu este colocata pe acestea ne vom confrunta cu o problema.


Acum daca primiti mesajul de mai sus probabil ve-ti verifica daca aveti credentialele necesare, sau daca ati facut RunAs Administrator…

Problema este alta. Trebuie vazut contul sub care ruleaza serviciul de ACS, care by default este NETWORK SERVICE.


Apoi trebuie sa verificam permisiunile in registrii pentru serviciul respectiv.


Calea dupa cum se vede si in imagine este :


Acolo este o cheie DbQueueQuery cu valoarea default select * from AdtsEvent. Acasta valoare se poate afla folosind parametrul /getquery si eventual /collectionserver  cand avem mai multe servere de management pe care rulam ACS.

Verificam Permissions pe cheia Parameters.



Observam ca nu poate scrie in acel container. Punem Allow pentru Set Value si mai incercam odata.


*Prima comanda a fost data cand nu existau permisiunile de set value.


The Microsoft Exchange Monitoring Correlation service cannot connect to RMS


The Microsoft Exchange Monitoring Correlation service cannot connect to RMS

Daca instalam management pack-ul de Exchange 2010 pe un server care nu este un RMS/MS va trebui sa editam un fisier de configurare pentru a specifica calea corecta catre serviciul OpsMgr SDK.

MSex corelation

Fisierul se gaseste in urmatoarea locatie by default daca nu ati specificat o alta cale de instalare a management pack-ului de Exchange 2010:

C:\Program Files\Microsoft\Exchange Server\V14\Bin\Microsoft.Exchange.Monitoring.CorrelationEngine.exe.config


Daca deschidem fisierul va arata cam asa:


modificati sau adaugati daca este cazul o cheie similara dar cu valoarea serverului RMS/MS.

Reporniti serviciul de Microsoft Exchange Monitoring Correlation si acum ar trebui sa se connecteze cu success.

Tot aici se dezactiveaza modul de corelare al evenimentelor folosit in Management pack-ul de Exchange 2010, modificand valoarea proprietatii AutoResolveAlerts la False.