SfB Hybrid to Cloud (TeamsOnly)

Wer nicht gleich mit Skype Business Online angefangen hat, wird seine lokale Skype for Business Installation in der Regel mit Office 365 im Hybrd-Mode betreiben und dann die Anwender, Policies etc. migrieren. Wer heute aber keine Telefonie nutzt und eine Einführung entweder über CloudPBX mit PSTN-Calling (by Microsoft) oder einen CCE bereitstellen will, braucht erst mal keinen lokalen Skype for Business Services mehr. Diese Seite beschreibt die ordnungsgemäße Trennung mit Umschalten auf die Cloud.

Teams/SfB Online einbinden

Die Seite beschreibt den Rückbau einer lokalen Skype for Business Installation und nimmt auch darauf Rücksicht, dass Sie vielleicht nach Skype for Business Online oder Teams migrieren. Wenn Sie die Nutzung komplett in die Cloud verlagern, dann möchten Sie ja lokal alle Server und Dienste deinstallieren. Allerdings gibt es hier ein paar Dinge zu beachten, da ADSync bestimmte lokale Felder in die Cloud repliziert.

Wenn Sie die Inhalte dieser Felder im Rahmen einer Deinstallation bei den Anwendern entfernen, dann wird auch ADSync diese Felder in der Cloud zumindest teilweise leeren. Das kann durchaus unerwünschte Effekte haben. Sofern noch nicht passiert, müssen Sie aber erst Hybrid einrichten.

Topic Erfüllt

Hybrid einrichten

Wer eine lokale Skype for Business Installation hat und diese gegen Microsoft Teams ablösen will, muss irgendwie in die Cloud. Wenn Sie ihre Anwender nicht zur Neuanlage von Kontakten in der Buddy-Liste und manuellen Aktualisierung von Terminen zwingen wollen, dann ist die Migration über den Skype for Business Hybrid Mode der beste Weg. Nur ganz kleine Firmen werden mit Teams direkt frisch anfangen und Skype einfach abschalten.

Direct Routing einrichten

Wer auch noch mit Skype for Business telefoniert und dazu lokal ein Gateway oder einen Session Border Controller hat, wird diesen auch noch mit Teams über Direct Routing oder andere Anbinden und die Telefone einrichten.

Die Einrichtung von DR bedeutet natürlich auch, dass das Gateway/der SBC Anrufe z.B. Anhand der Information im Active Directory zur richtigen Gegenstelle weiter routet.

Provisioning für SfBOnline/Teams auf die Cloud umstellen

Anders als bei Exchange brauchen Sie später keinen lokalen SfB-Server für die Verwaltung. Alle Einstellungen werden direkt in der Cloud vorgenommen. Aus dem lokale Active Directory kommt per ADSync nur noch die Identität, die Authentifizierung und die Mailadresse, welche zugleich auch die SIP-Adresse und Teams-Adresse ist. Das bedeutet aber auch, dass Lösungen zur automatisierten Verwaltung von Skype for Business Objekten nun für Teams umgebaut werden müssen.

Ein "Enable-CSUser -Hostingprovider sipfed.online.lync.com" wird nach dem Rückbau der lokalen SfB-Systeme nicht mehr möglich sein.

Wer bisher alle von Hand macht, muss zukünftig dann das Teams Admin Center oder die SfB Online PowerShell nutzen.

Alle Benutzer in die Cloud verlagern, TeamsOnly Setzen und Voice Routing optimieren

Wer Teams vollumfänglich nutzen will, muss in die Cloud umgezogen werden. Verlagern Sie alle Benutzer von Skype for Business OnPremises nach Skype for Business Online und stellen Sie den "TeamsUpgradeMode" entsprechend ein.

Der folgende Befehl sollte nichts mehr liefern:

Get-CsUser `
   | Where-Object {$_.RegistrarPool -ne $Null} `
   | select DisplayName,RegistrarPool

Vergessen Sie dabei nicht die Konferenzräume, Room Systems, Analoge Telefone, Konferenztelefone etc.

ResponseGroups auf Call Queues umstellen

Die Warteschlangen in TK-Anlagen müssen in dem Zug auch in die Cloud umgezogen werden

Voicemail/AutoAgent migrieren

