- Jan's Cloud - online Gedankenstütze ;)

Nutzungsspeicherort (Usage Location) mit Azure AD Connect synchronisieren

Erneut ein kurzes, knappes PowerShell Code Snippet welchen den Nutzungsspeicherort (die Usage Location (msExchUsageLocation)) aus dem On-Premise Active Directory per Azure AD Connect ins Azure AD synchronisiert.

Vorab: Das lokale Active Directory muss mittels Exchange Setup um die Exchange Active Directory Attribute erweitert werden, da ansonsten „msExchUsageLocation„, welches die Usage Location im AAD darstellt, fehlt! In der Regel sollte es an dieser Stelle keine Probleme geben, da irgendwo (On-Premise / Hybrid) sicherlich ein Exchange ist. 🙂

Zum Script-Snippet: Das Script liest die AD-User Objekte (Get-ADUser) in einer Organisationseinheit aus und filtert dabei auf die „ObjectClass“. Danach werden neben der „USageLocation“ noch weitere Standort Attribute befüllt.

foreach($ADUser in $(Get-ADUser -SearchBase "OU=Benutzer,OU=<Pfad zur OU>,DC=<SUB>,DC=<DOMAIN>,DC=<TLD>" -Filter {ObjectClass -eq "user"})){
    Write-Host "Passe Benutzer $($ADUser.Name) an.."
    Set-ADUser $ADUser -Replace @{C="DE"}
    Set-ADUser $ADUser -Replace @{co="Deutschland"}
    Set-ADUser $ADUser -Replace @{countryCode=276}
    Set-ADUser $ADUser -Replace @{preferredLanguage="DE-DE"}
    Set-ADUser $ADUser -Replace @{msExchUsageLocation="DE"}
}

Sollte den Usern z.B. noch die Straße, Bundesland oder Ort fehlen, könnte man das Script gleich noch erweitern:

foreach($ADUser in $(Get-ADUser -SearchBase "OU=Benutzer,OU=<Pfad zur OU>,DC=<SUB>,DC=<DOMAIN>,DC=<TLD>" -Filter {ObjectClass -eq "user"})){
    Write-Host "Passe Benutzer $($ADUser.Name) an.."
    Set-ADUser $ADUser -Replace @{C="DE"}
    Set-ADUser $ADUser -Replace @{co="Deutschland"}
    Set-ADUser $ADUser -Replace @{countryCode=276}
    Set-ADUser $ADUser -Replace @{preferredLanguage="DE-DE"}
    Set-ADUser $ADUser -Replace @{msExchUsageLocation="DE"}
    Set-ADUser $ADUser -StreetAddress "<Strasse und Hausnummer>" -State "NRW" -PostalCode "50859" -City "Köln"
}

Sollte man in seiner OU Struktur oder an einer anderen Stelle noch das Land / den Standort versteckt haben, könnte man natürlich noch weiter erweitern:

foreach($ADUser in $(Get-ADUser -SearchBase "OU=Benutzer,OU=<Pfad zur OU>,DC=<SUB>,DC=<DOMAIN>,DC=<TLD>" -Filter {ObjectClass -eq "user"})){
    Write-Host "Passe Benutzer $($ADUser.Name) an"
    if($ADUser.DistinguishedName -imatch "OU=Deutschland,"){
        Set-ADUser $ADUser -Replace @{C="DE"}
        Set-ADUser $ADUser -Replace @{co="Deutschland"}
        Set-ADUser $ADUser -Replace @{countryCode=276}
        Set-ADUser $ADUser -Replace @{preferredLanguage="DE-DE"}
        Set-ADUser $ADUser -Replace @{msExchUsageLocation="DE"}
        if($ADUser.DistinguishedName -imatch "OU=Koeln,"){
            Set-ADUser $ADUser -StreetAddress "<Strasse und Hausnummer>" -State "NRW" -PostalCode "50859" -City "Köln"
        } elseif($ADUser.DistinguishedName -imatch "OU=Xanten,"){
            Set-ADUser $ADUser -StreetAddress "<Strasse und Hausnummer>" -State "NRW" -PostalCode "46509" -City "Xanten"
        } elseif($ADUser.DistinguishedName -imatch "OU=Windeck,"){
            Set-ADUser $ADUser -StreetAddress "<Strasse und Hausnummer>" -State "NRW" -PostalCode "51570" -City "Windeck"
        }
    } elseif($ADUser.DistinguishedName -imatch "OU=USA,"){
        Set-ADUser $ADUser -Replace @{C="US"}
        Set-ADUser $ADUser -Replace @{co="USA"}
        Set-ADUser $ADUser -Replace @{countryCode=840}
        Set-ADUser $ADUser -Replace @{preferredLanguage="EN-US"}
        Set-ADUser $ADUser -Replace @{msExchUsageLocation="US"}
        if($ADUser.DistinguishedName -imatch "OU=LasVegas,"){
            Set-ADUser $ADUser -StreetAddress "3600 S Las Vegas Blvd" -State "Nevada" -PostalCode "89109" -City "Las Vegas"
        } elseif($ADUser.DistinguishedName -imatch "OU=Detroit,"){
            Set-ADUser $ADUser -StreetAddress "1777 3rd Ave" -State "Michigan" -PostalCode "48226" -City "Detroit"
        }
    }
}

