RobertWi

Moin, hast Du Dir die Konfig des Sende-Connectors mal angesehen? Es ist doch extrem offensichtlich, wo die Authentifizierungsdaten einzutragen sind. Ich bin auch bei Deinem Provider und das Senden mit Smart-Host, Authentifizierung und TLS funktioniert problemlos. Und BTW: SP 3 ist aktuell, SP 1 wird schon nicht mehr supported. Das POP3-Connectoren Mist sind, hat mir da ja schon gesagt. Bei 4 Exchange und diversen Windows-Lizenzen sollte es wohl nicht an ein paar Euro für eine fest IP-Adresse scheitern - falls die nicht schon in der Leitung mit drin ist.

Moin, die einzig gute Möglichkeit ist, eine neutrale Domäne zu nutzen. Die Message ID solltest Du tunlichst nicht anfassen, da Du sonst andere Probleme riskierst (z.B. Mail-Schleifen).

Moin, welche Mails können nicht empfangen werden? Intern? Externe? Was passiert mit den Mails? NDR? Warteschlange? Die verschwinden ja nicht einfach! Und auch, wenn Du was anders schreibst: Doppelt prüfen, dass KEIN Smarthost beim virtuellen SMTP bei 2003 eingetragen ist! Das ist die häufigste Fehlerursache für Deinen Fall.

Heute wir heute früh erst, die Antworten dürften die gleichen sein: http://www.mcseboard.de/topic/194535-tool-f%C3%BCr-esd-to-pst-export/

Hmm. Der Punkt "Externe Domäne für Clientzugriffsserver konfigurieren." ist einer früher, sieht man auch im Screenshot. Also: Was kommt den NACH "Externe Domäne für Clientzugriffsserver konfigurieren."?

Moin, Tipp für die Dienste: Nach Starttyp sortieren, dann siehst Du auf den ersten Blick, ob was nicht läuft. Geht der Zugriff über OWA Schon mal das Outlook-Profil gelöscht und neu angelegt?

Moin, öffne OWA im Browser und schau Dir dort das Zertifikat an. Solltest Du nicht eine komplett ungewöhnliche Konfig haben, dann ist das Zertifikat das gleiche, dass auch Outlook bekommt.

Moin, natürlich wäre es schöner zu erfahren, was genau Du da gelöscht hast, aber ich sage spontan mal: Nein, mit einfachen Mitteln bekommt man die nicht wieder.

Moin, blinder Aktionismus hilft Dir nicht und macht am Ende mehr kaputt. Daher: Bevor Du Dich an Problemlösungsgedanken machst, erstmal das Problem selbst identifizieren. Im Gegenteil: Bei ÖO und eventueller Umlaufprotokollierung muss man einiges beachten. Sonst hast Du am Ende zwar den Stand vom Backup (und damit Datenverlust), bekommst die Datenbank aber immer noch nicht eingebunden. Bei Exchange reicht es selten aus, einfach nur eine Datei auszutauschen, wenn man nicht genau weiß, was man macht.

Moin, welche Fehlermeldungen im Eventlog gibt es denn, wenn Du die ÖO-Datenbank manuell über die EMC bereitstellst?