Der Umzug muss auch diese Komponenten betreffen. Insbesondere die Voice-Mails wird zukünftig ebenfalls in der Cloud bereitgestellt werden. Der lokal vorhandene Exchange UM-Server wird in dem Zuge auch arbeitslos. Eventuell haben Sie aber eine 3rd Party Applikation, die sie an den SBC angebunden haben. Hier sind dann ggfls. weitere Schritte erforderlich.

Zwischenstand

  • Alle User in der Cloud
  • Der lokale SfB Server hat keine aktive Workload mehr außer Federation
  • Gateway/SBC routet keine Anrufe mehr zum Mediation Server

Wenn Sie alles richtig gemacht haben, dann sollten die lokalen Server nun "fast" keine Last mehr haben. Zur Sicherheit sollten Sie dies noch mal prüfen.

Benutzer verschieben

Benutzer, die aktuell noch „On-Prem“ sind, haben dort ihre Buddy-Liste und ggfls. Besprechungsinhalte. Solange die Services noch laufen, können diese Benutzer rechtzeitig in die Cloud verschoben werden. Wenn die lokalen Server nicht mehr zur Verfügung stehen, können die Benutzer nur noch unter Verlust diese Daten migriert werden. Verschieben Sie daher möglichst alle Benutzer:

Ein Blick mit CSUser zeigt, ob noch Anwender auf der On-Premises-Umgebung aktiv sind.

# Anzeige aller Anwender
PS C:\> Get-CsUser | select sipaddress,hostingprovider

SipAddress                              HostingProvider
----------                              ---------------
sip:User1@msxfaq.com                    SRV:
sip:User1@msxfaq.com                    SRV:
sip:User3@msxfaq.com                    sipfed.online.lync.com

# Anzeige gefiltert auf OnPremises
Get-CsUser -Filter {hostingprovider -eq "SRV:"} | ft

Beachten Sie aber, dass es noch andere Dienste in Skype fr Business gibt, z.B. Response Groups, die Sie zu Call Queues umstellen müssen etc.

Schwenk der Federation

Ehe wir die lokalen Skype for Business Server endgültig abschalten können, müssen wir diese geordnet aus der Kommunikation entfernen. Noch laufen ja z.B. alle Federation-Anfragen über die OnPremises Server. Es darf danach kein Eintrag mehr auf die OnPremises Umgebung verweisen, welche ja danach abgebaut wird. Es ist also der Zeitpunkt gekommen, dass ein Administrator die DNS-Einträge im Internet endlich auf den Wert stellt, den das Office 365 Admin Center schon viele Jahre anmahnt.

Noch verweisen die DNS-Einträge auf die OnPremises Umgebung, die aber nichts weiter tut als die Clients in die Cloud zu verweisen. Wenn die OnPremises Umgebung sogar ausfallen würde, könnte niemand mehr arbeiten. Daher nehmen wir im nächsten Schritt die OnPremises Umgebung aus der Namensauflösung. Über das Office 365 Admin Center können die korrekten Einträge unter „Office 365 Admin  - Setup – Domains – Domäne anwählen“. angezeigt und überprüft werden. Die Änderung selbst erfolgt über die DNS-Verwaltung.

Office 365 kann aber nur die externen DNS-Einträge überprüfen. In Verbindung mit einer internen gleichnamigen Zone oder Split-DNS sind die Einträge auch in der internen Zone anzupassen.

Gerade die Änderungen der Einträge zur Federation könnten mehrere Stunden dauern, bis Partner die neuen Einträge übernehmen.

Da DNS-Änderungen einige Zeit brauchen (DNS-Cache und TTL) sollten sie nach der Änderung der Einträge einige Stunden warten, ehe Sie die lokalen Server abschalten. Sie können ja beobachten, wer sich noch mit den lokalen Servern verbindet. Insbesondere Partner mit Federation hängen auch gerne mal 24h und länger an den alten Servern.

Topic Erfüllt

Externe DNS Einträge umstellen

Selbst wenn Sie "nur noch Teams" nutzen, sollten Sie den Eintrag für Lyncdiscover in die Cloud umstellen.

