07.07.2022, aktualisiert am 31.01.2023

4129

Teams-Telefonie: Einrichtung eines neuen Benutzers nur unvollständig

Hallo zusammen,

bei uns im Unternehmen wird Festnetztelefonie über Microsoft Teams via "Direct Routing" abgewickelt. Soweit so gut, hat bisher zufriedenstellend geklappt. Heute sollte ein neuer Kollege für Teams-Telefonie befähigt werden. Dieses wird bei uns über die PowerShell gehandhabt. In früheren Zeiten haben wir dazu den Befehl "Set-CsUser" genutzt, seitdem dieser seit einigen Wochen "decrapted" ist nun mit "Set-CsPhoneNumberAssignment". Premiere - und schon geht es schief.

Welche Schritte wurden gemacht? Gemäß der Microsoft-Seite Aktivieren von Benutzern für Direct Routing wurde der Benutzer mit

Set-CsPhoneNumberAssignment -Identity xxx@yyy.de -EnterpriseVoiceEnabled $true
Set-CsPhoneNumberAssignment -Identity xxx@yyy.de -PhoneNumber +4912312345678 -PhoneNumberType DirectRouting

eingerichtet.

Sah gut aus, nur fehlt dem Kollegen in der Teams-Desktop-App das Wählfeld um externe Anrufe tätigen zu können. Teams-zu-Teams-Anrufe innerhalb des Unternehmen sind möglich.

Die Fehlereingrenzung wurde dann anhand der Microsoft-Seite Konfiguration der Wähltastatur durchgeführt:

Der Benutzer verfügt über eine aktivierte Telefonsystem ("MCOEV")-Lizenz - Check, ok
Der Benutzer ist für Direct Routing aktiviert - Check, ok
Benutzer hat Enterprise-VoIP aktiviert - Check, ok
Der Benutzer wird online verwaltet - Fail, ein SIP-Pool fehlt
Benutzer hat Teams Anrufrichtlinie aktiviert - Check, ok

Hier die Ausgabe auf der CLI; zuerst wie meiner Meinung nach ein Benutzer aussehen sollte, als zweites der problematische Benutzer.

Ok, kann mal vorkommen, also die Parameter des Benutzers mit

Remove-CsPhoneNumberAssignment -Identity xxx@yyy.de -RemoveAll

wieder gelöscht und erneut angelegt. Wieder kein SIP-Pool vorhanden.

Zweiter Versuch, vielleicht funktioniert's über die GUI: Parameter gelöscht und im Teams Admin Center angelegt - Nope, immer noch kein SIP-Pool.

Als letzter Strohhalm die Überprüfung, ob ein Bereitstellungsfehler vorliegt (vgl. Screenshot). Leider oder auch zum Glück nicht.

Get-CsOnlineUser -Identity xxx@yyy.de|Select UserValidationErrors

Lange Rede, kurzer Sinn: nun gehen mir die Ansätze aus.
Ist das Fehlen des SIP-Pools überhaupt die Ursache? Wie kann der SIP-Pool manuell gesetzt werden oder müsste dieses beim Aktivieren des Benutzers automatisch geschehen?

Hat jemand noch eine Idee, wie der Benutzer komplettiert werden kann oder welche Einstellungen noch überprüft werden können um das Problem weiter einzugrenzen?

Viele Grüße
Martin

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3281494113

Url: https://administrator.de/contentid/3281494113

Ausgedruckt am: 23.11.2024 um 21:11 Uhr

22 Kommentare

Neuester Kommentar

Hi,

einen Dial-Plan hast du zugewiesen?
Ich erinnere mich schwach, dass das bei uns beim Direct Routing auch konfiguriert ist, allerdings bin ich mir nicht sicher ob das benötigt wird.

Gruß Nussi

Hallo Nussi,

danke für deine Antwort - ich hatte die Hoffnung schon fast aufgegeben nach 250 Views noch einen Tipp zu bekommen.