UPN anhand der primären E-Mail-Adresse genereieren

English

Deutsch

Hier ein kleines PowerShell Script (Set-UPNbasedSMTP), um den UPN (User Principal Name) anhand der primären SMTP Adresse (E-Mail-Adresse) für alle Active Directory Benutzer mit Postfach zu setzen.

Das PowerShell Script „Set-UPNbasedSMTP“ listet zuerst die vorhandenen von Exchange akzeptierten Domänen auf, vergleicht diese mit den ggfs. vorhandenen UPN Suffixen und ergänzt diese um nicht vorhandene User Principal Suffixe. Im nächsten Schritt wird der User Principal Name des AD User Objektes gleich der primären SMTP Adresse der entsprechenden Mailbox gesetzt.

$UPNSuffixe = New-Object -TypeName System.Collections.Generic.List[PSCustomObject]

if($env:ExchangeInstallPath){
    $ExchVer = $((Get-ChildItem $($env:ExchangeInstallPath + "Bin\ExSetup.exe")).VersionInfo.FileVersion).Replace(".","")
    if($ExchVer.StartsWith("1502") -or $ExchVer.StartsWith("1501") -or $ExchVer.StartsWith("1500")){
        Write-Host "Laden des Exchange PowerShell Snapins für Exchange 2013, 2016, 2019" -NoNewline
        Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
        Write-Host " -> Ok!"
    } elseif($ExchVer.StartsWith("14")){
        Write-Host "Laden des Exchange PowerShell Snapins für Exchange 2010" -NoNewline
        Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
        Write-Host " -> Ok!"
    }
}

if($(Get-PSSnapin | where { $_.Name -ieq "Microsoft.Exchange.Management.PowerShell.E2010" -or $_.Name -ieq "Microsoft.Exchange.Management.PowerShell.SnapIn" })){
    $DomainDNName = (Get-ADDomain -Identity $env:USERDNSDOMAIN).DistinguishedName

    foreach($UPNSuffix in $(Get-ADForest -Identity $env:USERDNSDOMAIN | Select-Object UPNSuffixes -ExpandProperty UPNSuffixes | Sort-Object)){
        $UPNSuffixe.Add($UPNSuffix)    
    }

    foreach($AcceptedDomain in $(Get-AcceptedDomain | ? DomainName -ne $env:USERDNSDOMAIN | Select-Object DomainName -ExpandProperty DomainName)){
        if($UPNSuffixe -inotcontains $AcceptedDomain.Domain){
            Write-Host "Füge UPN Suffix ""$AcceptedDomain"" hinzu" -NoNewline
            Set-ADForest -Identity $env:USERDNSDOMAIN -UPNSuffixes @{Add="$AcceptedDomain"}
            Write-Host " -> Ok!"
        }
    }

    foreach($Mailbox in $(Get-Mailbox | ? Name -inotmatch "DiscoverySearchMailbox")){
        Write-Host "Setze UPN ""$($Mailbox.PrimarySmtpAddress)"" für Benutzer ""$($Mailbox.SamAccountName)""" -NoNewline
        Set-ADUser -Identity $Mailbox.SamAccountName -UserPrincipalName $Mailbox.PrimarySmtpAddress
        Write-Host " -> Ok!"
    }
}

PowerShell Script Set-UPNbasedSMTP
User Principal Name Exchange 2010
Exchange 2016 UPN

