Salut,

Numele meu este Liviu si fac parte din echipa de Networking din RoGTSC.

In acest post o sa va vorbesc despre o problema destul de des intalnita de la aparitia sistemul de operare Windows Server 2008 R2, exemplificat de un scenariu concret pe care l-am intalnit.

Avem un Windows Server 2008 R2 care totodata este si DC (Domain Controller). DC-ul isi face actualizarea recorduriilor de DNS la un DNS 3rd Party, si anume un server BIND. Serverul de 2008 R2 isi face inregistrarea recorduriilor de DNS in mod dinamic.

Problema intalnita:
Desi serverul isi inregistreaza corect toate recorduriile in DNS, intalnim urmatoarea eroare:

Am vazut in jur de 15 erori de genul acesta, cate o eroare pentru fiecare record de DNS ce trebuia inregistrat de Netlogon pe serverul BIND.

Error      10/22/2009 10:41:32 AM               NETLOGON         5774       None

The dynamic registration of the DNS record '_ldap._tcp.test.local.com 600 IN SRV 0 100 389 Server.test.local.com.' failed on the following DNS server: 

DNS server IP address: 192.168.1.1
Returned Response Code (RCODE): 0
Returned Status Code: 9502 

Err 9502: 
DNS_ERROR_BAD_PACKET
# Bad DNS packet.

Ca sa verificam raspunsul serverului de DNS am luat si un Network Trace de pe DC. Am observat urmatorul lucru:

1              09:41:32.547375                192.168.1.2         192.168.1.1         DNS       Dynamic update SOA _tcp.test.local.com
Zone:
          + _tcp.test.local.com: type SOA, class IN
Updates:
          +_ldap._tcp.test.local.com: type SRV, class IN, priority 0, weight 100, port 389, target Server.test.local.com

2              09:41:32.547375                192.168.1.1         192.168.1.2         DNS       Dynamic update response
Flags: 0xa880 (Dynamic update response, No error)
Zones: 0
Prerequisites: 0
Updates: 0
Additional RRs: 0

Din cate vedem in Trace-ul confirma ca recorduriile sunt create pe serverul de DNS. Serverul de DNS raspunde la Dynamic Update-ul DC-ului cu "Dynamic update response, No error"
Cu toate ca raspunsul serverului de DNS este valid, putem observa ca raspunsul acestuia nu contine Zones, Prerequisites, Updates si Additional RRs.

Conform RFC-ului 2136, raspunsul serverul de DNS nu trebuie sa contina Zones, Prequisites, Updates si Additional RRs.

Concluzia:

Desi totul pare sa fie in ordine, noua ni se genereaza o eroare.

Solutia pentru aceasta problema se afla intr-un articol de KB nou aparut:

DNS updates may be incorrectly reported as failed when you use a third-party DNS server application for DNS registration on a computer that is running Windows Server 2008 R2 or Windows 7

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

In urma instalarii Hotfix-ului din acest articol de KB, va fi modificat printre altele si Dnsapi.dll, iar raspunsul serverului de DNS va fi interpretat corect de catre DC-ul nostru de Windows Server 2008 R2 si eroare nu va mai fi generata.

--- Liviu

Salut,

Am sa va scriu despre o situatie interesanta intalnita recent de mine in cadrul WINS-ul.

Infrastructura

=-=-=-=-=-=-=-=

Cluster de WINS cu doua noduri de Windows Server 2008 si unul cu doua noduri de Windows Server 2003.

Replicarea bazei de date a WINS-ului arata in felul urmator:

W2003 <--- W2008 <---> W2008 ---> W2003

Replicare de tip "Pull" de la serverele de 2003 la serverele de 2008, si replicare de ambele tipuri, "Push" si "Pull", intre serverele de 2008.

Problema

=-=-=-=-=-=

Replicarea (fie ea “Push” sau “Pull”) dintre serverele de 2008 nu functioneaza. Replicarea de tip “Push”dintre servere genereaza urmatoarul Event:

Log Name:      System
Source:        Wins
Date:          9/17/2009 1:10:08 PM
Event ID:      4243
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Wins.test.local.com
Description:
WINS Pull thread encountered an exception during the process of sending a push notification to another WINS.

De mentionat este ca replicarea de tip “Pull” de la serverele de 2003 la cele de 2008 functioneaza.

Testele si verificari pe care le-am facut

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

