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 :

Computer\HKLM\SYSTEM\CCS\services\AdtServer\Parameters

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.

Advertisements

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.

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.

 

SCOM 2012 R2 Install Exception Error Code: 0x80131509

SCOM 2012 R2 Install Exception Error Code: 0x80131509

A aparut versiunea de 2012 R2 a produsului System Center Operations Manager si am facut o instalare de proba sa vedem cum se prezinta. Dupa ce ne asiguram ca toate acele prerequisites au fost configurate ne lovim de o mica problema care arata cam asa.

Cautand in event logs gasim ca nu a putut scrie anumite performance counters.

Solutionarea problemei este documentata deja asa ca nu mai intru in detalii.

How to manually rebuild Performance Counter Library values:

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

How to rebuild performance counters on Windows Vista/Server2008/7/Server2008R2:

http://blogs.technet.com/b/yongrhee/archive/2009/10/06/how-to-rebuild-performance-counters-on-windows-vista-server2008-7-server2008r2.aspx

Removing Lingering Objects

Lingering objects se produc atunci cand anumite DC-uri nu se replica intr-un interval de timp mai lung decat TSL (Tombstone Lifetime). Dupa ce replicarea este din nou functionala, acest domain controller poate avea obiecte care au fost sterse din Active Directory cat timp el nu s-a putut replica iar aceste obiecte se numesc lingering objects.

Atunci cand stergem un obiect din AD acesta nu este sters din database-ul din AD. In schimb este marcat ca si un Tombstone Object iar valoarea atributului isDeleted va fi TRUE, si mutat intr-un container special CN=Deleted Objects. Cand un obiect este marcat ca si tombstone, acesta nu va mai avea toate atributele pe care le avea inainte de a fi sters. Din nou nu este efectiv sters ci doar marcat ca sters. Va avea un set limitat de atribute si va fi pastrat in functie de cat este valoare TSL configurata in forest.

Atributele limitate de pe un tombstone object

attributeID

attributeSyntax

dnReferenceUpdate

dNSHostName

flatName

governsID

groupType

instanceType

lDAPDisplayName

legacyExchangeDN

mS-DS-CreatorSID

mSMQOwnerID

nCName

objectClass

objectGUID

objectSid

oMSyntax

proxiedObejctName

replPropertyMetaData

sAMAccountName

securityIdentifier

sIDHistory

subClassOf

systemFlags

trustPartner

trustDirection

trustType

trustAttributes

userAccountControl

uSNChanged

uSNCreated

whenCreated

msDS-AdditionalSam­AccountName

msDS-Auxiliary-Classes

msDS-Entry-Time-To-Die

msDS-IntId

msSFU30NisDomain

nTSecurityDescriptor

uid

Atunci cand apar lingering objects in Active Directory exista doua posibilitati:

1. Daca avem enabled Strict Replication Consistency DC-ul destinatie va primi un update notification pentru un obiect care nu exista din punctul lui de vedere. Avand optiunea SRC enabled va bloca replicarea inbound de la DC-ul care inca are acel obiect. SRC este un mecanism de protectie pentru a preveni inconsitenta obiectelor in AD.
2. Daca Strict Replication Consistency este Disabled, atunci cand DC-ul destinatie primeste un notificare de tip update, acesta va cere toate informatiile despre acel obiect (Full Replica).

Daca obiectul existent de pe DC-ul sursa nu este updatat, fapt care face DC-ul sursa sa trimita update notifications la partenerii de replicare atunci nu se va intampla nimic care sa evidentieze existenta obiectelor lingering in AD.

DC-ul destinatie va inregistra evenimentul cu ID 1988 in care se va afisa obiectul si DC-ul sursa care il contine.

Urmatoarele evenimete arata ca ar putea exista obiecte de tip lingering in AD:

1862 The local domain controller has not recently received replication information from several domain controllers (intersite).

1863 The local domain controller has not recently received replication information from several domain controllers (intersite).

1864 The local domain controller has not recently received replication information from several domain controllers (summary).

1311 The Knowledge Consistency Checker (KCC) was not able to build a spanning tree topology.

2042 It has been too long since this server last replicated with the named source server. 

1084 There is no such object on the server.

1388 This destination system received an update for an object that should have been present locally but was not.

1311 Another domain controller replicated an object not present on this domain controller.

 Odata identificat obiectul sau obiectele, naming contextul care contine obiectele si pe ce domain controller se afla acestea, se va folosi comanda repadmin cu parametrul removelingeringobjects. In exemplul anterior dubdc03.contoso.com contine obiectele care incearca sa fie replicate in AD.

repadmin /removelingeringobjects dubdc03.contoso.com 667f7037-8198-4357-8f15-8f709f04b6e2 DC=europe,DC=contoso,DC=com /advisory_mode

In exemplul anterior dubdc03.contoso.com contine obiectele care incearca sa fie replicate in AD.

667f7037-8198-4357-8f15-8f709f04b6e2 reprezinta GUID-ul DSA. Sunt multe metode de a gasi guidul. De exemplu ruland repadmin /showreps

DC=europe,DC=contoso,DC=com – este naming contextul unde se afla obiectul

advisory_mode – obiectele nu vor fi sterse si vor fi afisate in event log. Pentru a se sterge se omite acest parametru.

Rulam comanda fara advisory_mode si vedem urmatoarele evenimente:

Din acest moment replicarea isi va relua cursul daca a fost oprita de SRC la DC-urile destinatie.