Deci, avem o sucursală care este conectată prin fibră optică de 10Mb la biroul principal. Conectarea la un PC de domeniu Windows 7 (pro, 32 biți) este foarte lentă. Prima dată durează până la 7 minute. După aceea, durează ~2 minute pentru logare și ~3-5 minute pentru deconectare.
Am verificat tot ce am putut și nu am văzut nimic special:
- Setări DNS
- Tracert la domeniu
- Nu există sarcini extreme pe server în timpul logării/ieșirii
- Descărcarea unui fișier de pe server pe calculatorul local nu prezintă viteze mici (1,2MB/s) (sau este prea lent?)
- Driver de rețea actualizat
- Setările GPO, cum ar fi
- așteptare pentru rețea la pornire și la conectare
- utilizați un GPO curat (fără opțiuni de profiluri de roaming setate)
- setați timpul maxim de așteptare
- permiteți numai profilurile utilizatorilor locali
- dezactivat Fișiere offline pe partajarea profilului de roaming
- dezactivat IPv6 pe PC-ul local
- firewall dezactivat pe PC-ul local
- servicii de indexare dezactivate pe PC-ul local
- computerul are un tapet (a se vedea http://support.microsoft.com/kb/977346)
jurnalul de evenimente prezintă avertismente cu ID-ul de eveniment 6005 și 6006:
Abonatul de notificare winlogon a avut nevoie de 284 de secunde pentru a gestiona evenimentul de notificare (Logon).
Așa că am făcut o logare de pornire așa cum am menționat aici și a arătat o mulțime de operațiuni NotifyChangeDirectory care au durat mult timp.
Am rămas fără opțiuni. Există altceva care ar putea rezolva acest lucru?
Actualizare
Cred că problema este mai mult legată de lățimea de bandă. Copierea unui fișier de 100mb de pe server pe client durează aproximativ 3 minute. Copierea de la un client win 7 din biroul principal la clientul din filială durează 1,5 minute. Așadar, cel mai probabil există probleme de performanță cu serverul win2003.
Actualizare 1 an mai târziu
Acum am dezactivat profilurile de roaming pentru acești utilizatori. Acest lucru a dat un impuls enorm de viteză. Acest lucru funcționează pentru noi, deoarece utilizatorii au propria lor stație de lucru.
- Aveți ADS&S configurat pentru ambele site-uri și subrețele? Clienții sucursalei sunt configurați cu DC-ul sucursalei ca server DNS primar? Presupun că fiecare birou se află pe o subrețea diferită și că fiecare are propriul server DCDNS. Dacă nu este cazul, atunci nu țineți cont de întrebările mele. – > Por joeqwerty.
- Au același server DNS, dar se află în subrețele diferite. Au în comun același DC – > Por jao.
- Există vreun firewalling între subrețele? Am luptat pentru zile întregi pe ceva de genul ăsta și în cele din urmă am văzut că primeam o tonă de jurnale de pachete pierdute pe firewall-ul meu central. – > Por Mike Renfro.
O captură de pachete de rețea la client ar ajuta probabil aici. Aceasta v-ar arăta cantitatea totală de date transferate în timpul conectării, iar pentru operațiunile sysvol/gpo, ați putea determina dacă clientul petrece o cantitate neobișnuită de timp pe un anumit gpo(s).
După instalarea Microsoft Network Monitor 3.4, salvați următoarele într-un fișier cmd și rulați-l ca sarcină programată la pornirea sistemului. Acest lucru va crea un fișier de captură pe care îl puteți analiza după ce logarea s-a încheiat.
cd /d "C:Program FilesMicrosoft Network Monitor 3"
nmcap.exe /network * /capture /DisableConversations /file c:temptest.cap:100M
Iată câteva setări de registru pe care le puteți testa pe stația de lucru a clientului pentru a determina dacă sunt de ajutor:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon]
"BufferPolicyReads"=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorer]
"NoRemoteRecursiveEvents"=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorer]
"NoRemoteChangeNotify"=dword:00000001
Mai multe informații:
319440 – Întârzierile la conectare apar pe o conexiune lentă dacă nu se acordă o blocare oportunistă pentru fișierul de politici din Windows
http://support.microsoft.com/kb/319440
Microsoft Network Monitor 3.4 Open Source Windows Parsers 3.4.2654
http://nmparsers.codeplex.com/
După ce ați descărcat și instalat Windows Parsers, în Network Monitor, sub Tools > Options > Parser Profiles, selectați Windows și faceți clic pe Set As Active.
La vizualizarea capturii, în fereastra Frame Summary, pachetele de protocol SMB/SMB2 vor afișa calea UNC către locația în care se citesc politicile de grup. Puteți rafina și mai mult afișarea prin aplicarea unui filtru, cum ar fi SMB2 && tcp.DstPort == 445 (sau SMB dacă nu se utilizează SMB2). Acest lucru ar trebui să ofere o afișare destul de concisă a procesării GPO.
Comentarii
- Mulțumesc. Am rulat Wireshark și a arătat o descărcare de 100 kb/sec în timpul conectării, cu o descărcare mai mare după conectare. Bineînțeles că voi încerca sugestia dvs. și voi posta rezultatele aici – > .
- Am capturat datele. Cum îmi dau seama de traficul GPO? – > .
- Consultați informațiile pe care le-am adăugat la sfârșitul răspunsului pentru instalarea analizoarelor Windows și aplicarea filtrului. – > .
- Mulțumesc foarte mult. Acest lucru mi-a oferit foarte multe informații despre funcționarea internă a Windows. Cu toate acestea, acum sunt aproape 100% sigur că este o problemă de lățime de bandă. încărcarea unui profil de 100 mb durează aproximativ 1:40 minute (100 de secunde), ceea ce reprezintă 1 mb/sec, ceea ce este aproape egal cu 10 Mbps – > .
Presupunând că nu aveți sub-rețeaua sucursalei asociată cu „site-ul” biroului principal în Active Directory Sites &; Services….
Dacă afirmația de mai sus este adevărată, problema dvs. este că PC-urile din sucursale se află într-o subrețea diferită de cea a DC la care vă așteptați să se autentifice. PC-urile din sucursale vor petrece timp căutând un DC în propria subrețea înainte de a eșua și de a-l utiliza pe cel din subrețeaua biroului principal.
Pentru a rezolva acest lucru, ați putea asocia subrețeaua sucursalei cu „site-ul” biroului principal care conține DC-ul la care vă așteptați să se autentifice.
Sau ați putea adăuga un DC la sucursală (în subrețeaua sucursalei). Dacă nu este deja configurat, adăugați un nou site în ADs&S pentru sucursală și asociați subrețeaua sucursalei cu acest site.
Creați o subrețea:
Deschideți Active Directory Sites and Services.În arborele consolei, faceți clic dreapta pe Subnets, apoi faceți clic pe New Subnet.În Address (Adresă), tastați adresa subrețelei.În Mask (Mască), tastați masca de subrețea care descrie intervalul de adrese incluse în această subrețea.Sub Select a site object for this subnet (Selectați un obiect de site pentru această subrețea), faceți clic pe site-ul care urmează să fie asociat cu această subrețea (site-ul principal), apoi faceți clic pe OK.
Trebuie să faceți parte din grupul de administratori de domeniu pentru a face acest lucru.
Comentarii
- Vă mulțumim pentru răspunsul dumneavoastră. Puteți să-mi spuneți cum ar trebui să fac acest lucru (sau să-mi indicați un site web care să explice acest lucru)? – > .
- Explicația privind modul de creare și asociere a unei subrețele a fost adăugată la răspunsul meu. – > .
- Am adăugat sub-rețeaua sucursalei, sub-rețeaua biroului principal și sub-rețeaua serverului. Este în regulă? – > .
- Da, dacă folosiți default-first-site-name (nu ați creat site-uri suplimentare în ADS&S. – > .
Aruncați o privire la acest blog de la sysinternals: http://blogs.technet.com/b/markrussinovich/archive/2012/07/02/3506849.aspx Acesta conține informații detaliate despre cum să depanați logările lente