Vor kurzem kam mir in einer frisch aufgebauten Azure Virtual Desktop (AVD) Umgebung ein merkwürdiger Fehler unter. Nach dem Login und der Auswahl der gewünschten App startet der Verbindungsaufbau. Dieser schlägt dann jedoch mit folgender Fehlermeldung fehl:
Wir konnten leider keine Verbindung mit „Outlook“ herstellen.
Mit dem Gateway konnte aufgrund eines Fehlers keine Verbindung hergestellt werden. Sollte das Problem wiederholt auftreten, wenden Sie sich an Ihren Administrator oder an den technischen Support.
Auf englischsprachigen Systemen sieht es dann so aus:
Oops, we couldn’t connect to „Outlook“
We couldn’t connect to the gateway because of an error. If this keeps happening, ask your admin or tech support for help.
Meine Suche im Internet zu möglichen Ursachen brachte leider nichts passendes. Da ich den Grund des Fehlers dann aber kurz darauf selber bemerkt habe, dachte ich, ich dokumentiere das Ganze hier kur, falls noch andere Nutzer in diese „Falle“ tappen:
Die Ursache des Fehlers hat nichts mit Netzwerk oder anderen Verbindungsproblemen zu tun, wie die Meldung zunächst vermuten lässt.
Ich hatte mich schlichtweg am AVD Webclient mit einem User angemeldet, den es in der Windows Server Domäne (ADDS / NTDS) nicht gibt, sondern nur im Azure AD. Die Anmeldung am Host des Hostpools erfolgt aber gegen einen regulären Domänencontroller! Der cloud-only User kann sich noch problemlos am AVD Webclient anmelden, dieser gibt auch keine Warnung o.ä., aus. Nur das Starten der Apps geht dann eben nicht…
Wenn ihr also auch auf diesen Fehler stoßt: Stellt sicher, dass der verwendete Benutzer in der Domäne bekannt und das Passwort dort identisch ist!
Microsoft stellt ein schönes PowerBI Tooling bereit, mit dem man für seine Azure AD location und die verwendeten Services feststellen kann, wo die Daten tatsächlich gespeichert werden:
Es geht hier also vor allem um das Speichern der Telefonnummern und UPNs in Amerika. Diese Tatsache war mir – und ich vermute da geht es einigen von euch ähnlich – so nicht bewusst…
Ich hatte vor Kurzem eine sehr interessante Konstellation: Ich hatte einen bereits im lokalen AD deaktivierten Benutzer wieder aktiviert, da der betroffene Mitarbeiter neuerlich für uns tätig werden sollte. Danach kam es zu Fehlern bei der Synchronisierung zwischen unserem lokalen Active Directory und dem AzureAD, das wir als Grundlage für Office 365 verwenden:
Auch der Versuch, das betroffene Konto in Office 365 aus den gelöschten Objekten wiederherzustellen, schlug fehl:
Dadurch hat sich aber der Grund für das merkwürdige Verhalten offenbart: Das Konto war exakt einen Monat vorher deaktiviert bzw. gelöscht worden – und existierte dadurch scheinbar nur noch halb.
Um das Problem zu lösen, habe ich das betreffende Konto in Office 365 per PowerShell dauerhaft gelöscht:
Nichts neues, aber da es mir heute wieder über den Weg gelaufen ist: Wenn man mittels Hyper-V Manager eine VM von einem Host auf einen anderen live verschieben, dann gibt es im Wesentlichen zwei mögliche Protokolle: CredSSP und Kerberos.
CredSSP ist in der Anendung grundsätzlich einfach, hat aber einen entscheidenden Nachteil: Man muss interaktiv (!) an dem Host angemeldet sein, von dem man die VM (weg) verschieben will. Andernfalls bekommt man einen hübschen Fehler:
Der Fehlertext lautet:
Fehler beim Herstellen einer Verbindung mit dem Host “DERHOSTNAME”: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).
Failed to establish a connection with host “THEHOSTNAME”: No credentials are available in the security package (0x8009030E)
Insbesondere auf Core-Servern bleibt hier also nur eine Möglichkeit: Man muss auf Kerberos umstellen! Dazu jedoch müssen sich die Server, zwischen denen man verschieben möchte, für das Protokoll “cifs” und “Microsoft Virtual System Migration Service” vertrauen.
Das könnte man jetzt im ActiveDirectory manuell konfigurieren – aber spätestens bei einer zweistelligen Anzahl an Hosts ist das eine sehr mühsame Klickerei. Also warum nicht PowerShell bemühen? Ich habe mir dazu schon vor einer ganzen Weile ein recht kurzes Skript geschrieben, was jeden der aufgeführten Host gegen jeden anderen berechtigt bzw. die Kerberos-Delegierung einrichtet.
Hier das Skript im Textlaut. Viel Spaß damit!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$Domain='domain.local'# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here$HyperVHosts="HOST1","HOST2","HOST3","HOST4","HOST5"ForEach($Host1in$HyperVHosts){ForEach($Host2in$HyperVHosts){If($Host1-ne$Host2){"Delegating from $Host1 to $Host2..."
Get-ADComputer $Host1| Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="Microsoft Virtual System Migration Service/$($Host2).$($Domain)","cifs/$($Host2).$($Domain)","Microsoft Virtual System Migration Service/$Host2","cifs/$Host2"}
Get-ADComputer $Host1| Set-ADAccountControl -TrustedForDelegation:$false-TrustedToAuthForDelegation:$true}}}
$Domain = 'domain.local'
# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here
$HyperVHosts = "HOST1","HOST2","HOST3","HOST4","HOST5"
ForEach($Host1 in $HyperVHosts)
{
ForEach($Host2 in $HyperVHosts)
{
If($Host1 -ne $Host2)
{
"Delegating from $Host1 to $Host2..."
Get-ADComputer $Host1 | Set-ADObject -Add @{"msDS-AllowedToDelegateTo" = "Microsoft Virtual System Migration Service/$($Host2).$($Domain)", "cifs/$($Host2).$($Domain)", "Microsoft Virtual System Migration Service/$Host2", "cifs/$Host2"}
Get-ADComputer $Host1 | Set-ADAccountControl -TrustedForDelegation:$false -TrustedToAuthForDelegation:$true
}
}
}
Heute bin ich über folgendes Problem gestolpert: Bei einem neuen Mitarbeiter enthielt die E-Mail-Adresse im Office 365 einen Unterstrich (“Underscore”) an erster Stelle:
(Zusätzlich wurde nicht die reguläre Domäne sondern eine “@*.onmicrosoft.com” verwendet…)
Die Benutzer werden mittels “Azure AD Connect” vom lokalen Active Directory nach Azure AD synchronisiert und bilden dort die Grundlage für die Office 365 Benutzer. Daher kann man die E-Mail-Adressen auch nicht online ändern, sondern nur on-premise. Im lokalen AD war aber auf den ersten Blick alles in Ordnung:
Nach kurzer Recherche fand ich einen Microsoft KB Artikel, der mich auf die Lösung brachte:
In this scenario, after directory synchronization is run, the special character is replaced by an underscore character. Therefore, the user’s Office 365 email address contains an underscore character instead of the special character.
Dabei wird eine Liste mit “verbotenen” Zeichen aufgeführt (die merkwürdigerweise auch das @-Zeichen enthält…), zu denen auch das Leerzeichen gehört. Bezogen ist das ganze auf die AD-Attribute “mail” und “proxyAddresses”. “Mail” war in Ordnung, aber “proxyAddresses”…
…nicht! Hier war ein Leerzeichen zwischen “SMTP:” und der eigentlichen E-Mailadresse. Nach dem ich dieses entfernt hatte und schnell noch den DirSync mit
Start-ADSyncSyncCycle -PolicyType Delta
angestoßen hatte, war der Benutzer mit seiner korrekten E-Mail-Adresse in Office 365 vorhanden!
Hat man häufig wechselnde Benutzer in seinem Active Directory (wie z.B. bei mir an der Hochschule, oder auch bei Lehrlingen, Werkstudenten oder ähnlichem), dann ist es sinnvoll, die Benutzerkonten dieser Personenkreise von vornherein mit einem Ablaufdatum zu versehen:
Ein mögliches Problem hierbei ist, dass die Benutzer erst NACH dem Ablauf feststellen, dass sie nicht mehr arbeiten können und sich bis zur Verlängerung durch einen Admin daran auch nichts ändert. Also wäre es doch schön, wenn die Benutzer schon vor dem Ablaufdatum daran erinnert werden, um sich zeitnah zu melden. Eine mögliche Lösung hierfür liegt wie so oft in einem PowerShell-Skript.
Der Kern des Skriptes ist die Suche nach den relevanten Accounts. Dazu dient “Search-ADAccount”:
Search-ADAccount -AccountExpiring -TimeSpan „32“
Diese Abfrage liefert alle Accounts, die in den nächsten 32 Tagen ablaufen (32 habe ich hier gewählt, um bei monatlicher Ausführung des Skriptes niemanden zu “vergessen”.
Der Rest ist dann eher schmückendes Beiwerk. Mit einer Schleife wird über alle entsprechenden Benutzer iteriert und jedem eine passende E-Mail gesendet:
Import-Module ActiveDirectory
# Werte wie gewünscht anpassen:[int]$AnzahlTage=32[TimeSpan]$Zeitraum=New-TimeSpan-Days$AnzahlTage[string]$subject="Ihr Benutzeraccount wird in den nächsten 31 Tagen ablaufen!"[string]$MailSender="ich@domain.de"[string]$MailServer="mail.server.com"ForEach($ExpiringUserin(Search-ADAccount -AccountExpiring -TimeSpan $Zeitraum| Get-ADObject -Properties samaccountname,mail,accountExpires)){$ExpDate=[datetime]::FromFileTime($($ExpiringUser.accountExpires))$body="Werter Benutzer!`r`r
Ihr Benutzerkonto `"$($ExpiringUser.samaccountname)`" wird in den kommenden 31 Tagen ablaufen. Das genaue Ablaufdatum lautet:`r`r
$(Get-Date ($ExpDate.AddDays(-1)) -Format "dd.MM.yyyy")`r`r
Mit freundlichen Grüßen,`r
Ihre IT-Abteilung"
Send-MailMessage -From $MailSender-To $ExpiringUser.mail -Subject $subject-Body$body-SmtpServer $MailServer-Encoding UTF8 -Priority High -Bcc $MailSender}
Import-Module ActiveDirectory
# Werte wie gewünscht anpassen:
[int]$AnzahlTage = 32
[TimeSpan]$Zeitraum = New-TimeSpan -Days $AnzahlTage
[string]$subject = "Ihr Benutzeraccount wird in den nächsten 31 Tagen ablaufen!"
[string]$MailSender = "ich@domain.de"
[string]$MailServer = "mail.server.com"
ForEach($ExpiringUser in (Search-ADAccount -AccountExpiring -TimeSpan $Zeitraum | Get-ADObject -Properties samaccountname,mail,accountExpires))
{
$ExpDate = [datetime]::FromFileTime($($ExpiringUser.accountExpires))
$body =
"Werter Benutzer!`r
`r
Ihr Benutzerkonto `"$($ExpiringUser.samaccountname)`" wird in den kommenden 31 Tagen ablaufen. Das genaue Ablaufdatum lautet:`r
`r
$(Get-Date ($ExpDate.AddDays(-1)) -Format "dd.MM.yyyy")`r
`r
Mit freundlichen Grüßen,`r
Ihre IT-Abteilung"
Send-MailMessage -From $MailSender -To $ExpiringUser.mail -Subject $subject -Body $body -SmtpServer $MailServer -Encoding UTF8 -Priority High -Bcc $MailSender
}
Das war es dann auch schon. Viel Spaß beim Adaptieren…
Das vollständige Skript kann auch hier heruntergeladen werden:
Wenn man mit Azure AD Sync arbeitet und einen neuen Mitarbeiter im lokalen on-premise Active Directory anlegt, dann kann es einem passieren, dass dieser im Office 365 Portal eine *.onmicrosoft.com E-Mail-Adresse als primäre Mailadresse bekommt, selbst wenn man im AD-Konto die richtige Adresse eingetragen hat:
Das lässt sich über das Office 365 Admin-Portal auch nicht ändern, da der Benutzer eben aus dem lokalen AD synchronisiert wird:
Der Trick besteht darin, im lokalen AD das Attribute “proxyAddresses” zu erweitern (entweder ist es leer oder es enthält bereits einen Eintrag “x500:/o=…”).
Der neue Eintrag muss mit “SMTP:” (Großbuchstaben und den Doppelpunkt nicht vergessen) gefolgt von der gewünschten E-Mail-Adresse (ohne Leerzeichen) bestehen:
Nach der nächsten Synchronisierung sollte es dann auch in Office 365 passen! Viel Spaß damit…
Nachtrag: In meinem Fall existiert kein on-premise Exchange Server! Wenn ihr einen solchen doch habt, dann verändert ihr mit der Änderung des AD-Attributes natürlich auch dort die Mailadresse…
Auf den bisher drei Treffen der in 2016 neu gegründeten Windows Server Usergroup Leipzig (WSUG L.E. – organisiert über Meetup unter meetup.com/de-DE/wsugle/) haben bereits diverse Leute Vorträge gehalten, darunter auch einige MVPs.
Hier möchte ich eine kurze Übersicht der Video geben, die ihr dann ganz bequem von zuhause anschauen könnt. Die Qualität der Videos variiert leider recht stark – seid also bitte nicht gleich abgeschreckt, wenn das erste Video das ihr euch zum Anschauen ausgewählt habt nicht so toll ist. Danke!
Nach einer Migration zu Office 365 kann es sinnvoll bzw. gewünscht sein, alle on-premise Exchange-Server zu deinstallieren. Microsoft selbst beschreibt dies z.B. in der Schritt-für-Schritt-Anleitung für eine Cutover-Migration (Übernahmemigration):
Außerbetriebnahme der lokalen Exchange Server. Nachdem Sie sich vergewissert haben, dass alle E-Mails direkt an die Office 365-Postfächer weitergeleitet werden, und wenn Sie Ihre lokale E-Mail-Organisation nicht mehr benötigen oder nicht planen, eine Lösung für einmaliges Anmelden zu implementieren, können Sie Exchange auf Ihren Servern deinstallieren und Ihre lokale Exchange-Organisation entfernen.
Im Nachsatz dazu heisst es dann interessanterweise:
HINWEIS : Eine Außerbetriebnahme von Exchange kann unerwartete Folgen haben. Vor der Außerbetriebnahme Ihrer lokalen Exchange-Organisation sollten Sie Kontakt mit dem Microsoft-Support aufnehmen.
Ich für meinen Teil wollte in erster Linie den Alten Exchange 2010 loswerden. Vermutlich werde ich später einen neuen Exchange 2016 installieren…
ACHTUNG: Wenn DirSync bzw. Azure AD verwendet werden, dann können AD-Attribute nur on-premise und nicht in Azure geändert werden. Wenn Exchange entfernt wird, können einige Mail-relevante Attribute nicht mehr geändert werden. Einige Attribute könnten zwar über ADSIEdit geändert werden, das wird aber offiziell nicht unterstützt!
Aber reden wir weniger über das WARUM als viel mehr über das WIE…
Wenn man sich nun also entschieden hat, den (letzten) Exchange-Server los zu werden und die Deinstallation gestartet hat, wird man relativ schnell feststellen, dass es nicht ganz so einfach ist! Die Deinstallation stört sich nämlich daran, dass es noch Postfächer gibt:
Nun könnte man natürlich einfach alle Mailboxen löschen (bzw. deaktivieren – löscht man eine Mailbox, löscht man den dahinterstehenden AD Benutzer, also keine gute Idee), aber: Nach dem Deaktivieren der Mailbox hat der entsprechende AD-Benutzer keine E-Mail-Adresse mehr (und er verliert auch auf anderen Attributen die Werte), was durchaus ein Problem für DirSync bzw. eine Synchronisation zu Azure AD sein kann. Was ist nun also der richtige Weg?
Im wesentlichen sind zwei Schritte notwendig:
Mailbox deaktivieren
Benutzer in einen so genannten “Mail-Enabled-User” umwandeln
Die Schwierigkeit dabei besteht darin, dass die E-Mailadresse “zwischengespeichert” werden muss, damit diese dem Mail-Enabled-User zugewiesen werden kann (oder man hat eine Syntax, nach der sich ALLE E-Mail-Adressen bilden lassen, da könnte man das weglassen)
Das Ganze habe ich natürlich mit PowerShell gelöst. Das folgende Skript soll ein Anhalt sein, passt es bitte an eure Gegebenheiten an!
Nur als kurze “Randnotiz”: Wenn man eine Office 365 Subscription hat und seine Benutzerkonten aus einem On-Premise Active Directory nach Azure AD synchronisiert, dann kann man zwar an verschiedenen Stellen Dinge wie Passwort-Reset und andere Self-Service-Angebote aktivieren, diese aber nicht (so ohne Weiteres) benutzen. Der Benutzer bekommt beim Versuch, das Kennwort zu ändern eine Fehlermeldung, in etwa so:
oder so:
Im Wortlaut für die Suche:
“Ihr Konto ist für ein Zurücksetzen des Kennworts nicht aktiviert. Leider hat der Administrator Ihr Konto nicht zum Verwenden dieses Dienstes eingerichtet.”
bzw.
“Sie können Ihr Kennwort hier nicht ändern. Eine Kennwortänderung auf dieser Website wird von Ihrer Organisation nicht gestattet.”
Das Problem dabei ist: Mit dem in Office 365 enthaltenen Azure AD Lizenzen (Entspricht der Lizenzstufe Azure AD Basic) ist das nicht möglich – man bräuchte dazu Azure AD Premium! Und das wiederum wäre nur für dieses eine Feature (wenn man den Rest nicht braucht) in meinen Augen zu teuer…
Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:
Azure AD Free – cloud-only administrators can reset their own passwords
Azure AD Basic or any Paid O365 Subscription – cloud-only users and cloud-only administrators can reset their own passwords
Azure AD Premium – any user or administrator, including cloud-only, federated, or password synced users, can reset their own passwords (requires password writeback to be enabled)
Heisst also, man kann nur die nicht-synchronisierten Accounts in der kostenlosen Stufe ändern bzw. zurücksetzen lassen.