RobertWi

uri mit i wie ida), nicht url mit l (wie ludwig). C&P meines Befehl hätte gereicht, dann wäre das richtig in der Shell gelandet. Oder nimmt "Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri" (i wie ida!), wenn Du das lieber magst. Nein. SplitDNS bedeutet, dass Du für die gleiche Zone zwei unterschiedliche DNS-Server hast, die unterschiedliche Daten ausliefern. Die Zone selbst heißt aber gleich auf beiden Servern, nur die Adressen, die geliefert werden unterscheiden sich. Siehe auch hier: MSXFAQ.DE - DNS Split-horizon DNS - Wikipedia, the free encyclopedia Nein, das meinte ich nicht. Da hast einen FQDN für OWA, auf den auch die anderen HTTPS-Dienste laufen (OAB, EWS -> die ExternalURL von oben wären also alle identisch) Beispiel owa.domain.de Dann legst Du die Zone mit dem Eintrag nicht nur im externen DNS an, sondern auch im interen. Im internen DNS lieferst Du aber natürlich andere, interne IP-Adresse aus (OAB, EWS -> die InternalURL von oben wären also alle identisch und sie entsprechen auch den ExternalURL). Nur für das CAS-Array benutzt Du einen anderen Namen, der kann auch rein intern sein. Beispiel: rpc.domain.local Das ist der Exchange-Server, mit dem sich die Clients im internen Netz direkt verbinden. Da dies kein HTTPS ist, muss der Name auch nicht ins Zertifikat. Eine URL für OWA, EAS, Outlook Anywhere ist also immer "owa.domain.de", Dein Exchangeserver-Name im Client aber "rpc.domain.local". Ein Beispiel, wie das bei mir aussieht (2 Server, wobei "it.xxxxx.de" nur intern auflösbar ist): [PS] C:\>Get-WebServicesVirtualDirectory | fl *url* InternalNLBBypassUrl : https://sv01.it.xxxxx.de/ews/exchange.asmx InternalUrl : https://exchange.xxxxx.de/EWS/Exchange.asmx ExternalUrl : https://exchange.xxxxx.de/ews/exchange.asmx InternalNLBBypassUrl : https://sv02.it.xxxxx.de/ews/exchange.asmx InternalUrl : https://exchange.xxxxx.de/EWS/Exchange.asmx ExternalUrl : https://exchange.xxxxx.de/ews/exchange.asmx [PS] C:\>Get-ClientAccessServer | fl *uri* AutoDiscoverServiceInternalUri : https://sv01.it.xxxxx.de/Autodiscover/Autodiscover.xml AutoDiscoverServiceInternalUri : https://sv02.it.xxxxx.de/Autodiscover/Autodiscover.xml [PS] C:\>Get-ClientAccessArray | fl Name,FQDN Name : exchange Fqdn : outlook.it.xxxxx.de

Moin, und was war beim letzten Befehl? Autodiscover ist auch wichtig. Grundsätzlich spricht nichts dagegen, interne und externe URL identisch zu habe - im Gegenteil empfiehlt MSFT sogar diese SplitDNS-Konfig. Nur der Name des CAS-Arrays sollte ein anderer sein, aus bestimmten technischen Gründen.

Das ist prima. Meine Erfahrung (mehr als eine Arbeitswoche) ist eine andere, war allerdings auch nicht mit dem Standard-User. Ich hatte sogar die Erfahrung, dass Outlook sich anderes verhält, je nach Version und nach der Berechtigung "Ordner sichtbar" im Postfach-Root. Outlook 2003 hatte kein Problem, Outlook 2007 wollte die Einträge erst anzeigen, wenn der Benutzer auch im Postfach-Root "Ordner sichtbar"-Berechtigungen hatte. Und alles nicht wirklich nachvollziehbar.

Moin, ok, das deutet dan daraufhin, dass das korrekte Zertifikat ausgeliefert wird, aber über die falsche URL. Also URLs prüfen und notfalls korrigieren: Get-OwaVirtualDirectory | fl *url* Get-EcpVirtualDirectory | fl *url* Get-ActiveSyncVirtualDirectory | fl *url* Get-OabVirtualDirectory | fl *url* Get-WebServicesVirtualDirectory | fl *url* Get-ClientAccessServer | fl *uri*

Moin, wie lautete denn der Zertifikatsfehler genau? Ist eventuell das Zertifikat richtig und nur die URL falsch?

