Quantcast
Viewing all articles
Browse latest Browse all 34890

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ésőbb 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 tőle 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:

Image may be NSFW.
Clik here to view.
image

Ahogy említettem a mirroring kialakítása egyszerű. 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:

Image may be NSFW.
Clik here to view.
image

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övetkező hiba jelent jött:

Image may be NSFW.
Clik here to view.
image

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):

Image may be NSFW.
Clik here to view.
image

Problémafeltárása

Sajnos magamra maradtam, a belső 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ó műkö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.

Image may be NSFW.
Clik here to view.
image

Ha az RPC server nem elérhető, akkor joggal élhetünk, azzal a feltételezéssel, hogy valami kommunikációs hiba van és első, előkelő helyen szerepel a gyanúsított listán a szerveren levő tűzfal. De mielőtt előre rohanunk, gondolkodjunk kicsit. A függvény hívásakor kapjuk az RPC server nem elérhető 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 ebből 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:

Image may be NSFW.
Clik here to view.
image

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 érhető 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ászűrve a TCP 445-re egy érdekes dolog látható:

Image may be NSFW.
Clik here to view.
image

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övetkező hibával megáll: DsRoleGetPrimaryDomainInformation failed with error “6BA”

Megoldás

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

Image may be NSFW.
Clik here to view.
image

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

Image may be NSFW.
Clik here to view.
image

 

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 időm nem volt rá. A határidő viszont a legnagyobb múzsa. Kedden jön hozzám az ügyfelem. Figyelj Gergő, a hibát megoldottam. Image may be NSFW.
    Clik here to view.
    Winking smile
  • Megoldás a lokális tűzfal kikapcsolása. Több ügyfelem is most mondhatja, hogy bezzeg, ha nem lenne tűzfal, akkor nem lenne ez a probléma, tehát igazunk van, kapcsoljuk ki. Továbbra is azt mondom, hogy NE.
  • A tűzfal 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ékű.
  • Nem, minden az aminek látszik. Első ránézésre ez egy komoly SQL Mirror hibának tűnik. Előszö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övetkező ilyen hiba megoldása. Image may be NSFW.
    Clik here to view.
    Winking smile
Image may be NSFW.
Clik here to view.

Viewing all articles
Browse latest Browse all 34890

Trending Articles