Skype/Lync mit vielen Domains

Viele kleine Firmen werden vermutlich nur ein oder wenige SIP-Domains betreiben, während "Hoster" natürlich hunderte und mehr auf ihrer Plattform betreiben wollen. Diese Seite beschäftigt sich den Besonderheiten, wenn Sie in Lync sehr viele SIP-Domains betreiben wollen. Sie gilt in Teilen aber auch für Hoster, die auf einer Lync Umgebung mehrere Kunden betreiben aber leider NICHT in der "Lync Hosting Provider"-Liste gepflegt sind.

Die hier beschriebene Problematik betrifft auch Lync Hosting Firmen, die aus dem Grund keine Skype-Federation und keine OpenFederation anbieten können.

Haben wir ein Problem ?

Ja, es gibt Einschränkungen, wenn sie sehr viele Domänen haben denn gleich mehrere Themen fallen mir da ein

  • Anmeldung der Clients über "_sipinternalts.tcp.<sipdomain>"
    Ein interner Client fragt diesen SRV-Record ab und verbindet sich dann mit dem angegebenen Lync Pool
  • Anmeldung der Clients über "_sip._tls.<sipdomain>"
    Ein interner Client fragt diesen SRV-Record ab und verbindet sich dann mit dem angegebenen Edge-Server
  • Federation über "_sipfederationtls._tls.<sipdomain>"
    Andere Partner können bei Federation diesen Eintrag nutzen, um den Weg zum Edge Server zu finden

In allen drei Fällen finden sie massenhaft Beschreibungen, wie dies "richtig" gemacht wird. Der Zielserver ist in der gleichen Domäne wie die SIP-Domäne. Das sieht dann so aus:

_sip._tls.msxfaq.net                SRV 0 0 443  sip.msxfaq.net
_sipfederationtls._tcp.msxfaq.net   SRV 0 0 5061 sip.msxfaq.net
sip.msxfaq.net                      A   1.2.3.4

Was würde bei vielen Domänen aber bedeuten, dass jede Domäne einen eigenen Edge-Server haben müsste oder der eine Edge-Server unter vielen Namen erreichbar sein muss. Das ist per DNS noch einfach aber die Kommunikation wird per SSL abgesichert und der Client prüft natürlich den Namen im Ziel. Schöner wäre hier, wenn die SRV-Records auf einen generischen Namen gehen könnten. 

Die Zertifikate (Edge und Pool)

Wer aber nun mehrere SIP-Domains hat, kann nur bis zu einer gewissen Menge an Domains dieses Prinzip durchhalten. Die Edge-Server und Pools benötigen nämlich ein SAN-Zertifikat, in der dann mehrere Namen enthalten sind. Da gibt es aber gleich zwei Probleme.

  • 1024 Byte Limit im SAN-Zertifikat
    Das Feld für die SAN-Einträge kann nur 1024 Bytes enthalten. wenn alle SIP-Domains nur 4 Stellen hätten und man ".de" anhängt und "sip." als Präfix verwendet und das "&" als Trenner dazurechnet, dann kommen schon 12 Zeichen zusammen. Mehr als 85 Namen passen nicht rein
  • Limit der Namen durch die CA
    Für den Edge Server werden meist Zertifikate einer "CA" gekauft. Auch hier haben verschiedene CAs entsprechende Vergaberichtlinien, z.B.: nicht mehr als 5 oder 25 Namen. Fragen Sie vorher nach
  • Umständlicher Ausstellungsprozess
    Selbst wenn die beiden ersten Bedingungen noch passen, muss die Zertifizierungsstelle für jeden Namen die Verifikation durchführen, wobei hier jeder Name aus einer anderen Domain ist. Das kann lange dauern, bis alle Admin-C zugestimmt haben
  • Veränderungen
    Sollten sie eine neue SIP-Domain addieren wollen, dann erlauben dies nicht alle Zertifizierungsstellen so einfach. Einige erfordern die Neuausstellung bei voller Berechnung. Nicht gerade flexibel.

Die Verwendung von SAN-Namen für Umgebungen mit wenigen SIP-Domains ist angeraten.

By default, queries für DNS records adhere to strict domain name matching between the domain in the User name and the SRV record. If you prefer that client DNS queries use suffix matching instead, you can configure the DisableStrictDNSNaming group policy
Quelle: Required DNS Records für Automatic Client Sign-In http://technet.microsoft.com/en-us/library/bb663700(v=office.12).aspx 

Die passende DNS Konfiguration

Wer nun also viele Domains auf der gleichen Umgebung hosten will, muss sich Gedanken über die sichere Verbindung und die Standardeinstellungen der Clients und Kommunikationspartner machen. Aktuell sieht es so aus, dass sie folgende Konfiguration nutzen können, um möglichst flexible mehrere SIP-Domains zu betreiben ohne bei Änderungen jedes mal Zertifikate ändern zu müssen. In der Lync Topologie sind alle SIP-Domains "gleich" aber eine Domain muss man sich aussuchen, die im Namen für die SimpleURLs und im Namen des Edge erscheint. Ich nenne diese "<hauptdomain>". Alle anderen SIP-Domains fasst ich unter "sipdomain1" zusammen. Die Namen können durchaus in einem SAN-Zertifikat zusammengefasst werden.

Einträge für die Hauptdomain

Zuerst müssen die Server natürlich SSL anbieten und dazu müssen die Hauptdomain festgelegt, die Einträge im DNS vorhanden und die Zertifikate vorhanden sein:

Name  Typ Daten Public Zert Beschreibung

sip.<hauptdomain>

A 

<IP-Adresse>

 Single
SAN

Access Edge als A-Record und der Name ist auch im Zertifikat vorhanden.

webconf.<hauptdomain>

A

<IP-Adresse>

 Single
SAN

Data Edge als A-Record und der Name ist auch im Zertifikat

avedge.<hauptdomain>

A

<IP-Adresse>

Nein

Der Name muss auflösbar sein aber das Zertifikat ist ein privates internes Zertifikat 

dialin.<hauptdomain>

A

<IP-Adresse>

 Single
SAN
Wildcard

xxx 

meet.<hauptdomain>

A

<IP-Adresse>

 Single
SAN
Wildcard

 

webapp.<hauptdomain>

A 

<IP-Adresse>

 Single
SAN
Wildcard

 

lyncdiscover.<hauptdomain>

A

<IP-Adresse>

kein

 

webmail.<hauptdomain>

A

<IP-Adresse>

ja

Adresse für den späteren Zugriff auf Exchange EWS und Autodiscover

autodiscover.<hauptdomain>

A

<IP-Adresse> 

ja 

Diese Adresse kann per SSL erreichbar sein, wenn es auch Postfächer für die Hauptdomäne gibt.

asredir.<hauptdomain>

A

<IP-Adresse> 

Nein ! 

Der Webserver, der auf diese Adresse reagiert, darf nicht per HTTPS erreichbar sein, da ansonsten der Client eine SSL-Warnung liefert. 

Einträge für jede weitere Domain

Achtung: Die Zusatzdomains können Sie per PowerShell oder den Topology Builder eintragen und würden auch beim Erstellen der Zertifikate mit addiert.

Topology Builder behautet man muss Setup auf jedem FE starten.

Der DNS-Administrator für die zusätzliche Domain muss natürlich einige Einträge vornehmen:

Name  Typ Daten Beschreibung

sip.<sipdomain>

CNAME

 
sip.<hauptdomain>

Dieser Alias dienst als Ziel für die SRV-Records und sollte in der gleichen Domain sein, damit die Clients sich nicht "beschweren"

lyncdiscover.<sipdomain>

CNAME

 
lyncdiscover.<hauptdomain>

Dieser Eintrag ist für die mobilen Clients besonders wichtig, aber wird nur per HTTP angesprochen. Hier gibt es keine Zertifikatprobleme

autodiscover.<sipdomain>

CNAME

 
asredir.<hauptdomain>

Der Eintrag muss auf einen Webserver verweisen, der NICHT per https erreichbar sein darf, damit die Umleitungslogik von Autodiscover ohne Zertifikatswarnung greifen kann 

_sip._tls.<sipdomain>

SRV

 
priority = 5
weight   = 25
port     = 443
hostname = sip.<sipdomain>

Der reguläre SIP-Eintrag für Clients mit einem Ziel in der gleichen Domain. Das Ziel ist aber ein CNAME auf den echten Server

_sipfederationtls._tcp.<sipdomain>

SRV 

 
priority = 5
weight   = 25
port     = 5061
hostname = sip.<sipdomain>

