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

 

 

 

Posted in Active Directory | Tagged , , , | Leave a comment

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.

 

 

Posted in Uncategorized | Leave a comment

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

Posted in Lync 2013 | Tagged , , , | Leave a comment

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

Posted in SCOM 2012 | Tagged , , , , | Leave a comment

Lync 2013 Client Access License Inventory


lync-logo2013Lync 2013 Client Access License Inventory

Lync 2013 vine cu ceva nou fata de Lync 2010 si anume modelul de licentiere si cateva cmdleturi noi care sa faciliteze estimare utilizarea de CAL-uri de catre useri sau device-uri intr-o organizatie.

Cateva linii mari despre licentierea la Lync 2013:

  • Licentele de server sunt asignate serverelor ce ruleaza rolul de Front-End.
  • CAL-urile sunt per Device si per User.
  • CAL-urile sunt de 3 tipuri: Standard, Enterprise, Plus.
  • CAL-urile Standard sunt necesare tuturor userilor interni ce acceseaza serverele de Lync. CAL-urile Enterprise si Plus sunt suplimentare licentei Standard. Pot fi adaugate individual sau impreuna licentei Standard CAL.

Listele de functionalitati per licente

StdCAL

entCAL

plusCAL

Acum daca vrem sa efectuam un inventar cu CAL-urile utilizate pentru Lync am cateva optiuni.

Una care imi place personal este MAP Toolkit care poate fi folosita si pentru alte cerinte si care functioneaza excellent. Urmatorul link descrie pasii necesari inventarierii CAL-urilor de Lync folosind MAP Toolkit:

http://blogs.technet.com/b/mapblog/archive/2012/11/28/using-map-toolkit-8-0-to-assess-your-lync-2010-licensing.aspx

In momentul scrierii acestui articol MAP Toolkit putea sa inventarieze doar servere Lync 2010. Urmeaza sa fie actualizata varianta curenta (8.5) pentru a functiona si cu alte produse gen Exchange 2013, Lync 2013, etc.

Assessing Lync Server Licensing – Download

Microsoft Assessment and Planning Toolkit -Download

Pana se poate folosi MAPToolkit mai avem o solutie.

In Lync 2013 a fost introdus un cmdlet special pentru acest scop. Aceasta este Get-CsClientAccessLicense.

Pentru a putea folosi acest cmdlet totusi exista un catch. Trebuie sa aveti configurat rolul de Monitoring. Cmdletul practic acceseaza informatia CDR (Call Detail Recording) care trebuie pornita din LSCP adica sa instalati rolul de Monitoring

lync cp

Deci in principiu se poate rula o comanda de genul sa exportam licentele intr-un csv pe care sa il manipulam mai usor:

Get-CsClientAccessLicense -MonitoringDatabase SQL.domain.com -LicenseName Plus -LicenseBasedType UserBased -StartDate 8/1/2013 -EndDate 11/5/2013 -DailyUsage | Export-Csv c:\users\Gigi\Desktop\PlusCallyncDaily.csv -NoTypeInformation

Output-ul va fi ceva dubios care va necesita ceva filtrari in Excel de genul sa scoatem duplicate sau numere de telefon. Acest lucru este totusi documentat in Release Notes for Lync Server 2013.

limitations

Inainte de incheiere puteti afla mai multe informatii despre Licentierea in Lync 2013 de aici –  Lync 2013 Licensing Guide.pdf

Posted in Lync 2013 | Tagged , , , , , | Leave a comment

ACS query – Access Denied


scom-gsx-solutions

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.

ACSdeniededt

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.

ACSprop

Apoi trebuie sa verificam permisiunile in registrii pentru serviciul respectiv.

ACSreg

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.

ACSacl

ACSsetvalue

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

ACSfinaledt

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

ACSfinal2edt

Posted in SCOM 2012 | Tagged | Leave a comment