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.

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
Advertisements

Seriennummer eines Computers auslesen

Bei einem Support-/Garantiefall wird immer die Seriennummer des betroffenen Geträtes benötigt. Falls mal wieder jemand bei der Dokumentation geschlampt hat (soll vorkommen ;), kann die Seriennummer mit folgendem CMD-Befehl auf dem System direkt ausgelesen werden:

wmic bios get serialnumber

Dies sollte bei den meisten Herstellern funktionieren.

Namespace „Microsoft.Policies.WindowsStore“ ist bereits als Ziel für eine andere Datei im Speicher definiert

Das Problem tritt auf, wenn die GPO-Definitionen (siehe Group Policy Definitions) aktualisiert werden, und zuvor alte Files vorhanden waren.

Das Problem ist, dass Microsoft Dateinamen angepasst hat, und der GPO Editor nun mehrere Dateien für dieselben Einstellungen vorfindet.

Die Lösung ist entsprechend einfach: die alte Datei „winstoreui.admx“ in den PolicyDefinitions löschen.

HP t530 ThinClients können nicht nach Windows Updates suchen

Wir haben heute neue t530er Thin Clients erhalten. Diese mussten wir bereitstellen, u.a. auch die aktuellsten Windows Updates installieren. Dies aber schlug fehl. Ein Blick in den Task Manager zeigte, dass, immer wenn die Suche gestartet wird, die (grosszügigen) 2 GB RAM sehr schnell voll sind, und sogar eine entsprechend Meldung von Windows angezeigt wird.

Die Lösung war recht einfach: Die Thin Clients hatten keine Auslagerungsdatei definiert. Ich aktivierte diese mit der Einstellung „durch Windows verwaltet“, und startete den Client neu. Anschliessend funktionierte die Update Suche.

Azure AD Connect: Powershell-Befehle zur Einrichtung

Bei weiteren Azure AD Connect Einrichtungen stiess ich auf folgende, nützliche Befehle:

Export aller aktuellen UPN Anmeldenamen, und Proxy-Adressen:

Get-ADUser -Filter {Enabled -eq $true} -SearchBase "OU=Users,DC=DOMAIN,DC=local" -Properties * | Where {$_.proxyAddresses} | select SAMAccountname,UserPrincipalName, @{L='ProxyAddress_1'; E={$_.proxyaddresses[0]}},@{L='ProxyAddress_2';E={$_.ProxyAddresses[1]}},@{L='ProxyAddress_3';E={$_.ProxyAddresses[2]}},@{L='ProxyAddress_4';E={$_.ProxyAddresses[3]}},@{L='ProxyAddress_5';E={$_.ProxyAddresses[4]}},@{L='ProxyAddress_6';E={$_.ProxyAddresses[5]}} | export-csv C:\Temp\ExportV1.csv

 

Anpassen sämtlicher UPN Anmeldenamen:

Import-Module ActiveDirectory
$oldSuffix = "DOMAIN.local"
$newSuffix = "URI.ch"
$ou = "OU=Users,DC=DOMAIN,DC=local"
$server = "SERVER"
Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$_ | Set-ADUser -server $server -UserPrincipalName $newUpn
}

 

Group Policy Definitions

Mit den Group Policy Definitions gibt Microsoft ja zu einem neuem Betriebssystem jeweils die aktuell gültigen Definitionen mit. Nachdem ein Kollege von mir diese Definitionen bei einem Kunden vom Stand „Windows 10 1607“ auf „Windows 10 1709“ aktualisierte, erhielten wir im GPO Editor folgende Fehlermeldung:

GPO

Richtlinienpräsentationsemelement "CSE_NOBACKGROUND" ... Präsentation "CSE_Drives" ... nicht vorhanden.

Das Problem: Microsoft hat gepatzt! In den „Administrative Templates“ für Windows 10 1703 und Windows 10 1709 fehlt (mindestens) das File „GroupPolicyPreferences.adml“ im Unterordner der entsprechenden Sprache. Nun gibt es zwei Szenarien:

  1. Die Version 1703 oder 1709 wurde als erste Version installiert
  2. Die Version 1703 und / oder 1709 aktualisierte eine bestehende Version

In erstem Szenario muss die Datei zuerst aus einer älteren Version kopiert werden (Links siehe am Ende des Artikels). Anschliessend muss diese noch angepasst werden (siehe Szenario zwei).

Im zweiten Szenario muss die Datei GroupPolicyPreferences.adml im Unterordner der entsprechenden Sprache, angepasst werden:

In Zeile 950 folgende Zeile einfügen (Deutsch):

<checkBox refId="CSE_NOBACKGROUND">Während regelmäßiger Hintergrundverarbeitung nicht übernehmen</checkBox>

GPO2

Original Englisch (Zeile 945):

 <checkBox refId="CSE_NOBACKGROUND">Do not apply during periodic background processing</checkBox>GPO3

Administrative Templates (.admx) for Windows 10 (1607) and Windows Server 2016

Administrative Templates (.admx) for Windows 10 Creators Update (1703)

Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709)

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.