Room Provisioning

Nicht erst seit COVID19 werden Räume mit Outlook für Besprechungen gebucht. Räume sind normalerweise Exchange Postfächer mit deaktivierten AD-Benutzern, die von Exchange und Teams als "Raum" erkannt und entsprechend in Adresslisten angeboten werden. Mittlerweile werden aber immer mehr Räume mit einem aktiven Konferenzsystem ausgestattet, welches sich natürlich anmelden muss und eine Lizenz benötigt.

Was geht, was nicht?

Vielleicht haben Sie schon einmal ein AD-Konto angelegt und später zu einem Raumpostfach konvertieren oder aktivieren wollen. Es gibt ja mehrere Wege und Ausgangssituationen so etwas zu tun. Durch eine Fragestellung bei einem Kunden zum richtigen Provisioning von On-Premises aber auch Exchange Online-Räumen habe ich eine Testserie durchgeführt. deren Ergebnisse ich hier am Anfang schon vorstellen möchte.

Ich habe folgende drei Startpunkte:

  • Kein AD-Konto
    Wenn Sie noch nie einen Raum hatten und das AD-Konto nicht durch einen anderen Prozess anlegt wird, dann ist "New-Mailbox" oder "New-RemoteMailbox" das mittel der Wahl auf einen Schlag das Konto anzulegen.
  • Deaktiviertes AD-Konto
    Vielleicht legen Sie schon auf einem anderen Weg die Konten voran als deaktivierten Benutzer an. Dann ist "Enable-Mailbox" oder "Enable-RemoteMailbox" der richtige Schritt einen Exchange Raum daraus zu machen
  • Aktiviertes AD-Konto
    Wenn Sie aber schon wissen, dass es auch ein Konferenzsystem geben wird, könnten sie das Konto auch als aktives Konto vorbereiten und daraus mit "Enable-Mailbox" oder "Enable-RemoteMailbox" einen Raum machen.

Bei allen Exchange PowerShell-Befehlen sind natürlich der Parameter "-Room" und ggfls. weitere Parameter anzugeben. Das Ziel ist immer ein Raum aber auch hier gibt es vier unterschiedliche Ergebnisse:

  • Deaktivierte Raum On-Premises
  • Aktivierte Raum On-Premises
  • Deaktivierte Raum Exchange Online
  • Aktivierte Raum Exchange Online

Damit ist klar, was nun kommt: Die klassische Matrix, wie komme ich von den drei Ausgangssituationen zu einer der vier Zielkonfigurationen und welche Option geht direkt und welche nur über Umwege.

Alle Tests wurden mit Exchange 2016CU22 im Jan 2022 durchgeführt.

Quelle/Ziel OnPrem Aktiv OnPrem Deaktiv Hybrid Aktiv Hybrid Deaktiv
Kein AD-Konto

Ja!(1)

Ja(1)

Nein(2)

Ja
Aktives AD-Konto

Nein(3)

Nein(3)

Ja

Nein(4)
Deaktives AD-Konto

Nein(5)

Ja

Nein(5)

Ja

Sie sehen dass einige Dinge gehen und andere nicht. Hier die Fußnoten:

  1. Ich finde interessant, dass ich ein neues Konto nicht nur als deaktivierten Raum sondern auch als aktives Konto mit einem Schritt anlegen kann
  2. Ich kann lokal keine aktive "RemoteMailbox" direkt anlegen
    Es ist immer ein deaktiviertes Konto, welches von Hand danach aktiviert werden kann
  3. Ein vorhandenes lokales aktive AD-Konto kann nicht als Raum aktiviert werden
    Ich muss das AD-Konto vorher deaktivieren, damit "Enable-Mailbox" funktioniert
  4. Ich kann das Konto zum Raum konfigurieren aber es bleibt aktiv.
    Ich muss es in einem zweiten Schritte im AD deaktivieren, wenn es nicht aktiv sein soll.
  5. Ich kann das Konto mit Exchange Bordmitteln nicht aktivieren
    Es wird also bei der Aktivierung als Raummailbox auch für Windows

Wenn Sie genau hinschauen, dann unterscheiden sich die Ergebnisse zwischen lokalen Raumpostfächern mit aktiver Anmeldung und solche in der Cloud.

  • RemoteMailbox -Room erlaubt aktive Konten
    Sie können also Konferenzgeräte in der Cloud auf einen Schlag anlegen und aktivieren
  • "Mailbox -Room" nur deaktiviert
    Für lokale Raumpostfächer muss das Konto deaktiviert sein und erst nachträglich aktiviert werden

Mit einer RemoteMailbox ist es ohne Umwege direkt möglich auch einen aktiven anzulegen, was mit einem lokalen Raum nicht geht. In den folgenden Abschnitten beschreibe ich die einzelnen Schritte.

