RobertWi

Exchange 2010 hat eher höhere Werte (zumindest in den Bereichen, die die Kunden interessieren), das ist ja gerade das Problem bei der Migration größerer Öffentlicher Ordner Strukturen.

Für 2013 wird die Grenze der Gesamtanzahl mit CU6 angehoben: http://blogs.technet.com/b/exchange/archive/2014/06/09/modern-public-folder-scale-improvements-and-more.aspx Allerdings redet Armin von Ex 2010, also "Legacy Public Folder". Die Zahlen von 2013 lassen sich nur sehr begrenzt auf 2010 übertragen. Da habe ich auf die schnelle keine Zahlen gefunden (außer DB Größe 16 TB). Zumindest bei der Gesamtanzahl kannst Du aber davon ausgehen, dass sie höher als in Daniels Limits sind. Das ist ja einer Hauptgründe, warum die nun erhöht werden - es verhindert die Migration sehr großer Öffentliche Ordner Strukturen. Ansonsten frage ich mich natürlich schon, was ein SBS Kunde macht, der an die Limits von ÖO stößt. :)

(Sorry Kennworttresor steht ja oben) Stand des Exchange Servers? Outlook gepatcht? Neues Profil getestet? Anderen PC getestet? Virenscanner ausgeschlossen?

Ich weiß schon, welchen Pfad Du meinst. Es war nur nicht klar, wo Du ihn siehst. Dieser Pfad steht in der Datenbank und kann offiziell nicht geändert werden (ein Relikt aus Ex 2003 Zeiten). Remote Wipe geht damit nicht, weil es dieses Gerät aus Exchange Sicht eh nicht mehr gibt. Der Eintrag kann nur gelöscht werden. Das ist aber nur lästig im Handling, aber sonst unwichtig. Dieser Eintrag funktioniert eh nicht mehr und sollte sich das Gerät nach der Änderung erneut verbunden haben, hat Exchange für das Gerät einen neuen Eintrag angelegt. Daher geht dann Dein Befehl auch, wenn Du das andere Gerät nimmst. Im Prinzip kannst Du daher per Script einfach alle veralteten Devices löschen. Die kommen mit richtigem Pfad von alleine wieder.

Moin, mir ist jetzt nicht so ganz klar, welchen "Pfad" Du in der EMC meinst? Bei der Verwaltung mobiler Geräte gibt es keinen "Pfad". könntest Du mal einen Screenshot davon posten? Außer poste bitte mal die Ausgabe der EMS, wo Du den richtigen Pfad siehst.

Das hat uns Bill schon mal hier bestätigt: Klick

OK. Das Problem bei Terminen ist, dass zum Großteil Outlook diese bearbeitet. Ohne Outlook gibt es nur Ja oder Nein. Das sieht man immer gut, wenn ein Anwender ein Einladung annimmt "ohne Antwort". Dann sieht der Einladende nichts davon, weil keine Mail an sein Outlook geschickt wurde. Eventuell wäre ein VB-Makro dafür eine Möglichkeit. Oder eine Änderung in der Zeiterfassung, damit die nicht ein Mail verschickt (das ist eher eine Spielerei), sondern direkt via EWS auf die Postfächer zugreift und in den Kalender einträgt.

Moin, wie generiert denn das Zeiterfassungssystem diesen Termin?

Moin, ist das sicher, das das automatisch passiert? Oder ist da eventuell ein Stellvertreter am Werk, der noch nicht bestätigte Buchungen nachbearbeitet.

Nein. Die OST-Datei ist verschlüsselt mit Informationen des Benutzeraccounts. Daher kann man die auch nicht von Account A nach Account B schieben.

Zu überprüfen wäre nur, ob die Systemfolder mit dem OAB eine funktionierende Replikation haben.

Mir wäre trotzdem die Sicherheit wichtiger, daher würde ich zuerst Outlook migrieren. Die technische Mehrarbeit ist zwar da (hat Norbert beschrieben), aber wäre mir weniger wichtig, als die Sicherheit. Nur, wenn die Tätigkeiten sehr schnell hintereinander kommen (< 1-2 Tage), würde ich mit Exchange beginnen. Aber in der Praxis fürchte ich, bis Du schnell mit Exchange durch und dann zieht sich die Outlook Migration.... Und mit jedem Tag wird das Risiko höher.

Moin, da beides nicht mehr im Support ist und die Sicherheit damit stark gefährdet, würde ich mit Outlook beginnen. Hier ist die Möglichkeit, anzugreifen, deutlich höher. Außerdem sagt die Erfahrung, dass Ol 2010 mit Ex 2003 besser läuft, als umgekehrt. Aber verlassen würde ich mich nicht darauf, wegen des fehlenden Supports wird diese Kombination weder in die eine noch in die andere Richtung getestet. Kann also sein, dass sie nicht mehr funktioniert.

DU sagst, es liegt am DNS. Natürlich könnte das auch an den akzeptierten Domänen, dem Emfpangsconnector, den E-Mail-Adresse und noch einigen weiteren Stellen liegen. Bist Du nicht gerade in einer Ausbildung? Was wird Euch den da beigebracht. Die drein von Mir oben genannten Dinge sind doch absolute Grundlagen, inklusive der dazu gehörenden SMTP-Protokollierung.

