ADSync mit Skype für Business

Auf der Seite Exchange Online und DirSync habe ich beschrieben, wie man als keine Firma in sehr kurzer Zeit einen Office 365 Vertrag abschließen und komplett autark nutzen kann. Im gleichen Schritt kann man auch Skype für Business aktivieren. Auch wenn man in Skype für Business nicht allzu viel konfigurieren kann, ist die SIP-Adresse natürlich der essentielle Faktor.

Woher bekommt Office 365 die SIP-Adresse?

Die SIP-Adresse leitet sich normalerweise vom UPN ab. Diesen können Sie wie gehabt in der Cloud einfach ändern indem Sie den UPN entsprechend ändern. Allerdings ist auch hier zu beachten, dass der DirSync selbst eine lokale UPN-Änderung nicht 1:1 in Office 365 nachführt. Die Details hierzu habe ich auf Office 365:UPN / Anmeldename ausführlich beschrieben.

Die Bedeutung des UserPrincipalName (UPN) im Office 365 Umfeld ist ihnen ja schon aus anderer Stelle bekannt. Der UPN ist der Dreh- und Angelpunkt für die Anmeldung an Office 365 und muss daher eine offizielle Domäne als Suffix haben, die auch in Office 365 eingerichtet ist. Durch die Einrichtung in Office 365 ist Sie aber automatisch auch als SIP-Domäne freigeschaltet. Wenn der User aber eine Cloud-Identität ist, dann gilt der UPN des Cloud Users. Einen DirSync gibt es da dann nicht.

Lizenz und Skype für Business

Allein mit einem gültigen UPN wird in der Cloud aus einem User noch kein Skype für Business Anwender. Wenn er die Dienste in der Cloud nutzen soll, dann muss den Benutzer erst noch eine passende Lizenz zugewiesen werden. Das macht der Administrator über das Office 365 Admin Portal oder ein Powershell Script. Erst mit der passenden Office 365 Lizenz erscheint der Benutzer dann auch in der Skype für Business Verwaltung in der Cloud und der Anwender kann sich anmelden.

Sollte sich der Benutzer dennoch nicht anmelden können, dann könnte es eine alte On-Prem-Installation ihnen noch Probleme bereiten. Wurde hier das Feld "msRCSIP-UserEnabled = false" gesetzt, dann repliziert der DirSync dies in die Cloud und verhindert dort auch die Aktivierung, selbst wenn Sie eine Lizenz zugewiesen haben

the msRTCSIP-UserEnabled attribute was set to FALSE. This attribute value is synced to Office 365 and disables the Skype für Business Online license of the Skype für Business Online User who can't sign in. (However, the Skype für Business Online license is still displayed as enabled in the Office 365 portal.)
Quelle: 2705378 Error message when you try to sign in to Skype für Business Online: "Cannot sign in to Lync because this sign-in address was not found"

Setzen Sie dann On-Prem den Wert auf "true" oder "null", je nach dem was für ihre Umgebung passend ist.

ADSync Regeln für "Lync"

Wenn Sie ADSync bzw. AADConnect einrichten, dann können Sie ja per Checkbox steuern, ob Exchange Hybrid genutzt wird oder nicht. Für Skype for Business gibt es diese Einstellmöglichkeit nicht. Der AADConnect-Assistent liest bei der Installation das AD-Schema aus ud wenn es die Schema-Erweiterung für Lync/Skype for Business findet, dann addiert er entsprechende Regeln, die sie im "Rule Editor" auch sehen können.

Die Regeln finden Sie Analog auch auf den ausgehenden Connectoren

Ein gesondertes Setup für den "Hybrid-Mode" gibt es so gesehen also nicht. Daher ist es natürlich umso wichtiger zu sehen, wann welche Felder synchronisiert werden. Das hat Microsoft recht gut dokumentiert

Migration SfB OnPremise zu SfBOnline

Auf der Seite Move-CSUser 365 habe ich die Details beschrieben, wie ein Administrator mittels "Move-CSUser" einen Benutzer zu SfBOnline migrieren kann. Anders als bei Exchange holt hier die Cloud nicht die Daten sondern die lokale SfB-PowerShell überträgt die Buddyliste in die Cloud und stellt lokal im Active Directory die Eigenschaften um. ADSync ist dann wieder an der Rolle, diese Änderungen ins AzureAD zu bertragen.

Hybrid und DirSync

