Fehler beim erstellen einer Usermailbox für einen bestehenden User

Wir hatten einen Kunden, welcher nachträglich einen Exchange-Server erhielt. Ich installierte Exchange 2019 in die Domäne, und erstellte während dem Setup eine neue Exchange Organisation.

Als ich nun für die bestehenden AD-Benutzer Mailboxen erstellen wollte, erhielt ich folgenden Fehler:

Fehler bei Active Directory-Vorgang mit SERVER.DOMAIN.local. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Insufficient access rights to perform the operation. Active Directory-Antwort: 00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Ich vermutete bereits ein Problem mit den Berechtigungen auf den bestehenden Benutzern. Und siehe da, die Benutzer hatten die Berechtigungsgruppe „Exchange Trusted Subsystem“ nicht hinterlegt:

sorry für die schlechten Screenshots – ich wünschte, Microsoft würde die Fenster endlich grösser machen…

Also habe ich die Berechtigungen auf der OU der betroffenen Benutzer hinzugefügt, und vererben lassen:

• Eigenschaften der betroffenen OU
• Security > Advanced
• Add
• Principal = Exchange trusted subsystem > OK
• Applies to = „This object and all descendant’s objects“
• Unter „Permissions“, „Modify permissions“ aktivieren
• OK

Die Benutzer erhielten die Berechtigung aber weiterhin nicht. Auf den Benutzerobjekten war die Vererbung nicht aktiv:

Das wollte ich natürlich nicht für alle Benutzer einzeln aktivieren. Hier kommt PowerShell zur Hilfe:

Mit folgendem Befehl kann der aktuelle Status ausgelesen werden (achtung: quick&dirty):

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter * -Properties ntsecuritydescriptor,admincount
foreach ($Aduser in $AdUsers)
{
$AdUserName = $AdUser.Name
$AdUserRule = $AdUser | select -expand ntsecuritydescriptor | select areaccessrulesprotected
$AdUserAdminCount = $AdUser.AdminCount
Write-Host $AdUserName
Write-Host $AdUserRule
Write-Host $AdUserAdminCount
}

True = Vererbung deaktiviert
False = Vererbung aktiviert
AdminCount = muss zuerst gelöscht werden. Details folgen in einem späteren Post.

AdminCount löschen:

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter *
foreach ($AdUser in $AdUsers)
{
set-aduser $AdUser -remove @{adminCount=1}
}

SecurityDescriptor auf „False“ setzen:

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter * -Properties ntsecuritydescriptor
foreach ($AdUser in $AdUsers)
{
$user = get-aduser $AdUser -properties ntsecuritydescriptor
$user.ntsecuritydescriptor.SetAccessRuleProtection($false,$true)
set-aduser $AdUser -replace @{ntsecuritydescriptor=$user.ntsecuritydescriptor}
}

Exchange 2019 Deinstallation: System.ComponentModel.Win32Exception: Zugriff verweigert

Ich musste einen Exchange 2019 deinstallieren, dabei trat folgender Fehler auf:

Der folgende Fehler wurde generiert, als "$error.Clear();
$regPath='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall';
$PackageGUIDRegEx = "{9BBCB5[0-9a-fA-F]{2}-AAC3-4BF5-[0-9a-fA-F]{4}-A4D51A19BF14}";
$InstallPath = (Get-ItemProperty
'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\setup').MsiInstallPath;
if(test-path ($regPath))
{
Write-ExchangeSetupLog -info ("Removing " + $RoleLanguagePackType + " Language Packs.");
Get-ChildItem ($regPath) | foreach{
if($_ -match
"(?$PackageGUIDRegEx)") {
$langPackPackageCode = $matches['ProductCode'];
if($langPackPackageCode -ne $null -and $langPackPackageCode.Length -ne 0) {
Write-ExchangeSetupLog -info ("Removing package $langPackPackageCode");
$language =
$langPackPackageCode.Substring(20,4);
$logFilePath = [IO.Path]::Combine($RoleLogFilePath,"Uninstall") + '.' + $language + '.' + "OwaPlus" + "." + $RoleLogDateTime + ".msilog";
uninstall-MsiPackage -ProductCode ($langPackPackageCode) -LogFile ($logFilePath);
};
};
};
Get-Childitem -Path $InstallPath -include ".Localized.js",".Localized.min.js" -recurse | foreach ($_) {remove-item $_.fullname};
Write-ExchangeSetupLog -info "Remove Language Packs completed.";
};
" ausgeführt wurde: "System.UnauthorizedAccessException:
Zugriff verweigert ---> System.ComponentModel.Win32Exception: Zugriff verweigert
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Management.Automation.Utils.NativeDirectoryExists(String path)
bei
System.Management.Automation.SessionStateInternal.IsItemContainer(CmdletProvider providerInstance, String path, CmdletProviderContext context)".
The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.