Lyncdiscover.<sipdomain>
sip.<sipdomain>
_sipfederationtls._tcp.<sipdomain>
_sip._tls.<sipdomain>

Diese Einträge müssen nach Office 365 verweisen

Hinweis: Gerade dieser Eintrag wird in vielen anderen Edge Server bis zu 24h im Cache gehalten. Wenn Sie den Eintrag umschwenken, sollten Sie nicht sofort erwarte, dass alle Federation-Partner dies mitbekommen.

Interne DNS-Einträge entfernen

Damit die internen Clients auch in den Genuss der Office 365 Adressen kommen, müssen Sie die internen Einträge entfernen.  Diese gibt es in der Cloud nicht mehr, da sie als Office 36t Benutzer immer von "Extern" kommen. Microsoft Teams braucht diese Einträge überhaupt nicht aber für Skype for Business Online sind diese Einträge auch nicht erforderlich. Also raus damit.

lyncdiscoverinternal.<sipdomain>
_sipinternaltls._tcp.<sipdomain>

Denken Sie bei Split-DNS daran, dass die externen Einträge ggfls. auch noch angepasst werden müssen.

SIP-Address Sharing abschalten

Solange Skype Online von einem “Hybrid-Mode” ausgeht, sendet es alle SIP-Pakete über den On-Prem EDGE-Server. Dies muss ebenfalls wieder abgeschaltet werden. Auf einem Client oder Server mit installierter Skype Business Online PowerShell sind daher die folgenden Schritte vorzunehmen:

Die frühere SfB Online PowerShell ist mittlerweile in der MicrosoftTeams-PowerShell aufgegangen

Mit den folgenden wenigen Zeilen stellen die Skype Business Online derart um, dass es wieder führend für die SIP-Domain ist.

Import-Module SkypeOnlineConnector
$session = New-CsOnlineSession 
Import-PSSession $session `
   -AllowClobber 

Get-CSTenant

Set-CsTenantFederationConfiguration `
    -SharedSipAddressSpace $false

Aus Sicht der Cloud sind damit die Vorarbeiten erledigt. Es kann aber auch hier einige Zeit dauern, bis alle Services in Skype Business Online diese Änderung „verstanden“ haben.

OnPremises Hosting Provider entfernen

Wenn die lokale Umgebung noch aktiv ist und nur getrennt werden soll, dann kann hier der „Hosting Provider“ abgeschaltet werden. Auch dies geht am einfachsten über die lokale Skype Business PowerShell:

# Hosting Provider abschalten
Get-CsHostingProvider `
| Set-CsHostingProvider -Enabled $false

Wer seine komplette On-Premises-Umgebung wieder zustopfen will, kann auch den Zugriff von Extern und Federation generell wieder abschalten.

Set-CsAccessEdgeConfiguration `
   -AllowOutsideUsers $false `
   -AllowFederatedUsers $false

Allerdings ist das alles eher nebensächlich, wenn die die On-Premises Umgebung eh zurückbauen wollen.

Zwischenstand

Nach einiger Zeit sollten ihre lokalen Skype for Business Server nun gar keine Kommunikation von Client oder anderen Systemen mehr haben

Rückbau der OnPremises Benutzer

Zwar sind nun wirklich alle Objekte und auch die Federation-Einträge umgestellt, so dass die lokalen Server nicht mehr zu tun haben, aber einfach Abschalten geht natürlich nicht. Zum einen bleiben dann einige "Leichen" in ihrem Active Directory vorhanden, die von anderen Programmen vielleicht noch gefunden werden. Auch ist eine saubere Deinstallation auch immer noch einmal eine Kontrolle, ob wirklich alles umgestellt wurde. Die Microsoft Tools meldet sich nämlich, wenn sie etwas vorschnell in der Topologie löschen wollen. Eine besondere Beachtung verdienen die Benutzer-Konten, die vor dem Rückbau der Server entsprechend deaktiviert werden müssen. Sie könnten nun natürlich einfach folgenden Einzeiler ausführen:

Achtung: Tun sie das erst, wenn die den gesamten Abschnitt gelesen und verstanden haben!

# Auflisten der "Cloud USer", die noch OnPremises bekannt ist
Get-CsUser | Where-Object {$_.RegistrarPool -eq $Null} | select DisplayName,HostingProvider 

# Es sollte keine Benutzer mehr da sein oder die bestehenden Benutzer sind nicht relevant und werden deprovisioniert
Get-CsUser | Disable-CsUser

Der Beschreibung nach wäre Disable-CSUser auch genau das richtige Werkzeug:

The Disable-CsUser cmdlet deletes all the attribute information related to Skype for Business Server from an Active Directory user account; this prevents the user from logging on to Skype for Business Server.
Quelle: https://docs.microsoft.com/en-us/powershell/module/skype/disable-csuser

Da gibt es aber zwei Probleme.

  1. ADSync repliziert auch Löschungen in die Cloud
    Und wir möchten sicher nicht, dass die vitalen Skype for Business Online/Teams Einstellungen in der Cloud durch ADSync noch mal angefasst werden
  2. Disable-CSUser pfuscht
    Zumindest in der Art, dass es auf der einen Seite zu viel löscht und auf der anderen Seite etwas übrig lässt

Schauen wir uns zuerst einmal ADSync an. Einfach Löschen ist kontraproduktiv, da die Einträge von dem ein oder anderen Client oder 3rd Party Tool vielleicht noch benötigt werden. Viel schlimmer ist es aber, wenn ADSync solche Löschbefehle auch in die Cloud überträgt und dort einen Schaden verursachen würde. Ich habe exemplarisch dazu aus ADSync die ausgehende Rule mit den relevanten Feldern dokumentiert:

Anders als bei Exchange können Sie in ADSync keine Option für Skype deaktivieren.

Weitere Details zu einigen Feldern im Active Directory finden Sie auch auf UC Felder. Für die Deprovisionierung müssen wir erst einmal aufpassen, dass das Entfernen von Inhalten nicht die Cloud stört.

Der zweite Aspekt ist die unvollständige Arbeit von Disable-CSUser. Technisch löscht das Commandlet im Hintergrund einige LDAP-Felder aber nicht alle und auch noch etwas mehr. Dummerweise mit einigen unschönen Auswirkungen.

Feld Auswirkung

Löscht msRTCSIP-PrimaryUserAddress

Dies ist die SIP-Adresse des Benutzers, die auch durch ADSync in die Cloud übertragen wird. Sie können die Adresse leeren und ADSync würde auch den Delete in die Cloud übertragen aber Skype for Business Online wird weiter funktionieren.

Allerdings wird SfB-Online und Teams dann den UPN als Adresse nutzen. Umgebungen, bei denen der UPN und die SIP-Adresse nicht identisch sind, sollten die Adresse also weiter im lokalen AD pflegen, da nur ADSync in dem Fall die Informationen in der Cloud aktualisieren kann.

Prüfen.

msRTCSip-DeploymentLocator

Diese Felder wird leider NICHT entfernt. Wenn alle Benutzer in die Cloud repliziert wurden dann sollte da "sipfed.online.lync.com" drin stehen.

Diese Feld enthält ein "SRV:", wenn der Benutzer für Skype for Business "OnPremises" aktiviert ist. Bei Benutzern mit dem Service in Skype for Business Online steht dann ein "sipfed.online.lync.com" im Feld. Das Feld kann gerne leer sein aber es darf unter keinen Umständen den Wert "SRV:" enthalten, da der Benutzer dann aus Sicht der Cloud "OnPremises" ist.

Der Wert kann gelöscht oder auf sipfed.online.lync.com gestellt werden. Er darf aber nicht "SRV:" enthalten.

Löscht msRTCSip-Line

Hier steht die Rufnummer für Enterprise Voice drin und selbst wenn der Benutzer in die Cloud übertragen wurde, können Sie über das Feld die Rufnummer in der Cloud verwalten. Das ist für CCE-Installation der OPCH (Hybrid = OnPremises Call handling) auch erforderlich. Auch einige SBCs werden gerne so konfiguriert, dass diese Nummer für das Routing genutzt wird. Sie können dieses Feld aber leeren und in der Cloud wieder setzen.

Set-CSUSer `
   -identtiy <sipadresse> `
   -lineURI $null"

Das Feld kann leer sein, da Sie den Wert in der Cloud auch manuell setzen können. Wenn es aber gefüllt wird, dann landet die Nummer auch in der Cloud. Damit dies dort nicht schädlich ist, sollten Sie die Rufnummer in der Cloud überschreiben.

Set-CSOnlineUser `
   -identity <sip-address> `
   -Telephonenumber <E.164 nummer>

Get-CSOnlineuser user1@uclabor.de `
   | fl OnPremLineURI*,LineURI,InterpretedUserType,VoicePolicy