Moin, der Benutzer kann sich beliebige Kalender, die er lesen darf, auch in OWA öffnen, muss das IMHO aber bei jedem Aufruf neu machen (OWA -> Kalender -> RMT auf "Mein Kalender" - Kalender werden hinzugefügt... Die URL findest Du hier: http://sysadmin-e.com/ex2010-owa-url-calendar

Ich kann Dich verstehen und höre das auch von anderen Seiten. Nur denke ich nicht, dass die Reaktion dann sein kann, in andere Orte auszuweichen. Ihr bezahlt dafür! Entweder stimmt der Service oder ihr gebt das Geld für das falsche Produkt aus und müsst wechseln.

Moin, bei Office 365 bezahlst Du für den Support, also solltest Du ihn auch von Microsoft nutzen. Nur so bekommen die auch mit, welche Probleme oder Wünsche es gibt. Also am besten die Frage noch mal hier stellen: http://office.microsoft.com/de-de/support/support-FX104018798.aspx?redir=0 Aber spontan würde ich sagen: Automatisch geht da gar nichts, weil auch bei Ex 2013 nichts automatisch geht. Alle Personen müssen das normal von Hand pflegen und dann ist das wie in einem stinknormalen Kalender.

Ja. Allerdings ist der Critical Security Fix in allen Exchange-Versionen (2007, 2010, 2013) der gleiche, wiedermal ein Problem mit der Oracle Komponente für Web Ready Viewing. Und da eines der Updates bereits böse Fehler hat, muss man befürchten, dass die anderen auch nicht besser sind. Entweder schaltet mal Web Ready Viewing ab und wartet auf offizielle Aussagen. Alternativ lautet der Workaround: - SP3 runterladen, auspacken und an die erwartete Stelle schieben - wer sich unsicher ist: Die Stelle bekommt man mit folgendem PowerShell-Befehl oder direkt aus dem Regkey raus: "Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{4934D1EA-BE46-48B1-8847-F1AF20E892C1}" | Select InstallSource" Der Pfad sollte dem entsprechen, den das RU anzeigt.

Meine Antwort nicht gelesen?

Moin, das Problem wird intern bereits diskutiert. Da der Hotfix für Ex 2013 aufgrund eines kapitalen Bugs gerade zurückgezogen wurde, würde ich mit der Installation bei Ex 2010 noch ein wenig abwarten. Eventuell sind hier auch Fehler drin. Als Workaround für den Critical Bug schaltet man das "Web Ready Document Vieweing" im OWA-Verzeichnis ab. Der Rest im RU sind nur normale Fehlerkorrekturen. Wir müssen offensichtlich damit leben, dass Updates für Exchange 2013 immer einen Fehler haben und für andere Exchanger Server meistens auch. :(

Du musst auch die Zahl bei "admincount" auf 0 setzen, geht normalerweise nicht alleine.

Da klingelt sofort die gleiche Glocke, wie bei Norbert: http://www.msexchangefaq.de/konzepte/adminsdholder.htm

Das glaube ich nicht, Du musst nur an die richtige Stelle schauen (weit rechts) und eventuell die Spalten vergrößern. Das sieht aus, als würde eine Firewall das blocken, bei Dir oder beim Empfänger. Nein, das ist normal, die Uhrzeit im Log ist UTC und da wir Sommerzeit haben, ist bei uns UTC+2. Du kannst das auch mit Telnet testen.

Moin, mit welche Fehlermeldung bleibt die Mail in der Warteschlange liege. Starte mal den Transport-Dienst neu und schau, ob sich dann was tut.

Moin, zwei Möglichkeiten: 1. Lösch die E-Mail-Adresse aus dem Postfach 2. Leg eine Transport-Regel an, in dieser kannst Du einen NDR generieren, wenn an die Adresse gesendet wird. Hierbei kannst Du dann noch einstellen, dass z.B. interne weiterhin dahin senden können. Na ja, gibt noch ein paar Möglichkeiten z.B. bei der Empfängerfilterung, aber die beiden sind die einfachsten.

Da musst Du natürlich auch einen passenden DNS-Eintrag für machen. Man kann bei Ex 2010 fast alles nachträglich ändern. Nur Outlook muss eventuell korrigiert werden. Das ist jetzt aber eventuell oder auch nicht ein vollkommen anderes Problem. Im Normalbetrieb und bei sauberer Konfig braucht es keine Anmeldung, das geht dann automatisch. Die verschiedenen URLs, Namen, DNS-Einträge und das Zertifikat von Exchange müssen natürlich zueinander passen. Das übersteigt aber schnell die Möglichkeiten eines Forums.

Moin, Wenn Du das schon weißt, warum fragst Du dann? Mach Doch einfach. ;) Ah, nicht mal "Mittelstandscluster", sondern Cluster für ganz Arme. Sagen wir mal: Es ist nicht die beste Lösung, aber supported. Du hast halt kein automatisches Fail-Over, sondern musst immer von Hand eingreifen. Zur Zeit hast Du: Ex1 mit IP1 Ex2 mit IP2 Du brauchst nun: Einen willkürlichen HTTPS-Namen (oder auch mehrere), für die HTTPS-Verbindungen der Clients. Nennen wir ihne "owa.xxxxx". "owa.xxxx" wird in den betreffenden URLs (OAB, ECP, OAW, EWS) hinterlegt, ein Zertifikat auf den/die Namen ausgestellt und in DNS auf IP 1 angelegt. Außerdem brauchst Du einen RPC-Name. Das ist der Name, der später bei Outloo als Exchange-Server steht. Das ist das CAS-Array, den Namen hast Du schon: cas.xxxxx mit IP1 im DNS Alle Clients verbinden sich nun mit den Namen "cas.xxxx" und "owa.xxxx" zum Ex1. Datenbanken können von Dir beliebig geschwenkt werden, der CAS leitet notfalls selbst auf Ex2 weiter. Sollte aber Ex1 ausfallen, musst Du im DNS die IP-Adressen von "owa.xxxx" und "cas.xxxx" auf IP2 stellen. Danach den Client-PC neustarten (Alternativ, Outlook schließen, cmd.exe mit ipconfig /flushdns, Outlook wieder starten, bekommen aber die meisten User eher nicht hin). Ab dann arbeiten die User mit Ex2, der notfalls auf die Datenbank von Ex1 weiterleitet. Sollte Ex2 ausfallen, geht das Spiel andersrum, in DNS dann wieder die IP-Adresse von Ex1 eintragen. Gemeint ist wahrscheinlich: "dass es ratsam wäre, erst das CAS-Array dann die DBs und dann die DAG anzulegen." Das ist ratsam, weil dann automatisch bei den Datenbanken das CAS-Array als RPCClientAccess-Server eingetragen wird. Ist aber kein Problem, kannst Du auch nachträglich korrigieren: Get-Mailboxdatabase | Set-Mailboxdatabase -RPCClientAccessServer cas.xxxxx Nur die Outlook-Clients musst Du leider von Hand ändern, die bekommen die Änderung nicht mit, weil die alte Einstellung bei denen ja noch funktioniert. ?? Per DNS? Oder was meinst Du? Das ist auch falsch. Die CAS-Rolle nutzt kein Failover-Cluster. Die nutzt entweder Networkload Balancing (geht aber bei Dir nicht, weil Du dafür dedizierte CAS-Servers brauchst) oder einen HW-LB. Im September ist doch kein Zeitdruck. Zeitdruck wäre heute Abend gewesen. ;)

Moin, ich habe hier PF, dagegen sind Deine winzig. Nimm mal Faktor 10, dann erreichst Du die hier. Sowas funktioniert problemlos. Welche Exchange-Version? Wie sind die zusätzlichen Postfächer in Outlook eingebunden?

Moin, die Frage wurde vermutlich schon 1000x gestellt: Du brauchst zusätzliche Postfächer und die Benutzer bekommen dann "Vollzugriff" und "Senden Als" auf diese. Wenn Du Mails auch für die Adressen empfangen willst, müssen eventuell Konfigs beim SBS gemacht werden (in Exchange werden Remote Domänen und eventuell E-Mail-Adressrichtlinien benötigt). Und der normale Hinweis: Das ist ein SBS, der hat eventuell einen Assistenten für so was.