Diese Maske liebe ich immer in Erklärungen bei Kunden. Ich glaube, eine noch unverständlichere gibt es wohl in der EMC nicht. Du musst Dir Outlook ab 2007 dazu denken -> da hat der Abwesenheitsassistent ZWEI Masken: intern und extern. Die Einstellung in der EMC bezieht sich genauf auf diese beiden Masken. "Externe Abwesenheitsnachrichten" bezieht sich also auf das "externe" Feld in Outlook. Die aktuelle Einstellung bedeutet also, das nur Ol 2007 und 2010 was bei extern eingegeben wurde, nach draußen geht. Ol2003 sendet nichts nach draußen, das hat ja noch kein "extern". Die 3. Enstellung bedeutet, dass Ol 2003 und EXTERNE Ol 2007 / 2010 nach draußen gehen. Die 4. bedeutet, dass Ol 2003 und INTERNE Ol 2007 / 2010 nach draußen gehen, die externe Maske ist dann unwirksam. Jetzt such Dir die passende Einstellung raus: Be Ol 2003 brauchst Du mindestens die 3.. Die 1. Enstellung schaltet alle externen Abwesenheitsnachrichten ab.

TS war unglücklich ausgedrückt, ich meinte damit natürlich Geräte, an denen mehrere Leute arbeiten - z.B. im Schichtbetrieb.

Moin, wie wäre es mit Virenscanner auf den Clients? ;) Viren, die über Outlook/MAPI Mails verschicken, sind eher unüblich und ab Outlook 2007 (eventuell auch Ol 2003) wird der User auch dick gewarnt mit 10 Sekunden Wartefrist, wenn eine Drittanwendung im Namen des Benutzer Outlook zum Senden nutzen will. Da sind 20.000 Mails fast unmöglich. Also gehe ich eher davon aus, dass Du ein offenes, internes Relay hast -> dichtmachen. Alternativ sendet ein verseuchter PC direkt per SMTP ins Internet -> Firewall zu machen. Und dann gibt es natürlich noch das Message Tracking in der EMS. Da musst Du zwar wissen, wonach Du suchen willst, aber wenn Du einen Ansatz hast, kannst Du sehr schnell damit den Beweis erbringen. Du könntest auch Mapi für die Clients deaktivieren und nach und nach wieder einschalten (Explaining the new MAPI Access feature included in Exchange Server 2003 Service Pack 2). Eventuell findest Du auch eine passende Einstellung im Diagnose Protokoll: Exchange 2000 Diagnostics Logging Auch der Exchange Server User Monitor könnte bei der Suche helfen: Download: Microsoft Exchange Server User Monitor - Microsoft Download Center - Download Details

Lizenzfragen beantworte ich nur in Anwesenheit meines Microsoft-Anwaltes. :) Grundsätzlich werden CALs pro User (=Postfach) oder pro Gerät (eher unüblich) gekauft und die Enterprise CAL ist eine Erweitung einer Standard-CAL. Da die Aufbewahrungsrichtlinie pro Postfach gilt, bräuchte man also pro Postfach eine Standard-CAL + die Enterprise CAL. BTW: HIer gibt es ein schickes kleines Script, dass die CALs berechnet und im Gegensatz zur Organisations-Übersicht in der EMC auch sagt, warum man welche CAL braucht: Script Report Exchange Server 2010 Client Access Licenses (CALs)

Es gibt leider keine Standard-Richtlinie, die löscht. Es gibt nur Standard-Richtlinien, die ins Exchange Archiv verschieben. Man kann das aber mit einer "alten" Managed Folder-Richtlinie hinbekommt. Solange dort nur Standard-Ordner und keine benutzerdefinierten verwendet werden, reicht die Standard-CAL. Die Konfig geht leider nur via EMS, seit SP1 ist in der EMC die Aufbewahrungsrichtlinie zu finden. Und mit dem nächsten Exchange werden die verwalteten Ordner vermutlich wieder weg sein.

Aus dem Kopf (Ex 2003 ist schon eine weile her) würde ich sagen, da gibt es kein Protokoll, das das aufzeichnet.

Moin, ehrlich gesagt stellst Du zu viele Grundsatzfragen, die man in einem Forum nur schwer beantworten kann. Ihr würdet Euch einen Gefallen tun, wenn ihr Euch einen Fachmann ins Haus holt. Ich versuche Dir mal ein Ansatzpunkte zu geben, aber lesen/erarbeiten musst Du Dir das dann schon selbst ein wenig: Ich denke kaum, dass Du doppelte ALIAS hast, ich denke eher, dass die Postfächer in der Datenbank doppelt sind (was erstmal nicht schlimm ist, wenn man vom "Müll" absieht). Vermutung: Autodiscover, Zertifikate oder URLs sind nicht korrekt konfiguriert. Genaueres geht mit so wenig Angaben nicht und wäre Thema für einen eigenen Thread. Dafür müsste man wisse, was verkehrt ist. Solange Du das nicht weißt, ist Hilfe in einem Forum fast unmöglich. Das muss man vor Ort sehen. PST-Rettungen sollte immer erst der letzte Schritt sein und immer von jemanden gemacht werden, der weiß, was er tut. Sonst hast Du danach ein Problem gegen ganz viele andere getauscht.

