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 On-Premises 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 Get-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 On-Premises
Get-CsUser -Filter {hostingprovider -eq "SRV:"} | ft

# oder Gegenprobe

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

Hybrid Abbauen

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 On-Premises Server. Es darf danach kein Eintrag mehr auf die On-Premises 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 On-Premises Umgebung, die aber nichts weiter tut als die Clients in die Cloud zu verweisen. Wenn die On-Premises Umgebung sogar ausfallen würde, könnte niemand mehr arbeiten. Daher nehmen wir im nächsten Schritt die On-Premises 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.

Teams Interop Mode

Mittlerweile sollten alle Tenant von Microsoft schon auf "UpgradeToTeams" stehen. Kontrollieren und setzen Sie dies ggfls., damit wirklich alle Online-Anwender auch "TeamsOnly" sind. Wenn aber eh schon alle Benutzer in der Cloud sind, dann können Sie ja nur noch Teams Only nutzen. SfB Online gibt es so ja nicht mehr 

Grant-CsTeamsUpgradePolicy `
   -PolicyName UpgradeToTeams `
   -Global

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.

# PowerShell 5.1
# Install-Module -Name PowerShellGet -Force -AllowClobber 
# Install-Module -Name MicrosoftTeams -Force -AllowClobber 
# Update-Module MicrosoftTeams 

Import-Module MicrosoftTeams
Connect-MicrosoftTeams

# Kurzer Check, ob es der richtige Tenant ist
Get-CSTenant

# Aktuell Einstellung auslesen
(get-CsTenantFederationConfiguration).SharedSipAddressSpace 

# SharedSupAddressSpace abschalten
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.

On-Premises 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 AD-Benutzerkonfiguration

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 sollen.

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

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

Sie müssen hier eine Entscheidung treffen:
Wollen Sie zukünftig die SIP-Adresse (msRTCSIP-PrimaryUserAddress) und Telefonnummer (msRTCSipLine) weiter "On-Premises" verwalten und durch ADSync in die Cloud übertragen lassen oder sollen die lokalen Objekte komplett deprovisioniert werden, damit sie nur noch in der Cloud verwalten.

Einen Mischbetrieb alter Objekte mit per ADSync replizierter SIP-Adresse und nach dem Umschalten rein in der Cloud verwalteter Objekte sollten Sie verhindern. Wenn Sie 3rd-Party Tools oder eigene Skripte haben, die sich auf die Informationen im lokalen AD stützen, dann sollten Sie weiter lokal provisionieren. Ich denke da an z.B. LDAP-Routing für SBCs.

Meine Empfehlung: Wenn Sie eh TeamsOnly nutzen und keinen lokalen SfB-Topologie betreiben, dann würde ich lokal alles zurückbauen.

Es kann immer mal etwas schief gehen. Daher ist ein "Export der relevanten Benutzerdaten in eine Datei wichtig, um später im Notfall auch verlorene Informationen wieder herzustellen, z.B.: mit:

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

Get-CSUser | export-clixml csuser.xml

Sie könnten nun natürlich einfach folgenden Einzeiler ausführen:

# Auflisten der "Cloud USer", die noch On-Premises 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

Allerdings können die Anwender dann nicht mehr telefonieren, das ADSync auch die Rufnummer in der Cloud löscht. Sie müssen sich also vorbereiten, dass Sie die Rufnummern in der Cloud wieder setzen können. Leider macht ihnen Get-CSOnlineUser diese Arbeit nicht gerade einfach, denn die Rufnummern kommen nur halb.

PS C:\> get-csonlineuser | ft sipaddress,enterprisevoiceenabled,lineuri,onpremlineuri

SipAddress                            EnterpriseVoiceEnabled LineUri            OnPremLineUri
----------                            ---------------------- -------            -------------
sip:fcadmin@msxfaqlab.onmicrosoft.com                  False                    Not Yet Supported.
sip:fctest1@uclabor.de                                  True tel:+495257123     Not Yet Supported.
sip:fctest6@uclabor.de                                  True                    Not Yet Supported.
sip:user1@uclabor.de                                    True tel:+495257456     Not Yet Supported.

Ich kann nicht sehen, welche Nummer von On-Prem kommt und die mit der aktuellen LineURI vergleichen. Nur wenn ich explizit einen Benutzer abfrage, kommen die Werte mit.

PS C:\> Get-CsOnlineUser fctest1 | ft sipaddress,enterprisevoiceenabled,lineuri,onpremlineuri