Exchange 2019 CU3 und Exchange 2016 CU14 sind verfügbar

English

Deutsch

Gestern hat Microsoft die nächsten kumalativen Updates für Exchange Server 2019 und 2016 veröffentlicht.

Hier der Blog Beitrag „September 2019 Quarterly Exchange Updates“ vom Exchange Team Blog: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Released-September-2019-Quarterly-Exchange-Updates/ba-p/853699

Alternativ hier auch die Direktlinks zu den Microsoft Knowledge Base Artikel:

Exchange Server 2019 CU3: https://support.microsoft.com/en-us/help/4514141/cumulative-update-3-for-exchange-server-2019
Exchange Server 2016 CU14: https://support.microsoft.com/en-us/help/4514140/cumulative-update-14-for-exchange-server-2016

Viel Spaß beim Patchen :).

An dieser Stelle ein kleines Update und Obacht (24.09.2019): Ich hatte bei den ersten 10 Exchange 2016 CU14 Updates bereits viermal den Fall, dass das Setup abgebrochen ist. Im Exchange Setup Log (C:\ExchangeSetupLogs\ExchangeSetup.log) fanden sich folgende Einträge:

[09.22.2019 17:00:59.0598] [1] The following roles are installed: BridgeheadRole ClientAccessRole MailboxRole UnifiedMessagingRole FrontendTransportRole AdminToolsRole CafeRole
[09.22.2019 17:00:59.0608] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:00:59.0609] [1] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0606] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0606] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0632] [0] [ERROR] Ein Aufrufziel hat einen Ausnahmefehler verursacht.
[09.22.2019 17:01:00.0636] [0] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0636] [0] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0636] [0] CurrentResult SetupLauncherHelper.loadassembly:444: 1
[09.22.2019 17:01:00.0638] [0] Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll ‚ExchangeSetup.log‘ im Ordner ‚:\ExchangeSetupLogs‘.
[09.22.2019 17:01:00.0639] [0] CurrentResult main.run:235: 1
[09.22.2019 17:01:00.0639] [0] CurrentResult setupbase.maincore:396: 1
[09.22.2019 17:01:00.0641] [0] End of Setup
C:\ExchangeSetupLogs\ExchangeSetup.log

Bei einer manuellen Prüfung wurde im besagten Verzeichnis („C:\Windows\Temp\ExchangeSetup\bin\“) in der Tat keine „EnterpriseServiceEndpointsConfig.xml“ gefunden. An dieser Stelle aber der Hinweis – Don’t Panic – Das Setup einfach erneut starten und beenden. Zumindest hat das in meinen vier Fällen geholfen. Noch ein Hinweis: Die GUI erkennt ein „Unvollständiges Setup“ und setzt diese Fort. Das Fenster der GUI wird nach Abschluss allerdings ohne Meldung geschlossen. Hier lohnt sich dann ein erneuter Blick ins ExchangeSetup.log, um sicher zu gehen, dass alles funktioniert hat. Nach etwas Troubleshooting und weiterer Analyse stelle sich heraus, dass hier wohl die „Advanced Threat Control/Protection“ vom BitDefender AV die Finger im Spiel hatte. Ein reines Deaktivieren schaltete scheinbar den „Aktivschutz“ und „Verhaltensscan“ nicht aus, sodass dieser sich an den Dateien vergriffen hatte. Besserung brachte eine Ausnahme für „%SystemRoot%\Temp\ExchangeSetup“.

Ein weiteres Update bzw. Problem, welches mir untergekommen ist (01.10.2019): Beim Vorbereiten der Organisation bzw. genauer beim Vorbereiten des ActiveDirectorys (Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD) bemängelte das Setup ein Fehlen des „Exchange Online-ApplicationAccount“ AD-Objektes. Ein späteres Anlegen des Objektes scheiterte mit dem Fehler „Das Objekt ist vorhanden.“ Bei einem Blick ins Active Directory-Benutzer und -Computer bestätigte dies.

