Sandro Reiter

vCard und IT-Blog

Office 365: Neue Möglichkeit zur Zusammenarbeit

Heute habe ich durch Zufall eine spannende Option in den Azure AD Organisationseinstellungen entdeckt:

Auch wenn derzeit noch Preview dran steht, finde ich die Funktion enorm nützlich. Ich weiß gar nicht, wie viele der durch mich betreuten Kunden schon danach gefragt haben.

 

Aber was hat es mit dieser Einstellung auf sich?

Auch wenn Microsoft fleißig daran arbeitet, gibt es auch in 2019 immer noch Personen die keinen Microsoft Account oder ein Office 365 / Azure AD Konto besitzen (wollen/können/dürfen).

Oftmals ist die IT in großen Konzernen sehr restriktiv und so dürfen bspw. keine privaten Accounts genutzt werden und der Einsatz von OneDrive ist frühstens in 2054 geplant.

Mit OTP (one time password) als Alternative zu klassischen Einladungen für die Zusammenarbeit in Office 365 ist auch denjenigen geholfen, die zu dem oben beschriebenen Nutzerkreis gehören.

Ein einmaliger Code in Kombination mit der eigenen E-Mail-Adresse dient als Authentifizierungsmethode um auf Inhalte zuzugreifen – Gültigkeit eines OTP: 24 Stunden.

 

Und so sieht es, anhand eines OneDrive Sharing-Prozesses, für die Benutzer aus:

Die Datei oder der Ordner wird über das Teilen-Menü mit einem externen Benutzer geteilt.

Der teilende Benutzer sendet eine Einladung zur Zusammenarbeit an die angegebene E-Mail-Adresse. 

Microsoft prüft im Hintergrund ob zu dem Konto ein Microsoft-/Azure AD-Account existiert. Wenn dies nicht der Fall ist, wird der Eingeladene auf das OTP-Verfahren umgeleitet. Der eingeladene Benutzer gibt zur Verifizierung seine E-Mail-Adresse und den Einmalcode (OTP), welcher gesondert per E-Mail versendet wird, zur Authentifizierung ein.

Nach erfolgreicher Authentifizierung kann nun endlich kollaboriert werden.

Der Besitzer bzw. Absender der Datei-/Ordnerfreigabe bekommt außerdem eine Benachrichtigung darüber, das die eingeladene Person den OneDrive-Link geöffnet hat.

 

 

Microsoft zeigt damit wieder, das Feedback gehört und berücksichtigt wird. Ich bin gespannt was sich bis zur finalen Veröffentlichung hier noch tut.

Teams: E-Mail-Kommunikation in Kanälen anzeigen

Microsoft Teams ist in seinem Segment als „eierlegende Wollmilchsau“ wohl einer der größten und gelungensten Würfe der IT-Branche in den letzten Jahren!

MS Teams hat sich so stark in meinen Arbeitsalltag integriert, das ich es nicht mehr missen möchte und vermutlich auch gar nicht kann. Ich bin bereits in Q4 2018 den Weg gegangen und habe mich als ersten User in unserem Tenant auf „teams-only“-Benutzung umgestellt.

Mein Skype for Business Client sagt mir beim Start nur noch freundlich:
Geh doch bitte zu Teams 😉
Meine letzte verbliebene S4B Funktionalität: An S4B-Meetings teilnehmen.

 

Teams auf Office 365 Gruppen aufzusetzen ist eine gelungene Entscheidung, mit einem großen Nachteil: Gruppenunterhaltungen – also E-Mails – tauchen nicht im jeweiligen Team auf. Ich muss zur Diskussion einer E-Mail diese immer erst an den Kanal weiterleiten.

 

Natürlich gibt es aber einen Workaround:

Jeder Teams-Kanal hat eine eigene E-Mail-Adresse welche auf @emea.teams.ms endet. Dieses Feature machen wir uns zu Nutze.

Als erstes empfiehlt es sich einen eigenen Kanal, beispielsweise namens „E-Mails“, im Team anzulegen.