Die Lizenz muss in Office 365 nur für Objekte aktiviert werden, die auch in der Cloud ihren Homeserver haben. Wenn Sie einen Hybrid Mode betreiben, dann synchronisiert , dann synchronisiert der DirSync die lokalen MSRTC-Properties in die Cloud, damit die On-Prem-Objekte auch in der Cloud als Skype 4 Business Objekte (nicht User) im Adressbuch erscheinen. In dem Fall können Sie quasi "dank DirSync" in der Cloud außer den Lizenzen auch nicht mehr viel verwalten. Speziell mit einer "Shared SIP-Domain", d.h. wenn die Benutzer On-Premises und in der Cloud die gleiche SIP-Domäne nutzen, müssen On-Prem die Cloud Benutzer richtig konfiguriert sein.

Da der DirSync aber per Default nur "ausgehend" in eine Richtung repliziert, und er damit On-Prem diese Felder nicht ändert, müssen Sie die Objekte On-Prem entsprechend provisionieren. Erst dann stehen die Benutzer sowohl On-Prem quasi als Platzhalter bereit, die eine Weiterleitung zu den Konten in der Cloud über die Edge-Server in der Cloud nutzen. Der DirSync schreibt dann die Felder in das Office 365 Directory und die Benutzer sind dann auch in der Cloud aktiv.

Wenn Sie im lokalen Skype for Business Control Panel die Eigenschaften eines Anwender betrachten, dann können Sie schön die Unterschiede sehen:

Beschreibung Bild

Hier noch ein Skype for Business Control Panel mit einem Benutzer, der in der Cloud liegt, aber keine Telefonie haben kann. Der Administrator kann hier zwar eine Rufnummer pflegen, die aber nur für das Adressbuch relevant ist.

Hier der Ausschnitt eines Control Panels eines Benutzers, der in der Cloud ist aber dank DirSync in Office 365 verwaltet wird. Hier sind dann die kompletten Einstellungen.

Beim Deprovisioning eines Benutzers ist die lokale Installation auch keine Hilfe. Ein Benutzer kann "disabled" werden, damit er sich nicht mehr anmelden kann. Er kann aber On-Premises nicht aus Skype for Business "gelöscht" werden.

Beide Seiten beschreiben aber genau, dass die hier On-Prem gemachten Einstellungen durch den DirSync in die Cloud übertragen werden. Aber alle anderen hier nicht sichtbaren Einstellungen weiterhin in Skype for Business Online per Browser oder PowerShell verwaltet werden müssen.

Bei dem Objekt in der Cloud haben sich dabei folgende Felder geändert. (Get-CSOnlineUser)

OnPremHostingProvider                : SRV:
OnPremOptionFlags                    : 385
OnPremEnterpriseVoiceEnabled         : True
OnPremSIPEnabled                     : True
OnPremSipAddress                     : sip:User1@msxfaq.net
OnPremLineURI                        : tel:+495251304613;ext=613
OptionFlags                          : 256
LineURI                              : tel:+495251304613;ext=613
SipAddress                           : sip:User1@msxfaq.net
Enabled                              : True

Benutzer direkt in SfBOnline/Teams anlegen

Wenn mit ADSync die lokalen AD-Benutzer in die Cloud repliziert werden, dann sind die Office365 Konten hinsichtlich bestimmter Einstellung "ReadOnly". Die Cloud "weiß", dass Felder durch ADSync verwaltet werden und auch der SfB HybridMode scheint dabei eine Rolle zu spielen. Leider habe ich bislang keine detaillierten Dokumentationen dazu  gefunden und kann nur aus der täglichen Praxis berichten.

Ich kann nicht genau schreiben, wann es passiert ist, aber mittlerweile bekommt ein ein per ADSync in die Cloud repliziertes Konto und konfiguriertem SfBHybrid-Mode nach Zuweisung der Lizenz keine SfBOnline-Dienste mehr. Beim SfB-Hybrid Mode ist es unerlässlich, die Benutzer im lokalen Active Directory zu aktivieren.

Wenn wir nun Benutzer in einer per ADSync replizierten Umgebung direkt in SfBOnline bzw. teams anlegen wollen, dann sind die folgenden Schritte relevant:

Schritt erledigt

Benutzer im lokalen AD anlegen

Jeder Benutzer in Office 365 sollte ein korrespondierendes Objekte im lokalen Active Directory haben. Das ist insbesondere beim Einsatz des SfB Hybrid Mode zwingend erforderlich

Benutzer für SfBOnline aktivieren