Zu deinem Hinweis: Innerhalb des "Teams Admin Centers" sind Wählpläne (also Richtlinien, wie Teams auf verschiedene Eingaben reagieren soll) hinterlegt und den Benutzern zugewiesen.
[Den Begriff "Wählplan" scheint MS anscheinend öfter zu verwenden. Gemeint sind hier die Richtlinien und nicht die Möglichkeit seinen Rufnummernblock bei MS zu hosten und MS als Provider zu nutzen. Dafür wurde ja später "direct routing" eingeführt, dass man seine Nummern bei einem Telefon-Provider seiner Wahl lassen kann.]

Im Moment ist mein heißester Kandidat bei dem Problem, dass MS was im AzureAD umgestellt hat, evt. Felder nicht mehr in Benutzung sind oder Funktionen anders zu realisieren sind. Hinweis dafür ist die Beobachtung, dass von Skype-4-Business bekannt Befehle (z. B. Set-CsUser, enable-CsUser) nicht mehr genutzt werden können. Aber das sind nur Indizien.

Und das Problem taucht nur bei neueren Benutzern auf (etwa seit Mitte/Ende Mai oder Anfang Juni); bei älteren Usern ist das RegistrarPool-Attribut gefüllt.

Oder kann es sein sein, dass so ein SIP-Pool irgendwann voll ist, also beispielsweise "200 Benutzer" und dann ist Schluss?

Grüße in die Runde
Martin

Hallo Martin,

hab mich mit meinem gefährlichen Halbwissen zuerst nicht getraut 😉

Mit der Umstellung der Befehle hatte ich auch schon meine Probleme, aber mittlerweile ist mein Script für unsere Supporter wieder lauffähig. Man merkt doch noch, dass Micorosft an der Teams-telefonie noch arbeitet...

Zurück zu deinem Thema:

Hier die Ausgabe auf der CLI; zuerst wie meiner Meinung nach ein Benutzer aussehen sollte, als zweites der problematische Benutzer.

Der fehlende Registrar-Pool und der "Lync"-Absatz klingt für mich stark nach Skype for Business, du könntest mal versuchen den gleichen Registar-Pool zuzuweisen.

Set-CsRegistrar -Identity "....." -SipPort 5060

https://docs.microsoft.com/en-us/powershell/module/skype/set-csregistrar ...

Vielleicht hilft das ja, falls du das nicht selber schon gefunden hast. Ich kann jetzt allerdings auch nur ins Blaaue raten.

Gruß
Nussi

Hallo Nussi,

ach ja, Microsoft und seine ewigen Baustellen - ein Thema für sich.

„Set-CsRegistrar“ : dieser PS-Befehl ist mir bei der Fehler-Recherche bisher nicht unterkommen. Danke für den Tipp. Dann werde ich mal Morgen deinen Ansatz verfolgen…

Viele Grüße
Martin

Hallo Nussi,

leider nein: auch dieser Befehl ist schon im PowerShell-Nirvana gelandet

Bei mir ist die Version 4.5.0 des MicrosoftTeams-Cmdlet installiert.

Sollte ich zu einer Lösung finden, werde ich es hier kund tun.

Grüße
Martin

Hallo,

Der Benutzer wird online verwaltet - Fail

wurden die alten user korrekt übergeben, aber die neuen sind noch lokal oder werden nicht richtig gesynct.
Habt ihr AAD Connect, Skype sync?

Hat evtl hiermit zu tuen
docs.microsoft.com/de-de/skypeforbusiness/hybrid/move-users-between-on-premises-and-cloud

Habt ihr noch einen lokalen Skype Server?

Wenn der User richtig online auftaucht dann holt er sich sicherlich auch den richtigen pool.
Kann aber nach Erstellung einige Stunden dauern.

Lizenzen sollten zugewiesen sein für den User:
Jeder Anwender benötigt eine Telefonie-Lizenz für Office365

