Archívum

Posts Tagged ‘replication’

AD és O365

július 31, 2019 1 hozzászólás

Aktuális történetem szintén AD-ról szó, bár ez érdekes módon most Exchange-problémából indult. Igen, természetesen tudom, hogy az Exchange az AD-ra épül – de azért mégis két külön termék.

Adott egy elég nagy szervezet, több tartománnyal, több Exchange kiszolgálóval. Egyes helyeken a levelezést már kiszervezték O365-be, míg más tartományok maradtak a hagyományos Exchange-verziónál (ami ráadásul most van migráció alatt, egy újabb verzió kerül bevezetésre – de jelen esetben ez lényegtelen).

A gond ott merült fel, hogy bizonyos tartományokból nem lehetett másik tartománybeli felhasználóknak emailt küldeni, „A postaláda címzettjének nincs postaláda-adatbázisa.” hibaüzenettel eldobta – s itt most csak a „belső” („testvér”) tartományokra gondolok.

Szokás szerint a helyzet nem volt ennyire egyszerű, ugyanis első információk szerint csak egy tartomány volt, amelyik nem tudott a cél-tartományba küldeni, miközben minden más irányba csont nélkül kimentek a levelek.

Kezdjük az elejével. A hibaüzenet alapján látszott, hogy a cél-tartományban (amelyik ráadásul O365-be költözött) nem történt meg minden lépés a migráció során, konkrétan a felhasználók TargetAddress címe nem lett kitöltve. Ha ez viszont igaz, akkor miért csak egy tartományból pattannak vissza a levelek? Utánajárva, letesztelve, kiderült, hogy ez csak feltételezés volt – ugyanis máshonnan nem küldtek levelet a cél-tartományba, ezért feltételezték, hogy akkor mindenki rendben tud küldeni. Amint másik „testvér” próbált emailt küldeni, természetesen ott is jelentkezett a hiba.

Rendben, akkor tehát a megoldás a TargetAddress kitöltése. A kollégák elvégezték a feladatot, majd újabb tesztek következtek. Nos, ekkor már valóban teljesült az előző állítás: csak egy (az eredetileg is jelzett) tartományból voltak sikertelenek a küldések, a többiek rendben tudtak küldeni.

Pontosabban, az előző mondatom sem teljes. Ugyanis ki kell egészíteni egy „általában” szócskával a mondat első felét. Volt, amikor sikeresen megérkezett a levél, volt, amikor nem (s ebben az esetben ugyanezzel a hibaüzenettel akadt el). Ugyanattól a feladótól, ugyanannak a címzettnek.

A nyomozás során újra átnéztem minden beállítást, értéket. ADSIEdit volt egyik fő eszközöm, de mindegyre meggyőződtem róla, hogy bármelyik DC-re is csatlakozom a hibás tartományból, annak GC partíciója (hiszen az tartalmazott infót a testvér-tartományról) helyes értékeket ad vissza a címzettről.

Aki ismer, tudja, hogy nem adom fel egykönnyen. Nos, ebben az esetben is elég komolyan foglalkoztatott a történet, szinte éjjel is ezzel aludtam 🙂

A megoldást egy véletlen hozta el. A „hibás” tartományban a kollégák felvettek egy új felhasználót, email-fiókkal, ahogy illik – de röviddel rá eltűnt a postaláda. Jelezték felém, hogy a Bermuda-háromszög ide költözött, így megkértek, hogy próbáljam én helyretenni a fiókot. Amikor elkezdtem utánajárni, akkor egy hirtelen ötlettől vezérelve megpróbáltam RDP-vel rámenni a DC-kre. Egyikre csont nélkül csatlakoztam, a másik… hát az elfogadta a név/jelszót, de utána nem történt semmi. A kollégát kértem, hogy próbálja ő – neki sem sikerült. A furcsa az volt, hogy mmc-vel, adsiedit-el csont nélkül tudtam rá csatlakozni. Kértem, hogy mindegy, milyen módon (ha lehet, „rendesen”, ha nem, akkor bárhogy) indítsák újra a DC-t – s utána érdekes módon minden megjavult.

Utólag persze könnyű okosnak lenni. A hibás email-küldés azért volt véletlenszerű, mert annak függvényében, hogy melyik DC-től kérdezte le a címzettet, kapott/nem kapott jó adatot. Igen, ennek ellentmond az, hogy a rossz DC is már tartalmazta a jó címet (hiszen más módon lekérdeztem tőle), de hogy mitől volt mesebeli (adott is, meg nem is; működött is, meg nem is)… A szokásos „indítsd újra” megtette a hatását 🙂

Kategóriák:Exchange, Windows Server Címkék: , , ,

Hyper-V replika gondok

február 9, 2016 Hozzászólás

Adott cégnél próbálták a replikát beállítani, de nem sikerült, a felpattanó 0x80090303 hibák kissé megakasztották a kollégákat:

Hyper-V failed to authenticate the Replica server <server name> using Kerberos authentication. Error: The specified target is unknown or unreachable (0x80090303)

A replika-szerveren keletkező 14050-es eseménynapló bejegyzések következtében rájöttek, hogy az SPN-név regisztrációval van gond, így megpróbálták felvenni kézileg, az ADUC-ban található attributum-szerkesztővel, amit az alábbi parancs vissza is igazolt:

