Friss telepítés után nem indul el a Lync 2013 Front-End Service


Úgy adódott, hogy egy nagyon kedves ügyfelemnél egy teljesen új telepítésu Lync 2013-as környezetet építettem. Minden az elvárt módon, egyszeruen ment. Nem is mehetett volna másként, hiszen ez Lync. Az elso probléma rögtön azután jött, hogy már minden funkciót telepítettünk és indítottuk volna a szolgáltatásokat.

Az összes szolgáltatás beindult, kivéve a Front-End. Az starting állapotba maradt. Az eseménynaplóban kevés használható információ volt ami a hiba megoldásához vezetett volna. Látszólag.

Az eseménynapló tele volt kapcsolódási kísérleteket tartalmazó hibával, ami elnyomta a számunkra hasznos hibaüzenetet. Ezek a hibák mindegyike már csak okozat volt, ugyanis a Front-End szolgáltatás nem futott, így a Lync saját automatikus ellenorzései által keltett hibák voltak. Tehát nem ezek miatt nem indult el a Front-End szolgáltatás. Példa a félrevezeto hibákra:

Untitled

 

Ahhoz, hogy a hibát jobban megértsem kézzel újraindítottam párszor a szolgáltatást és figyeltem az eseménynaplót. A szolgáltatás üzemszeruen indult, azonban egy ponton az üzemszeru indulás megállt és Starting állapotba ragadt. Az utolsó üzenet az eseménynaplóban egy Warning üzenet volt:

Untitled2

 

Eloször nem is gondoltam, hogy ennek a hibához köze lehet. De második-harmadik indításnál is ez játszódott le, így nem lehetett mindezt figyelmen kívül hagyni. A széken hátradolve, egeret billentyuzetet hátrahagyva elkezdtem kutatni az emlékeimben, hogy mi lehet itt az összefüggés. Aztán hirtelen összeállt a kép:

  • a UserReplicator komonens valóban a Front-End kontextusában fut
  • a UserReplicator az Active Directory címtár összes tartományával szeretne kapcsolatba lépni alapértelmezett beállítások szerint
  • az ügyfél környezetében a child domain biztonsági okokból hálózatilag teljesen elkülönített, értsd, csak a DC-k látják egymást, az egyik tartomány kliensei a másik tartomány tartományvezérloit nem látják és fordítva.

Innen a kérdés megválaszolása már egyszeru. Ugyanis két ellentmondó követelményünk van:

ügyfél követelménye: nem lehet elérni az összes tartomány tartományvezérlojét <– –>termék követelménye: el kell érni minden tartományvezérlot

Ezt kell összeilleszteni. Erre (is) való a Set-CsUserReplicatorConfiguration cmdlet. Segítségével mi a környezetünkben hozzáadtuk az egyetlen tartományt amit elérhet a Lync, ezzel az elérhetetlen tartományt kihagyva és kikerülve. A cmdlet példájában szereplo harmadik parancsot használtuk a megfelelo tartományi információ behelyettesítésével:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add="dc=fabrikam,dc=com"}

 

Minden jó, ha a vége jó. Az ügyfél boldog, a tanácsadó nyugodt, a szolgáltatás fut.

Comments (2)

  1. Anonymous says:

    Kedves Richard,

    Igazad van, forest-wide alkalmazás, ahogy abban is igazad van, hogy elég akár csak egy domain controller is amit a DSDiscover segítségével megtalál a szerver. Azonban ebben az ügyfélhelyzetben ez sem volt engedélyezett. Az ominózus child tartomány tartományvezérlőit a parent tartományból csak a DC-k érhették el. Pech.

    Lehet, hogy lassan elindult volna (ezt letesztelem, mert erre nem tudom csak sejtem a választ), de ez nem optimális. A javasolt kezelési mód az exclude.

    Egyet kell Veled értenem abban, hogy ez egy nagyon fontos komponens!

  2. Richard says:

    Mivel a Lync egy forest-wide alkalmazás, a dobozból kicsomagolva (gyk. install után) azt hinné teljesen logikusan h. a forest minden tartományában fel tudja venni a kapcsolatot min 1. DC-vel (nem kell minddel, elég ha sikerül 1 élőt elkapnia). Ha nem tudja felvenni, végsősoron el kellene indulnia a FE service-nek (ahogy  te is láttad starting-ban maradt és nem lett stopped), de lehet h. várni kell 10-15 v. még több percet amíg a kezdeti szinkronizálási kísérletet feladja és elindul a service miközben a user replicator átvált a háttérben próbálkozásra. Rui Maximo ezért szorított helyet a Lync poszteren annak a fránya és elsőre oda nem illőnek tűnő AD szinkronizációs kis ábrának.