RobertWi

Moin,

ich bin leider noch nicht dazu gekommen. Du findest mit adesiedit die Datenbank GENAU an der Stelle, die Du auch in der Ausgabe findest, also unter:

CN=Public Folder Database 1610729624,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domäne,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domäne,DC=local

Du musst den Pfad nur "rückwärts" durchgehen. Und nichts löschen, wo Du Dir nicht sicher bist.

Moin,

IPv6 wenn überhaupt, nur über die Registry deaktivieren.

Was sagt denn der Befehl, wenn Du ihn mit dem Schalter "-verbose" ausführst?

Moin,

bei Deiner Mailboxstatistic fehlt noch die Angabe von "TotalDeletedItemSize". Die musst Du auch einrechen.

Ansonsten kann Dir leider außerhalb von Microsoft niemand wirklich dabei helfen.

Das Datenbank-Format ist nicht offengelegt, es weiß also niemand, was da wirklich drin ist.

Vermutlich sind es Verwaltungs- und Header-Informationen in den Postfächern. Diese werden (noch) nicht in der Mailbox-Statistic angezeigt. Daher sind die Werte dort immer kleiner, als die Gesamtsumme.

Du kannst ja zum Spaß mal eine Kopie der EDB-Datei machen und mit eseutil /p ein Offline-Defrag durchführen. Dann siehst Du, was tatsächlicher für Whitespace drin ist.

Ansonsten können wir ohne weitere Angaben von Dir nicht wirklich was beurteilen. In meiner Umgebung hier sind täglich "ein paar hundert MB mehr" das Grundrauschen. 2000 Postfächer machen mehr Arbeit.

Moin,

die Leute hier arbeiten ehrenamtlich. Da kannst Du nicht erwartet, dass innerhalb weniger Stunden eine Lösung kommt. Zumal es vermutlich gar keine gibt, wie man hier lesen kann:

Exchange 2010 Mail Enabled Public Folder Items change randomly the read / unread status

Wenn Du eine entgültige Klärung haben willst, musst Du Dich also vermutlich an MSFT wenden.

Moin,

aj, das ist dann wohl doch noch ein wenig mehr defekt.

1. Adressbücher können nicht aktualisiert werden « Robert Willes Welt

Danach sollten dann die Fehler aus dem ersten und zweiten CMDLET weg sein. Bei den Empfängern, die kein Leerzeichen habe (Gast) dürfte Fehler der gleiche sein, den wir zwei Posts davor schon hatten -> leeres Datenbank-Feld.

2. Das Offline Adressbuch scheint es nicht mehr zu geben. Du könntest erstmal einfach ein neues anlegen. Ob es aus der Ferne möglich sein wird, den verwaisten Eintrag zu entfernen, kann ich nicht aus dem Kopf sagen.

Fehlende LegacyExchangeDN. Das wäre ein möglicher Grund dafür, warum sie nicht adressierbar sind.

Probieren wir mal andere, ob die Fehler bringen:

get-addresslist | update-addresslist

get-globaladdresslist | update-globaladdresslist

get-offlineaddressbook | update-addressbook

Ok, das ist nicht der Fehler, den ich erwartet hatte, aber den solltest Du auch korrigieren: "set-mailbox Gast -database NAME_EINER_MAILBOXDATENBANK". Oder diese Mailbox deaktivieren.

Moin,

könntest Du mal checken, ob der folgende Befehl eine Ausgabe bringt (sollte er nicht):

Get-Mailbox | Where-Object { $_.LegacyExchangeDN -eq $null -or $_.LegacyExchangeDN -eq ""}

Moin,

der Fehler ist vermutlich hier:

"DC=JMSRV,DC=JMM,DC=LO"

Dreimal DC= bedeutet, dass die DOMÄNE jmsrv.jmm.lo" heißt, nicht der Server.

Sollte der Server so heißen, muss es "CN=JMSRV,DC=JMM,DC=LO" heißen.

Allerdings frage ich mich, warum Du nicht einfach in die Anleitung von BB schaust. Die ist IMHO richtig gut.

Der zweite ist nicht notwendig. In Ad gibt es wirklich zwei Datenbanken für öffentliche Ordner. Interessant, dass die Ems neu eine zeigt.

Die erste oben in der Liste ist zviel und müsste mit adsiedit gelöscht werden. Anleitung kann ich heute aber nicht mehr schreiben, bin schon unterwegs. Bis auf die Fehlermeldungen kann das aber auch bis Montag warte, ist ungefährlich.

Ok, dann machen wir mal eine AD-Suche, ob noch irgendwo eine Leiche ist.

Erste Suche - öffentliche Ordner Datenbanken:

$rootdse=new-object directoryservices.directoryentry("LDAP://rootdse") 
$Configpath=$rootdse.configurationNamingContext 
$adsientry=new-object directoryservices.directoryentry("LDAP://$Configpath") 
$adsisearcher=new-object directoryservices.directorysearcher($adsientry) 
$adsisearcher.pagesize=1000 
$adsisearcher.searchscope="subtree" 
$strfilter="(ObjectClass=msExchPublicMDB)" 
$adsisearcher.filter=$strfilter 
$adsisearcher.FindAll() | select Path