SetSPN hostnév

Ezzel a probléma nem oldódott meg, amit a kétpercenként továbbra is megjelenő 14050 hibabejegyzések is jeleztek. Azt még ellenőrizték, hogy a Self-nek van autoregisztrációs joga, de utána segítséget kértek.

A hiba elhárításához alapul vettük azt a tudásbázis cikket (KB2761899), ami elég jól leírja a problémánkat, így csak azt kellett követni – némi pontosítással; a tűzfalszabály létrehozása után megszűntek a hibák (VMM szolgáltatás újraindítása nélkül is).

Az egyik pontosítás az, hogy a szükséges RPC portok lekérdezéséhez a tartományvezérlőn futtatjuk ezt:

netsh int ipv4 show dynamicportrange tcp

A kapott eredmény elég meglepő volt (bár utána ellenőrizve, bármely SBS 2011-nél alapból ilyen széles a skála): 6005-től 59530 db port (magyarul 6005-65535). Tehát a Hyper-V hostgépeken ezt kell beállítanunk.

Első körben lekérdezzük a meglévő, grafikus felületre nem kivezetett tűzfal-szabályokat, hogy ha netalán már valaki próbálkozott ennek beállításával, akkor azzal legyünk tisztában:

Get-NetFirewallRule -PolicyStore ConfigurableServiceStore

Jelen esetben nem volt semmi zavaró tényező, így mehettünk tovább. A beállítás akár az említett KB cikkben található vbs segítségével, akár PS segítségével megoldható:

$HT = @{

DisplayName = “VMMS (DC-RPC-Out)”

Description = “Outbound rule to allow traffic to DC using RPC on TCP 6005 to 65535”

Direction = “Outbound”

InterfaceType = “Any”

Action = “Allow”

Protocol = “TCP”

Service = “vmms”

Program = “$($env:systemdrive)\WINDOWS\system32\vmms.exe”

Enabled = “TRUE”

RemotePort = “6005-65535”

PolicyStore = “ConfigurableServiceStore”

}

New-NetFirewallRule @HT

Aki inkább COM objektumokkal akarja létrehozni, itt megtalálja a szükséges scriptet. Amennyiben rosszul hoztuk létre a tűzfalszabályt, a törléshez először pontosan leszűrjük a törlendő bejegyzést, majd töröljük:

Get-NetFirewallRule -PolicyStore ConfigurableServiceStore | where {$_.displayname -like “*Felesleges tűzfal*”} | Remove-NetFirewallRule

Alap-probléma elhárítva, jöhetett a replika beállítása 🙂

AD-replikáció problémák

január 7, 2016 1 hozzászólás

Az egész úgy kezdődött, hogy adott cégnél a kollégák első alkalommal próbálták használni a GPMC-t Win10-ről. Amikor adott házirendet próbáltak megnyitni, pontosabban annak GPP részét, akkor az alábbi 0x80070041 kódú hibaüzenettel szembesültek:

GPO-error

Nem értették a dolgot, hiszen egyrészt a házirend-ág teljesen használható volt, másrészt látszólag minden rendben volt a két DC között (AD Sites&Services-el kért replikáció nem jelzett hibát, repadmin /showrepl szintén jó értékeket mutatott). Arra gondolva, hogy ez valószínűleg kliens-oldali gond, a kért házirend-módosítást megoldották egy másik adminisztratív gépről, majd napirendre tértek a dolog felett.

Mondhatni szerencsére, nem sok idő elteltével egy másik probléma is felmerült: nevezetesen, hogy egy kliens-gépen nem futott le egy szintén házirendben beállított parancsállomány. A próbálkozások során megpróbálták közvetlenül megnyitni a házirendet, s kézzel lefuttatni – ekkor derült ki, hogy azon a tartományvezérlőn, amelyiken hitelesített a kliens, a Sysvol tartalma nem egyezett meg a másik tartományvezérlőn található tartalommal, többek között hiányzott a kérdéses batch-állomány is.

A nyomozás során tisztáztuk az előzményeket is: a tartomány egy régi, 2000-es tartományról lett folyamatosan migrálva (most 2008 R2-es DC-k vannak), de a tartomány szintje 2003-ason van, ezért értelemszerűen a replikációra még FRS-t használnak, nem DFSR-t, így az eseménynaplóban ezt érdemes ellenőrizni. Nos, nem kellett sokat keresni, az FRS naplójában ott virított az Ntfrs 13568-as hiba, amiből kiderül a turpiság: a Wrap Journal sérült. A hibaüzenet mellett ugyanakkor ott van a megoldás is, amelynek során egy teljes szinkronizációt hajtottunk végre, így a két Sysvol mappa egyforma lett, így a kérdéses parancsállomány is átkerült – öröm, boldogság :).

Utólag elmondták, hogy ezzel egy másik, régóta hajszolt problémára is pont került: időnként a kliensek nem csatolták fel a GPP-ben hozzájuk rendelt meghajtókat. Ezt is rengeteget keresték, de mivel a replikációt rendben levőnek gondolták, a gpresult eredménye pedig azt mutatta, hogy a házirend érvényesül, nem tudtak merre indulni…

Kategóriák:Windows Server Címkék: , ,