Für einige Befehle ist die Angabe eines Kennworts für das neue Konto als "SecureString" erforderlich. Dieses habe ich vorab wie folgt erzeugt.

$pass = ConvertTo-SecureString -String "Superg3he!m" -AsPlainText -Force

Testserie On-Premises

Die Ergebnisse der obigen Matrix habe ich in meiner Testumgebung auf Exchange 2016CU22 ausgeführt. Hier die Ergebnisse für On-Premises:

PowerShell Kontostatus Beschreibung 
New-Mailbox `
   -Name RaumNeuLokaldeaktiv `
   -Room

Deaktiv

Legt einen lokalen Raum als deaktiviertes Konto an. Der nicht angegebene Parameter "EnableRoomMailboxAccount" ist per Default "$False"

Ich aknn mit "-RoomMailboxPassword " oder "-Password" ein Kennwort setzen aber bei einem deaktivierten Konto macht das keinen Unterschied

 
New-Mailbox `
   -Name RaumNeuLokalaktiv `
   -Room `
   -RoomMailboxPassword $pass `
   -EnableRoomMailboxAccount $true

Aktiv

Legt einen lokalen Raum als deaktiviertes Konto an. Das Kennwort muss mit übergeben werden. Ich kann hier nicht den Parameter "Password" nutzen, sondern muss das Kennwort mit RoomMailboxPassword übergeben.

Die Parameter "RoomMailboxPassword" und "EnableRoomMailboxAccount" müssen gemeinsam verwendet werden

 
Enable-Mailbox `
   -Name RaumADLokalaktiv `
   -Room

Error: The user's Active Directory account `
  must be logon-disabled for linked, `
  shared, or resource mailbox.

Fehler

Ein bereits lokal existierendes aktives und mit Kennwort versehenes AD-Konto kann ich nicht zum Raum hochstufen. Ich muss das Konto zuerst deaktivieren und bei Bedarf danach wieder aktivieren. Interessanterweise sind "Räume" in der Fehlermeldung nicht aufgelistet.

 
Enable-Mailbox `
   -Name RaumADLokaldeaktiv `
   -Room

Deaktiv

Ein im AD deaktiviertes Konto kann ich ohne Probleme zu einem Raum aktivieren. Es bleibt deaktiviert und es gibt auch keinen Parameter "EnableRoomMailboxAccount ", um das Konto zu aktivieren.

Hier sind keine unerwarteten Resultate sichtbar geworden aber es ist natürlich für ein Provisioning unschön, dass ich zwar neue Benutzer als aktivierten Raum anlegen kann aber bestehende aktive Konten nicht ohne Umweg zum Raum konfigurieren kann.

Testserie Hybrid

Die gleiche Serie habe ich noch einmal für "RemoteMailbox" gemacht. Zum Exchange 2016CU22 wurde ADSync 2.0.19 und Exchange Hybrid-Mode konfiguriert. Anstelle des "*-Mailbox" wurde nun ein "*-RemoteMailbox" verwendet:

PowerShell Kontostatus Beschreibung 
New-RemoteMailbox `
   -Name RaumNeuRemoteDeaktiv `
   -Room

Deaktiv

Lokal wird ein deaktivierter Benutzer angelegt, der über ADSync in der Cloud als Raum erscheint.

Ich kann zusätzlich noch ein Kennwort mit "-password" mitgeben aber das Konto bleibt deaktiviert.

 
New-RemoteMailbox `
   -Name RaumNeuRemoteAktiv `
   -Room `
   -RoomMailboxPassword $pass 
A parameter cannot be found that 
matches parameter name 'RoomMailboxPassword'.
New-RemoteMailbox `
   -Name RaumNeuRemoteAktiv `
   -Room `
   -Password $pass `
   -ResetPasswordOnNextLogon:$true

Deaktiv

Der Versuch, ein aktives Raumpostfach in der Cloud anzulegen, funktioniert leider nicht. Es gibt weder den Parameter "RoomMailboxPassword" noch "EnableRoomMailboxAccount".

Ich kann aber mit dem Parameter "Password" das Kennwort setzen und mit "ResetPasswordOnNextLogon" optional sogar eine Änderung bei der Anmeldung erzwingen aber es bleibt ein deaktiviertes Konto.

Irgendwie macht der Befehl alleine keinen Sinn.

Um die Anforderung zu erfüllen, muss ich im Nachgang noch das Konto aktivieren.

 
Enable-RemoteMailbox `
   -Identity RaumADRemoteAaktiv `
   -Room `
   -RemoteRoutingAddress `
       "RaumADremoteaktiv
        @xx.mail.onmicrosoft.com"

Aktiv!