schau mal hier
www.skysystems.it/microsoft-teams-direct-routing-technik-tutorial/
Nachdem die Policy dann zugewiesen ist, dauert es nochmals bis zu 24 Stunden, bis der Ziffernblock in Teams erscheint und ausgehende Anrufe möglich sind.

Viele Grüße
Mr.Molochos

Hallo Molochos,

wir erstellen unser User lokal im AD und lassen sie mit dem Azure AD Connector syncen. Im AAD (M365 Admin Center) tauchen diese auch auf, die benötigten Lizenzen werden über Gruppen zugewiesen und korrekt im Admin Center wiedergegeben.
Skype Server haben wir seit Anfang des Jahres nicht mehr, die bestehenden User wurden schon im letzten Jahr nach Teams überführt. Diese wie auch die neuen User sind „Teams only“ mit „direct routing“. So wird es auch im „Teams Admin Center“ angezeigt - selbst bei den „problematischen“ Usern. Unterm Strich sind wir rund ein Jahr „Teams only“ und seit dem eigentlich auch kein Problem mit neuen Usern gehabt.

Auf deine Anregungen hin habe ich die VoiceRoutingPolicy gelöscht und neu gesetzt - mal abwarten, was Morgen das AAD dazu sagt.

Danke für deine Tipps und viele Grüße
Martin

Hallo,

hast du mal
OnPremLineUri,LineUri
bei altem und neuem User verglichen?

Hast du beim anlegen bei der Nummer beim neuen User das selbe Format wie bei den alten Usern benutzt?

Was bei der Beschreibung auffällt ist der Hinweis mit der E.164 Nummer zur Onlineverwaltung
docs.microsoft.com/de-de/microsoftteams/direct-routing-enable-users

Wieviele User (Anzahl) waren bis dato dem Sippool zugewiesen?

Ich würde möglichst viele/alle Attribute eines korrekten und des neuen Users mal selektieren und dann vergleichen, Vielleicht werden einige Attribute nicht richtig oder garnicht gesynct, sodas er zwar online aufftaucht aber einiges fehlt und so der user nich korrekt online verwaltet wird auch wenn er dort aufftaucht.

Vielleicht auch die Gruppenzugehörigkeit vergleichen, habt ihr noch spezielle 365 Gruppen angelegt in die er dafür muss, was beim sync nicht geklappt hat.
Möglichst mit Powershell prüfen, um alle Daten zu sehen.

Grüße
Mr.Molochos

Hallo,

hoffe, ihr seid bei den Temperaturen nicht alle weggeschmolzen oder habt euch wenigstens in den Serverraum verkrümelt.

hast du mal
OnPremLineUri,LineUri
bei altem und neuem User verglichen?

Jepp, sind identisch.

Hast du beim anlegen bei der Nummer beim neuen User das selbe Format wie bei den alten Usern benutzt?
Was bei der Beschreibung auffällt ist der Hinweis mit der E.164 Nummer zur Onlineverwaltung
docs.microsoft.com/de-de/microsoftteams/direct-routing-enable-users

Jepp, alle im Format +4912312345678
Nach der angeführten Microsoft-Anleitung wurden die User eingerichtet.

Wieviele User (Anzahl) waren bis dato dem Sippool zugewiesen?

Alle User sind auf zwei Pools verteilt: der erste umfasst 224 User der zweite 24 User. Im zweiten Pool sind überproportional neuere User vertreten.

Ich würde möglichst viele/alle Attribute eines korrekten und des neuen Users mal selektieren und dann vergleichen, Vielleicht werden einige Attribute nicht richtig oder garnicht gesynct, sodas er zwar online aufftaucht aber einiges fehlt und so der user nich korrekt online verwaltet wird auch wenn er dort aufftaucht.

Habe jetzt alle Attribute aller User, die man mit Get-CsOnlineUser ermitteln kann, ausgelesen: der Unterschied bei den problematischen Usern ist i) das Fehlen des RegistrarPools (der Fakt ist bekannt, s. o.) und ii) der Wert "65664" bei OptionFlags. Andere User haben an dieser Stelle "196992". Zu diesem Attribut konnte ich allerdings keine valide Beschreibung ermitteln (eine ältere Beschreibung mit Bezug auf S4B findet sich hier).