Nun können wir den Benutzer im lokalen AD auch mit Skype for Business Properties versehen, die aber direkt nach SfB Online verweisen. Der folgende Befehl nutzt dazu die Mailadresse

Enable-CsUser `
   -Identity “user1@msxfaq.de” `
   -SipAddressType “EmailAddress" `
   -HostingProviderProxyFqdn “sipfed.online.lync.com”

Als "SipAddressType" sind natürlich auch die anderen Optionen nutzbar

ADSync abwarten

Nun heißt es etwas Geduld haben, bis ADSync den neuen Benutzer samt msRTC*-Attributen ins AzureAD repliziert hat.

SfB/Teams-Lizenz/PhoneSystem/AudioConference zuweisen

Damit der Benutzer auch in der Cloud die Dienste nutzen kann, müssen die gewünschten Lizenzen zugewiesen werden.

TeamsOnly setzen

Soll der Anwender direkt mit Teams durchstarten und ist ihr Tenant noch nicht per Default auf "TeamsOnly" gestellt, dann müssen Sie den Interop-Mode zuweisen:

Grant-CsTeamsUpgradePolicy `
   -Identity user1@msxfaq.de `
   -PolicyName UpgradeToTeams

Weitere Einstellungen

Damit ist es aber noch nicht getan. ADSync repliziert nur die Einstellungen zur Identität. Ale Teams Richtlinien, Dialpläne, Rufnummern etc. müssen Sie Anwender natürlich auch noch zuweisen. Das kann nicht On-Premises erfolgen, da die lokale SfB-Installation keine Informationen über die Objekte in die Office 365 hat

CloudOnly User matchen

Wenn Sie in der Vergangenheit schon "CloudOnly"-Benutzer angelegt haben und erst nachträglich feststellen, dass dies eine schlechte Wahl war, hindert sie niemand daran, die fehlenden Einstellungen im lokalen Active Directory nachzuholen. Sie können einfach einen lokalen Benutzer mit der gleichen Mailadresse, wie das Cloud-Objekt anlegen. ADSync wird dann diesen Benutzer ebenfalls replizieren und den "CloudOnly"-Benutzer zuordnen und zum "ADSync-Benutzer" machen.

Da ADSync das lokale AD-Objekt dabei erstmalig sieht, kann ADSync auch leere msRTC-Felder nicht als Änderung erkennen und löscht die Daten in der Cloud nicht. Für den Hybrid-Mode müssen Sie aber natürlich dennoch den Benutzer im lokalen Active Directory für SfBOnline konfgurieren. Den Befehl dazu kennen Sie ja schon:

Enable-CsUser `
   -Identity “user1@msxfaq.de” `
   -SipAddressType “EmailAddress" `
   -HostingProviderProxyFqdn “sipfed.online.lync.com”

Wenn Sie hier dem Benutzer aber eine abweichend SIP-Adresse geben, wird ADSync die lokale SIP-Adresse auch auf das Office 365 Objekt zuweisen.

Es ist bei solchen Aktionen immer eine gute Idee, einen Export der Benutzer in der Cloud (Get-CSOnlineuser/CSUser) als CSV-Datei/CliXML-Datei anzufertigen um danach vergleichen und notfalls noch korrigieren zu können.

On-Premises Altlasten bereinigen

Am Anfang hatte ich schon geschrieben, dass ADSync/AADConnect das lokale AD-Schema ausliest und wenn es die Lync/Skype for Business Erweiterungen findet, legt es entsprechende Regeln zum Abgleich der Felder an. Das ist natürlich eine latente Gefahr, wenn es lokal schon einmal eine Skype for Business, Lync oder sogar OCS Installation gegeben hat und die Benutzer ggfls. noch entsprechende Properties haben. In so einen Fall ist es ratsam die Quelle zu "reinigen" ehe Sie ADSync einrichten. Auch wenn ein Kunden beteuert, keinen Lync oder OCS-Server genutzt zu haben, ist das immer noch keine Garantie, ob das nicht in der Vergangenheit mal so war. Die Regel zeigt, dass solche Altlasten viel häufiger vorkommen. Schließlich ist ein einzelner Lync-Server schon mal schnell als Evaluierungsversion installiert und ein paar Benutzer angelegt. Das Produkt ist schon einige Jahre alt und nicht immer sind die Administratoren von damals noch im Unternehmen.

