Monitor DHCP interaction with DNS through audit logging
Am scris zilele trecute cateva chestii despre cum interactioneaza serviciul DHCP cu DNS-ul dar am uitat sa specific cum puteti monitoriza aceste activitati.
Puteti vedea cand serverul DHCP trimite update-uri catre DNS din DHCP audit log:
Pe care il gasiti in %windir%\System32\Dhcp
Iata un exemplu despre cum arata evenimentele din acest log:
O lista cu o parte din codurile intalnite in acest log gasiti aici:
http://technet.microsoft.com/en-us/library/dd759178.aspx
De exemplu 30 inseamna ca update-ul a fost trimis catre DNS iar 32 inseamna ca a fost procesat cu succes. Lista cu celelalte coduri ce lipsesc de acolo o gasiti chiar la inceputul fisierului de log.
Powershell #Requires statement
De curand am dat de situatia in care am scris un script pe un sistem cu Powershell 3.0 si am ajuns sa il rulez pe un sistem ce avea doar versiunea 2.0. Stiam ca acest lucru s-ar putea intampla si am eliminat cmdlet-urile ce nu erau prezente in 2.0, apeland direct clasele din DotNet. Cu toate acestea exista schimbari de sintaxa ce cateodata fac incompatibile scripturile scrise in versiuni diferite de Powershell.
Si pentru a elimina cateodata munca in zadar si confuzia celor care ne ruleaza scripturile, putem folosi declaratia #Requires unde putem specifica cateva cerinte minime pentru ca scriptul sa poata rula. Gen versiunea de Powershell, drepturi de admin sau prezenta unor anumite module.
#requires -RunAsAdministrator
Sau:
#requires –version 3
Iata de exemplu ce se intampla cand incerc sa rulez scriptul de mai sus dintr-un prompt cu drepturi normale.
Keeping DNS clean with the help of DHCP
Inregistrarile outdated in DNS sunt ceva “normal” cam pentru orice admin cu o retea maricica. Cum saptamana trecut am avut conversatii cu mai multe persoane pe acest topic m-am gandit sa mai arunc un ochi pe DHCP si DNS. De ce DHCP, pentru ca este principalul mod prin care clientii isi inregistreaza numele in DNS. Cu cat intelegem mai bine interactiunea dintre cele doua componente cu atat mai usor vom intelege de ce avem inregistrari outdated in DNS.
Sa lamurim cateva chestii de baza:
– clientii configurati static isi inregistreaza singuri inregistrarile A si PTR in DNS. Cum in general vorbim de zone DNS AD Integrated, inseamna ca vor fi owneri pe acele obiecte si deci doar ei le vor putea updata (by default). Deci daca un astfel de client paraseste reteaua sa zicem si nu se mai intoarce, inregistrarea lui poate ramane in DNS pentru totdeauna. De asta trebuie sa aveti configurat DNS Aging and Scavenging.
– Aging and Scavenging e de baza intr-o infrastructura cu mai multe servere DHCP
– clientii setati pe DHCP vor negocia prin optiunea 81 cine va face inregistrarea in DNS. By default clientul isi face A-ul, iar DHCP-ul face PTR-ul. Recomand sa schimbati aceasta optiune si sa setati ca serverul DHCP sa faca inregistrarile in DNS. In felul acesta DHCP-ul va fi owner pe inregistrari iar daca este setat si cu credentialele potrivite, cu atat mai bine.
– serverele DHCP trebuie setate sa foloseasca un user special facut pentru dynamic updates. Daca toate serverele din organizatie folosesc acelasi user atunci, atunci clientul se poate plimba intre servere iar serverele ii vor putea updata inregistrarile.
Ok, am lamurit cateva chestii de baza, acum sa luam un caz in care generam inregistrari outdated in DNS. Userul scoate cablul din laptop si pleaca acasa, sau mai bine in vacanta. In mod normal clientul ar trebui sa faca un release pe DHCP si DNS (la shutdown sau ipconfig /release) insa daca se deconecteaza brusc lucrul asta nu se mai intampla.
Deci ce se intampla cu acea inregistrare in DNS? Pai e posibil sa ramana mult timp acolo daca nu avem setat Aging and Scavenging sau “Discart A and PTR records when lease is deleted”.
Da, serverul DHCP poate sterge inregistrarile in DNS (daca le-a facut el si are drepturi), dar asta doar cand expira lease-ul. Iar cu un lease de 8 zile, abia dupa 8 ZILE! Daca laptopul a fost deconectat dupa o zi, inseamna inca 7 zile in care inregistrarea mea pluteste prin DNS.
Dar si optiunea asta este influentata de cateva chestii. Odata de drepturi am zis. Pe urma de durata lease-ului.
Urmeaza optiunea DatabaseCleanupInterval ce specifica la ce interval serverul trece prin baza de date si sterge lease-urile expirate (60min by default, 4h pe W2K)
http://technet.microsoft.com/en-us/library/cc963208.aspx
Dar asta nu e tot, chiar daca lease-ul a expirat, nu este sters din baza de date. Exista un grace period numit LeaseExtension (4h by default). Abia dupa ce trece si LeaseExtension si ruleaza din nou DatabaseCleanup, abia atunci lease-ul este eliberat si sunt trimise comenzi catre DNS sa stearga vechile inregistrari. Astfel serverul DHCP va sterge si A-ul si PTR-ul (daca poate bineinteles).
http://technet.microsoft.com/en-us/library/cc783573(v=ws.10).aspx
Am lamurit aspectul asta, dar ce se intampla cu vechile inregistrari ce nu au fost puse in DNS de catre serverul DHCP. Pai e simplu si am mai spus. Aging and Scavenging. Sau se poate manual; cu powershell poti face foarte multe in ziua de azi si chiar exista exemple pe net. Doar sa ai rabdare, iar asta e regula de baza in DNS.
In Windows 2012 R2 exista si optiunea “Disable dynamic updates for DNS PTR records”. In felul acesta se va face update doar la A.
Deci, durata lease-ului este foarte importanta. Un lease mare poate face sa avem inregistrari outdated in DNS (unde clientul initial este offline de mult timp) dar ne poate scapa de duplicate pentru ca adersa IP nu va fi refolosita pe durata lease-ului. Pe partea cealalta, un lease mic, setat incorect, poate crea o tona de inregistrari in DNS, dar setat cum trebuie poate fi o varianta mai buna. Bineinteles ca si aging and scavenging trebuie setat iar recomandarile sunt ca intervalul de scavenging sa fie putin mai mare decat lease-ul din DHCP.
Sunt atatea variante si scenarii incat nu am cum sa le acopar pe toate asa ca o sa pun si cateva link-uri utile pe acest subiect:
http://support.microsoft.com/kb/816592
Si vreau sa mai reamintesc ca informatiile din DNS nu sunt ceva real time, e nevoie de timp pentru ca acestea sa fie updatate, nu o sa vedeti niciodata ca un client iese din retea si automat nu il mai rezolvi prin DNS. In majoritatea cazurilor intervalul asta de timp in care se updateaza informatia nu creeaza nici un fel de probleme, poate doar vizuale pentru unii admini. Dar asta nu inseamna ca nu trebuie sa faceti tot posibilul pentru a tine zonele DNS cat mai curate.
Active Directory Sizing
Cand vine momentul sa implementam un mediu nou Active Directory este foarte important sa facem un sizing corespunzator. De multe ori acest aspect trece cu vederea si din cauza ca serverele din ziua de azi sunt foarte performante iar degradarile de performanta din cauza unui sizing gresit pot trece cu vederea in prima faza. Dar pentru ca environmentul sa se comporte cat mai bine pe toata durata lui de viata, e bine sa facem putin studiu inainte.
Pe vremuri exista un tool de sizing pentru Windows 2000 insa cum hardware-ul s-a schimbat enorm de atunci nu prea mai e de folos. In schimb exista doua documente foarte bune; unul este de Windows 2003 insa il consider inca folositor:
Capacity Planning for Active Directory Domain Services
Active Directory Performance for 64-bit Versions of Windows Server 2003
Foarte important pentru un domain controller este RAM-ul si procesorul. Disk-ul nu este atat de important, daca sizing-ul pentru RAM se face cum trebuie, iar adaptoarele de retea rar ajung sa fie folosite la maxim. Regula de baza este ca NTDS.DIT-ul sa incapa in RAM. Daca DC-ul va reusi sa-l cache-uiasca in RAM atunci nu va mai apela la disk. Iar pentru a estima cam la ce dimensiune maxima poate ajunge baza de date gasiti informatii in primul link. Eu de regula calculez cam 60Kb/user.
Iar pentru CPU gasiti in al doilea document cateva teste facute cu 100.000 si 3.000.000 useri. O sa vedeti ca este foarte important modul in care clientul interactioneaza cu domain controllerul (protocol, autentificare, query). Ganditi-va ca sunt cazuri cand nu veti avea foarte multi clienti ce se autentifica interactiv pe Kerberos la DC (operatiune destul de costisitoare) dar veti avea foarte multe aplicatii ce isi trag date despre useri din AD.
Deci foarte important este sa puneti intrebarile potrivite si sa aflati exact cine si ce va interactiona cu noul mediu. Partea buna la AD este ca daca nu e suficient poti foarte usor sa mai trantesti un domain controller (daca ai bani bineinteles).
Batchpatch – Windows Updates tool
Weekendul acesta am dat peste un utilitar foarte util si cu toate ca este pe bani, am reusit sa il folosesc intr-un environment mic unde trebuia sa fortez instalarea unor updateuri de windows remote. Se numeste BatchPatch si iti permite sa executi software remote, scripturi, procese, updateuri, sa downloadezi si sa instalezi updateurile de pe WSUS sau de pe Microsoft Updates si cate si mai cate.
Dupa cum am zis, este pe bani, dar fara sa il licentiezi (adica in modul trial) te poti conecta cu el la 4 sisteme.
Interfata arata cam asa.
O lista de servere, click dreapta si ai o gramada de optiuni.
Odata updatat un server de exemplu, putem culege si logul cu ce s-a intamplat pe sistemul remote:
Nu o sa detaliez prea multe, pentru ca este banal de folosit (atata timp cat nu te incurca Windows Firewall si ai pus PSExec acolo unde trebuie).
Mai multe informatii gasiti pe http://batchpatch.com/
PS: mai exista si varianta PoshPaig dar mie personal mi se pare cu mult sub BatchPatch.
Set background/wallpaper on RDS Servers
Cum setarile din GPO pentru wallpaper (cateodata cu un motiv intemeiat) nu se aplica pe masinile cu rolul de TS/RDS instalat, setarea unui background pe o masina cu rolul de Remote Desktop Session Host se poate face din registry.
Tocmai de asta pun ca referinta aici (mai mult pentru mine) cheile din registry responsabile pentra asa ceva:
Pentru background color: HKEY_CURRENT_USER\Control Panel\Colors\Background
Si pentru wallpaper: HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper
Dupa cum vedeti cheile se afla in HKCU, asa ca vor trebui impinse prin Group Policy Preferences.
Iar daca preferati varianta in care sa modificati Default User Profile pentru a aplica aceste setari pentru toate profilele nou create, puteti modifica valorile ce se afla in HKEY_USERS\.DEFAULT\.
PS: In clientul de RDP trebuie verificata si urmatoarea bifa:
Microsoft Virtual Machine Converter 3.0
Microsoft Virtual Machine Converter 3.0 aka MVMC tocmai a fost lansat. Pentru cei ce nu stiu inca, MVMC este varianta MS a Vmware Converter. Doar ca este orientat catre migrarile V2V, de la Vmware la Hyper-V. Si este free.
Daca stau si ma gandesc, cred ca in loc sa bage atatia bani in marketing, mai bine dezvoltau in astfel de tool de la inceput, super capabil si macar migrarile ar fi mers struna. In schimb au scos tool-uri ce de multe ori erau nefolositoare sau te impotmoleai in tot felul de probleme.
Sa revenim totusi la produsul din titlu. Am spus ca este orientat catre V2V (Vmware to Hyper-V) Cel putin vechile versiuni nu faceau decat V2V si daca asta nu mergea trebuia sa apelezi la procesul de P2V din SCVMM. Asta pana cand au scos P2V-ul din SCVMM. (Mi s-a parut o decizie super proasta, dar deja m-am obisnuit ca doar lucrez in IT.) In schimb in versiunea MVMC 3.0 a fost introdus suportul pentru P2V.
Asta este un lucru foarte bun pentru ca inca se mai fac migrari ale serverelor fizice si era nevoie de asa ceva. Plus cazurile cand procesul de V2V nu functioneaza asa cum trebuie. Imi aduc aminte multe cazuri cand toolurile de P2V au mers mult mai bine decat cele de V2V.
Iar pentru procesul de V2V vad ca se pune accent foarte mare pe migrarea catre Azure. Exista suport pentru migrarea directa din Vmware in Azure si bineinteles suport pentru automatizare prin numeroase cmdlet-uri puse la dispozitie.
Ce sa va mai spun, ca exista suport pentru Linux (versiunile le gasiti in Admin Guide), conversii online si offline, si suport pentru Windows doar de la Windows 2008 in sus (sorry, no W2K3).
Si nu in ultimul rand, exista suport pentru Vcenter si ESXi 5.5. Asa ca daca va bate gandul sa faceti o astfel de migrare sau va impinge cineva de la spate, mai aveti un ajutor in plus.
Download aici: http://www.microsoft.com/en-us/download/details.aspx?id=42497
Whitelisting a domain or email address in Exchange 2010/2013
Exchange Content Filtering e o functionalitate ce nu o gasiti in interfata grafica si e nevoie de Powershell pentru a schimba configuratia. Si de regula aveti nevoie atunci cand trebuie sa setati un domeniu sau o adresa de email ca fiind safe si filtrele sa nu o blocheze in nici un fel.
Daca doriti sa vedeti configuratia pentru Content Filtering o puteti face prin comanda get-contentfilterconfig:
Dupa cum vedeti in exemplul de mai sus BypassedSenders si BypassedSenderDomains nu au nici o valoare.
Cum proprietatile respective trebuie sa respecte un anume model e nevoie sa facem urmatoarea procedura pentru a le modifica:
Si anume, am pus intr-o variabila tot ce exista in BypassedSenders (chiar daca nu era nimic am obtinut formatul necesar):
$bypassedsenderlist = (Get-ContentFilterConfig).BypassedSenders
Am adaugat in array-ul nou creat $bypassedsenderlist doua intrari noi:
$bypassedsenderlist.add("andrei.ungureanu@winadmin.ro")
$bypassedsenderlist.add(administrator@winadmin.ro)
Dupa care am trimis-o in comanda Set-ContentFilterConfig:
Set-ContentFilterConfig -BypassedSenders $bypassedsenderlist
Si exact la fel se procedeaza daca vreti sa excludeti unul sau mai multe domenii din mecanismul de filtrare, doar ca proprietatea se numeste BypassedSenderDomains.
Windows 10 & Windows Server Next
Zilele astea Microsoft a prezentat urmatoare versiune de Windows sub denumirea de Windows 10. Despre schimbarile care au aparut nu as vrea sa comentez prea mult, doar ca multe dintre lucruri trebuiau sa fie de la inceput in Windows 8.
Daca vreti sa testati Windows 10 trebuie sa va inscrieti in programul Windows Insider dupa care veti putea downloda si testa sistemul de operare, de mentionat faptul ca este doar un technical preview.
Ieri a fost prezentat si technical preview pentru Windows Server, pe care insa daca vreti sa il testati va trebuie o subscriptie MSDN.
Inca nu am apucat sa ma joc cu nici unul din ele, dar le-am downlodat pe amandoua si urmeaza sa revin cu alte detalii mai tehnice.
Cateva link-uri ajutatoare:
http://www.petri.com/microsoft-announces-windows-10-hopes-we-forget-windows-8.htm
http://windowsitpro.com/windows-server/whats-new-windows-server-next-preview
Microsoft Certification Exams Online?
http://www.pearsonvue.com/microsoft/op/
Sincer nu vreau sa zic daca este o miscare buna sau nu. Cei ce vor dori sa triseze vor reusi oricare ar fi formatul. Dar pana la urma se pacalesc pe ei insisi, ca diplomele nu o sa faca munca in locul tau.