Auf einer anderen Webseite zum Thema "troubleshooting no dialpad" steht noch die Empfehlung die Lizenzen wegzunehmen und neu zu vergeben. Das werde ich dann auch noch mit den Kollegen abstimmen. Bin gespannt, ob das was bringt.

Allen einen schönen Abend.
Martin

Hallo,

git es bei dem problematischen User Onpremises das Attribut msRTCSIP-PrimaryUserAddress
siehe
docs.microsoft.com/en-us/skypeforbusiness/hybrid/cloud-consolidation-managing-attributes

answers.microsoft.com/en-us/msteams/forum/all/teams-skype-and-attributes/80d4cf3c-dfe5-4a25-9d33-0c19fe03b878

Grüße
Mr.Molochos

Hallo,

wie du ja angemerkt hast wird der User nicht online verwaltet, er wird onprem verwaltet und dann nur gesynct.
Er muss aber online verwaltet werden.
Um vollständige Teams-Funktionen zu erhalten, müssen diese Benutzer von Skype for Business lokal in die Cloud verschoben werden, wodurch der Benutzer zu TeamsOnly wird. Durch das Verschieben eines Benutzers aus der lokalen Umgebung in die Cloud wird der Koexistenzmodus des Benutzers auf TeamsOnly festgelegt.

Kunden, die eine lokale PSTN-Konnektivität benötigen, sollten Direct Routing verwenden. (Habt ihr ja)
bestimmte Teams-Funktionen sind nicht verfügbar, während diese Benutzer lokal verwaltet werden, z. B.:
-> PSTN-Anruffunktion (wenn dem Benutzer eine Telefonsystemlizenz zugewiesen ist).
docs.microsoft.com/de-de/skypeforbusiness/hybrid/plan-hybrid-connectivity

-> Weitere Informationen finden Sie unter "Verschieben von Benutzern aus der lokalen Umgebung zu Teams".
docs.microsoft.com/de-de/skypeforbusiness/hybrid/move-users-from-on-premises-to-teams
docs.microsoft.com/de-de/SkypeForBusiness/hybrid/move-users-between-on-premises-and-cloud

Ich würde mal einen neuen User zum testen onprem erstellen dem alles korrekt zuweisen und ihn dann online verwaltet verschieben.

Hier wird alles schön erklärt der Move und auch mit AADConnect
Infos zu Move-CSUser 365
www.msxfaq.de/cloud/sfbonline/movecsuser365.htm
-> Früher war die SfBOnline-PowerShell ein eigenes Modul, welches mittlerweile aber nicht mehr gültig ist. Die Commandlets sind in der Teams PowerShell aufgegangen.

Bei eurer Umstellung von Skype auf Teams müsstet ihr die User alle onlineverwaltet umgestellt haben.
Kann sein das die alten Skype Powershellcommandos das änderten und die neuen Teamskommandos das nicht machen.
Wie oft bekommen User bei euch einen neue Telefonconnect.

Grüße
Mr.Molochos

Hallo Molochos,

nochmals Danke für deine Ideen und Unterstützung.

Ich hoffe, ich hatte mich beim AD-Sync und dem Hinweis auf ein vormaliges S4B nicht irreführend ausgedrückt, aber ich fast überzeugt, dass es an dieser Ecke nicht hakt. Vielleicht erläutere ich eben den Prozess bei uns:

ein neuer Kollege wird im lokalen AD angelegt, der User wird ins AzureAD gesynct
erst nachdem der User an sich im AAD vorhanden ist, wird dieser "Teams-befähigt" (Powershell, Connect-MicrosoftTeams, Set-CsPhoneNumberAssignment)

Mein Hinweis, dass wir ursprünglich mal eine S4B-Installation hatten, hat vielleicht auf die falsche Fährte geführt, denn nachdem klar war, dass MS S4B sterben lassen wird, sind wir mit unseren weiteren Gehversuchen (das war alles noch EDV-interne Testphase) nur noch der Teams-Schiene gefolgt. Das müsste fast noch vor Corona gewesen sein, die S4B-Server liefen nur so "als Rückfallebene" mit. IM AAD sind daher alle User "TeamsOnly" [TeamsUpgradeEffectiveMode], "DirSyncEnabledOnlineTeamsOnlyUser" [InterpretedUserType] und haben "UpgradeToTeams" als TeamsUpgradePolicy. Als HostingProvider hat jeder User- selbst der problematische - "sipfed.online.lync.com" eingetragen, keiner hat einen SRV:-Eintrag, der auf eine lokale Verwaltung hindeutet.

git es bei dem problematischen User Onpremises das Attribut msRTCSIP-PrimaryUserAddress

Im lokalen AD hat kein Benutzer einen Wert in den msRTCSIP-Attributen mehr; diese wurden gelöscht.

Wie oft bekommen User bei euch einen neue Telefonconnect.

Wenn er ins Unternehmen eintritt bzw. die Stelle wechselt und dort eine Nummer vorgegeben ist. Sonst nimmt er die Nummer mit (habe ich dich richtig verstanden?).

Viele Grüße
Martin

Hallo TwistedAir,

mich würde Interessieren wo der Fehler lag.
Oder könnt ihr jetzt in eurer Firma nie wieder Telefonnummern anlegen oder ändern?

Grüße
Mr.Molochos

Hallo Molochos,

jetzt zum 1.8. haben wir neue Azubis bekommen - und siehe da, bei denen ist alles normal, als wäre nichts geschehen. Für mich sieht es aus, als ob das Ganze nur ein temporäres Problem (im MS-Dienst?) war. Wegen der zwei Problemfälle sind wir mit dem Microsoft-Support in Kontakt. Wenn ich von dort belastbare Infos bekomme, werde ich sie - sofern möglich - hier posten.
Habe mir eh schon ein paar Notizen gemacht (quasi "troubleshooting light", ein paar Powershell-Befehle zum Eingrenzen des Problems....), die ich hier nach Abschluss posten möchte... Vielleicht hat es dann ein Nächster einfacher.

Danke für deine Anteilnahme
TA

Hallo zusammen, gibt es mittlerweile eine Lösung? Wir haben das gleiche Problem! Vielen Dank

Hallo Dornski,

es gab bei uns keine Lösung aber eine Entwicklung: das Problem hat sich (nach einigen Wochen) von selbst gelöst. Wir hatte damals versucht über den Microsoft-Support das Problem lösen zu lassen, aber der Vorgang ist nicht gut verlaufen. Die Textbausteine und Hilfe-Links, die vom Support kamen, hatten wir entweder schon ausprobiert (und dieses bei der Supportanfrage entsprechend erwähnt) oder bezogen sich auf Skype4business, was bei Teams nicht funktioniert. Also eher eine frustrierende Erfahrung. Vermutlich haben wir nur den falschen Supportler erwischt.

Inzwischen können alle Kollegen mit Teams telefonieren. Was hat sich geändert?

Der "RegistrarPool" wurde von Microsoft ~~klammheimlich~~ im Hintergrund auf "Teams:" geändert
Dort, wo der RegistrarPool fehlte, wurde er ohne eigenes Zutun von MS ergänzt.

Also kann ich dir nur die Empfehlung geben dich direkt an den MS-Support zu wenden und um Ergänzung der fehlenden Einträge zu bitten.

Um mir einen Überblick zu verschaffen, welche Kollegen von dem Problem betroffen und welche individuellen Einstellungen gespeichert waren, habe ich mir damals ein PowerShell-Skript geschrieben, das die User-Attribute ausliest und als CSV (mit Tab-Stopp als Trennzeichen, da andere Zeichen als Wert vorkamen) speichert. Das stelle ich gerne zur Verfügung:

$host.ui.RawUI.WindowTitle = "CsOnlineUser-Attribute in Tabellenform"  

Clear-Host
Write-Host "Dieses Skript erzeugt eine CSV-Datei mit CsOnline-Attributen aller User im Azure AD.  
Das Trennzeichen der CSV-Datei ist 'TAB'.  

Zur Ausführung des Skripts sind Teams-Admin-Berechtigungen erforderlich.
Diese ggf. aktivieren/via PIM anfordern.


"  

Write-Host "Verbinden mit Azure AD...`n" -ForegroundColor Yellow  

Connect-MicrosoftTeams

Write-Host "Bitte warten..." -ForegroundColor Yellow -nonewline  

$User = Get-CSOnlineUser | foreach {$_.UserPrincipalName}
foreach($u in $user | select -first 1) {Get-CsOnlineUser -Identity $u | out-string | % {$_ -replace "`r`n +", "" -replace " +: .*`r`n", "`t" -replace "`r`n", "" -replace "(`t$){1}", ""} | Out-File -FilePath .\teams-user.csv -Force}  
foreach($u in $user) 
{
	Get-CsOnlineUser -Identity $u | out-string | % {$_ -replace "`r`n +", "" -replace "`r`n[a-zA-Z]+ +: ", "`t" -replace "`r`n", "" -replace "(^`t){1}", ""} | Out-File -FilePath .\teams-user.csv -Append  
	Write-Host "." -ForegroundColor Yellow -nonewline  
}

Write-Host "`n`n`nFertig. Fenster kann geschlossen werden.`n`n" -ForegroundColor Yellow  
Read-Host -Prompt " :: Drücken Sie Enter um das Fenster zu schließen :"  
Exit

Im Prinzip macht es drei Dinge:

mit dem AAD verbinden
die Attributnamen auslesen und speichern
die Attribute der User abfragen und speichern

Den Teil mit 'Connect-MicrosoftTeams' hätte man schöner mit Passwortabfrage machen können, aber für meine Zwecke reicht es.

Vielleicht hilft es dir.

Gruß
TA

Hallo TwistedAir,

vielen lieben Dank für deine schnelle Antwort und dem Skript. Ich kann den Sachverhalt exakt so bestätigen. Das Ticket bei MS ist offen und nur das Standardprogramm kommt bislang zurück. Keinerlei Reaktion - auf genau den Punkt Registrarpool ist nicht gefüllt, obwohl wir mehrfach darauf hinweisen.

Ich bin gepsannt wie es weitergeht, da wir über 300 Benutzer migrieren wollen und hier natürlich sofort die Telefonie funktionieren soll. Bisher haben wir nur Testuser.

Grüße
Dornski

Kleine Info, wenn ich das hier gerade richtig überflogen haben:
Bei uns hat das Entfernen und Neuzuweisen der Lizenz geholfen. In unserem Fall hängt die Lizenz im AAD an einer vom AD gesyncten Lizenzgruppe. Daher mussten wir die Gruppen im AD entfernen, ADsync abwarten, Lizenz hinzufügen. Und siehe da: registrarpool wurde von der Cloud selbstständig auf "Teams:" gesetzt.

Hallo und willkommen 213a107b502c75,

deine Vorgehensweise ist gut einen Versuch Wert, manchmal hilft es bei MS ein Ding neu aufzubauen.
Wir hatten damals auch experimentiert den Benutzer neu anzulegen, aber leider ohne Erfolg. Verstehe einer was da bei MS vorgeht.

Gruß
TA

Hallo, bei uns werden auch die Lizenzen per lokaler AD Gruppe ins Azure AD gesynct/verteilt/aktiviert. Habe eben einen betroffenen Benutzer aus der Gruppe entfernt (sync) und die Lizenzen nochmal entfernt und manuell zugwiesen. Aber bisher ist der RegistrarPool weiterhin leer. Hat das ggfs. wieder 24 Stunden gedauert? Viele Grüße