Im Internet findet mal allerhand zu diesem Thema.

Kurz Zusammenfassung:
- Es handelt sich um einen Schutzmechanismus von Exchange
- Defekte Mails oder mit vermeintlich schädlichen Inhalt wandern in die Poison Queue
- Jede Mail die den Exchange Transportdienst zum Absturz bringt gilt als schädlich (klingt einleuchtend)
- Nach einer Migration können durch die Übernahme der Öffentlichen Ordner viele Nachrichten dort landen
- Im Eventlog finden wir die EventID:100001, 10002, 10003 MSExchange Transport PoisonMessage
- In den Warteschalgen finden wir eine neue (giftige) Schlange „Nicht verarbeitete Nachrichten“
- Die Poison Queue darf unter keinen Umständen deaktivert werden / das Mail Routing könnte darunter leiden

Es gibt leider wenig konkrete Lösungsansätze leider meist gleich Tipps die tief in die Eingeweide von Exchange greifen. Bevor man den Exchange Server zerlegt sollte man einen kurzen Blick auf den Patchlevel werfen und ggf. die aktuellen Updates einspielen. Das hat zum Glück bei uns geholfen. Nach dem Update konnte ich alle Mails nochmal laufen lassen und siehe da es geht.
Anbei ein Link der sich mit dem Export von Mails aus der Queue beschäftigt sollte es immer noch hängen.

http://technet.microsoft.com/en-us/library/bb125215%28v=exchg.80%29.aspx

Windows kann auf dem Datenträger nicht installiert werden. Der ausgewählte Datenträger enthält eine MBR-Partitionstabelle. Auf EFI-Systemen kann Windows nur auf GPT-Datenträgern installiert werden.

Ich hatte das Problem bis jetzt nur auf einem HP Pavilion. Mit aktuellen Dell´s oder Lenovo´s hatte ich bis jetzt noch keine Probleme.

Ich habe bis jetzt nur einen kleinen Workaround im Internet gefunden.
1. In das Verzeichniss \\opsi\pc_bin\Install\win7-x64\winpe wechseln
2. Die Datei bootmgr.efi umbenennen in bootmgr.efi_old
3. Das Verzeichnis efi in efi_old umbenennen

Ich bin damit auch nicht ganz zufrieden hat aber geholfen. Ich hoffe es gibt mal eine generelle Lösung,
da EFI ja überall ist…..

Um eigene Routing Informationen auszublenden muss man über die Powershell gehen:

; Abfrage
Get-SendConnector "Mein-Connector" | Get-ADPermission | Where-Object { $_.extendedrights –like “*routing*” } | fl user, *rights
; Routing Info löschen
Get-SendConnector "Mein-Connector" | Remove-ADPermission -User "Nt-Autorität\Anonymous-Anmeldung" -ExtendedRights "ms-Exch-Send-Headers-Routing"
; Auf englischen System
Get-SendConnector "Mein-Connector" | Remove-ADPermission –User “Nt Authority\Anonymous Logon” –ExtendedRights “ms-Exch-Send-Headers-Routing”

In der Abfrage ist in der Standard Konfiguration die Berechtigung “ms-Exch-Send-Headers-Routing” für Anonyme Benutzer gesetzt. Diese Berechtigung löscht man und filtert dadurch die Exchange internen Routing Informationen aus den E-Mail Headern.

Darüber hinaus müssen unbedingt auch die FQDN Einträge in den Sende Connectoren eingestellt werden (Exchange Konsole / Organisationskonfiguration / Sendeconnectoren):

Es wurden einige Einträge in der Offlineadressliste „\Globale Adressliste“ von OALGen ausgelassen. Um festzustellen, welche Einträge betroffen sind, muss die Ereignisprotokollierung für den Offlineadress-Generator mindestens auf „Mittel“ festgelegt sein.
– \Standard-Offlineadressbuch