In primul rand am verificat conform KB-ului 822158, sa fie totul in regula cu exceptiile Antivirusului.

Am adaugat “%systemroot%\system32\wins” la exceptii, am incercat replicarea din nou, dar eroarea era generata in continuare.

Am vrut sa vedem intr-un Trace de retea aceasta replicare dintre nodurile de Windows Server 2008.

Vom testa cateva scenarii:

Scenariul 1:

W2008 <--- W2008

192.168.1.1 face o replicare de tip “Pull” de la 192.168.1.2

192.168.1.5 (adresa clusterului)          192.168.1.2                   TCP               TCP:Flags=......S., SrcPort=64237, DstPort=Internet Name Server(42), PayloadLen=0, Seq=80858379, Ack=0, Win=8192

192.168.1.2 (adresa resursei WINS)         192.168.1.5                TCP               TCP: [Bad CheckSum]Flags=...A..S., SrcPort=Internet Name Server(42), DstPort=64237, PayloadLen=0, Seq=1956818950, Ack=80858380

192.168.1.5 (adresa clusterului)          192.168.1.2                   TCP               TCP:Flags=...A...., SrcPort=64237, DstPort=Internet Name Server(42), PayloadLen=0, Seq=80858380, Ack=1956818951, Win=513

192.168.1.2 (adresa resursei WINS)          192.168.1.5                TCP               TCP: [Bad CheckSum]Flags=...A...F, SrcPort=Internet Name Server(42), DstPort=64237, PayloadLen=0, Seq=1956818951, Ack=80858380

192.168.1.5 (adresa clusterului)          192.168.1.2                   WinsRpl     WinsRpl:Transport on TCP: Association Start Request Message                      {WinsRpl:7, TCP:6, IPv4:5}

192.168.1.2 (adresa resursei WINS)         192.168.1.5                TCP               TCP: [Bad CheckSum]Flags=...A.R.., SrcPort=Internet Name Server(42), DstPort=64237, PayloadLen=0, Seq=1956818952, Ack=80858425

Se face TCP Handshake-ul si pe urma se initiaza replicarea bazei de date. Se vede in ultimul frame *** 192.168.1.2 da Reset la conexiune.

Scenariul 2:

W2008 ---> W2008

192.168.1.2 face o replicare de tip “Push” la 192.168.1.1

192.168.1.5 (adresa clusterului)          192.168.1. 1                TCP               TCP: [Bad CheckSum]Flags=......S., SrcPort=57227, DstPort=Internet Name Server(42), PayloadLen=0, Seq=3180611831, Ack=0, Win=8192

192.168.1.1 (adresa resursei WINS)       192.168.1.5                TCP               TCP:Flags=...A..S., SrcPort=Internet Name Server(42), DstPort=57227, PayloadLen=0, Seq=3509702165, Ack=3180611832, Win=8192

192.168.1.5 (adresa clusterului)          192.168.1.1                TCP               TCP: [Bad CheckSum]Flags=...A...., SrcPort=57227, DstPort=Internet Name Server(42), PayloadLen=0, Seq=3180611832, Ack=3509702166

192.168.1.5 (adresa clusterului)          192.168.1.1                WinsRpl     WinsRpl:Transport on TCP: Association Start Request Message                      {WinsRpl:3, TCP:2, IPv4:1}

192.168.1.1 (adresa resursei WINS)       192.168.1.5                TCP               TCP:Flags=...A.R.., SrcPort=Internet Name Server(42), DstPort=57227, PayloadLen=0, Seq=3509702166, Ack=3180611877

Si aici vedem, ca si in cazul primului scenariu, ca 192.168.1.1 da Reset la conexiune.

Scenariul 3:

W2003 <--- W2008

192.168.1.3 face o replicare de tip “Pull” de la 192.168.1.2

192.168.1.3 (adresa resursei WINS)               192.168.1.2                   TCP               TCP:Flags=......S., SrcPort=3361, DstPort=Internet Name Server(42), PayloadLen=0, Seq=2827702968, Ack=0, Win=65535 (  ) = 65535               {TCP:2, IPv4:1}

192.168.1.2 (adresa resursei WINS)                  192.168.1.3                TCP               TCP: [Bad CheckSum]Flags=...A..S., SrcPort=Internet Name Server(42), DstPort=3361, PayloadLen=0, Seq=3681779573, Ack=2827702969, Win=8192 ( Scale factor not supported ) = 8192           {TCP:2, IPv4:1}

