Drücke "Enter", um den Text zu überspringen.

Schlagwort: Office 365

Office 365 / Azure AD – Fehler bei der Synchronisierung

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:

Screenshot (183)

Auch der Versuch, das betroffene Konto in Office 365 aus den gelöschten Objekten wiederherzustellen, schlug fehl:

Screenshot (181)

Screenshot (180)

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:

1
2
3
4
5
$UserCredential= Get-Credential -UserName "h.hertes@DOMAIN.COM" -Message "Bitte das Passwort für O365 eingeben!"
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $ExchangeSession -AllowClobber
Connect-MsolService -Credential $UserCredential
Get-MsolUser -ReturnDeletedUsers | Where UserPrincipalName -eq "USER@DOMAIN.COM" | Remove-MsolUser -RemoveFromRecycleBin
Schreibe einen Kommentar...

Office 365 – Verteiler eines Benutzers mittels PowerShell herausfinden

Immer mal wieder stell sich uns die Frage, in welchen Verteilern ein bestimmter Benutzer Mitglied ist. Natürlich kann man sich im Office365 Admin-Portal das Postfach ansehen, dort wird einem aufgelistet, wo der User Mitglied ist – allerdings werden hier nur die direkten Mitgliedschaften aufgelistet. In der Regel sind Verteiler / Distribution Lists aber in einander verschachtelt, um z.B. Team- / Gruppen- /Abteilungsstrukturen abzubilden. Um nun nicht von Hand alle Verteiler auf deren Mitgliedschaft in weiter oben liegenden Verteilern prüfen zu müssen, habe ich ein PowerShell-Skript geschrieben.

Dieses ermittelt zunächst, in welchen Verteilern der Benutzer unmittelbar enthalten ist und prüft dann diese Verteiler auf “Eltern”, also weiter oben stehende Verteiler, die den betreffenden Verteiler (und damit dann eben indirekt den Bnutzer) enthalten.

Hier ist das Skript:

[string[]]$global:AllreadyChecked = $null
 
function Get-DistributionGroupAllParents
{
    param ([string]$GroupName)
 
    [string[]]$Parents = $null
 
    ForEach ($Group in Get-DistributionGroup) 
    {
       If((Get-DistributionGroupMember $Group.Name | Where RecipientType -NE "UserMailbox").Name -contains $Groupname)
       {
          # Make sure, we are only checking every DGs parents once as many DG tree leafs may lead to the same parent DG
          If($global:AllreadyChecked -notcontains ($Group.Name))
          {
                $Parents += $Group.Name
                Get-DistributionGroupAllParents -GroupName $Group.Name
                $global:AllreadyChecked += $Group.Name
          }
       } 
    }
    Return $Parents
}
 
# Connect to Office 365
If((Get-PSSession | Where Computername –like "*ps.outlook.com*" | Where State –eq "Opened" | Measure-Object).Count -lt 1)
{
    $Credentials = Get-Credential –UserName "USER@DOMAIN.COM" -Message "Please enter your Office 365 / Azure AD password!"
    $ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $Credentials -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue
    Import-PSSession $ExchangeSession -AllowClobber -DisableNameChecking >> $null
}
elseif((Get-PSSession | Where Computername -like "*ps.outlook.com*" | Where Availability -eq "Available" | Where State -ne "Opened" | Measure-Object).Count -ge 1)
{
    Import-PSSession -Session (Get-PSSession | Where Computername -like "*ps.outlook.com*" | Where Availability -eq "Available" | Select -Last 1)
}
 
# Get all DGs a user is member of
$User = Read-Host -Prompt "Enter User to check!" 
$Recipient = (Get-Recipient -RecipientType UserMailbox -Identity $User).Name
Write-Host "Script started discovery - this could take a while" -ForegroundColor Red
 
[string[]]$AllParents = $null
ForEach ($Group in Get-DistributionGroup) 
{
   If((Get-DistributionGroupMember $Group.Name).Name -contains $Recipient)  # Find all Groups the User is immediate member of:
   {
      $AllParents += $Group.Name
      Write-Host -ForegroundColor Green "$($Group.Name) ($($Group.PrimarySmtpAddress))"
      $AllParents += (Get-DistributionGroupAllParents -Group $Group.Name)
   } 
}
 
Write-Host "User is member of these groups (for some of them, he may be member through nested groups!):"
$AllParents.Where({ $_ -ne "" }) | select -uniq | sort | Get-DistributionGroup | ft DisplayName,Name,PrimarySmtpAddress -AutoSize

 

Viel Spaß damit!

Schreibe einen Kommentar...

Office 365 – E-Mail-Adresse enthält einen Unterstrich (“_”)

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:

underscore1