Anschließend kann über das Kanal-Kontextmenü (•••) mit einem Klick auf „E-Mail-Adresse abrufen“ die Kanal-E-Mail-Adresse ausgelesen werden.

Mit dieser E-Mail-Adresse wird im Azure AD ein Gast-Nutzer angelegt.

Der angelegte Gastnutzer muss anschließend nur noch als Mitglied zur Office 365 Gruppe hinzugefügt werden. Das erledigt am besten die PowerShell um zu garantieren das der Gastnutzer auch ein Abonnent der Gruppe wird:

#add guest user as member to o365 group
Add-UnifiedGroupLinks -LinkType Members -Identity "myO365Group" -Links "myTeamsChannelGuestUser"
#add guest user as subscriber to o365 group to receive emails
Add-UnifiedGroupLinks -LinkType Subscribers -Identity "myO365Group" -Links "myTeamsChannelGuestUser"

Ab diesem Moment werden E-Mails an die O365 Gruppe auch in dem jeweiligen Teams-Kanal zugestellt.

Azure: Tenant-übergreifendes VNet-Peering

Peerings zwischen virtuellen Netzwerken in Azure sind eine tolle Sache: Einfach zu konfigurieren, schnell bereitgestellt und die Performance ist ebenfalls klasse!

Zum Verbinden von virtuellen Netzwerken aus verschiedenen Azure Active Directory Tenants, wie es beispielsweise in Unternehmensgruppen der Fall ist, mussten bis vor Kurzem noch VPN-Gateways bereitgestellt werden.

Jetzt ist es möglich VNet-Peerings Tenant-übergreifend zu erstellen, derzeit allerdings nur über Azure CLI, PowerShell oder als ARM-Template.

Ich zeige Euch die PowerShell Variante.

Als Voraussetzung benötigt Ihr einen Azure AD-Benutzer, welcher sowohl in Tenant A als auch Tenant B (dann als Gast) die Berechtigung „Network Contributor“ auf das jeweilige virtuelle Netzwerk hat, um das VNet „auf der anderen Seite“ auslesen und das Peering erstellen zu können.

 

Ist das gegeben, kann es losgehen. Folgendes Skript erledigt alles nötige für Euch, wenn Ihr die Variablen korrekt befüllt:

#declare variables
$subscriptionTenantA = "subscriptionID"
$vNetTenantA = "vNet"
$vnetResourceGroupTenantA = "vNetResourceGroup"
$peerAtoBname = "TenantA-TenantB-Peer01"
$subscriptionTenantB = "subscriptionID"
$vNetTenantB = "vNet"
$vnetResourceGroupTenantB = "vNetResourceGroup"
$peerBtoAname = "TenantB-TenantA-Peer01"

#connect to AzureRM
Connect-AzAccount

#select subscription in Tenant A
Select-AzSubscription -Subscription $subscriptionTenantA

#peer vnet in tenant A to vnet in tenant B
$vNet = Get-AzVirtualNetwork -Name $vNetTenantA -ResourceGroupName $vnetResourceGroupTenantA
Add-AzVirtualNetworkPeering -Name $peerAtoBname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantB/resourceGroups/$vnetResourceGroupTenantB/providers/Microsoft.Network/virtualNetworks/$vNetTenantB"

#select subscription in Tenant B
Select-AzSubscription -Subscription $subscriptionTenantB

#peer vnet in tenant B to vnet in tenant A
$vNet = Get-AzVirtualNetwork -Name $vNetTenantB -ResourceGroupName $vnetResourceGroupTenantB
Add-AzVirtualNetworkPeering -Name $peerBtoAname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantA/resourceGroups/$vnetResourceGroupTenantA/providers/Microsoft.Network/virtualNetworks/$vNetTenantA"

Läuft, oder? 😉

 

Der Vollständigkeit halber noch folgender Hinweis zum Schluss:

Die Optionen „Allow gateway transit“ und „Use remote gateway“ stehen nur zur Verfügung, wenn sich die virtuellen Netzwerke in der selben Azure Region befinden. Bei einer Verbindung bspw. zwischen Westeuropa und Frankreich-Mitte funktioniert das derzeit leider noch nicht.