Dann sollten wir das machen was in diesem Blog beschrieben wird:

http://deadaffebeef.com/blog/exchange-2010-ereignis-id-9320-9325-und-9327/

Bei uns hat das aber auch nicht geholfen. Alle Attribute waren i.o.

Was bei uns geholfen hat:
1. Adresse nicht im Adressbuch anzeigen anklicken
2. Get-OfflineAddressBook | Update-OfflineAddressBook
3. Adresse wieder im Adressbuch anzeigen
4. Get-OfflineAddressBook | Update-OfflineAddressBook
Und der Fehler war weg. Bitte daran denken die Protokollierung wieder zu kastrieren

Unsere überlegung: Da der Kunde eine öffentliche IP hat und die Datenverbindung zwischen Client und Server auch intern verschlüsselt erfolgt einfach den Agentserver von Außen erreichbar machen.

- Die Ports 13000 und 14000 TCP in der FW freischalten
- Auf dem Client das Kaspersky Agent und AV Packet installieren
- CMD als Admin
- in den Ordner “C:\Programme (x86)\Kaspersky Lab\NetworkAgent”
- klmover -address xxx.xxx.xxx.xxx -logfile klmover.log ausführen und Fertig

Der Computer sollte nun im Administrationserver erscheinen

Wie installiere ich SNMP unter Windows 2008:

1. Server Manager > Featureübersicht > Features hinzufügen > SNMP-Dienst
2. Dienste > Eigenschaften von SNMP-Dienst > Sicherheit (Einstellung siehe Bild)

Nun haben wir die Voraussetzungen geschaffen das GFIMax Abfragen starten kann. Jetzt nur noch den betreffenden Server auswählen und eine Überprüfung hinzufügen:

Keine Sorge die üblichen Verdächtigen sind bereits vorhanden:

Dell liefert mit OpenManage eine gute Verwaltungs und Überwachungsschnittstelle. Mit Nagios kann man diese auch abrufen – doch nur wenn diese auch installiert ist.

Soweit die Theorie – nun, Dell liefert angepasste ISO Abbilder von ESXi (ESXi 5.1 für Dell T610 Server), doch leider (wie in der Beschreibung dann auch irgendwo zu lesen) ohne die OpenManage Schnittstelle. Diese muss man dann erst selbst nachinstallieren.

Dell stellt dafür diese Anleitung bereit: How to setup and configure ESXi for OME

Zuerst lädt man sich die Voraussetzungen herunter:

• VMware CLI 5.1
• WinSCP
• Dell OpenManage Offline Bundle and VIB for ESXi

Die Installation erfolgt so:

• Herunterfahren aller ESXi Gäste (Anhalten reicht auch)
• ESXi in den Maintenance Modus versetzen
• Mit WinSCP die heruntergeladene Datei (OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX51i.zip) auf den ESXi Server in das Verzeichnis /tmp kopieren
• Mit der VMware CLI dann die Installation ausführen

  • cd C:\Program Files (x86)\VMware\VMware vSphere CLI\bin
    esxcli --server <IP address of ESXi5 host> software vib install -d /tmp/OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX51i.zip

• Neustart des ESXi Servers durchführen

Mit der VMware CLI kann man auf dem VMware ESXi die SNMP Schnittstelle aktivieren: ESXi SNMP

Die folgenden Schritte müssen mit der VMware CLI durchgeführt werden, um SNMP zu aktivieren:

• esxcli --server system snmp set --communities public
  vicfg-snmp.pl --server hostname --username username --password password --enable

• Gegebenenfalls muss man sich mit PuTTY verbinden und die /etc/vmware/
• Neustart des ESXi Servers durchführen

An dieser Stelle bin ich noch nicht weiter gekommen. Per SNMP kann man nun zwar schon einiges abrufen – aber es ist offensichtlich keine 100% Kompatibiltät zu dem Windows OpenManage vorhanden. Außerdem scheint mir das System auf SNMP Traps ausgerichtet zu sein.