192.168.1.3 (adresa resursei WINS)               192.168.1.2                   TCP               TCP:Flags=...A...., SrcPort=3361, DstPort=Internet Name Server(42), PayloadLen=0, Seq=2827702969, Ack=3681779574, Win=65535 (scale factor 0x0) = 65535        {TCP:2, IPv4:1}

192.168.1.3 (adresa resursei WINS)               192.168.1.2                  WinsRpl     WinsRpl:Transport on TCP: Association Start Request Message                      {WinsRpl:3, TCP:2, IPv4:1}

192.168.1.2 (adresa resursei WINS)                  192.168.1.3                WinsRpl     WinsRpl:Transport on TCP: Association Start Response Message                   {WinsRpl:3, TCP:2, IPv4:1}

192.168.1.3 (adresa resursei WINS)               192.168.1.2                   WinsRpl     WinsRpl:Transport on TCP: Replication Message       {WinsRpl:3, TCP:2, IPv4:1}

Replicarea aici functioneaza fara nici o problema. Diferenta evidenta fata de cele 2 scenarii care nu functioneaza si acesta este ca initializarea replicarii, cand pleaca de la un server WINS de 2008 foloseste adresa clusterului in loc de adresa resursei WINS!

Solutia

=-=-=-=-=

Intrand in Failover Cluster Manager la clusterul de WINS, am adaugat serviciului de WINS un dependency pe adresa de IP a resursei WINS.

Astfel comunicarea va fi initiata tot pe adresa de IP a resursei si putem evita aceaste probleme la nivel de replicare a bazei de date, fie ea de tip “Push” sau “Pull”.

Sper ca aceste randuri sa va fie de folos in eventual rezolvare a unei problem de replicare in cadrului WINS-ului.

--- Liviu

Salut,

As dori sa va prezint una din urmarile cauzate de o problema foarte “in voga” a anului trecut si anume Virusul Conficker.

Se iau 3 servere Windows Server 2003 SP2, care au fost afectate de virusul mai sus mentionat. Remedierea virusului a fost facuta cu ajutorul KB-ului 962007.

Problema
==========

*** remediere, am observat ca niciunul din serverele afectate nu isi mai primeau adresa de ip de la serverul de DHCP, serviciul de client DHCP era oprit iar orice incercare de a-l porni se solda cu un Access denied.

Teste si verificari pe care le-am facut
================================

In primul rand am vrut sa fim siguri ca “Dhcpcsvc.dll” este actualizat pe toate serverele, asa ca am download-at ultima versiune din articolul de KB 927288.

Actualizarea  DLL-ului pentru DHCP Client Service nu ne-a ajutat.

Am hotarat sa vedem reproducerea problemei intr-un log de Process Monitor.

In logul facut de Process Monitor am putut observa urmatorul lucru:

10:10:10.111111 AM        svchost.exe        784         RegOpenKey                HKLM\System\CurrentControlSet\Services\Dhcp\Parameters   ACCESS DENIED

Solutia
=========

Primim acest Access Denied deoarece contul Network Service nu are permisiuni suficiente pe cheia de registry HKLM\System\CurrentControlSet\Services\Dhcp\Parameters.

Daca adaugati “NETWORK SERVICE” in permisiunile  cheii respective de registrii si ii dati acces “Full Control”, serviciul de client DHCP va porni fara probleme din nou.

--- Liviu

Salut,

am sa abordez astazi o tema recent intalnita despre protocolul Data Link Control (DLC).

Este un protocol mai vechi, dezvoltat pentru comunicarea sistemelor de operare cu IBM mainframe-uri si unele printere  conectate direct la retea.

Protocolul respectiv era folosit in special pana la inclusiv Windows 2000.

Recent mi-am pus intrebarea asupra utilizarii acestuia intr-o infrastructura mai noua *** ar fi de Windows XP sau Server 2003, chiar si Windows Server 2008.

Pentru Windows Server 2008, DLC-ul mai este numai folosibil cu Host Integration Server 2009 (HIS 2009).

La Windows XP si Windows Server 2003 acesta poate fi folosit separat de Host Integration Server. Driverul se poate downloada de aici.

Totusi de tinut minte este ca DLC-ul este “out of support” conform urmatorului articol.

---Liviu