Teste halt mal nicht von WEB oder GMX, sondern von einem anderen Anbieter. Ansonsten können wir prinzipbedingt bei DNS-Problemen nicht wirklich helfen, wenn die Namen verschleiert werden. Dann können wir nur das Prinzip sagen, aber das hast Du selbst schon als "fehlerfrei" erkannt (mit ExRCA).

Korrekt. Und deswegen brauchst Du eben doch einen Smarthost. Mittlerweile mache ich das daher nicht mehr direkt, sondern über meinen Provider. Der bekommt die geänderten DNS Einträge sofort mit und probiert auch schneller die erneute Zustellung.

Die Mails sind nicht von einem Exchange importiert worden, dann gibt es IMHO auch kein legacyDN, was man eintragen könnte.

Moin, das erste Problem ist normal. Der Schreiber muss den Absender einmal auf sich selbst ändern. Er blendet das VON-Feld ein und sucht sich selbst aus dem Adressbuch aus. Allerdings muss er das mit jeder Mail machen, die er "nochmal" senden will, aber nur beim ersten Mal. Nimmt er dann die neue Mail, muss er es nicht mehr tun. Das hat etwas damit zu tun, dass Exchange hierbei nicht die E-Mail-Adresse nutzt, sondern den sog. legacyExchangDN. Der passt bei den importieren Mails aber nicht. Es kann Dir auch passieren, dass die Anwender auf alte, interne Mails nicht antworten können (Empfänger nicht gefunden). Dann gilt das gleiche: Der Empfänger muss neu aus dem Adressbuch ausgelesen werden. Das sind ein typisches Probleme beim Import von PST-Dateien. Das zweite Problem müsstest Du mit dem russischen Admin klären, da können wir nichts zu sagen. Scheint auch ein Linux-Server zu sein.

Hatten wir eben erst, schaust Du hier: http://www.mcseboard.de/topic/198936-mobiler-e-mail-empfang-geht-nicht-bei-allen-benutzern/?hl=%2Bexchange+%2B2003&do=findComment&comment=1237253

Für Outlook braucht man keine Anleitung. Starten, im Assistenten auswählen, dass man ein Mailkonto einrichten will, E-Mail-Adresse + Password eingeben. Fertig. Das bekommt sogar ein Anwender hin. Du musst aber dafür: - Autodiscover korrekt konfiguriert haben - ein Zertifikat haben, dem der Client ohne Fehler vertraut und das die richtigen Namen hat - DNS konfigurieren - eventuell die Firewall öffnen/weiterleiten Die einzelnen Schritt hängen davon ab, wie der Rest der Umgebung konfiguriert ist, da es meist mehr als eine Option gibt.

Port 443 reicht.

Bei LTE IMHO nein. Außerdem haben die ganz böse Volumenbegrenzungen, Bei 5 GB pro Monat von "Data Comfort L Business Basic" zur reden, ist schon frech. Eventuell ist das eine Alternative, kenne ich aber nicht, hat eine Suchemaschine ausgeworfen: https://www.mdex.de/produkte/zugriff.htm Kabel hängt vom Anbieter ab, KDG hat das "größe" Businessgeschäft IMHP aufgegeben (evt. übernimmt Vodafone dann diesen Part).

Moin, der Header wird von den jeweiligen SMTP-Servern generiert. Ob und was die da eintragen, ist also deren Sache. Headerzeilen sind allerdings kein Protokoll, sondern nur eine Zustandsbeschreibung von Eigenschaften. Und sie können an jeder Stelle beliebig manipuliert werden. Auf dieser Seite wird Die ein Header übersichtlich aufbereitet und (wenn alle Zeilen korrekt sind) man kann die Mailverlauf durch die Server besser analysieren: http://mxtoolbox.com/ Du kannst in Deinem SMTP-Protokoll den Verbindungsaufbau sehen, aber richtig sieht das eigentlich nur der Admin des Absender-Servers. Ich nehme an, Du hast eine dynamische IP-Adresse? Es scheint so zu sein, dass einige Provider den TTL des dynamischen DNS-Eintrages ignorieren. Mal wieder, das gab es vor Jahren schon mal und eine zeitlang danach nicht mehr. Und leider auch besonders GMX. Bei mir wurde im Testsystem wurde das so schlimm, dass ich direkten Empfang auf meinen Provider umstellen musste, d .h. dort gibt es alle Postfächer und der leitet dann 1:1 an meinen Exchange weiter.

Eine schieflauende oder nicht mehr existende Replikation könnte ein Grund sein - nicht nur bei SCR, auch bei CCR. Ansonsten: Sind das wirklich noch alle Log-Dateien, also ab Nummer E0000001.log? Was steht dazu im Eventlog? Exchange protokolliert bei der Sicherung normalerweise sehr viel.

Dazu passt übrigens nicht, dass laut Aussage des OP die Datenbank sich selbst als gesichert betrachtet, bestätigt durch die Kopie der eseutil-Ausgabe. ;) Ich bin sicher, wenn man sich die Dateien anschaut wird man sehen, dass es Lücken in der Nummerierung und dem Erstellungsdatum gibt und die Logs als Reste von irgendwann früher übrig geblieben sind.