Office 365 blog

Bár nem teljesen kapcsolódik a BPOS Office 365-höz, azért megosztom veletek hátha tanulságos, milyen jellegű problémákba lehet belefutni, ha mi állunk neki Lync szervert telepíteni/konfigurálni. Microsoft Online-on jóval egyszerűbb a helyzet csak bekattingatni az admin interfészen, ha esetleg baj van szólni a támogatásnak.

Van nálunk üzemben egy Lync szerver, amit már nagyon gyakran használunk az ügyfelekkel és a Microsofttal is a federáció révén. A federációra lehetőség lesz az Office 365-ben is, Berlinben az oktatáson láttam is, tényleg csak pár kattintás a beállítása az admin interfészen, fel lehet venni a domaineket vagy meg lehet adni, hogy bárkivel/senkivel federálunk és kész.

A helyi szerverre telepített Lync esetén a federációhoz egy Edge szerver kell, ami egy másik gépet igényel, nem lehet a Lync szerverre telepítve. (*)  Fel is telepítettem a szervereket a doksi szerint, nem is volt velük baj, a külső elérés és a federáció is remekül működött. Azt kivéve, hogy a beszélgetés vagy alkalmazás megosztás nem működött, ha az egyik felhasználó a belső LAN-on volt a másik pedig valahol NAT mögött (NAT nélkül remekül ment). Még telepítéskor használtam a Microsoft által publikált Lync Protocol Workload Poster -t, amit ajánlok mindenkinek, mert a certificatek és hálózati forgalom elég jól össze vannak foglalva. A hibát okozó esetben nagyon leegyszerűsítve az alábbiak szerint néz ki:

Mivel szerettük volna használni kívülről is a Lync-et, ma este nekiestem megtalálni a hibát. Mielőtt a wireshark-ot előszedtem volna, első dolgom a kliens naplózás beállítása volt. Ez egy jelölőnégyzet az általános opciók között és a user profil Tracing nevű könyvtárába ( pl. c:\users\username\tracing ) teszi a logokat, ez elég részletes, megtaláltam a hibát, de okosabb nem lettem tőle:

12/21/2010|20:46:01.172 1324:1328 TRACE :: CRTCMediaController::OnStreamingEvent[00344780] - 0864F900, event=RTC_ME_STREAM_STOPPED, type=RTC_MT_AUDIO, dir=RTC_MD_CAPTURE, reason=RTC_ME_CAUSE_CONNECTIVITY_CHECK_FAILURE

Nem maradt más hátra nekiestem a Lync Edge Logoknak. Ez akár nagyon részletes is tud lenni, még az adott .c fájl sora is szerepel benne, ahol a hiba előjött. Itt már több infó volt:

TL_ERROR(TM_Tdi) [0]08B8.0514::12/21/2010-20:09:38.732.000000b1 (MediaRelay,ConnectAddrInterface:tdix.c(6958))ConnectAddrInterface: failed to connect, status=c000023c?

TL_ERROR(TM_Tdi) [0]08B8.0514::12/21/2010-20:09:38.732.000000b2 (MediaRelay,ConnectAddrInterface:tdix.c(6966))               Connecting 192.168.001.023-3478 -> 010.000.000.077-3778 

192.168.1.23 a Lync edge szerver címe
10.0.0.77 a belső hálózaton figyelő Lync kliensé

Hoppá! A Lync Edge szerver közvetlenül kapcsolódik a klienshez? A probléma megértéséhez tudni kell, hogy az Edge szervernek legalább 2 hálózati kártyája van, az egyik az internetre csatlakozik, a másik a belső hálózatra. Mivel egy gépen az alapértelmezett átjáró csak 1 lehet normál esetben, ezért ez kifele az internet felé kell, hogy mutasson. A másik interfész csak a belső háló egy subnetjét látta, ezen volt a Lync szerver is, viszont a klienshez nem volt útvonala, hiszen a workload ábra alapján nem is kell. A doksiban írtak erről, hogy állítsunk be route-okat kézzel a belső LAN felé, de nálunk nem láttam értelmét, hiszen csak az ugyanazon a subneten lévő lync szerverhez kapcsolódik. Hát nem.
Egy parancs kiadása az edge szerveren megoldotta a problémát és már minden flottul működik:

route add -p 10.0.0.0 mask 255.0.0.0 192.168.1.1

(*) Újdonság a Lync szerveren, hogy a Mediation Gateway-t már rá lehet telepíteni a Lync Pool-ra, egy szerverrel kevesebb kell! Ha federáció is kell a mininum két szerver szükséges a 3 helyett.

Végül a teljes poszter: