locked
Lync Deplyoment mit 2 Sites - SIP-Domains? RRS feed

  • Frage

  • Hallo,

    ich habe eine Frage zu einem Lync Deployment über zwei Standort (z.B. Deutschland und Spanien). Beide Standorte greifen auf das gleiche Stamm-AD zu.

    Nun will ich das NutzerA (nutzerA@domain.de) dem Standort Deutschland (Site 1), einem Lync Pool, zuweisen und den NutzerB (nutzerB@domain.es) dem Standort Spanien (Site 2), einem Lync Standard, Server zuweisen. Jede Site hat ihren eigenen Lync Edge Server.

    Nun meine Frage: Reicht es aus in Site 1 nur die primäre SIP-Domain domain.de zu definieren und in Site 2 domain.es oder muss ich in beide Sites beide SIP-Domains eintragen? Weil wenn ich nur pro Standort die entsprechende SIP-Domain verwende werden ja SAN-Eintrage im Zertifikat gespart, da ich ja pro Site nur eine SIP-Domain verwende; oder irre ich mich?

    Grüße

    Samstag, 15. September 2012 14:35

Antworten

  • Also generell wird bei Lync die Verbindung über ICE ausgehandelt. D. h. es wird eine sogenannte Kandidaten Liste erstellt und im SDP per SIP mitgeschickt.

    Wenn also User Deutschland eine Konferenz einrichtet. Versuchen alle Lync Clients eine Verbindung zu dem Server in Deutschland herzustellen.

    Wenn der Lync Client in Spanien dann im internen Netzt ist, würde er, wenn dies nicht durch eine Firewall verhindert wird, über das interne Netz mit dem Server verbinden. Ansonsten aber über seinen Edge Server. Man müsste also die SAN nicht auf beiden Edge konfigurieren. Allerdings könnte man so auch ein manuelles Failover vornehmen, falls mal ein Internet Breakout nicht funktioniert.

    Für externe Teilnehmer würde dann immer der Edge des Home Server genommen. 

    Das Thema Backup Registrar ist ja nur für den Voice teil interessant, da dann ja nur Enterprise Voice zur Verfügung steht.


    regards Holger Technical Specialist UC

    Sonntag, 16. September 2012 11:46
  • Was mir jetzt noch aufgefallen ist, jeder Standort bzw. Site muss seinen eigenen CMS hosten, da bei einem zentralisierten CMS alle SIP-Domains in die Topologie aufgenommen werden müssen und die entsprechenden SAN-Einträge automatisch im Lync Deplyoment-Wizard beim Zertifikatsrequest erscheinen. Also müsste die Topologie für jede Site einzeln geplant werden?

    Achtung, es ist gibt pro Forest immer nur einen CMS. Es ist nicht möglich in einem Forest mehr als einen Central Management Store zu installieren.

    Intern ist es ja kein Thema das Zertifikat für alle SIP Domänen auszustellen. Extern, dann nur auf den entsprechenden Edge Servern.


    regards Holger Technical Specialist UC

    Mittwoch, 3. Oktober 2012 11:39

Alle Antworten

  • Das würde ich mir noch überlegen. Es ist zwar kostengünstiger die entsprechenden Zertifikate aufzuteilen. Wenn man allerdings ein Public Zertifikat für beide Edge/Reverse Proxy konfigurieren würde, hätte man immer noch eine  entsprechende Notfall Lösung.

    Deutschland und Spanien haben auch einen eigenen Internetzugang?


    regards Holger Technical Specialist UC

    Sonntag, 16. September 2012 10:56
  • Hallo,

    also jeweils Duetschland und Spanien haben einen eigenen Internet- als uach PSTN-Breakout. Es ist so gedacht das jeder Standort einen eigenen Edge als auch Reverseproxy bekommen soll.

    Mein Gedanke dahinter war das eben SAN-Einträge gespart werden in dem jeder Standort nur "seine" SIP-Domain bekommt.

    Jetzt ergeben sich mir aber diverse Fragen:

    - Die Standort sind direkt mittels VPN verbunden; Wie erfolgt ein Online-Konferenzaufbau, wenn NutzerA eine Online-Meeting erstellt und sich NutzerB einwählt? Verbindet sich NutzerB dann über den Edge Server oder "merkt" er das der zweite Frontend Server auch internen ist und bei die Verbindung dementsprechend aus?

    - Wenn ich die Zertifikate wie beschrieben erstelle, ist es dann noch problemlos möglich den jeweiligen Standort den anderen Standort als Backup Registar zuzuordenen? Also Spanien (Standard Frontend) -- Deutschland (Pool) und umgekehrt.

    Da sind primär die Punkte, welche ich noch nicht durchschaue.

    Freundliche Grüße

    Sonntag, 16. September 2012 11:28
  • Also generell wird bei Lync die Verbindung über ICE ausgehandelt. D. h. es wird eine sogenannte Kandidaten Liste erstellt und im SDP per SIP mitgeschickt.

    Wenn also User Deutschland eine Konferenz einrichtet. Versuchen alle Lync Clients eine Verbindung zu dem Server in Deutschland herzustellen.

    Wenn der Lync Client in Spanien dann im internen Netzt ist, würde er, wenn dies nicht durch eine Firewall verhindert wird, über das interne Netz mit dem Server verbinden. Ansonsten aber über seinen Edge Server. Man müsste also die SAN nicht auf beiden Edge konfigurieren. Allerdings könnte man so auch ein manuelles Failover vornehmen, falls mal ein Internet Breakout nicht funktioniert.

    Für externe Teilnehmer würde dann immer der Edge des Home Server genommen. 

    Das Thema Backup Registrar ist ja nur für den Voice teil interessant, da dann ja nur Enterprise Voice zur Verfügung steht.


    regards Holger Technical Specialist UC

    Sonntag, 16. September 2012 11:46
  • OK, also soweit erschließt sich mir der Zusammenhang langsam. Vielen Dank :)

    User Deutschland eröffnet eine Konferenz:

    Da beide Frontends durch das gleiche AD sowie den gleichen DNS bedient werden, checkt der Client in Spanien zuerst die internen DNS Records und "findet" den Frontend in Deustchland und wird deshalb internen an der Konfernz teilnehmen; auch wenn jeder Standort seinen eigenen Edge und Reverseproxy-Server hat. Wenn er Client aber aus z.B. netzwerktechnischen Gründen gehindert wird intern sich auf den Frontend in Deutschland zu verbinden, wird durch den "DNS-Fallback" des Lync-Clients, nach dem öffentlichen DNS-Records des Lync in Deutschland "gesucht", was dann natürlich über den Edge-Server erfolg - soweit gut.

    Mein primäres Ziel ist es SAN-Einträge zu sparen, Failover erstmal außen vor gelassen.

    Situation: Deutschland Lync mit der SIP-Domain @domain.de & Spanien Lync mit der SIP-Domain @domain.es.

    Da die SIP-URI der User die jeweiligen E-Mail-Adresse sein soll, kann ich im Endeffekt auch NUR die .de User dem Frontend In Deutschland zuordnen und analog für die Spanien User - ebenfalls soweit klar.

    Aber jetzt das Thema Backup Registrar: Wieso ist der nur für das Enterprsie Voice relevant? Der Backup Registrar übernimmt doch auch bei Ausfall des primären Frontends die Userauthentifizierung, oder verwechsel ich das jetzt? Ich bin gerade dabei mir diesen Artikel zu erarbeiten.

    Müssen die privaten Zertifikate für die beiden Frontend, speziell Internal Web Services, jetzt noch um die jeweilig andere Frontend-FQDN ergänzt werden?

    Viele Grüße

    Was mir jetzt noch aufgefallen ist, jeder Standort bzw. Site muss seinen eigenen CMS hosten, da bei einem zentralisierten CMS alle SIP-Domains in die Topologie aufgenommen werden müssen und die entsprechenden SAN-Einträge automatisch im Lync Deplyoment-Wizard beim Zertifikatsrequest erscheinen. Also müsste die Topologie für jede Site einzeln geplant werden?

    • Bearbeitet Ericsson89 Montag, 17. September 2012 15:13 Nachtrag
    Montag, 17. September 2012 11:55
  • Was mir jetzt noch aufgefallen ist, jeder Standort bzw. Site muss seinen eigenen CMS hosten, da bei einem zentralisierten CMS alle SIP-Domains in die Topologie aufgenommen werden müssen und die entsprechenden SAN-Einträge automatisch im Lync Deplyoment-Wizard beim Zertifikatsrequest erscheinen. Also müsste die Topologie für jede Site einzeln geplant werden?

    Achtung, es ist gibt pro Forest immer nur einen CMS. Es ist nicht möglich in einem Forest mehr als einen Central Management Store zu installieren.

    Intern ist es ja kein Thema das Zertifikat für alle SIP Domänen auszustellen. Extern, dann nur auf den entsprechenden Edge Servern.


    regards Holger Technical Specialist UC

    Mittwoch, 3. Oktober 2012 11:39