LepideAuditor Suite

The Enterprise IT “Swiss army knife”

I’ve recently had the chance to work with the newest version for LepideAuditor Suite which is a comprehensive tool that does more than the name states (auditing). Of course out of all the targeted products I chose to focus on Active Directory, Group Policy and Exchange 2013.


I am not going to go over the installation part because it’s pretty straight forward and Lepide already covers well all the installation steps involved.

Active Directory Auditing

The LepideAuditor for Active Directory comes with a built in Active Directory Health Monitor Dashboard view and integrated Backup and Restore solution. So this is something I really like; having not only audit information but also a view of the overall health and performance history of the AD environment and also the possibility to quickly restore from backup anything related to Active Directory. That is nice!

The first dashboard that opens up shows an overview of the changes in your environment at a glance.


In order to audit logon/logoff events in your environments there are some preliminary steps to configure. For this you can follow the steps described in this article which covers everything very well:


Once you have logon auditing enabled you can see for example when a User has logged on, from where and the type of logon that was performed. See below an example:


Another useful audit report is the Failed Logon report. Here you can see not only the number of failed logon attempts but also the reason why it failed. For Auditors this is the kind of information they are interested in. Below you can see an example:


You can check the uses that were created during a specified period of time. You can see an example below.


One of my favorites when tracking down a “resource access” issue or a “did not receive some email” issue is to see when Group membership was modified. For me this is very useful and I am sure that for some of you as well.


You can even monitor DNS changes and track down what happened to each individual DNS record.


Above you can see the typical STS record created for ADFS. And that is not all;


You can even see tombstoned DNS records! I remember having to remove some lingering objects related to tombstoned DNS records. This tool would have been really useful back then.

GPO Auditing

Looking into the GPO monitoring capabilities and available reports I must say I was impressed with the amount of built in Audit Reports. In a large environment with hundreds of Group Policy Objects where multiple Domain Admins (or delegated GPO admins) manage the settings, it can get hard to keep track of who changed what and when. So a good GPO auditing tool is more than welcomed in this case.

The Lepide GPO Auditor comes with the built in backup feature which can be extremely useful for restoring previous working GPOs to their initial state. By default the backup interval for GPOs is every 1 hour. If your environment doesn’t have a large number of GPOs or a lot of ‘hands’ working with them you can set this interval to something like every 8 hours.


In the restore tab you will be able to restore for example a deleted GPO which is pretty cool and fast.





This will restore the previously backed-up GPO with all settings as expected.


Above is a screenshot with all the available built in audit reports that make auditing GPOs really easy even for someone without a lot of Group Policy management experience.

You can easily setup alerts or scheduled reports whenever an event is recorded.


I like the Set Alert option as it allows to keep track of important GPO changes like the Default Domain Controllers Policy or the Default Domain Policy.

I did a lot of tests with the GPO monitoring part and I have to say that you cannot get any more detailed in terms of Auditing GPOs. I replicated a simple but common issue related to GPOs, when for example someone deletes a GPO link. By doing this, the GPO is not removed but the settings will no longer apply. If you use a complex OU structure and don’t link GPOs to the Domain Root and filter using groups, it can be hard to detect when this has happened.

LepideAuditor-Marius-Ene-16 Sure enough, the change is picked up quite quickly.


Another common one, when the GPO link is disabled (not removed).


Again the change is picked up fast.


I’ve also scheduled a report that sends periodically related to GPO Link changes. This works great as you can see below:


I am not sure about you but for me this is really helpful. Along with the integrated backup/restore feature for the GPOs I believe this is an invaluable tool to have.

Exchange Auditing

Exchange server is the typical enterprise email solution for many companies and sometimes evaluating the health or monitoring the changes can be a difficult task without a specialized software. LepideAuditor for Exchange Server covers all these tasks and more.

When looking at the built in available audit reports you can instantly appreciate the usefulness of this tool.


Keep in mind that these are only the built in ones, you can easily create custom reports and alerts that meet your needs.

You can see for example when a send or receive connector was modified,


You can see when mailbox permissions were modified, database changes were performed, as you can see below



I did a simple test; we get mailbox and grant Full Access permissions to another user. Below are the default permissions.


And we see the change being picked up by Lepide. That is nice!


You can easily schedule an Alert based on this object change which would allow you to be informed in almost real time of the change.

I am not going to continue with all the options and possibilities that this tool can bring to the table, if I had to do that we would need a series of blog posts to show everything.

The conclusion

The LepideAuditor Suite is an invaluable toolset for any System Admin that wants full visibility into his environment in terms of auditing, server health monitoring, alerting, and backup history with fast restore capabilities. LepideAuditor Suite manages to put all these features under a single pane of glass.


You can download your trial version here:


More information about LepideAuditor Suite here:



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

AD Initial Sync Requirement


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.


“Repl Perform Initial Synchronizations”=dword:00000000







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 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.


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.


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.




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.


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:


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.


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