DsRoleGetPrimaryDomainInformation failed with error “6BA”

Bevezetés

Úgy alakult, hogy az egyik ügyfelemnél magas rendelkezésre állású Lync 2013-as környezetet kell(ett) építenem. Lync 2013 esetében ez gyakorlatilag egyet jelent az SQL mirroring használatával, mivel hivatalosan már nem támogatott az SQL clustering a Lync 2013 esetében. Ez a support állítás is megér majd késobb egy blog bejegyzést, de ezen most emelkedjünk felül.

Az SQL replica kiépítése nem túl komplikált a Lync esetében, ezért nem is tartottam tole túlságosan. Az elképzelés az volt, hogy három kiszolgálónk lesz, egy primary, egy mirror és egy witness kiszolgálóval:

Ahogy említettem a mirroring kialakítása egyszeru. A támogatott SQL verziók valamelyikét kell telepíteni, majd a Topology Builder alkalmazásban beállítáni, hogy ki a mirror és ki a witness:

Ezt követi szerencsés esetben a topológia publikálása. Ami az ügyfélkörnyezetében valamint a saját demo környezetemben is konzekvens módon a következo hiba jelent jött:

Megpróbáltam Powershell segítségével a –verbose paraméterrel is, hátha több és hasznosabb információt kapok (sajnos nem hozta a várt eredményt):

Problémafeltárása

Sajnos magamra maradtam, a belso tudásbázisunkban semmi használható információt nem találtam. Így maradt a magányos problémafeltárás ami jó kaland, pláne akkor ha elég sok információnk van ahhoz, hogy a hibát megoldjuk. Két fontos információ áll rendelkezésünkre:

• DsRoleGetPrimaryDomainInformation – ezt a függvényt hívjuk és ez a hívás ad vissza hibát. A stackben tisztán látszik, hogy ez az utolsó hívás.
  • 
• 6BA – ezt a hibát adja vissza a DsRoleGetPrimaryDomainInformation függvény

Általában a hibából indulok ki, utána próbálom azt összeegyeztetni az adott funkció muködésével. Az ERR.EXE kiváló, egyben pótolhatatlan eszköz arra, hogy a hibakódokat “visszafejtsük”. Most is az err.exe –t hívtam segítségül, amivel sikerült megállapítani azt, hogy a 6BA = “The RPC server is unavailable”. Eddig ez 5 perc.

Ha az RPC server nem elérheto, akkor joggal élhetünk, azzal a feltételezéssel, hogy valami kommunikációs hiba van és elso, elokelo helyen szerepel a gyanúsított listán a szerveren levo tuzfal. De mielott elore rohanunk, gondolkodjunk kicsit. A függvény hívásakor kapjuk az RPC server nem elérheto hibaüzenetet. De vajon milyen porton akar kommunikálni? Ha ez valós RPC forgalom, akkor a How RPC Works leírás lehet segítségünkre. Hosszú olvasmány, de ebbol ami nekünk fontos az az, hogy a TCP 135, TCP 445 és dinamikus port range jöhet szóba. Egy másik lehetséges irány a port megtalálásához az, ha DsRoleGetPrimaryDomainInformation függvényt megnézzük az MSDN-en.

Itt megtalálhatjuk azt, hogy ez a függvény a netapi32.dll-ben van implementálva:

Történelmileg a netapi32.dll-ben több sérülékenység is volt, ami TCP 135 és / vagy TCP 445 portokon keresztül folt támadható. Ennek kiderítése szintén kb. 5 percnyi munka.

Megvan a hiba, van egy sejtésünk, hogy a TCP 135 vagy a TCP 445 porton keresztül nem érheto el a Master SQL szerver. Nincs is más dolgunk, mint elindítani újra az adatbázis telepítést és közben hálózati monitorozást végezni. Rászurve a TCP 445-re egy érdekes dolog látható:

A Front-end kiszolgáló háromszor próbálja elküldeni ugyanazt a csomagot, de nincs válasz. Bingo. Újabb 5 perc.

Probléma

Ha a Front-End kiszolgáló nem éri el az SQL szervereket a TCP 445-s porton keresztül, akkor a database mirror kialakítása a következo hibával megáll: DsRoleGetPrimaryDomainInformation failed with error “6BA”

Megoldás

A lokális tuzfal helyes konfigurálásának több módja is van. Az egyik lehetséges megoldás egy új tuzfalszabály létrehozása ami engedélyezi a TCP 445-s portot:

A tuzfalszabály létrehozása után az SQL mirror kialakítása hiba nélkül lefut:

Zárszó

Néhány záró gondolat a végére:

• A hiba az íróasztalomon hevert január óta. Tudtam, hogy megoldom, csak eddig idom nem volt rá. A határido viszont a legnagyobb múzsa. Kedden jön hozzám az ügyfelem. Figyelj Gergo, a hibát megoldottam.
• Megoldás a lokális tuzfal kikapcsolása. Több ügyfelem is most mondhatja, hogy bezzeg, ha nem lenne tuzfal, akkor nem lenne ez a probléma, tehát igazunk van, kapcsoljuk ki. Továbbra is azt mondom, hogy NE.
• A tuzfal helyes konfigurálása többféle módon is megtörténhet. A TCP 445 portot több protokoll is használja, ezért egy File and Printer Sharing látszólag kinyitja és engedélyezi a forgalmat, de nem lesz teljes értéku.
• Nem, minden az aminek látszik. Elso ránézésre ez egy komoly SQL Mirror hibának tunik. Eloször pánikoltam, mert nem értek az SQL-hez mélyen. De nem minden az aminek látszik és itt is bebizonyosodott, hogy alapos platform ismeret kiment a bajból.
• Laci, tiéd a következo ilyen hiba megoldása.