AD KCC & Bridge All Site Links Behaviour
KCC sau Knowledge Consistency Checker este procesul ce ruleaza pe domain controllere si care este responsabil de crearea si modificarea conexiunilor de replicare dintre DC-uri.
Nota: In AD nu este nevoie sa faceti conexiuni de replicare manual. KCC se ocupa de asta daca stiti sa il influentati in asa fel incat sa lucreze pentru voi. De regula cand se creaza conexiuni manual, se creaza si probleme.
Astazi o sa ma folosesc de urmatorul exemplu in care am trei site-uri A,B,C unde B este HUB site iar A si C se conecteaza la el. Fiecare site contine doar un domain controller DC1, DC2, DC3, exact ca in imaginea de mai jos.
La nivel de Active Directory in Site and Services am definit doua site link-uri, fiecare ce contine doar site-urile ce se vor replica direct.
Iar efectul acestor configurari se poate vedea in conexiunile de replicare facute de KCC.
Dupa cum se vede si mai sus nu exista conexiuni directe intre Site A si Site C.
Pe acest exemplu o sa incerc sa explic ce se intampla atunci cand DC-ul din site-ul central (Site B) nu mai este disponibil.
In titlu ati observat ca m-am referit si la optiunea Bridge All Site Links ce este ACTIVATA by default.
Prima data o sa va spun ce se intampla daca ati dezactivat aceasta optiune (nerecomandat) si DC2 devine indisponibil. Raspunsul e simplu, replicarea nu mai merge intre nici un site iar KCC nu va face nimic pentru a remedia acest lucru. Si bineinteles ca veti vedea mesaje in event viewer asemanatoare cu acesta:
In schimb daca activa Bridge All Site Links, la urmatoarea rulare a KCC acesta va genera un link de replicare temporar intre site-urile A si C.
Iar in momentul in care DC2 revine online, KCC va sterge conexiunea nou creata.
Intr-un mediu de test sau intr-unul foarte strict monitorizat si in care se intervine foarte repede, acest comportament este destul de greu de observat. Asta pentru ca exista cateva reguli ce trebuiesc indeplinite inainte de a efectua acesta masuri corective. Si anume trebuie sa exista macar o incercare de replicare esuata (si schedule-ul trebuie sa permita) si sa fi trecut cel putin 2 ore de la ultima replicare efectuata cu succes. Plus ca mai exista si intervalul de 15 minute la care ruleaza KCC. De aici si motivul pentru care nu prea vedem foarte des aceste masuri corective.
Iar acesta este scenariul simplu. Pentru ca daca in HUB Site avem mai multe DC-uri, atunci se va face fallback la urmatorul DC din site (si nu la urmatorul site) respectand regulile de mai sus (timpul explicat in regula de mai sus se va multiplica pentru fiecare DC din site). Abia cand au fost incercate toate DC-urile din site-ul central fara succes, abia atunci intreg site-ul va fi considerat deconectat si se va face failover catre alt site. Deci daca intreg site-ul a picat e posibil sa asteptam multe ore pana cand o sa vedem o conexiune temporara creata de KCC.
Dar exista si metode de a grabi acest proces. Si anume prin urmatoarele valori de tip REG_DWORD ce le gasiti in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:
IntersiteFailuresAllowed
Value: Number of failed attempts
Default: 1
MaxFailureTimeForIntersiteLink (sec)
Value: Time that must elapse before being considered unavailable, in seconds
Default: 7200 (2 hours)
Pentru mai multe detalii despre aceste setari dar si despre KCC in general va recomand urmatorul link: http://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx
PS: Scenariul merge pe premiza ca exista conectivitate IP si intre site-urile A si C. KCC va incerca sa conecteze direct cele doua site-uri chiar si daca nu exista conectivitate intre ele atata timp cat optiunea Bridge All Site Links este activa.
Disk2VHD 2.0
Uite ca se mai misca ceva prin tool-urile de la Sysinternals si Disk2VHD e la versiunea 2.0.
Noutatea este ca acum suporta si formatul VHDX.
http://technet.microsoft.com/ro-ro/sysinternals/ee656415.aspx
PS: Ma intreb daca nu cumva s-ar putea face ceva oarecum asemanator si cu New-VHD prin parametrul SourceDisk.
RDP 8.1 Restricted Admin mode – security feature or not?
De la un prieten am aflat si eu de functionalitatea numita RDP Restricted Mode ce permite autentificarea de tip SSO fara a mai reintroduce credentialele.
Sincer nu am stat sa studiez foarte mult insa cateva detalii gasiti in link-urile de mai jos:
http://redmondmag.com/articles/2013/08/15/restricted-admin-mode.aspx
Ce este important este ca deja se discuta despre cum aceasta functionalitate e exact opusul a ce se dorea si anume ca permite PTH attacks:
http://www.kali.org/penetration-testing/passing-hash-remote-desktop/
Totusi mie ceva nu imi suna bine pentru ca daca sunt in domeniu atunci voi folosi Kerberos si dupa cum se vede in primul link postat, kerberos este folosit pentru autentificare. Deci eu personal cred ca scenariul este posibil doar atunci cand statiile nu sunt in domeniu si se foloseste NTLM.
Si stau si ma intreb, oare cum se compara acest /restrictedadmin cu ce am scris eu aici.
Ca lectura suplimentara va recomand urmatorul document:
Free Backup Solutions – Veeam & Unitrends
Saptamana asta m-am apucat sa studiez ceva solutii de backup pentru mediul virtual si bineinteles ca nu puteam sa trec peste versiunile free disponibile de la cativa producatori. Sunt doua solutii ce se remarca – Veeam Backup & Replication si Unitrends Enterprise Backup ambele disponibile si pentru Vmware si Hyper-V si cu versiuni free.
Ar trebui sa mai reamintesc ca pentry Hyper-V mai exista si Altaro ce are versiune free singura limitare fiind la numarul de masini virtuale protejate (doar doua).
Dar cum eram axat pe Vmware saptamana aceasta m-am uitat doar la Veeam si Unitrends. Oricum problema e cu Vmware si anume cu versiunea Free unde dupa cum stiti Vmware nu permite utilizarea API-urilor de backup. Ceea ce inseamna ca nici un produs de backup nu va functiona cu versiunea free de Vmware. Si mai jos aveti dovada cu Veeam.
Totusi Unitrends Enterprise Backup (UEB) se lauda ca poate face asa ceva. Solutia lor este una de compromis; UEB vine si cu agent de backup pentru OS si astfel va face backup direct din masina virtuala ocolind platforma virtuala. Totusi este diferit de un backup la nivel de masina virtuala si va face tot procesul ceva mai complicat (vei fi nevoit sa folosesti procesul de Bare Metal recovery pentru a restaura o masina virtuala – exact cum ai face pentru un server fizic, adica foarte complicat comparativ cu mediul virtual).
Dar daca nu folositi versiunea free de ESXi si aveti macar pachetul Essentials atunci puteti beneficia de backup-uri la nivel de platforma virtuala din ambele produse. In versiunile free exista limitari la ambele produse dar cele mai importante o sa le mentionez acum. In Veeam nu exista posibilitatea de a schedula backup-uri. Adica trebuie sa le faceti de mana:
Luati versiunea pe bani si scapati de problema asta, plus aveti si un modul Powershell ce va poate ajuta sa automatizati unele chestii.
Nota: modulul Powershell e disponibil din freeware insa tot nu va poate ajuta sa faceti joburi de backup.
Unitrends Enterprise Backup e ceva mai generos. Nu exista limitare in genul celei de la Veeam ci doar o limita a numarului de servere protejate si anume 8 (e super suficient pentru un SMB). Inca un avantaj ar fi ca vine sub forma de virtual appliance pentru Vmware deci nu mai e nevoie de inca un server de Windows.
Ambele produse am observat ca au optiunea de instant restore adica iti creaza masina virtuala direct din backup dupa care fac un Vmotion in datastore-ul din Vmware.
Dar cam atat deocamdata, sper totusi sa fie suficient pentru a va face o idee daca aveti de gand sa mergeti pe o versiune free a acestor produse. Sfatul meu la acest moment (pentru Vmware) este ca cel putin sa folositi o versiune Essentials pentru a scapa de limitarile de backup din platforma virtuala. Produsele le puteti gasi la adresele de mai jos:
http://www.veeam.com/virtual-machine-backup-solution-free.html
http://www.unitrends.com/products/software
Hex Dump din Powershell
Am gasit pe net cateva variante foarte bune pentru un replacement la un hex viewer din Powershell si m-am oprit la varianta celor de la Sans care mi se pare foarte ok, afiseaza si offset-ul si hex si Ascii.
In link-ul de mai jos gasiti o adevarata colectie de scripturi pentru astfel de conversii.
http://www.sans.org/windows-security/2010/02/11/powershell-byte-array-hex-convert/
WinRT adica Windows Runtime Library
In primul rand La Multi Ani! ca e primul meu post pe 2014.
In al doilea rand m-am gandit sa incep anul cu un subiect destul de interesant si anume WinRT si ce necesita putina istorie pentru a fi inteles din prisma unui non-dev ca sa nu zic sysadmin.
Nota: A nu se confunda cu Windows RT aka Windows on ARM aka Windows-ul ce ruleaza pe tabletele cu procesoare ARM.
Acum un an citisem un articol foarte bun pe subiectul acesta si cand l-am gasit acum din intamplare mi-am zis ca este un must sa pun un link catre el si aici.
http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/
Credeti-ma pe cuvant cand va spun ca trebuie sa il cititi, insa atentie, nu este scurt ci are 7 pagini destul de stufoase si cu multe detalii insa foarte bine explicate pentru publicul non-dev, sau cel putin asa consider eu. Daca aveti rabdarea sa treceti prin tot ce e acolo veti descoperi si veti intelege multe din componentele ce stau (sau au stat) la baza Windows-ului actual, OLE,COM, WIN16, WIN32, DirectX, .Net, WinFX, WPF si mai nou WinRT.
Windows 8.1 Shutdown shortcut
Am vazut ca foarte multa lume inca mai apeleaza la Charm Bar sau la Modern Interface pentru Shutdown/Reboot/Signout, insa in Windows 8.1 nu este necesar.
Un simplu right click pe noul buton de start va aduce in urmatorul meniu:
Unde dupa cum se vede exista si optiunea Shut down or sign out.
Iar shortcut-ul pentru acest meniu este START KEY+X si este disponibil si din desktop si din modern interface.
Page File, again & again …
Din cand in cand vine cate un moment in care iar intru in discutii despre paging file, rolul lui si dimensiunea recomandata.
Exista multa informatie scrisa pe acest subiect si nu o sa intru in foarte multe detalii ci vreau sa atrag atentia acelor “best practices” de a seta o anumita dimensiune a acestui fisier.
Sincer, nu exista “best practices” pe acest subiect. Fiecare sistem are nevoie de page/swap file in functie de incercarea lui iar asta se poate afla doar monitorizand sistemul o periada de timp.
By default page file-ul este “system managed”.
Setare de care multi admini fug si se apuca sa seteze 1.5 x dimensiunea RAM-ului.
Dar ce nu stiu ei este ca “system managed” seteaza swap-ul aproape de dimensiunea RAM-ului (e un algoritm care functioneaza si in functie de RAM-ul de pe sistem, la sub 1Gb incepe de la 1.5xRAM) si il creste dinamic atunci cand e nevoie pana la 3xRAM.
Deci setari fixe gen 2Gb sau 1.5xRAM nu isi au rostul facute asa dupa ureche sau doar ca asa zice cineva intr-o carte. Pentru ca daca exista presiune pe sistem si este fortat sa mute multe pagini in swap e posibil sa nu mai aiba unde sa le mute daca nu a fost dimensionat corespunzator. Stiu, 1.5xRAM ar cam trebui sa fie suficient dar mai sunt si exceptii si atunci poate e mai bine cu system managed pentru ca se poate adapta on the fly.
Problema cu system managed inca de pe vremuri era ca performanta sistemului ar fi afectata atunci cand page file-ul este extins. Oricum cand scrii in swap deja esti la mana hard disk-ului deci chestia asta e insesizabila si consider ca teoria asta nu prea mai are rost.
In schimb exista si cazuri valide pentru a seta custom size gen:
– avem nevoie de swap mai mare de 3xRAM
– nu avem spatiu suficient si vrem sa impiedicam ca pagefile-ul sa umple tot volumul
– nu avem spatiu pe volumul cu sistemul de operare si vrem sa-l mutam pe alt volum cu spatiu disponibil.
– vrem sa-l mutam pe alt disc pentru a imbunatati performanta procesului de paging (pot fi si mai multe discuri)
– vrem sa dezactivam swap-ul de tot (nu sunt fan asa ceva dar e un scenariu posibil).
Ca material de studiu va dau cateva link-uri utile insa sunt doar cateva, exista probabil mult mai multe insa astea mi-au sarit mie in ochi la primele cautari.
http://support.microsoft.com/kb/2860880
http://technet.microsoft.com/en-us/magazine/ff382717.aspx
http://blogs.technet.com/b/askperf/archive/2007/12/14/what-is-the-page-file-for-anyway.aspx
Exchange & SSL Certificates for Internal Server Names
Cum in ultimul timp am fost putin mai deconectat de tehnologie mi-au scapat cateva anunturi importante cum ar fi cel de aici:
http://www.digicert.com/internal-names.htm?SSAID=314743
Sau:
http://support.godaddy.com/help/article/6935/phasing-out-intranet-names-and-ip-addresses-in-ssls
Care in mare spun ca nu se vor mai emite certificate pentru nume de domenii gen .local sau .internal sau doar pentru un hostname, iar cele emise vor fi invalidate din 2016. Iar asta e cam dificil atunci cand in certificatul de tip SAN pentru Exchange ai nevoie si de numele externe si de cele interne unde domeniul AD este de tip .local.
Si este cam “big problem” pentru ca majoritatea implementarilor de Active Directory + Exchange au folosit nume de domenii private pentru a elimina orice conflict cu domeniile externe.
Inca mai rumeg la chestia asta dar pot sa va dau cateva idei pe care le-am identificat rapid:
– daca este deployment nou evitati .local, .internal sau orice alt nume privat.
– daca este deployment existent, un domain rename se poate lua in considerare. (Am inceput sa zic cam des chestia asta insa nu am dat de nici un kamikaze pana acum care sa treaca printr-un domain rename)
– daca exista TMG in fata Exchange-ului, in intern raman certificatele emise de CA-ul intern iar pe TMG se pun cele emise pt domeniile externe.
– folositi site-uri diferite pt OWA, unele cu certificatele private iar altele cu cele publice.
– folositi acelasi service connection point si pentru intern si pentru extern, folosind numele public.
PS: https://www.cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
Group Policy Caching in Windows 8.1 si Windows Server 2012 R2
Group Policy Caching suna destul de interesant ca subiect, insa in realitate nu prea este. M-am abtinut o perioada sa scriu despre subiect pentru ca nu intelesesem exact cand si cum este folosit si nici nu vedeam avantaje.
Oricum au clarificat altii mult mai destepti ca mine si o sa va si arat despre ce e vorba.
Setarea se poate configura tot din GPO si o gasiti in Computer Configuration\Policies\Administrative Templates\System\Group Policy:
Dar daca cineva crede ca acest caching face exact ce spune denumirea se inseala. La fiecare procesare GPO in background, policy-urile sunt stocate in
c:\windows\system32\GroupPolicy\Datastore. Dar nu sunt procesate decat atunci cand urmatoarea procesare GPO este sincrona (synchronous policy processing). Si nu oricum, ci numai cand aceasta procesare sincrona este declansata de un CSE din GPO. Deci fortand procesarea sincrona prin “Always wait for network …” nu va declansa utilizarea cache-ului. Si mai uitam ceva, procesarea GPO este oprita atunci cand nu exista conectivitate cu un domain controller, deci si scenariul asta pica.
Asa ca pana la urma este doar un feature de marketing. Sau poate ca in urmatorul service pack o sa se mai schimbe ceva.
Iata si alte referinte pe aceasta tema:
http://sdmsoftware.com/group-policy-blog/windows-8-1/clarifying-group-policy-caching-in-windows-8-1/