Genau diese alten Einträge im Active Directory sind problematisch für Office 365, die durch den DirSync in die Cloud übertragen werden und letztlich die Aktivierung des Skype für Business Kontos in Office 365 verhindern. Daher sollten Sie auf jeden Fall prüfen, ob es in einer Umgebung schon Objekte gibt. Am einfachsten geht da über die Powershell:

Import-Module ActiveDirectory

# Suche nach alten Lync Servern
Get-ADObject -LDAPFilter "(msRTCSIP-PrimaryHomeServer=*)"

# Suche nach Lync Usern. Denkbar sind auch andere msRTC-Felder
Get-ADObject -LDAPFilter "(msRTCSIP-PrimaryUserAddress=*)"

Die Listen sollten "leer" sein, wenn es keine RTC-Server und User mehr gibt. Sollte es hier Objekte geben, dann ist ein erster Blick auf ein paar der Objekte ratsam, um anhand des "msRTCSIP-PrimaryHomeServer" zu sehen, welche Restinstallation vielleicht doch noch da ist. Nicht immer wissen die Administratoren von heute, was vorgestern passiert ist. Wenn Sie den Server ermittelt haben und dieser wirklich nicht mehr gültig ist, dann können Sie die Felder bei den Benutzern schon mal problemlos entfernen. Die Deinstallation der OCS/Lync-Server ist ein anderes Kapitel. In dem gleichen Zuge sollten Sie beim Einsatz von Split-DNS auch prüfen, dass lokal entsprechende DNS-Einträge (_sipinternaltls._tcp.<sipdomain> etc.) entfernt sind, um die spätere Anmeldung nicht zu blockieren.

Folgendes kurzes Skript entfernt die Felder von den AD-Objekten:

Import-Module ActiveDirectory
$Lyncobjects = Get-ADObject -LDAPFilter "(msRTCSIP-PrimaryHomeServer=*)" 
ForEach-Object (Lyncobject in Lyncobjects ) {
   Set-ADObject `
      -Identity $Lyncobject.DistinguishedName `
      -Clear ("msRTCSIP-DeploymentLocator", 
              "msRTCSIP-FederationEnabled", 
              "msRTCSIP-InternetAccessEnabled", 
              "msRTCSIP-OptionFlags", 
              "msRTCSIP-PrimaryUserAddress", 
              "msRTCSIP-UserEnabled", 
              "msRTCSIP-UserPolicies",
              "msRTCSIP-UserRoutingGroupId",
              "msRTCSIP-PrimaryHomeServer");
   Cleaned $($_)
}

Wenn Sie dann einen DirSync forcieren, sollten die Objekte auch in der Cloud sehr zügig mit Skype für Business Online arbeiten können

Hybrid zurückbauen

Wenn Sie bislang eine lokale Skype for Business/Lync-Installation hatten und über den Hybrid-Mode langsam alle Benutzer in der Cloud haben, dann können Sie natürlich weiterhin einen lokalen Server zur Verwaltung der Empfänger weiter lauen lassen. Viel Sinn macht dies aber nicht, denn er muss betrieben werden und Policies und Dialpläne etc. sind sowieso getrennt in der Cloud zu pflegen. Da kommt dann schon der Wunsch auf, die lokalen Server einfach zu deprovisionieren. Das ist möglich aber sie sollten unter keinen Fällen die Skype for Business Benutzer "bereinigen". Ansonsten wird ADSync dies als "remove User" ansehen und auch in der Cloud die Skype for Business Properties erst mal entfernen. Ich sehe vier Optionen diese Situation zu bereinigen.

  • ADSync "frisch" machen
    Bislang haben Sie ja schon nein ADSync aktiv, welcher die MSRTC-Felder in das Metaverse entfernt. Ein Weg wäre der folgende:
    • ADSync-Maschine abschalten
      Damit geht zugleich auch die SQL-Datenbank verloren. Dsa ist aber nicht schlimm.
    • msrtc-Properties der lokalen Benutzer "bereinigen"
      Diese "Lösch-Aktionen" kann ADSync nicht mehr erkennen und in das AzureAD übertragen
    • ADSync neu installieren
      Dabei müssen Sie natürlich wieder alle vorher ggfls. durchgeführten Anpassungen an Regeln etc. neu eintragen. Aber ADSync wird dann per FullSync die Daten aus dem AD lesen. Er wird zwar das Lync-Schema erkennen aber keine Felder und auch keine "Feld gelöscht"-Information in das Metaverse eintragen. Beim Export in das AzureAD werden die Felder dann auch nicht gesetzt und in der Cloud bleibt alles beim alten. Die Benutzer wird ADSync natürlich "matchen".
  • AD Cleanup und Skype Online Umkonfiguration
    Sie können natürlich auch einfach stumpf die MSRTC-Felder bereinigen und ADSync zerstört damit auch die Konfiguration in der Cloud. Sie können dann die User in der Cloud ja wieder manuell aktiveiren und die Policies zuweisen. Schade nur, dass die User dann die gleiche SIP-Adresse haben aber dennoch ihre Buddylisten leer und die Meeting-Einladungen ungültig sind
  • Alles belassen
    Natürlich können sie einfach die Skype for Business Server deinstallieren und die Rest im AD einfach lassen.
  • Regeln anpassen
    Wenn Sie "mutig" sind können Sie natürlich im AADConnect auch die Export-Regeln zu Office 365 verändern oder deaktivieren. Dann passiert in der Cloud auch nichts mehr. Aber wer sagt ihnen, dass beim nächsten Update von AADConnect nicht wieder die "Standardregeln" eingebaut werden?