OnPremLineURI                : tel:+495251304613
OnPremLineURIManuallySet     : True
LineURI                      : tel:+495251304613
InterpretedUserType          : HybridOnlineSfBUser
VoicePolicy                  : HybridVoice

Entfernt "sip:user1@uclabor" aus den proxyAddresses

Hier ist Disable-CSUser vorschnell, denn dieser Eintrag wird für VoiceMail und teilweise SingleSignOn benötigt. Nach dem Disable-CSUser sollten Sie also auf jeden Fall dafür sorgen, dass der Eintrag "SIP:<sipadresse>" wieder aufgenommen wird.

Dies ist eigentlich ein Exchange Feld für die primäre und sekundären Mailadressen. Allerdings nutzen Skype for Business und Outlook auch dieses Feld, um die Kopplung zu verifizieren. Die SIP-Adresse sollte also schon in dem Feld verbleiben.

Dies gilt insbesondere, wenn sich SIP-Adresse und Mailadresse unterscheiden.

Hier sollten sie sicherstellen, dass auch die SIP-Adresse im Feld Proxy Addresses enthalten ist.

Andere msRTC* Felder werden nicht gelöscht

Bei meinen Tests habe ich aber auch festgestellt, dass nicht alle msrtc*-Felder geleert werden, obwohl diese nur für Skype for Business relevant sind.

Wir müssen also einige Felder manuell entfernen aber z.B. ProxyAddresses beibehalten und ggfls. abweichende SIP-Adressen wieder setzen. In der Cloud müssen wir zumindest beim Einsatz von Telefonie-Funktionen (Phone System) auch die Rufnummer wieder setzen.

OnPremises Rückbau

Sie wissen nun, dass ein einfaches Deaktivieren der Benutzer im lokalen AD nicht ratsam ist. Aber es kann dennoch gewünscht sein, das lokale AD zu "bereinigen". Wenn Sie nun aber vorschnell einen "Disable-CSUser" machen, dann entfernen Sie die lokalen Einträge und ADSync löscht zu dem Benutzer auch in der Cloud. Dort soll der Anwender aber weiterhin Teams nutzen. Daher müssen sie eine gewisse Vorgehensweise einhalten.

Mittlerweile hat Microsoft eine eigene Beschreibung veröffentlicht.

Wenn Sie final ihre lokale Skype for Business Umgebung abschalten wollen und die msRTC-Felder im AD nicht weiter über eine SfB PowerShell verwalten wollten, dann müssen Sie sich zwischen zwei Modellen entscheiden. Dabei geht es um die Pflege von.

  • SIP-Adresse
    Wenn die Adresse zum UPN abweichend sein muss, dann geht dies nur per ADSync und OnPremises-Pflege
  • Telefonrufnummer
    Die Rufnummer für Telefonie kann im lokalen AD gepflegt werden, z.B. weil Sie diese Information auch für das Routing ihres Session Border Controllers nutzen. Wenn die Rufnummern durch einen Provider kommen oder sie kein lokales SfB-Schema haben, dann bringt die lokale Pflege aber nichts.

Sie können zwischen den Versionen auch wechseln, aber Ziel sollte eine einheitliche Verwaltung ihrer Plattform sein.

Option Option 1: Management über AD Option 2: Management im AzureAD
ADSync

Erforderlich

Nicht erforderlich

SfB Schema

Erforderlich

Nicht erforderlich

SIP-Adresse

Lokales AD

msRTCSIP-PrimaryUserAddress

Identisch zum UPN

Rufnummer

Lokale AD

msRTCSIP-Line

AzureAD mit

Set-CSUSer -onpremLineUri 
ProxyAddress

SIP-Adresse aus msRTCSIP-PrimaryUserAddress empfohlen aber wird von Office 365 ignoriert, wenn msRTCSIP-PrimaryUserAddress gepflegt und repliziert wird.

