Felsökning för klientinloggning på servrar i Lync 2010 och 2013

Den här artikeln innehåller information om hur du felsöker en Lync-klient.

Innehållsförteckning:

1. Hämta distributionsspecifik information
2. Testa Lync-klientanslutning
3. Återställ Lync-klienten
4. Åtgärda problemet

Problem 1: hämta distributionsspecifik information

Innan du börjar felsöka problem med Lync-distributioner ska du identifiera distributionens egenskaper. Vissa frågor att ställa kan vara:

1. Vad är källans undernät och målundernät?

2. Hur många brandväggar, routrar och switchar är en del av Lync-nätverket?

3. Är en Edge-Server distribuerad?

4. Används VLAN? Hur många och är de korrekt anslutna?

5. Hur många platser och domänkontroller ingår?

6. Vad är namnet på SIP-domänen? Är det samma som e-postdomänen eller domännamnet?

7. Används offentliga certifikat?

Microsoft har formaliserat processen i en checklista: Checklista för Microsoft Lync.  Ett annat verktyg som kan vara användbart är Planeringsverktyget för Lync. Om du svarar på frågor på planeringsverktyget för Lync-servern skapas ett nätverksdiagram. Under förutsättning att frågorna besvarades med den faktiska inställningen för Lync-distribution genererar detta ett korrekt diagram över nätverkstopologin, vilket kan användas för att granska Lync-miljön för bästa praxis.

Överst på sidan

Problem 2: testa Lync-klientanslutningen

Ett viktigt felsökningssteg för Lync-klienten är informationsegenskapen för klienten. Håll ned kontrolltangenten på tangentbordet och högerklicka på Lync-ikonen i det nedre högra hörnet i fönstrets aktivitetsfält. Du ser ett alternativ som kallas för Konfigurera information. Välj det alternativ som visas nedan i bild 1.

Bild 1.

Granska och utforska felrader från bild 2 nedan. Felraden för EWS kan exempelvis indikera att det finns ett Exchange-kommunikationsfel. Även om detta inte är grundorsaken indikerar det att det finns ett fel mellan Exchange och Lync. Se det fjärranslutna Unified Communications-felsökningsverktyget (RUCT-verktyget) i slutet av den här artikeln. RUCT-verktyget kan hjälpa till att förklara varför vissa av felen i bild 2 uppstår.

Bild 2.

Manuell konfiguration

Om du stöter på ett anslutningsproblem i Lync-informationen ska du jämföra resultaten med hjälp av en manuell konfiguration. Steg för manuell konfiguration:

1. Verifiera att konfigurations läget är automatiskt (Verktyg -> Alternativ -> Avancerad på Lync-klienten)

2. Om konfigurationen redan är automatisk och misslyckas ska du försöka med att ange IP-adressens anslutning (bild 3).

Bild 3.

Adressökning

Ett annat steg för att isolera felet till IIS eller http är att verifiera URL-adressen för lync.domain.com/abs/handler URL. Skriv http-adressen i en webbläsare i den berörda klienten.

Ett fel indikerar ett anslutningsproblem med IIS på Lync-servern. Mer information finns i dokumentationen för TechNet . Portfel med en liknande sökväg för felsökning. Kontrollera SRV-posten för automatisk klientinloggning. Skriv Retur efter varje rad nedan:

• Nslookup (Retur)

• set type=srv (Retur)

• _sipinternaltls._tcp.contoso.com (Retur)

Om sökningen misslyckas saknas antingen tjänstespår (SRV) från server-DNS eller så finns en blockering i anslutningen till servern. En annan anslutningspunkt som måste gå att nå är Lync-serverns fullständiga offentliga namn. Starta en ny felsökningssession och skriv fqdn.domain.com för att bekräfta att det fullständiga offentliga domännamnet kan nås.

Lync-klientloggning

Om allt stämmer hittills ska du slå på klientinloggning för Lync på själva Lync-klienten. Se bild 4 och 5 nedan. (klicka på kugghjulssymbolen (bild 4) -> Verktyg -> Alternativ -> Allmänt i Lync-klienten). Du ser kryssrutor där du kan att slå på loggnings-och händelsefel (bild 5).

