Denne artikkelen inneholder informasjon om hvordan du feilsøker en Lync-klient.
Ta deg tid til å finne egenskapene for implementeringen før du begynner å feilsøke problemer tilknyttet Lync-implementering. Her er noen spørsmål du kan stille:
Hva er kildedelnett og måldelnettet?
Hvor mange brannmurer, rutere og svitsjer er en del av Lync-nettverket?
Er det implementert en Edge-server?
Brukes VLAN? Hvor mange, og er de godt tilkoblet?
Hvor mange områder og DCS er involvert?
Hva er navnet på SIP-domenet? Er det det samme som e-postdomenet eller domenenavnet?
Brukes offentlige sertifikater?
Microsoft har formalisert prosessen i en sjekkliste: Kontrolliste for Microsoft Lync. Et annet verktøy som kan være nyttig, er planleggingsverktøyet for Lync. Å svare på spørsmål i planleggingsverktøyet for Lync-server genererer et nettverksdiagram. Når spørsmålene besvares med de faktiske innstillingene for Lync, vil dette generere et nøyaktig nettverkstopologidiagram som kan brukes til å teste Lync-miljøet for å oppnå best mulig praksis.
Et viktig feilsøkingstrinn for Lync-klienten benytter seg av klientinformasjon. Hold nede Kontroll-tasten og høyreklikk på Lync-ikonet nederst i høyre hjørne på oppgavelinjen i Windows. Du vil se et valg der du kan konfigurere informasjon. Velg dette alternativet som vist nedenfor i figur 1.
Figur 1.
Gjennomgå og undersøk feillinjer fra figur 2 nedenfor. For eksempel kan EWS-feillinjen indikere at det er en feil med Exchange-kommunikasjonen. Selv om dette ikke er en rotårsak, peker det mot en feil et sted mellom Exchange og Lync. Se RUCT-verktøyet (Remote Unified Communications Troubleshooting Tool) i slutten av denne artikkelen. RUCT-verktøyet kan forklare hvorfor noen av feilene i figur 2 oppstår.
Figur 2.
Hvis du oppdager tilkoblingsproblemer fra Lync-informasjon, sammenligner du resultatene ved bruk av en manuell konfigurasjon. Dette er trinnene for manuell konfigurasjon:
Kontroller at konfigurasjonsmodus er automatisk (Verktøy ->Alternativer ->Avansert i Lync-klienten)
Hvis konfigurasjonen allerede er automatisk og ikke fungerer, kan du prøve å sette inn IP-adressen for tilkoblingen (figur 3).
Figur 3.
Et annet trinn for å isolere feilen i IIS eller http er å bekrefte nettadressen lync.domain.com/abs/handler. Plasser denne http-adressen i en nettleser på den berørte klienten.
Feil indikerer at det er et problem med tilkoblingen til IIS på Lync-serveren. Se dokumentasjon fra TechNet for mer informasjon. Portfeil oppdages med en lignende feilsøking. Verifiser SRV-posten for automatisk klientpålogging. Trykk ENTER etter hver linje nedenfor:
Nslookup (enter)
set type=srv (enter)
_sipinternaltls._tcp.contoso.com (enter)
Hvis søket mislykkes, mangler tjenesten Service Locator (SRV) fra DNS-serveren, eller så er det et avbrudd i tilkoblingen til serveren. Et annet tilkoblingspunkt som må nås, er det fullt kvalifiserte domenenavnet til Lync Server. Start en ny nslookup-økt, og skriv inn fqdn.domain.com for å kontrollere at det fullt kvalifiserte domenenavnet kan nås.
Hvis alt ser ok ut hittil, må du slå på Lync-klientlogging på selve Lync-klienten. Se figur 4 og 5 nedenfor. (Klikk på tannhjulsymbolet (figur 4)->verktøy -> alternativer -> generelt på Lync-klienten). Du kan se avmerkingsbokser for å slå på logging og hendelsesfeil i (figur 5).
Figur 4.
Figur 5.
Hvis logging er aktivert, bruk Remote UC Troubleshooting Tool (RUCT) til å verifisere at SRV kan løses. Du kan også kontrollere om klienten hadde tilgang til alle nødvendige sertifikater, porter og tilkoblingsoppføringer.
Hvis det oppstår en feil under påloggingen, kan det tyde på feil med klientgodkjenningen. Feilen kan til og med vise til et problem med sertifikat. Problemer med hurtigbufret legitimasjon eller sertifikat kan løses ved å tømme loggen på klientmaskinen. Den enkleste måten å teste for dette problemet på er å opprette en bruker som aldri har logget på noe som helst sted. En ny bruker må kommunisere med Lync-serveren og hente ny legitimasjon og sertifikat som er registrert på klienten. Hvis denne brukeren er i stand til å logge på, tror vi det følgende vil løse problemet for eksisterende brukere.
Kontroller at DNS oppføringer registreres på vanlig måte. Hvis de har et annet Exchange-godkjent domene, et unikt SIP domene og domenenavn .local og .com, kan det bli forvirrende. Se Microsoft-dokumentasjonen for spesielle scenarier med kompliserte navngivningsskjemaer.
Fjern brukerlegitimasjonsloggen ved å slette hurtigbufferen fra «legitimasjonslåsen». Finn denne låsen i Windows 7. Banen er kontrollpanel \ Alle kontrollpanelelementer \ Legitimasjonsbehandling (eller skriv inn Legitimasjon i Start->-Søk i Windows 7)
Det kan hende at mesteparten av Lync-materialet her er relatert til hvordan du finner informasjon. Man kan finne ut at det ikke er Lync-klienten som må fikses. Som denne artikkelen illustrerer er Lync-klienten avhengig av at servertilkoblingen er angitt på riktig måte. Her er et sammendrag av hva du skal se etter:
DNS – klienten må kunne løse FQDN til Lync-frontserveren.
SRV – klienten ser etter Auto Configuration-posten etter at du har fornyet Lync FQDN
@domain. Klienten sjekker SIP-domenet ditt ved hjelp av SRV-oppføringer for å se om det finnes frontservere med dette navnet
Hvis domenet blir funnet, vil klientsertifikatet på serveren bli krysset av.
Server- og klientsertifikatet må begge være klarerte (utstedt av den samme myndigheten).
Hvis sertifikatet er OK, får klienten forhandlet godkjenning. Dette vil være NTLM eller Kerberos.
Eksterne barrierer til prosessen inkluderer, men er ikke begrenset til, virus, portblokkering av brannmur, bufret legitimasjon og sertifikater, feilaktige godkjenningsinnstillinger, virtuelle mapper og brukerlegitimasjon som er feil eller ikke konfigurert i Lync-kontrollpanelet.
Forhåpentligvis gir dette deg en begynnelse til å begynne å løse problemene tilknyttet pålogging på Lync-klienten. Se flere ressurser her: Microsoft TechNet-bloggerog Microsoft TechNet.