Wird durch Exchange Online verwaltet oder mit ADSync durch den

 

 

Die folgende Tabelle muss ich noch überarbeiten

 

Bitte prüfen Sie die Skripte gegen ihren lokale Umgebung mit einzelnen Testusern, ehe sie diese pauschal auf alle Benutzer loslassen

Schritt Erledigt

Kontrolle

Zuerst würde ich einmal prüfen, ob alle lokalen Benutzer tatsächlich in der Cloud sind. Über die lokale SfB PowerShell sollten hier keine Objekte mehr gelistet werden.

Get-CSUser `
   -Filter {HostingProvider -ne "sipfed.online.lync.com"} 

 

Einstellungen sichern

Ehe wir etwas verändern, sollten wir die wichtigen Daten sichern.

Get-CSUser | select sipaddress,lineuri | export-csv sipphone.csv

 

Online Rufnummer setzen

Zuerst überschreibe ich die Rufnummer in der Cloud mit der durch ADSync schon hinterlegten Rufnummer:

foreach($user in (get-csonlineuser)) {
   set-csuser `
      -sipaddress $user.sipaddress `
      -OnPremLineURI $user.OnPremLineUri
}

Zuerst erscheint diese Aktion unsinnig, in das gleiche Feld noch mal den gleichen Wert zu schreiben. Aber Office 365 setzt zusätzlich damit auch noch das Flag "OnPremLineURIManuallySet" auf "true".

OnPremLineURI                : tel:+495251304613
OnPremLineURIManuallySet     : True

Das ist ein Zeichen, das ADSync das Feld nicht mehr synchronisiert.

 

Benutzer deaktivieren

Im nächsten Schritt entferne ich dann die Skype Properties im lokalen AD aber stelle sicher, dass die SIP-Adresse in den ProxyAddresses erhalten bleibt.

Ich gehe davon aus, dass die SIP-Adresse und der UPN schon immer identisch sind Ansonsten müssen Sie den Code erweitern, dass Sie das Feld msRTCSIP-PrimaryUserAddress noch pflegen.

foreach($user in (Get-ADUser -ldapfilter "(msRTCSIP-PrimaryUserAddress=*)" -properties UserPrincipalName,proxyAddresses)) {
    $userupn=$user.UserPrincipalName
    write-host "Proxessing UPN $($userupn)"
   
    if(($null -eq $user.proxyAddresses) -or ($user.proxyAddresses -notmatch "^sip:.*")) {
        write-host "Add UPN as SIP to Proxy $($userupn)"
        Set-ADUser `
            -identity $user `
            -Add @{"proxyAddresses"=userupn}
    } 
    Set-ADUser `
    -identity $user `
    -Clear  msRTCSIP-ApplicationOptions,`
            msRTCSIP-DeploymentLocator,`
            msRTCSIP-Line,`
            msRTCSIP-OwnerUrn,`
            msRTCSIP-PrimaryUserAddress,`
            msRTCSIP-UserEnabled,`
            msRTCSIP-OptionFlags
}

 

Kontrolle in der Cloud

Kontrollieren sie nach all diesen Aktionen das Feld InterpretedUserType in Skype for Business Online.

Get-CSOnlineuser `
| ?{$_.OnPremLineURI  } `
| group InterpretedUserType `
      -NoElement `
| ft -AutoSize

 

Zukünftiges Provisioning

Wenn Sie im nächsten Schritt alle lokalen SfB Server deinstallieren, dann haben Sie natürlich auch keine Skype for Business PowerShell mehr zum Verwalten der Benutzer. Die Einträge für ProxyAddresses und ggfls. msRTCSIP-PrimaryUserAddress müssen Sie dann per Set-ADUser, ADSIEDIT oder anderen Tools manuell setzen oder Sie erweitern ihr Provisioning in der Cloud. Maßgeblich sind sowieso die Werte in Teams Online.

 

OnPremises Topologie entfernen

Wenn nun keine Benutzer mehr im lokalen Active Directory mehr vorhanden sind, dann können Sie auch die Server langsam entfernen. Dazu gibt es eine eigenen Seite:

Weitere Links