Ich verbrachte einige Stunden mit der Problemsuche, fand aber keine Lösung.

Ein paar Tage später führten wir Wartung an diesem Server durch, installierten die aktuellsten Microsoft Updates und starteten den Server neu. Danach konnte die Deinstallation erfolgreich abgeschlossen werden:

Ok – erledigt 🙂

Verbindungsdaten (Mail) aus Exchange exportieren

In einem komplexeren Fall musste ich die gesamten Verbindungsdaten des ganzen Mailservers untersuchen, um einige spezielle Mails zu identifizieren. Im konkreten Fall ging es darum, festzustellen, ob noch über eine spezifische Inboud-Connector-IP Mails versendet werden.

Normalerweise verwende ich PowerShell und exportiere in csv. Diese Files importiere ich dann in Excel. In Excel kann ich dessen potenten Sortier- und Filterfunktionen nutzen.

Doch hier stiess ich an eine Grenze. Ich musste den Wert „EventData“ exportieren. In Excel (via Export-Csv) erhielt ich nur unsinnige Daten:

System.Collections.Generic.KeyValuePair`2[System.String,System.Object][]

Also wechselte ich auf

ConvertTo-Html

und

Out-File

Da sich in diesem Fall die Info über die Server-IP nur in den Logs mit „EventID = RECEIVE“ befand, habe ich noch danach gefiltert:

Get-MessageTrackingLog -Start (Get-Date).AddDays(-5) -ResultSize Unlimited | Where-Object {$_.EventID -match "RECEIVE"} | convertto-HTML TimeStamp,Sender,{$_.recipients},MessageSubject,{$_.EventData} | out-file C:\Temp\ExportLog_01.html

Das ergibt ein „schönes“ HTML File, welches auch problemlos durchsucht werden kann.

Migration Exchange Unified Messaging von Exchange 2010 auf Exchange 2016

Ich musste obige Migration vornehmen. Exchange-seitig ja kein Problem. Aber UM war für mich Neuland.

Falls das nicht auf Anhieb funktioniert, hier einige Anlaufstellen:

1. Eventlog (Anwendung) des alten Exchange-Server, Quelle = „MSExchange Unified Messaging“
2. Eventlog (Anwendung) des neuen Exchange-Server, Quelle = „MSExchange Unified Messaging“
3. Eventlog (\Anwendungs- und Dienstprotokolle\Lync Server) auf dem Skype for Business (SfB) Server, Quelle = „LS Exchange Unified Messaging Routing“

Wir mussten in unserem Fall (nur 1 SfB Server), folgendes konfigurieren:

Exchange Admin Center > Server > neuen Server auswählen > bearbeiten > Unified Messaging
Bei „UM-Anrufrouter“ und „UM-Dienst“ jeweils Startmodus = „DUAL“ und Wählplan = den einzigen vorhandenen Wählplan auswählen.

Zuvor musste das Deutsche Sprachpaket noch auf dem neuen Exchange-Server installiert werden.

Als Zertifikat wurde das Server-Zertifikat (von der internen CA ausgestellt) verwendet.

Folgende Befehle sind in diesem Zusammenhang relevant:

Enable-ExchangeCertificate -Thumbprint [THUMBPRINT] -Services UM,UMCallRouter

Restart-Service MSExchangeUM ; Restart-Service MSExchangeUMCR

Wenn den UM-Diensten ein Wildcard Zertifikat zugewiesen wird, wird folgende Fehlermeldung protokolliert (dies ist nämlich nicht supported):

Certificate subject name .domain.ch is not valid. UM local monitoring sip options probe will fail System.ArgumentException: The specified routing host name '.realit.ch' isn't valid
bei Microsoft.Exchange.Data.Transport.RoutingHost..ctor(String address)
bei Microsoft.Exchange.UM.UMCore.SipPeerManager.GetSipPeerFromUMCertificateSubjectName()

Falsche Konfiguration des Startmodus erzeugt folgende Fehler:

The Microsoft Exchange Unified Messaging Call Router service failed to exchange the required certificates with an IP gateway to enable Transport Layer Security (TLS). Please check that the gateway is configured to operate in the correct security mode. If the gateway is required to operate in TLS mode, check that the certificates being used are correct. More information: "A TLS failure occurred because the remote server disconnected while TLS negotiation was in progress. The error code = 0x80131500 and the message = Unknown error (0x80131500).". Remote certificate: (). Remote end point: [IP SfB]:60589. Local end point: [IP Exchange 2016]:5061.

Diese Meldung wird beim Neustarten des Dienstes angezeigt:

The Client Access server isn't currently enabled and the Microsoft Exchange Unified Messaging call router can't listen on any TCP/UDP ports. Any existing connections will be disconnected.

Exchange Postfächer in PST exportieren

Exchange unterstützt seit 2010 SP1 ja den Export direkt auf dem Server in PST Files. Dies nutzen wir, um Migrationen von onPremise in unsere Hosted Exchange (HEX) Umgebung durchzuführen.

Um den Export ausführen zu dürfen, benötigt dein Exchange-Admin-User die entsprechenden Berechtigungen:

New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "admin.wildi"

Mit folgendem Befehl kann eine Übersicht aller Postfächer erstellt werden:

Get-Mailbox | Get-MailboxStatistics | Sort-Object User | ft @{label="User";expression={$_.DisplayName}},@{label="Total Size(MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{label="Items";expression={$_.ItemCount}},@{label="Total Deleted Item Size";expression={$_.TotalDeletedItemSize}} -Auto

Benutzerliste für Planung exportieren:

Import-Module ActiveDirectory
Get-ADUser -Filter {(Enabled -eq "true")} -properties SamAccountName,sn,GivenName,mail,EmailAddress,CanonicalName,Enabled | Select-Object sn,GivenName,UserPrincipalName | Export-Csv C:\Temp\users.csv -Encoding UTF8 

Wichtig: wenn nun ein PST-Export gestartet wird, wird das Postfach INKLUSIVE gelöschter Elemente exportiert.

Entweder wird in den Eigenschaften der Mailbox-Database die „Löscheinstellung“ auf „0 Tage“ angepasst:

Dann muss aber der nächste Wartungs-Zyklus abgewartet werden.

Mit folgendem Befehl können diese Elemente pro Postfach gelöscht werden:

Search-Mailbox -Identity admin.wildi -SearchDumpsterOnly -DeleteContent

Erklärung: https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/Search-Mailbox?view=exchange-ps

The SearchDumpsterOnly switch specifies that only the Recoverable Items folder of the specified mailbox be searched. You can also use this switch with the DeleteContent switch to delete messages from the Recoverable Items folder and reduce the size of the folder.

Davor natürlich am besten ein Vollbackup des Exchange-Servers erstellen!

Der eigentliche Export kann mittels folgendem Befehl erfolgen:

New-MailboxExportRequest -Mailbox Alias -FilePath PstFileName

Ich benutze folgendes Script, um die Aliase und PST-Filenamen aus einem Textfile auszulesen, und danach den Export zu starten:

$strExportData = Import-Csv C:\Temp\ExportPST\UserList.txt -Delimiter ',' -Header 'alias', 'pstfile'
forEach ($strUser in $strExportData) {
$strPstFileName = "\SERVER\export$\" + $strUser.pstfile + ".pst"
New-MailboxExportRequest -Mailbox $strUser.alias -FilePath $strPstFileName
}

Inhalt Textfile (erste Spalte = Alias; zweite Spalte = PST-File)

sekretariat,user1
sekretariat2,user2
chef,chef1

Happy exporting!

Exchange mit mehreren UPN-Domain-Namen – DNS SRV Record erstellen

Ein Kunde hat mehrere UPN-Domain-Namen. Als Hauptdomainname z.b. contoso.com, die zweite Domain adatum.com.

Dies hat immer wieder Fehlermeldungen betreffend Zertifikat erzeugt, da der Name autodiscover.adatum.com nicht im Zertifikat aufgeführt ist.

Natürlich könnte der Name dem Zertifikat hinzugefügt werden, aber das geht in diesem Fall leider nicht.

Somit musste ich einen SRV-Record für die entsprechende Domain (mit Split-DNS) erstellen:

1. neue Zone „autodiscover.adatum.com“ erstellen (primär, in AD speichern, nur sichere Updates zulassen)
2. „weitere neue Einträge“ – SRV Record erstellen

Host = Mailserver; Name sollte via Split-DNS auf interne IP aufgelöst werden

Der Eintrag sieht nun wie folgt aus:

Die Änderung ist sofort aktiv, die Meldungen betreffend Zertifikat sollten nicht mehr angezeigt werden.

 

Welche Clients verbinden mit meinem Exchange?

Während den Vorbereitungen einer Exchange Migration stellte sich mir die Frage, welche Exchange-Clients im Einsatz sind. Folgender Befehl zeigt die verwendeten Clients an:

Get-MailboxServer | Get-LogonStatistics | Select UserName,ClientVersion,LastAccessTime,ServerName

Die Clientversionen:

Client Version number	Friendly Name
5.0.3165.0	Outlook 2000
6.0.7654.12	Outlook 2000
6.0.8153.0	Outlook 2000
6.0.8165.0	Outlook 2000
6.0.8211.0	Outlook 2000
6.0.8244.0	Outlook 2000
10.0.0.2627	Outlook 2002
10.0.0.4115	Outlook 2002 SP2
10.0.0.6515	Outlook 2002 SP3
10.0.0.6742	Outlook 2002 SP3
11.0.5604.0	Outlook 2003
11.0.6352.0	Outlook 2003 SP1
11.0.6555.0	Outlook 2003 SP2
11.0.8000.0	Outlook 2003 SP2
11.0.8161.0	Outlook 2003 SP3
11.0.8200.0	Outlook 2003 SP3
11.0.8303.0	Outlook 2003 SP3
12.0.4518.1014	Outlook 2007 RTM
12.0.6024.5000	Outlook 2007 RTM
12.0.6211.1000	Outlook 2007 SP1
12.0.6300.5000	Outlook 2007 SP1
12.0.6315.5000	Outlook 2007 SP1
12.0.6423.1000	Outlook 2007 SP2
12.0.6504.5001	Outlook 2007 SP2
12.0.6509.5000	Outlook 2007 SP2
12.0.6529.5000	Outlook 2007 SP2
12.0.6539.5000	Outlook 2007 SP2
12.0.6550.5000	Outlook 2007 SP2
12.0.6554.5000	Outlook 2007 SP2
12.0.6557.5000	Outlook 2007 SP2
12.0.6562.5003	Outlook 2007 SP2
12.0.6606.1000	Outlook 2007 SP3
12.0.6661.5000	Outlook 2007 SP3
12.0.6665.5000	Outlook 2007 SP3
14.0.4734.1000	Outlook 2010 RTM
14.0.6025.1000	Outlook 2010 SP1
14.0.6109.5000	Outlook 2010 SP1
14.0.6117.5001	Outlook 2010 SP1
15.0.4128.1019	Outlook 2013 Preview
HTTP	MAC or other HTTP clients

Das TechNet-Script OutlookVersion.ps1 (Verwendung auf eigene Gefahr – ich konnte allerdings keinen Schadcode entdecken) spuckt in etwa dasselbe aus.

Exchange DB nicht eingebunden

Die DB eines Exchange 2013 liess sich nicht mehr einbinden, der Status unter EAC lautete „Einbindung aufgehoben“. Eventlog zeigte diverse Fehler und Warnungen:

Quelle: ESE (ESE); Ereignis ID: 482

Information Store - Mailbox Database xxx (12380) Mailbox Database xxx: Fehler nach 0.000 Sekunden beim Schreiben in Datei "D:\ExchangeData\Mailbox\Mailbox Database xxx\Mailbox Database xxx.edb" bei Offset 110595407872 (0x00000019c0000000) für 0 (0x00000000) Bytes mit Systemfehler 665 (0x00000299): "Der angeforderte Vorgang konnte aufgrund einer Dateisystemeinschränkung nicht abgeschlossen werden. ". Fehler -1022 (0xfffffc02) bei Schreiboperation. Wenn dieser Zustand andauert, ist die Datei möglicherweise beschädigt und muss aus einer vorherigen Sicherung wiederhergestellt werden.

Quelle: ESE (ESE); Ereignis ID: 454

Information Store - Mailbox Database 2072421121 (12380) Mailbox Database 2072421121: Fehler bei der Datenbankwiederherstellung mit dem unerwarteten Fehler -1022.

Quelle: ExchangeStoreDB; Ereignis ID: 206

28.05.2018 08:43:12: Für die Kopie der Datenbank 'Mailbox Database xxx' auf diesem Server scheint ein schwerwiegender E/A-Fehler vorzuliegen. Überprüfen Sie das Ereignisprotokoll auf dem Server hinsichtlich anderer Speicher- und "ExchangeStoreDb"-Ereignisse, um detailliertere Informationen zu dem Fehler zu erhalten. Die Dienstwiederherstellung wurde mithilfe eines Failovers auf eine andere Kopie versucht. Failover konnte den Dienst nicht wiederherstellen. Fehler: Es ist nur eine Kopie der Postfachdatenbank (Mailbox Database 2072421121) vorhanden. Es ist keine automatische Wiederherstellung verfügbar.

Mit folgendem Befehl konnte ich den Status der DB prüfen:

C:\Program Files\Microsoft\Exchange Server\V15\Bin\eseutil.exe /MH "D:\ExchangeData\Mailbox\Mailbox Database xxx\Mailbox Database xxx.edb"

Output war folgender:

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
         Database: D:\ExchangeData\Mailbox\Mailbox Database xxx\Mailbox Database xxx.edb
DATABASE HEADER:
Checksum Information:
Expected Checksum: 0xcf09ec4a
  Actual Checksum: 0xcf09ec4a
Fields:
       File Type: Database
         Checksum: 0xcf09ec4a
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,20
 Engine ulVersion: 0x620,20
Created ulVersion: 0x620,20
     DB Signature: Create time:12/21/2013 10:33:03.226 Rand:3416686835 Computer:
         cbDbPage: 32768
           dbtime: 953713227 (0x38d8824b)
            State: Dirty Shutdown
     Log Required: 1013428-1013474 (0xf76b4-0xf76e2)
    Log Committed: 0-1013475 (0x0-0xf76e3)
   Log Recovering: 1013453 (0xf76cd)
  GenMax Creation: 05/28/2018 08:32:51.797
         Shadowed: Yes
       Last Objid: 464345
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00.000
 Old Repair Count: 0
  Last Consistent: (0xE923A,E,5C)  03/14/2018 20:02:47.244
      Last Attach: (0xE923B,2,268)  03/14/2018 20:22:22.866
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000
    Last ReAttach: (0xF76C4,2,268)  05/28/2018 10:37:14.921
             Dbid: 1
    Log Signature: Create time:12/21/2013 10:33:02.867 Rand:763432890 Computer:
       OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)
Previous Full Backup:
        Log Gen: 1012126-1012128 (0xf719e-0xf71a0) - OSSnapshot
           Mark: (0xF71A1,1,0)
           Mark: 05/26/2018 21:55:25.610
Previous Incremental Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000
Previous Copy Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000
Previous Differential Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000
Current Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000
Current Shadow copy backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000
     cpgUpgrade55Format: 0
    cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
       ECC Fix Success Count: none
   Old ECC Fix Success Count: none
         ECC Fix Error Count: none
     Old ECC Fix Error Count: none
    Bad Checksum Error Count: none
Old bad Checksum Error Count: none
  Last checksum finish Date: 00/00/1900 00:00:00.000
Current checksum start Date: 00/00/1900 00:00:00.000
      Current checksum page: 0
Operation completed successfully in 2.375 seconds.

Insbesondere der „State: Dirty Shutdown“ lieferte den Beweis, dass mit der DB etwas nicht in Ordnung war. In diesem Falle muss die DB repariert werden. Dazu wird insbesondere folgendes benötigt: Diskspace! Und zwar mindestens 110% der DB-Grösse!

Nun prüfen wir zuerst, wie der Stand der Logfiles ist:

Die Befehle werden am einfachsten im Verzeichnis ausgeführt , in welchem sich die Logfiles befinden:

D:\ExchangeData\Mailbox\Mailbox Database xxx>"C:\Program Files\Microsoft\Exchange Server\V15\Bin\eseutil" /ML E00.log

Prüfung sämtlicher folgender Logfiles:

eseutil /ML E00

Der Output ist im Idealfall:

No damaged log files were found.
Operation completed successfully in 100.797 seconds.

Prüfung des Checkpoint Files:

eseutil /MK E00.chk

Nun können wir ein Soft Recovery versuchen:

"C:\Program Files\Microsoft\Exchange Server\V15\Bin\ESEUTIL" /r E00 /l "D:\ExchangeData\Mailbox\Mailbox Database xxx" /d "D:\ExchangeData\Mailbox\Mailbox Database xxx"

Das Recovery konnte einige Logfiles einspielen, brach dann aber mit einem Fehler ab:

Operation terminated with the following error -1022 (Jet_errDiskIO, Disk IO error) after xx seconds.

Somit musste ich ein Hard Recovery ausführen:

"C:\Program Files\Microsoft\Exchange Server\V15\Bin\ESEUTIL" /P "D:\ExchangeData\Mailbox\Mailbox Database xxx\Mailbox Database xxx.edb"

Dies dauerte ca. eine Stunde in meinem Fall (DB Grösse von 100GB). Anschliessend muss ein Defrag ausgeführt werden:

"C:\Program Files\Microsoft\Exchange Server\V15\Bin\ESEUTIL" /d "D:\ExchangeData\Mailbox\Mailbox Database xxx\Mailbox Database xxx.edb"

Im Anschluss an diesem Befehl konnte ich die DB wieder mounten. Ein abschliessender Integ-Check steht noch aus.

Update 20.01.2020: ISINTEG gibts ab Exchange 2010 eigentlich nicht mehr, bzw. funktioniert nicht mehr. Die DB muss ab Exchange 2010 Online (mounted) sein, und kann dann mit folgendem Befehl überprüft werden:

Nachtrag: mit diesem Befehl lässt sich die DB überprüfen:

[PS] C:\>New-MailboxRepairRequest -Database "Mailbox Database xxx" -DetectOnly -CorruptionType ProvisionedFolder,
SearchFolder,AggregateCounts,Folderview | fl

Es ist zwingend „FL“ am Ende zu verwenden, da der Request sonst nicht wiederauffindbar ist. Mit diesem Befehl kann der Status überprüft werden:

Get-MailboxRepairRequest ID von Oben\ID von Oben | fl

Comodo PositiveSSL Wildcard Certificate zu Exchange 2016 hinzufügen

Ich habe in meinem Exchange 2016 Labor lange nach einem günstigen Nachfolger von startssl.com gesucht. StartSSL hat sich ja bei Firefox und Konsorten unbeliebt gemacht, weshalb ich das bisherige, auslaufende Zertifikat nicht mehr dort erneuert habe.

Ich wollte aber kein Zertifikat von einem der „Grossen“ wie GoDaddy oder so haben. Die sind für meine Zwecke schlicht zu teuer.

Nach einiger Suche, bin ich auf Cheapsecurity.com gestossen. Die bieten Zertifikate von diversen Herstellern an, unter anderem von Comodo. Auch diese CA ist nicht „ganz sauber“ wie mir scheint, dafür sind die Preise schlichtwegs zu tief. Für meine Zwecke aber ideal. Also habe ich mir ein Comodo PositiveSSL Wildcard Certificate zugelegt.

Auf den Prozess, ein Zertifikat zu beantragen, gehe ich hier nicht näher ein. Während des Prozesses muss man den private Key exportieren. Diesen habe ich in einem TextFile gesichert.

Als Ergebnis davon erhielt ich ein ZIP-File mit crt-Files drin: 3x von Commodo’s CA’s und mein eigenes.

Dieses Zertifikat beinhaltet aber keinen private-Key, und kann darum nicht direkt in Exchange verwendet werden. Damit Exchange das Zertifikat akzeptiert, muss OpenSSL heruntergeladen und installiert werden. Nun kann mit folgendem Befehl ein Zertifikat inklusive private Key erstellt werden:

openssl pkcs12 -export -out cert.pfx -inkey my.key -in STAR_domain_tld.crt

cert.pfx = Ausgabe-File (Zertifikat inkl. private key)

my.key = Textfile mit dem private key drin

STAR_domain_tld.crt = Zertifikats-File von cheapsecurity.com

Das damit entstandene File cert.pfx konnte ich danach erfolgreich in Exchange importieren.

Exchange meldet „RevocationCheckFailure“

Der Zugriff auf einen Exchangeserver brachte manchmal Fehlermeldungen, manchmal klappte es. OWA via Chrome klappte gar nicht mehr, der IE funktionierte einwandfrei.

Ich prüfte die Zertifikate auf dem Exchangeserver (insbesondere dasjenige, welches IIS zugewiesen war), und dort wurde gemeldet:

RevocationCheckFailure

Nunja, das kann ja nichts gutes heissen 🙂

Meine Vermutung bestätigte sich umgehend: Die Firewall war derart restriktiv eingestellt, dass der Exchange ausgehend keine HTTPS Verbindungen herstellen durfte. Nach deren Freigabe klappte das dann.