Der Grund hierfür ist, dass das eigentlich als CSV-Trennzeichen vorgesehene Komma „,“ im europäischen Sprachraum das Trennzeichen für Nachkommastellen ist. Im englischen Sprachraum ergibt sich das Problem nicht, hier werden Nachkommastellen mit dem Punkt „.“ abgetrennt und das Komma ist dadurch frei. Als Lösung für dieses Problem verwendet (und erwartet) Excel daher auf europäischen Systemen ein Semikolon „;“ als Trennzeichen.

Als Workaround waren mir bisher zwei Lösungen bekannt:

• Ersetzen der Kommas vor dem Öffnen durch Semikolons bzw. Ersetzen der Semikolons nach dem Speichern durch Kommas
• Ändern der Regions- und Spracheeinstellungen

Nun habe ich aber eine neue Lösung gesehen, die so simpel wie genial ist:

Mit Hilfe der Zeile

sep=,

in der ersten Zeile der CSV Datei teilt man Excel mit, das eben das Komma als Trennzeichen zu verwenden ist. Das setzt natürlich voraus, dass in der CSV-Datei keine anderen Kommas außer als Trennzeichen verwendet wurden.

Viel Spaß beim Ausprobieren!

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:

$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

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!

https://www.sysadminday.it/

Wir sehen uns am Freitag!

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

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…

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.

(https://support.office.com/de-de/article/Durchf%C3%BChren-einer-%C3%9Cbernahmemigration-von-E-Mails-zu-Office-365-9496e93c-1e59-41a8-9bb3-6e8df0cd81b4?ui=de-DE&rs=de-DE&ad=DE#postmigration)

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:

1. Mailbox deaktivieren
2. 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!

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Import-Module ActiveDirectory

$mbxs = Get-Mailbox # This will disable ALL mailboxes! Pay attention...

foreach ($mbx in $mbxs) 
{
    $adusr = Get-ADUser $mbx.SamAccountName -Properties mail,mailNickname,msExchShadowProxyAddresses,proxyAddresses,UserPrincipalName
        
    # Getting Mailboxes mail adress befor disabling it
    If($adusr.Mail -eq "")
    {
        [string]$MailAdress = $mbx.UserPrincipalName
    }
    else
    {
        [string]$MailAdress = $adusr.Mail
    }

    Disable-Mailbox -Id $mbx.Identity -Confirm:$False
    Enable-MailUser -Id $mbx.Identity -ExternalEmailAddress $MailAdress
    Set-MailUser -Id $mbx.Identity -EmailAddresses $MailAdress
}

# Make users MailEnabled users that never had a mailbox

$newUsersWithoutMailbox = Get-ADUser -Filter * -SearchBase "OU=Useraccounts,DC=DOMAIN,DC=local" -Properties Mail,UserPrincipalName
foreach($user in $newUsersWithoutMailbox)
{
    $FullDistinguishName = “LDAP://” + $user.distinguishedName
    $AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName
    $AccountEntry.PutEx(1, “msExchHomeServerName”, $null)
    $AccountEntry.SetInfo()

    If($user.Mail -ne "")
    {
        [string]$MailAdress = $user.Mail
    }
    else
    {
        [string]$MailAdress = $user.UserPrincipalName
    }
    # Enable-MailUser 

    If((Get-MailUser $user.SamAccountName -ErrorAction SilentlyContinue).RecipientType -ne "MailUser")
    {
        Enable-MailUser -Id $user.SamAccountName -ExternalEmailAddress $MailAdress
    }

    Set-MailUser -Id $user.SamAccountName -EmailAddresses $MailAdress
}

Nach dem nun keine Mailboxen mehr vorhanden sind, wäre es möglich, dass der Deinstallationsassistent weitere Probleme meldet, u.a. könnten:

• noch Public Folder Databases mit Replikaten,
• Arbitration-Mailboxes oder
• weitere Inhalte in der Mailbox Database

vorhanden sein.

Für die Replicas in der Public Folder Database bzw. die Database selbst könnten folgende PowerShell-Aufrufe nützlich sein:

Get-PublicFolder -Identity \ -GetChildren | Remove-PublicFolder -Recurse 

Remove-PublicFolderDatabase -Identity "My Public Folder Database" 

Get-PublicFolderDatabase | Remove-PublicFolderDatabase –RemoveLastAllowed

Für das Entfernen der (ggf. letzten) Arbitration Mailbox hilft

Get-Mailbox –Arbitration | Disable-Mailbox –Arbitration –DisableLastArbitrationMailboxAllowed

Danach sollte es möglich sein, Exchange “normal” zu entfernen:

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…

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.

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.

Viel Spaß damit!

Dieser kann hier direkt herunter geladen werden:

https://www.microsoft.com/en-us/download/details.aspx?id=54108

In diesem Blogbeitrag des Microsoft Office Teams könnt ihr Näheres lesen:

https://blogs.office.com/2016/10/27/skype-for-business-announces-new-mac-client-and-new-mobile-sharing-experiences/