Wenn ich vorab einen lokalen AD-User für den Raum anlegen und mit Kennwort versehe und aktiv schalte, dann kann ich das Konto zu einem "RemoteRoom" machen und es bleibt aktiv.

Diese Funktion erleichtert das Anlegen von RemoteRoom-Postfächern mit einem Schritt und unterscheidet sich von On-Premises.!

 
Enable-RemoteMailbox `
   -Identity RaumADremoteDeaktiv `
   -Room `
   -RemoteRoutingAddress `
       "RaumADremotedeaktiv
        @xx.mail.onmicrosoft.com"

Deaktiv

Genauso kann ich ein vorhandenes deaktiviertes AD-Konto als RemoteRoom aktivieren. Es bleibt deaktiviert.

Im Unterschied zu einem On-Premises-Raumpostfach kann ich im Hybrid-Mode keine aktiven "RemoteMaibox -Room" anlegen. Es wird immer ein deaktiviertes Konto, selbst wenn ich ein Kennwort für das Konto bei der Neuanlage mit setze. Allerdings kann ich problemlos auch aktive Konten ohne Postfach zu einem Raumpostfach machen. Dieser Schritt wird On-Premises mit einem Fehler verhindert.

Exchange Online

Zuerst habe ich gedacht, dass die Provisionierung in Exchange Online ohne ADSync eigentlich nur ganz kleine Firmen betrifft und dort die Räume dann eh über das Admin Center im Browser angelegt werden. Es geht aber auch per Exchange Online PowerShell (Verwendet wurde Version 2.0.5). Hier die Ergebnisse der "OnlineOnly"-Serie:

PowerShell Kontostatus Beschreibung 
New-Mailbox `
   -Name RaumNeuOnlineDeaktiv `
   -Room
# Explizit deaktivieren
New-Mailbox `
   -Name RaumNeuOnlineDeaktiv2 `
   -Room `
   -EnableRoomMailboxAccount:$false

New-Mailbox: Der Parameter "-RoomMailboxPassword" 
kann für diesen Raum nicht festgelegt werden, 
wenn "-EnableRoomMailboxAccount" auf 
"false" gesetzt ist.

Aktiv!

Per Powershell kann ich so auf einen Schlag einen "CloudOnly"-User anlegen, der als Raumpostfach aktiviert wird.

Überraschend ist hier aber, das das Konto aktiviert ist. Das unterscheidet sich von On-Premises! Allerdings weiß nicht, welchs Kennwort er gesetzt hat.

Interessant ist, dass der Versuch scheitert, mit EnableRoomMailboxAccount:$false das Konto deaktiviert anzulegen. Als wenn der Parameter "RoomMailboxPassword" gesetzt wäre, obwohl ich ihn nicht gesetzt habe.

 
New-Mailbox `
   -Name RaumNeuOnlineAktiv `
   -Room `
   -RoomMailboxPassword $pass `
   -EnableRoomMailboxAccount:$true

Aktiv

Der Unterschied zum vorherigen Test ist minimal, denn auch ohne die Angabe von EnableRoomMailboxAccount hat New-Mailbox schon aktive Räume angelegt

 
Enable-Mailbox RaumNeuOnlineDeaktiv
Enable-Mailbox RaumNeuOnlineAktiv

WARNING: Wechseln Sie nach dem Erstellen 
eines neuen Postfachs zum Office 365 
Admin Center, und weisen Sie dem Postfach 
eine Lizenz zu, oder es wird nach dem 
Aktivierungszeitraum deaktiviert.

Enable-Mailbox: Fehler bei Überprüfung im 
Agent 'Archive ParameterSet Enforcement 
Agent': 'Dieser Vorgang kann nur mit den 
Parametern "Archive" und 
"PermanentlyDisable" ausgeführt werden.'

Fail

In Exchange Online gibt es bei "Enable-Mailbox" nicht den Parameter "Room". Ich kann ein bestehendes AD-Konto aber auch nicht zu einer Mailbox aktivieren.

Die Aussagen sind hier mehrdeutig, denn auf der einen Seite warnt mich Enable-Mailbox, dass ich noch nachträglich eine Lizenz zuweisen soll. Auf der anderen Seite wird die Mailbox aber nicht angelegt, weil der ArchivAgent ohne Lizenz die Aktivierung verhindert.

CloudOnly-Konten brauchen aktuell wohl immer eine Lizenz.

Eine existierende Mailbox kann ich aber immer mit "Set-Mailbox -Type Room" zu einem Raum machen.

Nachdem ich per PowerShell mit "Enable-Mailbox" ein bestehende AzureAD-Konto nicht zu einem Raum aufwerten konnte, habe ich beide Exchange Admin Portals ausprobiert und interessante Dinge festgestellt, die mir vorher gar nicht aufgefallen sind:

  • Altes AdminCenter - Benutzer
    Hier gibt es gar keine GUI, um ein bestehendes AD-Konto mit einem Postfach zu versehen oder das Postfach zu deaktivieren. Die Funktion von "Enable-Mailbox" und "Disable-Mailbox" ist nicht da. Für mich ist das ein deutliches Zeichen, dass es nur über die Lizenzvergabe gesteuert wird.
  • Altes AdminCenter - Ressourcen
    Auch bei Ressourcen kann ich über das Plus nur neue Räume oder Geräte anlegen aber auch keine bestehenden Konten aktivieren.
  • Neues AdminCenter - Benutzer
    Auch hier gibt es keine Option, bestehende AD-Konten mit einem Postfach aufzuwerten. Ich kann nur "Shared Mailboxen" anlegen.
  • Neues AdminCenter - Ressourcen
    Auch hier kann ich nur neue Räume oder Ressourcen anlegen aber keine bestehenden AzureAD-Konten nutzen.

Es hat den Anschein, dass in einer reinen Online-Welt die Räume in Exchange Online direkt "neu angelegt" werden, so dass im Hintergrund das AzureAD einen Benutzer bekommt und in Exchange ein Raum daraus wird. Das AzureAD-Konto ist interessanterweise immer aktiviert und hat ein nicht näher bekanntes Kennwort. Ich kann bei einem aktivierten Raum ein eigenes Kennwort mitgeben aber den Raum nicht als "deaktiviertes Konto" anlegen.

New-Mailbox room3 `
   -Room `
   -EnableRoomMailboxAccount:$false
New-Mailbox: Der Parameter "-RoomMailboxPassword" kann für diesen Raum nicht festgelegt 
werden, wenn "-EnableRoomMailboxAccount" auf "false" gesetzt ist.

New-Mailbox room4 `
   -Room `
   -EnableRoomMailboxAccount:$true `
   -RoomMailboxPassword:(ConvertTo-SecureString -String "Superg3he!m" -AsPlainText -Force)