Für die Überwachung mit Nagios kann dann dieses Plugin leider nicht verwendet werden dafür aber für die Windows Systeme: check_openmanage

Nun – ganz aufgegeben habe ich noch nicht… deswegen habe ich zumindest diese Tools gefunden, die mich der Überwachung näher bringen:

• check_esxi_hardware.py
• Monitoring VMware ESX 3.x, ESXi, vSphere 4 and vCenter Server

Damit kann ich mit SNMP und check_esxi_hardware die wichtigsten Daten überwachen:

Wenn man den Service Check so aufruft, bekommt man sogar alle wichtigen Performance Daten:

$USER1$/check_esxi_hardware.py -H $HOSTNAME$ --user USER --pass=PASSWORT -p

Das Gerät sagte schlicht: Verbindung zu Exchange nicht möglich

Erst im Eventlog des Servers wurden wir fündig.Dort tauchte folgende Fehlermeldung auf:

Protokollname: Application
Quelle:        MSExchange ActiveSync
Datum:         25.02.2013 22:01:01
Ereignis-ID:   1008
Aufgabenkategorie:Anforderungen
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:     Server.domain.local
Beschreibung:
Ausnahme, die von Exchange ActiveSync behandelt wurde. Diese kann von einer veralteten oder fehlerhaften Exchange ActiveSync-Gerätepartnerschaft verursacht worden sein. Dieser Fall kann eintreten, wenn ein Benutzer versucht, das gleiche Element von mehreren Computern aus zu ändern. Wenn dies der Fall ist, erstellt Exchange ActiveSync die Partnerschaft mit dem Gerät erneut. Die Elemente werden bei der nächsten Synchronisierung aktualisiert.

URL=/Microsoft-Server-ActiveSync/default.eas?User=maxmustermann&DeviceId=ApplDNQH6EV7DTD7&DeviceType=iPhone&Cmd=FolderSync

Ich war ganz verwirrt, da anscheinend Active Sync nicht mehr funktioniert, obwohl es vorher unter Windows 2003 Small Business Server einwandfrei funktionierte.
Erstes Mittel der Wahl war die Exchange Diagnoseseite von Microsoft: https://www.testexchangeconnectivity.com/

Nach der Diagnose staunte ich nicht schlecht das fehlende Benutzerrechte mein Problem verursachten. Nicht etwa das der Benutzer kein Recht auf sein Exchangepostfach hat,nein, dem Benutzerobjekt im Active Directory fehlen Berechtigungen, da die Vererbung der Berechtigungen ausgeschaltet war. Die Lösung des Problems findet sich im folgenden Microsoft Artikel: http://technet.microsoft.com/de-de/library/620c5ce8-3595-4658-9a7a-ec76c10e4a69.aspx

Also wieder ein Grund warum man nicht normale Benutzer zu Domänen-Admins macht. Diese Personen sind sonst Mitglied in einer geschützten Gruppe und die Vererbung ist dann deaktiviert….

Eigentlich ganz einfach dachten wir, doch leider falsch gedacht.

Andreas war frohen Mutes und erstellte über opsi-newproduct ein netboot Packet, ISO war vorhanden und damit waren wir aber schon am Ende. Nach 5 Sekunden PXE Boot wurde abgebrochen mit der Meldung “Can´t find acronis/cd.iso”

Bei der anschließenden Suche im Internet waren wir froh, dass wir nicht die Einzigen mit diesem Problem waren. Es wurde uns schnell klar, dass wir es vergessen konnten das ISO über PXE zu laden da es zu groß für den atftp von OPSI ist. Auch eine Vergrößerung der Blocksize brachte uns nicht zum Erfolg – im Gegenteil der atftp versagte darauf hin seinen Dienst. Im Übrigen meckert OPSI auch im atftp log das die Blocksize nicht passt…