Der reguläre SIP-Eintrag für Clients mit einem Ziel in der gleichen Domain. Das Ziel ist aber der CNAME auf den echten Edge Server.

Sie die Sie verschiedenen Einstellungen in ihrem DNS-Server eintragen, ist natürlich abhängig vom Betreiber des DNS-Servers. Wenn ein Provider die Verwaltung der DNS-Zone übernimmt, dann müssen Sie prüfen, ob die Einträge überhaupt möglich sind. Die "A-Records" lassen sich oft als "Subdomain" tarnen, z.B.: bei 1und1. Die Eintragung der SRV-Records hingegen kann knifflig werden.

Das sogenannte Sender Policy Framework (SPF) sowie SRV- und TXT-Einträge sind auf den 1&1 Nameservern fest definiert und können nicht angepasst werden. Wenn Sie hierfür eigene Einträge benötigen, ist dies über die Administration eines eigenen Nameservers möglich.
Quelle: http://hilfe-center.1und1.de/domain-c82638/dns-einstellungen-c82657/was-sind-dns-einstellungen-a783568.html

Bei HostEurope.de hingegen kann der Administrator diese Einträge recht einfach und schnell "selbst" machen. Hier ein Beispiel:

Änderung der SIP Domains

Als Lync Administrator interessiert sie natürlich, was Sie auf dem Backend machen müssen:

  • SIP-Adresse addieren
    Addieren Sie per PowerShell oder den Topology-Builder die SIP-Domäne. Denken Sie auch daran, dass Sie die SimpleURL für Meetings entsprechend anpassen müssen, da hier sonst ein "meet.<sipdomain>" angelegt wird. Genau das wollen wir uns ja auch ersparen um im Zertifikat der Webveröffentlichung keinen weiteren Namen addieren zu müssen.

Danach meldet der Topology Builder, dass Sie auf den Frontend Servern den Deployment Wizard ausführen müssen. Nach meiner Erfahrung ist das aber nicht erforderlich, wenn Sie keine neuen Hostnamen z.B. bei den SimpleURLs addiert haben.

Wichtiger Hinweis für Webveröffentlichung
Wenn Sie die Webseiten über einen Reverse Proxy mit HostHeader-Prüfung veröffentlichen, müssen sie später jeden LyncDiscover-Hosteintrag ebenfalls addieren, da der CNAME nur die IP liefert aber nicht den Hostnamen ändert und natürlich darf kein SSL-Zwang aktiv sein.

Auf dem FE erscheint die Änderung nach kurzer Zeit im Control Panel und es gibt im Eventlog eine Bestätigung:

Log Name:      Lync Server
Source:        LS Protocol Stack
Date:          5/10/2014 12:31:44 PM
Event ID:      14553
Task Category: (1001)
Level:         Information
Keywords:      Classic User:          N/A
Computer:      NAWLYNC001.netatwork.de
Description:
The following domain was added to the list supported by 
SIP Registrar in this Lync Server deployment : 
Domain: msxfaq.net; Allow sub-domains [1=yes,0=no]: 0; Authoritative [1=yes,0=no]: 0

Allerdings hat bei mir der externe Zugriff über den Edge nicht sofort geklappt. Ein Trace auf dem liefert als Antwort auf den "REGISTER" folgende Meldung:

TL_WARN(TF_DIAG) [0]0D74.07D0::05/10/2014-13:50:00.382.001d4b6b (SIPStack,
SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(805))[37660141] $$begin_record
Severity: warning
Text: The source domain of the remote User client's message is not in the list
 of internally supported domains
Result-Code: 0xc3e93d72 SIPPROXY_E_EPROUTING_MSG_CLIENT_DOMAIN_NOT_INTERNAL
SIP-Start-Line: REGISTER sip:msxfaq.net SIP/2.0
SIP-CSeq: 1 REGISTER
Peer: 79.236.225.184:51924
Data: source-type="domain-type-none"

Der Client bekommt dann einen "504 Server Timeout". Im Eventlog des Edge Servers wird dies aber nicht protokolliert. Ich habe ca. 3 Stunden gewartet und gehofft, dass der Edge Server die Einstellung alleine übernimmt. Dann habe ich aber doch den Access Edge Service (RTCSVR) neu gestartet und umgehend wurden Anmeldungen an die neue Domäne angenommen. Einen Eintrag im Eventlog bezüglich dieser neuen Domäne konnte ich aber nicht finden. Vielleicht hatte ich einfach nicht genug Geduld.

Clients: Communicator 2013 und neuer auf Windows

Der erste Client, der natürlich gegen diese Konfiguration getestet wurde ist ein Lync 2013 Communicator. Und wie nicht anders zu erwarten, kommt beim ersten Anmelden die folgende Warnung.

Ist ist egal, ob der _sip._tls.<sipdomain> nun direkt auf den Namen des Edge-Servers oder erst über einen CNAME-Record auf den Server verweist. Der Client "warnt" den Benutzer, dass er seine Daten an einen Edge-Server sendet, dessen Zertifikat keinen Server mit einem Namen in der SIP-Domain enthält. Das kann der Anwender aber hier auch so bestätigen, dass die Warnung nicht mehr kommt. Alternativ kann der Administrator z.B. per Gruppenrichtlinie dafür sorgen, dass der Edge-Server als "Trusted" addiert wird. Hier eine REG-Datei als Beispiel

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Policies\Microsoft\Office\15.0\Lync]
"TrustModelData"="uclabor.de"

Damit sind alle Server in "uclabor.de" per Se vertrauenswürdig.

Den Key können Sie auf von ihnen verwalteten Computern per Gruppenrichtlinie oder Softwareverteilung einfach setzen. Dennoch ist die Lösung unschön, wenn Anwender von privaten Clients ebenso das Backend nutzen sollen oder früher Lync-Hoster sehr viele Domains auf einer "Shared Plattform" betreiben wollten und quasi keinen Client kontrollieren.
Microsoft als Hersteller des Backend und des Client hat es einfacher, um kann die Office 365 Edge per Default einfach als "vertrauenswürdig für alle Domains" eintragen

Clients: Communicator 2010 auf Windows

Auch der Lync 2010 Client kann auf dieses Problem stoßen. Auch hier gibt es einen, allerdings anderen, Registrierungsschlüssel:

Achtung: Dieser Schlüssel ist "vorbelegt", daher hier ein Export meiner Einstellung:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Communicator]
"TrustModelData"="lync.com, outlook.com, lync.glbdns.microsoft.com, microsoftonline.com" 

Damit ist auch klar, warum ein Lync Client gegen Office 365 keine Warnungen ausspuckt, wenn im Zertifikat des Edge-Servers die SIP-Domain nicht enthalten ist. Diesen kleinen Vorteil haben andere Hoster nicht. Viele behelfen sich mit einem "Anmeldeassistent", der solche Einstellungen dann einfach setzt.

  • 2531068 "Lync cannot verify that the server is trusted für your sign-in address." message when you sign in to Lync 2010 by authenticating to Lync Online

Clients: Mobile

Mobile Clients machen keine Anfrage nach "_sip._tls.<sipdomain>" sondern nutzen "lyncdiscover.<sipdomain>". Anders als Exchange greifen die Clients aber per Default erst einmal per HTTP und nicht gleich per HTTPS zu und erwarten eine XML-Struktur, in der die Adresse der LyncWeb-Dienste enthalten sind. Und hier vertraut der Client auch blind der Antwort, selbst wenn die LyncWeb-Dienste in einer andere DNS-Domain liegen.

Wenn ich also einen Lync User angreifen möchte, dann könnte ich versuchen auf dem Weg die DNS-Abfrage zu verändern, damit der Client per LyncDiscover auf meinen präparierten Lync Server kommt, der ihm dann eine andere LyncWeb-Serivce URL liefert und hoffen, dass der Client diese URL nutzt, um sich damit mit einem "unsicheren Kennwort" anzumelden.
Ich habe noch nicht geprüft, ob dieser Angriff auch möglich ist. Bislang meldet sich mein Lync Client beim ersten mal bei NTLM an (sicheres Kennwortverfahren) und bekommt dann ein Zertifikat für die weiteren Aktionen.

Clients: Mac

Ich habe leider keinen Mac und kann daher nicht die Funktion von extern entsprechend testen.
Vielleicht kann jemand der Leser dazu etwas beitragen.

Partner: Lync Federation (Partner, O365)

Sie haben gesehen, dass auch DNS-Einträge der Form "_sipfederationtls._tcp.<sipdomain>" möglich sind. Insofern scheint es möglich zu sein, über diesen Eintrag auch eine Open Federation zu betreiben. Leider geht das scheinbar nicht von Hause aus. Ich habe versucht mit einem Office 365 Konto meinen Status der On-Premises-Umgebung abzufragen oder eine Kurzmitteilung zu senden. Die Fehlermeldung im Trace war aber

ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";
   ErrorType="The peer certificate does not contain a matching FQDN";
   tls-target="sip.msxfaq.net";HRESULT="0x80090322(SEC_E_WRONG_PRINCIPAL)";
   source="sipfed0E.online.lync.co

Ein NSLookup zeigt aber, dass der DNS-Eintrag korrekt per CNAME auf den eigentlichen Edge verwiesen hat.

> set q=CNAME
> sip.msxfaq.net
Nicht autorisierende Antwort:
sip.msxfaq.net  canonical name = sip.netatwork.de

So einfach ist es also nicht mehrere SIP-Domains hinter einem Edge zu verbergen, wenn der Gegenüber nicht manuell einen Eintrag für die Domäne auf den Edge Server addiert oder den Edge Server per Default als "Hoster" hinterlegt.

Partner: Skype

Entsprechend hat auch die Federation mit MSN, was letztlich Skype ist, nicht funktioniert. Ich konnte weder einen Skype-Anwender in der Schreibweise User(domain)@msn.com addieren noch konnte der Skype User meine Lync-Adresse auflösen und nutzen.

Wie machen es andere ?

"Jeder" kann DNS-Abfragen machen und so ist es relativ einfach folgende Schritte durchzulaufen:

  1. Suchen Sie einen Anbieter für Lync Hosting
    Jede Suchmaschine hilft ihnen dabei.
  2. Suchen Sie nach "Referenzen"
    Fast jeder Provider, der etwas auf sich hält, führt auch Referenzen an. Zu solchen Referenzen gehören natürlich Firmennamen und damit auch DNS-Domainnamen. Aber auch der Hoster selbst wird ja hoffentlich mit Lync arbeiten. Damit haben Sie schon mehrere Domänenamen
  3. Per NSLOOKUP nachschauen.
    Wenn diese Firmen ihre Lync Nutzung nicht verheimlichen, dann können Sie einfach mit NSLOOKUP nachschauen, wie deren DNS-Setup ist. Ein paar Beispiele folgen
  4. SAN-Einträge im Zertifikat
    Wer noch etwas weiter nachschauen will, kann sich natürlich auch per TLS mit dem Service verbinden und das angebotene Zertifikat untersuchen. Manchmal ist es schon interessant zu sehen, welche Namen sich hinter einem Zertifikat noch verbergen.

Ich habe mir ein paar Firmen geschnappt, die Lync Hosting anbieten und zum Access Edge, sofern er per DNS veröffentlich war, die Zertifikate und DNS-Einträge angeschaut.

Die Liste bitte nicht als Empfehlung oder Referenz verstehen. Es ist nur eine technische Stichprobe zur Erläuterung des Sachverhalts.

Hinweis
Microsoft Office 365 hat gegenüber den Mitbewerbern einen Vorteil, weil die Office 365-Services per Default im Lync Server schon als "Hosting Provider" eingetragen sind.

Und hier mal ein paar Ergebnisse. (Stand Anfang Mai 2014).

Hoster Edge SAN-Namen DNS-Eintrag für Kunden
Qualityhosting
https://www.qualityhosting.de/
lync/hosted-lync-2013.html

cn:lyncaccess.qualityhosting.de
san:lyncaccess.qualityhosting.de
san:webconf.qualityhosting.de

cn:lync.de2.hostedoffice.ag
san:lync.de2.hostedoffice.ag
san:sip.de2.hostedoffice.ag
san:lyncwebconf.de2.hostedoffice.ag

 
_sipfederationtls._tcp.qualityhosting.de
   SRV service location:
      priority       = 0
      weight         = 0
      port           = 5061
      svr hostname   = lyncaccess.qualityhosting.de
_sipfederationtls._tcp.ecgouh.hostedoffice.ag
   SRV service location:
      priority       = 0
      weight         = 0
      port           = 5061
      svr hostname   = lync.de2.hostedoffice.ag