Moin, das musst Du ein wenig genauer beschreiben. Welche Client? Welches Übertragungsprotokoll? Exchange 2003 schreibt SMTP-Logs nur, wenn man sie vorher aktiviert hat.

Ich kann meine Aussage nur noch mal wiederholen, weil ich es in einem Selbstversuch über eine Woche ausprobiert habe: Unterschiedliches Verhalten, trotz scheinbar (!) identischer Konfig. Das lässt mich ja auch vermuten, dass unter der Oberfläche andere Dinge ablaufen, als bei normalen Postfächern. Ach ja: Richtig lustig wurde das ganze, als ich auch noch unterschiedliche Outlook-Versionen nutzte: Drei Kalender, sechs unterschiedliche Verhaltensweisen. Genaues dazu wird Dir nur Microsoft sagen können.

Moin, ach, habe ich überlesen. IMHO gibt es keine Möglichkeit, eine Nicht-Standard-Kalender zu öffnen, außer über Vollzugriff. Ich bin allerdings nicht der Outlook-Experte.

Moin, vermutlich ist die Mailbox irgendwie beschädigt. Ich würde das Postfach zuerst mal in eine andere Datenbank verschieben und dann neu probieren.

Moin, mann kann technisch zwar die Datenbank später wieder in eine neue leere DB einbinden und auch die getrennten Postfächer wieder neuen Benutzer zuweisen. Das ganze ist aber doch relativ kompliziert und es besteht die Gefahr, dass die getrennten Postfächer vor dem Wiederverbinden schon als White Space gekennzeichnet werden und dann weg sind. Ich würde die Daten dann für den Fall der Fälle lieber in PST-Dateien exportieren. Bei wenigen kann man das manuell machen (Vollzugriff an den Admin, raus damit), bei mehreren mit einem übersichtlichen PowerShell-Script und New-MailboxExportRequest: Hilfe zu Exchange*2010.

Bei guten (!) DHCP-Servern kann man Verzögerungen einstellen, nach denen die antworten. So kann ein DHCP sofort, ein anderer erst nach fünf Sekunden antworten. Gute DHCP erkennen auch, dass es einen anderen Server für den Bereich gibt und starten nicht. Aber wenn ich höre, dass es sich hier um den Router handelt denke ich, dass man bei diesem das alles nicht konfigurieren kann.

Moin, ok. Grundsätzlich habe ich keine guten Erfahrungen gemacht, manuelle Kalenderberechtigungen bei Ressourcen-Postfächern zu vergeben. Das Verhalten ist ungefähr so, wie Du es siehst: Drei identische Einstellungen, drei unterschiedliche Ergebnisse. Ich persönlich denke, dass der Mechanismus des Berechtigungsauswerten nicht so funktioniert, wie bei normalen Postfächern - eventuell auch wegen der Ressourcen-Delegierten. Nach einer Woche intensiver Fehlersuche habe ich damals alle Änderungen rückgängig gemacht und akzeptiert, dass Berechtigungen bei Ressourcen nicht wie erwartet funktionieren.

Moin, die Frage war: Ist Outlook Anywhere aktiviert? Outlook Anywhere ist etwas anders, als Exchange Active Sync (für mobile Geräte). Im Gegensatz zu EAS muss man OA erst einschalten, bevor es benutzt werden kann. EMC -> Server-Kongfig -> CAS -> oben auf den Server mit der RMT -> Outlook Anywhere aktivieren Dann die den externen Domänen-Namen eingeben und nach dem Speichern 15 Minuten warten.

Über welche Exchange und Outlook-Version reden wir denn?

Wenn Du nicht weiß, wo die ist, was hast Du dann hier gemacht?

Sind das denn die richtigen Ordnertypen - sieht man z.B. am Symnol? Was bringt oulook.exe /resetfoldernames?

Moin, was da reinkommt, können wir Dir nicht sagen, das sollte der gleiche Name sein, der auch von Exchange beim Senden benutzt wird und zu der IP-Adresse passen, mit der gesendet wird. Allerdings ist das ein Einstellung die für das Senden von E-Mails gebraucht wird, wenn Deine Mails auf der anderen Seite nicht im Spam landen sollen und nicht für das Empfangen. Die Einstellungen zum Empfangen müssen im DNS des Providers der Mail-Zone gemacht werden, aber das sagte ich ja schon mal auf der ersten Seite.

Moin, ich weiß nicht so richtig, was Du da geändert hast, aber der Hoster für "huhu.de" ist Strato, d.h. Du musst die DNS-Einstellungen über Strato ändern, nicht über die Telekom. Im Augenblick gibt es für huhu.de zwei MX-Einträge und beide zeigen auf Mail-Server von Strato.