Zweite Suche - Mailbox Datenbanken:

$rootdse=new-object directoryservices.directoryentry("LDAP://rootdse") 
$Configpath=$rootdse.configurationNamingContext 
$adsientry=new-object directoryservices.directoryentry("LDAP://$Configpath") 
$adsisearcher=new-object directoryservices.directorysearcher($adsientry) 
$adsisearcher.pagesize=1000 
$adsisearcher.searchscope="subtree" 
$strfilter="(ObjectClass=msExchPrivateMDB)" 
$adsisearcher.filter=$strfilter 
$adsisearcher.FindAll() | select Path

Und los.... :)

Ok. Und wann und wo genau bekommst Du nun den o.g. Fehler?

Nein. Der Name "Public Folder Database 1610729624" ist eindeutig ein Name von Exchange 2010. Das sieht man an der zufälligen Zahlenkombination dahinter.

Bitte poste mal die Ausgabe von "get-publicfolderdatabase -status | fl Server,Name,Mounted".

Wie Norbert schon schreibt, generiert der sendende Server den NDR.

Aber über das Nomen "SystemMessage" kannst Du die Exchange-Texte verändern: New-SystemMessage: Exchange 2010 Help

Das ist aus der Ferne quasi nicht zu sagen, weil vorher erstmal analysiert werden müsste, was alles kaputtgegangen ist.

Ich persönlich würde entweder auf eine alte AD-Sicherung gehen oder das AD parallel neu aufbauen (Mails vorher in PST sichern). Je nachdem, was weniger Aufwand macht.

Moin,

hat er eventuell eine Regel in seinem Outlook (kannst Du mit get-inboxrule" prüfen).

Oder eine Weiterleitung und die Mail kommt woanders her?

"Kopie" ist IMHO an dieser Stelle Standard-Terminologie - verallgemeinert aus der DAG-Technik.

Welche Eventlog-Einträge gibt es denn, wenn die Datenbank bereitgestellt wird.

Du wirst um ein Zertifikat nicht herumkommen. Da das aber dauern kann, wäre der erste Workaround, die o.g. URI anzupassen, so dass sie auf den alten Server zeigt.

Achtung: Wenn Du vergisst, die nach dem Umzug wieder zurückzustellen, dann wird Autodiscober nach der Deinstallation von Ex2007 nicht mehr funktionieren!

Ja, das lohnt sich!

Ich habe darüber schon Festplatten umgehängt, LUNs zu neuen Servern verbunden, einmal sogar eine VMDK von VMWARE einfach in eine andere Maschine eingehängt und nach SoftRecover und Mailbox-Korrektur einfach wieder online geschaltet.

Was heißt denn "nur kommt leider keine zurück"

SMTP-Logs, MessageTracking - was gibt es da für Meldungen?

Empfangsconnectoren - wie sind die konfiguriert?

Der Ex2010 hat einen Autodiscover-Eintrag angelegt, der auf sich selbst zeigt. Hast Du den angepasst?

Kontrolle:

Get-ClientAccessServer | fl name,*uri*

Wenn nein, dann ist es Zufall, ob die Clients den von Ex2007 oder von Ex2010 bekommen.

Moin,

hast Du meinen Link wirklich gelesen?

Da ist keine Rede von einer Recovery DB.

Das würde auch gar nicht funktionieren, da die Recover DB die Kopie einer parallel laufenden DB darstellt. Ohne Original, keine Recovery DB.

Ja, zwar ist das ohne Angabe der Rollen und Benutzer-Anzahl nur Glaskugellesen, aber im Betrieb sind man nicht umsonst, warum da diese Mindestgrößen angegeben sind.

Moin,

Du tust Exchange, dem Server und Dir keinen Gefallen, wenn Du der store.exe den Speicher begrenzt.

Exchange nimmt sich grundsätzlich allen freien Speicher, den es gibt (warum auch nicht, was soll er leer rumliegen).

Aber der Speicher wird wieder freigegeben, wenn eine andere Anwendung ihn braucht und Exchange nicht.

Gibt Exchange den Speicher nicht wieder frei, braucht Exchange ihn.

So einfach ist das. Ich habe hier SBS-Server, auf denen wenig Leute sind und kann sehen, dass das funktioniert.

Also gibt es für Dich nur zwei echte Lösungen: Weniger Anwendungen oder mehr RAM. Alles andere ist nur Bastelarbeit, die Dir eher früher als später massive andere Probleme einbringt.

BTW: Auf einen Exchange-Server gehört nichts rauf, was nicht direkt was mit Exchange zu tun hat. Also Exchange + Virenscanner + Backup + Monitoring -> Ende.

Aus dem Kopf würde ich sagen, das 2007 das im Eventlog protokolliert. Eine echte Anzeige gibt IMHO erst ab Ex2010.