Wir versuchten dann wie im OPSI Forum beschrieben direkt Acronis zu Booten: (https://forum.opsi.org/viewtopic.php?f=7&t=3922&start=10 / Beitrag von msc)

Das klappte im ersten Anlauf leider auch nicht. Die kernel.dat konnte nicht gefunden werden. Was ja aber nicht sein kann, da sie definitiv vorhanden ist.

Was war da faul? In unserem Fall war Windows schuld. Wir enpackten die Daten unter Windows und kopierten Sie auf die OPSI Netzwerkfreigabe, dabei wurden die Dateien kernel.dat und ramdisk.dat beschädigt oder anders geartet verändert.

Als wir das ISO unter Linux direkt entpackten startete Acronis über PXE – oh Wunder.
So weit so gut. Jetzt bekamen wir nur die Meldung, dass wir eine “Trial Version” benutzen würden.

Aber auch hierfür gab es eine Lösung:

http://www.gtkdb.de/index_7_1290.html

- USB Stick besorgen
- In Acronis einen Bootbaren USB Stick erstellen
- Den Stick abziehen und in den Linux Server stecken (oder in der VM an den Server durchreichen)
- Die Datei “dat2″ in “ramdisk.dat” umbenennen (unter Linux)
- Die Datei “dat3″ in “kernel.dat” umbenennen (unter Linux)
- Die beiden neuen Dateien in das Acronis PXE root kopieren
- per PXE booten

Wichtig! diese Dateien dürfen nicht von Windows auf die Maschiene kopiert werden, da es sonst wieder nicht funktioniert. Warum auch immer.
Eigentlich benötigen wir auch nur die dat2.dat (ramdisk.dat), da dort die Lizenz Informationen abgespeichert sind.

Anleitung in Kurz:

- nach OPSI Handbuch ein neues netboot Paket erstellen
- Die Acronis PXE Config Datei sollte wie folgt aussehen:
label acronis
kernel acronis/kernel.dat
append initrd=acronis/ramdisk.dat vga=791 root=/dev/ram0 quiet
- Acronis installieren mit gültiger Lizenz
- Mit Acronis eine Rettungs CD Image / ISO erstellen
- Dieses Image auf ein OPSI Share kopieren (gerne auch unter Windows)
- Aus dem ISO den Ordner “Recovery Manager” in den Ordner /tftboot/linux/acronis entpacken (nicht unter Windows entpacken oder die Dateien in das OPSI kopieren)
- USB Stick besorgen
- In Acronis einen Bootbaren USB Stick erstellen
- Den Stick abziehen und in den Linux Server stecken (oder in der VM an den Server durchreichen)
- Die Datei “dat2.dat” in “kernel.dat” umbenennen (unter Linux)
- Die Datei “dat3.dat” in “ramdisk.dat” umbenennen (unter Linux)
- Die beiden neuen Dateien in das Acronis PXE root kopieren und die vorhandenen überschreiben
- per PXE Booten

Eine Antwort auf dieses Problem ist SlimDrivers. Eine kleine Anwendung die auch von einem USB-Stick
gestartet werden kann spart mehrere Stunden Treibersuche ein.

In der kostenlosen Variante gibt es leider kleine Einschränkungen. Die Treiber werden zwar alle automatisch gesucht, können aber nur manuell nach einander geladen und installiert werden. Bei der Installation des zweiten Treibers muss man sich auch noch dort registrien, ist aber weiterhin kostenlos.

Ich habe es eine Weile getestet und bin bis jetzt voll auf begeistert. Wer alles automatisiert haben möchte muss sich die Vollversion kaufen aber für den privat Bedarf ist der Funktionsumfang völlig ausreichend.

Die Treiber werden über die uns so liebgewonne Cloud bereitgestellt und die sind ganz schön auf Zack.
Selbst Notebooks von Toshiba / Dell / HP können so ohne den üblichen Ballast mit Treibern versorgt werden.