# erfolgreich

Man kann nun geteilter Meinung sein, ob ein aktives Raumpostfach mit unbekanntem Kennwort weniger sicher ist als ein deaktiviertes Postfach. Wer hier sensibel ist, kann das eigene Provisioning erweitern, dass die Konten deaktiviert werden oder per Conditional Access den Zugriff auf Räume z.B. auf ausgewählte Konferenzgeräte einschränkten.

Weitere Exchange Einstellungen

Wenn Sie nun den Raum angelegt haben, gibt es natürlich noch weitere Parameter zu konfigurieren, z.B. die Anzahl der Sitzplätze und wie der Raum auf eingehende Buchungsanfragen reagiert.

Weitere Teams Einstellungen

Für die Nutzung als Teams-Raum sind weitere Einstellungen erforderlich. Sie brauchen natürlich zuerst einmal das aktive Raumpostfach mit einem Kennwort zur Einrichtung des Konferenz-Systems. Vorher sollten Sie das Raumpostfach für Terminzusagen anpassen, z.B:

Set-CalendarProcessing `
   -Identity 'raum1@msxfaq.de' `
   -AutomateProcessing AutoAccept `
   -AddOrganizerToSubject $false `
   -AllowConflicts $false `
   -DeleteComments $false `
   -DeleteSubject $false `
   -RemovePrivateProperty $false

Set-CalendarProcessing `
   -Identity 'raum1@msxfaq.de' `
   -AddAdditionalResponse $true `
   -AdditionalResponse "Dies ist ein Teams Raum"

Weiterhin müssen Sie die "Usage Location" und Lizenz konfigurieren:

Set-MsolUser `
   -UserPrincipalName 'raum1@msxfaq.de' `
   -UsageLocation 'DE' `
   -PasswordNeverExpires $true 

Set-MsolUserLicense `
   -UserPrincipalName 'raum1@msxfaq.de' `
   -AddLicenses 'msxfaq:MEETING_ROOM

Dann muss der Raum auch noch für Teams/Skype aktiviert werden, z.B. für Enterprise Voice, wenn Sie im Raum auch Teilnehmer per Telefonanruf addierne wollen.

Enable-CsMeetingRoom `
   -Identity 'raum1@msxfaq.de' `
   -SipAddressType “EmailAddress” `
   -RegistrarPool “sippoolblu2a05.infra.lync.com“

Set-CsMeetingRoom 
   -Identity 'raum1@msxfaq.de'
   -EnterpriseVoiceEnabled $true

Denken Sie auch daran, dass das Device nicht nur im Teams Admin Center verwaltet werden kann, sondern eventuell auch Intune oder ein Gerätemanagement des Hersteller eingebunden werden soll.

Weitere Links