Mein Kandidat ist natürlich der erste und "saubere" Weg. Die zweite Option ist unschön und Altlasten mag ich gar nicht. Ich habe aber noch keinen Microsoft Artikel gefunden, der den "richtigen" Weg beschreibt.

SIP und Mailadresse

Skype für Business nutzt natürlich auch Exchange On-Prem oder Exchange Online, um dort nach Terminen und Einladungen zu schauen und z.B. nach verpassten Anrufen und Sprachnachrichten zu suchen. Der Client nutzt dazu die Information aus dem Feld "Mail", welches sie in der normalen MMC sehen:

Diese Feld ist aus AD-Sicht komplett unabhängig von dem Feld "ProxyAddresses", welches Exchange für die Zustellung von Mails verwendet. Die Verwaltung von Exchange sorgt aber dafür, dass der Inhalt des Feldes "mail" mit der primären SMTP-Adresse aus dem Feld "ProxyAddresses übereinstimmt. Insofern sollten Sie zumindest bei einem installierten Exchange Server das Feld Mail nicht manuell ändern, sondern über die Exchange Verwaltung die primäre Mailadresse anpassen.

Lync sees the WindowsEmailAddress or MAIL attribute to determine which Exchange server Outlook should connect to
Quelle: 2436962 "There was a problem connecting to Microsoft Office Outlook" error when you sign in to Skype für Business Online

it compares the SMTP (email) address in Outlook with the sign-in address that's used to connect to Skype für Business Online. If the SMTP and Lync sign-in addresses don't match, you may experience this error. 
Quelle: 2436962 "There was a problem connecting to Microsoft Office Outlook" error when you sign in to Skype für Business Online

SIP-Adressen ändern

Anwender haben durchaus die Eigenschaft, ihren Namen zu ändern. Meist ist dies durch Hochzeit oder Scheidung begründet und natürlich möchte die Person dann den alten Namen nicht mehr nutzen. Ein Objekt kann im Active Directory ziemlich problemlos aus technischer Sicht geändert werden. Die Auswirkungen auf andere Dienste sind aber nicht zu unterschätzen. Ich habe da eine gesonderte Seite auf.

Mit Office 365 ist die SIP-Adresse natürlich komplett vom UPN abhängig. Sie können die SIP-Adresse nicht unabhängig davon ändern. Durch die Änderung des UPN On-Premises wird allerdings der UPN, und damit die SIP-Adresse, in der Cloud gerade nicht gesändert. Der DirSync ist (Stand Okt 2015) dahingehend beschränkt. Er macht das nicht weil er es nicht könnte, sondern weil wohl eher die Auswirkung durchaus umfangreich sind und daher diese Aktion explizit in der Powershell in Office 365 umgesetzt werden müssen.

Interessant ist aber, dass die Änderung eines UPN On-Prem nur dann nicht in die Cloud repliziert wird, wenn der Anwender dort auch eine Lizenz zugewiesen bekommen hat.

Lync PowerShell

Leider kann man nicht mit den "normalen" Azure PowerShell Befehlen wie "Get-MSOLUser" die SIP-Adressen oder ProxyAddresses sehen. für Exchange muss man eine Remote PowerShell zu Exchange Online aufbauen und für Lync gib es eben die Lync PowerShell:

Windows PowerShell Module für Lync Online
http://www.microsoft.com/en-us/download/details.aspx?id=39366

Damit können Sie dann auch gegen Office 365 einen Blick in die SIP-Adressen werfen

Weitere Links