[09.30.2019 10:39:37.0397] [2] Beginning processing Get-LinkedUser
[09.30.2019 10:39:37.0407] [2] Searching objects „Exchange Online-ApplicationAccount“ of type „ADUser“ under the root „$null“.
[09.30.2019 10:39:37.0426] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0426] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0426] [2] Preparing to output objects. The maximum size of the result set is „1000“.
[09.30.2019 10:39:37.0435] [2] The object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“ has been retrieved, but it will not be output to the shell.
[09.30.2019 10:39:37.0439] [2] The operation couldn’t be performed because object ‚Exchange Online-ApplicationAccount‘ couldn’t be found on ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0449] [2] The operation couldn’t be performed because object ‚Exchange Online-ApplicationAccount‘ couldn’t be found on ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0456] [2] Ending processing Get-LinkedUser
[09.30.2019 10:39:37.0463] [2] Die Active Directory-Sitzungseinstellungen für ‚New-LinkedUser‘ lauten: Vollständige Gesamtstruktur anzeigen: ‚True‘, Konfigurationsdomänencontroller: ‚DOMAINCONTROLLER‘, Bevorzugter globaler Katalog: ‚DOMAINCONTROLLER‘, Bevorzugte Domänencontroller: ‚{ DOMAINCONTROLLER }‘
[09.30.2019 10:39:37.0463] [2] User specified parameters: -Name:’Exchange Online-ApplicationAccount‘ -UserPrincipalName:’Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD‘ -DomainController:’DOMAINCONTROLLER‘
[09.30.2019 10:39:37.0463] [2] Beginning processing New-LinkedUser
[09.30.2019 10:39:37.0477] [2] Searching objects „SUB.DOMAIN.TLD/Users“ of type „ExchangeOrganizationalUnit“ under the root „$null“.
[09.30.2019 10:39:37.0486] [2] Previous operation run on global catalog server ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0488] [2] Getting the organization for organizational unit SUB.DOMAIN.TLD/Users.
[09.30.2019 10:39:37.0498] [2] Searching objects of type „ADRecipient“ with filter „(|((&((Id NotEqual SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount)(UserPrincipalName Equal Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD)))))“, scope „SubTree“ under the root „$null“.
[09.30.2019 10:39:37.0500] [2] Previous operation run on global catalog server ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0501] [2] Processing object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“.
[09.30.2019 10:39:37.0516] [2] The properties changed on the object ‚Exchange Online-ApplicationAccount‘ (CN=Exchange Online-ApplicationAccount,CN=Users,DC=SUB,DC=DOMAIN,DC=TLD) are: „{ UserPrincipalNameRaw[userPrincipalName]=’Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD‘, Id[distinguishedName]=’SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount‘, RecipientTypeDetailsValue[msExchRecipientTypeDetails]=’LinkedUser‘, RecipientDisplayTypeRaw[msExchRecipientDisplayType]=’LinkedUser‘, RecipientDisplayType[msExchRecipientDisplayType]=’LinkedUser‘, RawName[name]=’Exchange Online-ApplicationAccount‘, RecipientTypeDetails[mailNickname, msExchHomeServerName, proxyAddresses, objectClass, homeMDB, groupType, msExchRecipientTypeDetails, userAccountControl]=’LinkedUser‘, ObjectCategory[objectCategory]=’SUB.DOMAIN.TLD/Configuration/Schema/person‘, OrganizationId[msExchOURoot, msExchCU]=“ }“.
[09.30.2019 10:39:37.0517] [2] Saving object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“ of type „ADUser“ and state „New“.
[09.30.2019 10:39:37.0522] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0545] [2] [ERROR] Active Directory operation failed on DOMAINCONTROLLER. The object ‚CN=Exchange Online-ApplicationAccount,CN=Users,DC=SUB,DC=DOMAIN,DC=TLD‘ already exists.
[09.30.2019 10:39:37.0545] [2] [ERROR] Das Objekt ist vorhanden.
ExchangeSetupLog

Ein erster Versuch, war das Verschieben des AD-Objektes in eine andere OU. Dabei änderte sich das Fehlerbild allerdings nur minimal. „Das Objekt ist vorhanden.“ wurde zu „The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.“

[09.29.2019 11:37:00.0768] [2] [ERROR] The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.
[09.29.2019 11:37:00.0769] [2] [ERROR] The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.
ExchangeSetupLog

Der Fehler konnte letztlich durch Umbennung des vorhandenen und warum auch immer nicht gefundenen AD-Objektes des “ Exchange Online-ApplicationAccount “ behoben werden. Dem Anzeigenamen und dem User Principal Name wurde lediglich eine „1“ angehangen. Nach erneutem Start des Setups konnte dieses dann erfolgreich abgeschlossen werden!