(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:

underscore2

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”…

underscore3

…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!

1 Kommentar

Office 365 – E-Mail-Adressen von neuen Benutzern aus on-premise AD falsch

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:

o365_1

Das lässt sich über das Office 365 Admin-Portal auch nicht ändern, da der Benutzer eben aus dem lokalen AD synchronisiert wird:

o365_2

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:

o365_4

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…

5 Comments

Passwort Self-Service für Office 365 und Azure AD – nur mit Premium-Lizenz

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:

kennwort1

oder so:

kennwort2

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…

Zitat aus der Microsoft Doku (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords):

Pricing and availability

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.

2 Comments

Office 365 / Azure AD: Kennwort eines Benutzers soll nicht ablaufen

Wenn man Office 365 Konten hat, die keinem Benutzer fest zugeordnet sind (in meinem Fall für Konferenz-Telefone), dann ist es eher ungünstig, wenn das Kennwort abläuft. Auch bei regulären Benutzern kann es gewünscht sein, dass das Kennwort nicht abläuft.

Wenn der Benutzer aus dem lokalen Active Directory synchronisiert wird, dann kann man diese Option einfach im lokalen AD einstellen. Aber bei einem Benutzer, der nur online existiert geht das nicht. Wie also dort das Ablaufen eines Kennwortes deaktivieren? Natürlich per PowerShell!

Dazu muss erst mit

Connect-MsolService

eine Verbindung mit Azure AD aufgebaut werden. Danach kann dann mit

Set-MsolUser -UserPrincipalName USER@MAIL.DE -PasswordNeverExpires $True

die entsprechende Einstellung vorgenommen werden.

O365_User_Password_Expire

Viel Spaß damit!

Schreibe einen Kommentar...

Office 365–Einige Hinweise zur Cut-Over Migration

Die “Übernahmemigration” (Englisch: Cutover-Migration) ist eine nette Option, um alle Postfächer eines Exchange-Servers in einem Rutsch nach Office 365 zu migrieren. Allerdings gibt es ein paar Dinge zu beachten. Und manches erfährt man nur durch Ausprobieren, auch das möchte ich euch hier nicht vorenthalten…

o365_1

Zu beachten:

  • Die Option “Übernahmemigration” bzw. “Cutover Migration” ist ausgegraut, wenn “Azure DirSync” bzw. “Azure AD Connect” aktiv sind. Am einfachsten ist es, dies im Azure-Portal abzuschalten. Erst danach steht die Option zur Verfügung.
  • Konten, die bereits per Azure AD Connect oder Vorgänger-Techniken nach Azure bzw. Office 365 synchronisiert wurden, können nicht durch die Übernahmemigration “befüllt” werden. Diese Konten müssen gelöscht und neu angelegt werden.

Allgemein hin liest man immer wieder, das man mit der Cutover-Migration nur ALLE Postfächer auf einmal (bzw. nacheinander, aber in einem Rutsch) migrieren kann. Das ist so nicht ganz richtig… Insbesondere für Tests vor der eigenen Migration ist es sinnvoll, nur ein paar wenige (Test)Postfächer zu migrieren. Jedoch hat man bei dem Assistenten keine Möglichkeit zur Auswahl. Der Trick ist, die Postfächer vor Office 365 zu “verstecken”. Office 365 liest nämlich einfach nur die Global Address List (GAL, Globales Adressbuch) aus. Wenn dort nun nur die Postfächer drin stehen, die migriert werden sollen, dann wird der Rest einfach ignoriert.

Um jetzt ein Postfach aus der GAL zu entfernen, gibt es zwei Wege:

    1. Das Postfach öffnen und den entsprechenden Haken setzen:o365_2
    2. Die Änderungen (vor allem bei vielen Postfächern) durch PowerShell erledigen lassen:
1
2
Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $true 
Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $true

Mit der PowerShell-Variante werden ALLE Postfächer und Verteiler aus dem Adressbuch entfernt. Danach können die gewünschten Postfächer wieder händisch hinzugefügt werden. Nach der (Test)Migration sollte man dann nicht vergessen, die Postfächer wieder im Adressbuch sichtbar zu machen:

 

1
2
Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $false 
Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $false

 

o365_3

Auf dem Bild ist zu sehen, dass nur 2 (von insgesamt deutlich mehr) Postfächern synchronisiert wurden!

 

Wichtig ist noch, dass Benutzer, die bereits in Office 365 von Hand angelegt wurden (! – wichtig, das geht nicht bei synchronisierten Benutzern – !), nicht gelöscht werden müssen! Die Cutover-Migration kann diese einfach mit dem passenden Postfach vom Exchange-Server verbinden und auffüllen. Wichtig ist dazu nur, dass der O365-Account als primäre Mailadresse die selber hat wie auf dem Exchange-Server und eben noch keine AD-Attribute synchronisiert wurden.

Schreibe einen Kommentar...