Bild 4.

Bild 5.

Om du loggar använder du det fjärranslutna UC-felsökningsverktyget (RUCT) för att verifiera att SRV går att lösa. Du kan även kontrollera att klienten har åtkomst till alla nödvändiga certifikat, portar och anslutningsposter.

Överst på sidan

Problem 3: återställa Lync-klienten

Om ett fel uppstår under inloggningen kan felet bero på att autentiseringsfel hos klienten. Felet kan även innebära att ett certifikatproblem uppstår. Cachelagrade inloggningsuppgifter eller certifikatproblem kan åtgärdas genom att rensa historiken på klientmaskinen. Det enklaste sättet att testa det här problemet är att skapa en användare som aldrig har loggat in någonstans. En ny användare måste kommunicera med Lync-servern och få nya uppgifter och certifikat registrerade på klienten. Om användaren kan logga in tror vi att följande kan åtgärda problemet för befintliga användare.

1. Kontrollera att det inte finns några felaktigheter för hur DNS-poster skapas. Om användare har en annan Exchange-accepterad domän, en unik SIP-domän, och ett .local- och .com-domännamn, kan förvirring uppstå. Läs dokumentationen från Microsoft för specifika scenarion där namnscheman är komplexa.

2. Rensa användarens historik för inloggningsuppgift genom att rensa cache från ”Credential Locker”. Hitta detta i Windows 7 med sökvägen Kontrollpanelen\Alla objekt i kontrollpanelen\Autentiseringshanteraren (eller skriv ”cred” i Start -> Sök i Windows 7)

3. Rensa historiken för användarregister:

• Gå till registret och ta bort de användarspecifika registernycklarna
• Ta bort namnmappen för användarens unika namn som orsakar problem från HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient
• Ta bort namnmappen för användarens unika namn som orsakar problem från HKEY_CURRENT_USER\Software\Microsoft\Communicator\ConfAddin\
• Ta bort användarmappen från \Users\username\AppData\Local\Microsoft\Communicator
• Kör ipconfig /flushdns && ipconfig/registerdns på klienten
• I Windows XP öppnar du Windows Explorer och går till C:\Documents och mappen Settings\User\Application Data\Microsoft\Crypto\RSA\ och tar bort undermappen för RSA-nyckeln

Överst på sidan

Problem 4: åtgärda problemet

Du kanske upptäcker att det mesta av Lync-materialet här är relaterat till hur du hittar information. Tänk på att det vanligtvis inte är Lync-klienten som måste åtgärdas. Så som den här artikeln visar är Lync-klienten beroende av att serveranslutningen är korrekt konfigurerad. Så här sammanfattar du vad du ska söka efter:

1. DNS – klienten måste kunna lösa FQDN för Lync-frontservern.

2. SRV. Klienten söker efter den automatiska konfigurationsposten efter att den hittat Lync-FQDN

3. @domän. Klienten kontrollerar din sip-domän för att se om det finns några frontservrar med det namnet, med hjälp av SRV-poster

4. Om domänen hittas kommer klientcertifikatet att kontrolleras på servern.

5. Server- och klientcertifikatet måste båda vara betrodda. (utfärdad av samma utfärdare).

6. Om certifikatet är OK förhandlas autentisering för klienten. Detta är NTLM eller Kerberos.

Kringliggande hinder för processen innefattar, men är inte begränsat till, antivirus, blockering av brandväggsport, cachelagrade inloggningsuppgifter och certifikat, felaktiga autentiseringsinställningar, virtuella kataloger, felaktiga användaruppgifter eller att det inte konfigurerats i kontrollpanelen i Lync.

Förhoppningsvis ger detta en fingervisning till var problemet ska åtgärdas när du stöter på inloggningsproblem med Lync-klienten. Läs ytterligare resurser från Microsoft TechNet Blogs och Microsoft TechNet.

Överst på sidan