SBC Europe
https://www.sbc-europe.com		 cn:sip.cust.sbc-europe.com
san:sip.cust.sbc-europe.com
san:autodiscover.canacoon.com
san:autodiscover.mayato.com
san:sip.allnet-cloud.de
san:sip.bayercloud.de
san:sip.beispielfirma.net
san:sip.bkk-lv-bayern.de
san:sip.henning-keil.de
san:sip.mri.tum.de
san:sip.mshosted.net
san:sip.sbc-europe.com
san:sip.secunet-cloud.de
san:sip02.cust.sbc-europe.com		 
_sipfederationtls._tcp.sbc-europe.com
   SRV service location:
      priority       = 5
      weight         = 25
      port           = 5061
      svr hostname   = sip.sbc-europe.com

NetTask
http://www.nettask.de/

Andere Adressen
http://dialin.lync-call.net
https://outlook.dehosted.net

cn:*.nettask.de
san:*.nettask.de
san:*.hosting.dehosted.net
san:*.subdots.de

cn:*.lync-cloud.net
san:*.lync-cloud.net
san:*.aixvox.net
san:*.hsc-solutions.de
san:*.leonhofmeister.de
san:sip.datecom.de
san:sip.udo-last.de

 
_sipfederationtls._tcp.nettask.de
   SRV service location:
      priority       = 0
      weight         = 0
      port           = 5061
      svr hostname   = sip.nettask.de
_sipfederationtls._tcp.dehosted.net
   SRV service location:
      priority       = 100
      weight         = 1
      port           = 5061
      svr hostname   = sipdir.lync-cloud.net
_sipfederationtls._tcp.yourdomain.com
   SRV 0 50 5061 sipdir.lync-cloud.net
      priority       = 0
      weight         = 50
      port           = 5061
   SRV 0 50 443 sipdir.lync-cloud.net
sip.yourdomain.com 
   CNAME sipdir.lync-cloud.net
lyncdiscover.yourdomain.com
   CNAME webdir.lync-cloud.net
_sipfederationtls._tcp.datecom.de
   SRV service location:
      priority       = 0
      weight         = 50
      port           = 5061
      svr hostname   = sip.datecom.de
sip.datecom.de 
   CNAME sipdir.lync-cloud.net

Sie können sehen, dass die Konfiguration sehr unterschiedlich ist. Einige Hoster scheinen in ihrem Edge-Zertifikat durchaus auch sich die Mühe zu machen, weitere Domains, die Kunden sein könnten, aufzunehmen. Das skaliert natürlich nicht gut. Aber die Beispiele zeigen auch, dass man wirklich mit einen SRV Record auf einen Server mit dem gleichen Name, der in Wirklichkeit aber ein CNAME ist, arbeitet.

Einige der Anbieter haben auch online entsprechende Anleitungen gestellt. Allerdings habe ich auch bei vielen Anbietern außer dem Marketing keine weiteren technischen Informationen gefunden. Da ist Office 365 die große Ausnahme. Als wenn andere Anbieter was zu verbergen hätten. Hoffentlich haben diese dann zumindest im geschlossenen Bereich weitergehende Informationen.

Was ist mit Exchange (Autodiscover) ?

Der Lync Client nutzt EWS (Exchange Web Services) um z.B. auf den Kalender. Der Lync Client ignoriert aber aktuell (Mai 2014) die SRV-Records und bedient sich der Autodiscover-Auflösung per DNS. Er stellt also eine Anfrage an https://autodiscover.sipdomain.tld... und erwartet eine Antwort. Systeme die viele SIP-Domains hosten, müssten dann ein Zertifikat auf diesem Server haben, welches wieder alle Namen enthält. Auch das wäre unschön.

Exchange Autodiscover kennt aber den Weg, dass die HTTPS-Verbindung gar nicht zustande kommt. Läuft die Verbindung auf Port 443 auf einen Timeout, dann macht Autodiscover einen "Fallback" auf HTTP, d.h. auf http://autodiscover.<sipdomain>... Und erwartet hier dann eben einen "Redirect" auf eine andere URL. Genau das ist aber die Lösung für Hoster, auch wenn der ein oder andere Client ohne passende Konfiguration den Anwender fragt, ob er der Umleitung folgen will.

Alternativ können Sie auch per Gruppenrichtlinie für Lync die URL vorgeben:

Weitere Links