SipAddress                            EnterpriseVoiceEnabled LineUri            OnPremLineUri
----------                            ---------------------- -------            -------------
sip:fctest1@uclabor.de                                  True tel:+495257123     tel:+495257123

Sie sollten also vor dem "Disable-CSUser" entsprechende Vorkehrungen treffen, um die Rufnummern zu "retten" und später wieder zu setzen. Ein Weg wäre der Export über ein kleines Skript mit For-Schleife.

Hierzu hat Microsoft schon eine umfangreiche Beschreibung veröffentlicht, wenn Sie nicht weiter die Rufnummer im lokalen AD verwalten wollen:

Disable-CSUser im Details

Ein Schritt bei der lokalen Deprovisioninerung der Benutzer ist der Aufruf von "Disable-CSUser", um aus dem lokalen AD die Skype for Business-Daten zu entfernen ohne das AD-Konto selbst zu löschen.

Im Grunde macht Disable-CSUser auch ziemlich viel richtig aber einigen Feldern sollten Sie mehr Aufmerksamkeit schenken. Weitere Details zu einigen Feldern im Active Directory finden Sie auch auf UC Felder

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.

Wenn Sie aber UPN=SIP nutzen, dann stört sie das nicht.

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 "On-Premises" 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 "On-Premises" ist.

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

Get-ADUser | %{Set-ADUser -Identity $_.SamAccountName -Clear msRTCSIP-DeploymentLocator}

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 = On-Premises 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 `
   -Identitiy <sipadresse> `
   -lineURI $null"

Das Feld muss leer sein, damit Sie den Wert in der Cloud auch manuell setzen können. Wenn es im lokalen AD gefüllt und oer ADSync in die Cloud repliziert wird, dann dominiert der Inhalt in der Cloud und sie müssen die Rufnummern weiter lokal verwalten.

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

Disable-CSUSer entfernt aus den ProxyAddresse den "SIP:"-Eintrag. Er war früher für die Verbindung von Skype for Business und Exchange Postfach erforderlich und für Exchange unified Messaging und CloudVoiceMail. Mittlerweile ist dies wohl nicht mehr so wichtig.

If the ProxyAddresses attribute contains a sip address, also update that value as a best practice. Although the sip address in ProxyAddresses is ignored by O365 if msRTCSIP-PrimaryUserAddress is populated, it may be used by other On-Premises components.
Quelle: Decide how to manage attributes after decommissioning
https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/cloud-consolidation-managing-attributes#method-1---manage-sip-addresses-and-phone-numbers-for-users-in-active-directory

Auf der gleichen Seite beschreibt Microsoft, wie man vorher die SIP-Adresse "sichert" um sie nach dem Disable-CSUser wieder anzufügen.

Interessant finde ich, dass Microsoft mit Set-ADUser die ProxyAddresses bearbeitet, was laut Exchange Support-Statement nicht supported wäre.

Ich habe mittlerweile Umgebungen, in denen die SIP-Adresse nicht mehr nachträglich wieder hergestellt wurde und bislang keine Einschränkungen bemerkt. Es hängt dann wohl von 3rd-Party Programmen ab. Wer mag, kann z.B. den UPN einfach addieren

foreach($user in (Get-ADUser -ldapfilter "(msRTCSIP-PrimaryUserAddress=*)" -properties UserPrincipalName,proxyAddresses)) {
    $userupn=$user.UserPrincipalName
    write-host "Processing 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
}

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. Allerdings dürfte das kaum jemand stören, da nur Skype for Business diese Felder liest und selbst hier zuerst das Feld "msRTCSIP-PrimaryUserAddress" ausgewertet wird, was zum MailNickName (Alias) vergleichbar ist. Sie können ja gerne aufräumen.

foreach($user in (Get-ADUser -ldapfilter "(msRTCSIP-PrimaryUserAddress=*)" -properties UserPrincipalName)) {
    write-host "Processing UPN $($user.UserPrincipalName)"
    Set-ADUser `
    -Identity $user `
    -Clear  msRTCSIP-ApplicationOptions,`
            msRTCSIP-DeploymentLocator,`
            msRTCSIP-Line,`
            msRTCSIP-OwnerUrn,`
            msRTCSIP-PrimaryUserAddress,`
            msRTCSIP-UserEnabled,`
            msRTCSIP-OptionFlags
}

On-Premises 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 On-Premises-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

 

On-Premises 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:

Skype for Business deinstallieren

Weitere Links