RobertWi

Moin,

beides Probleme, die gefühlt schon eine Million mal behandelt wurden:

0. Folgende Befehle einmal in der Shell ausführen:

get-addresslist | update-addresslist

get-globaladdresslist | update-globaladdresslist

Beide müssen fehlerfrei durchlaufen, sonst sind die Fehler zuerst zu korrigieren.

zu 1. Den Outlook-Vorschlags-Speicher mal löschen und das zweite Postfach nochmal aus der GAL heraussuchen. In schlimmen Fällen muss eventuell auch das Profil entfernt werden.

zu 2.: In den Eigenschaften der Verteilergruppe abschalten, dass Authentifikation notwendig ist.

Beim TMG sollte der SSL-Tunnel am TMG enden. Dann kann der Reverse-Proxy schon Einiges bewirken.

Nicht wirklich mehr, als Exchange auch alleine kann.

Am TMG können auch zusätzliche Authentifizierungsmechanismen implementiert werden.  

Das wäre ein Argument (und eventuell die Aufteilung auf zwei Zertifikate).

Grundsätzlich ist eine Firewall zwischen Exchange und DC schon erlaubt - wenn die Regel Any/Any lautet. Ok, das hebt die Firewall dann faktisch auf, macht die Firewall ansich aber nicht unsupported.

@user09: Wie gesagt, TMG wird noch bis 2020 supported und läuft mit Ex 2013.

Aber rein aus der Praxis kann ich das Argument der Entwickler ("Firewall nach ganz vorne und Port 443 an Exchange weiterleiten") schon verstehen. Ich kenne außer dem TMG - und dort auch nur in sehr engen Grenzen - keinen Proxy, der wirklich einen Sicherheits-Gewinn bringt. Dafür müsste ja nicht nur auf Layer 5 od. 6 (= HTTP), sondern eigentlich auf Layer 7 (= OWA mit HTTP) analysiert und gescannt werden. Und da sind die Möglichkeiten eines Proxys extrem eingeschränkt.

Das UAG muss formal noch erwähnt werden. Allerdings ist das DIng so teuer, dass es bei den meisten mehr kostet, als Exchange. :)

Dann stellt sich mir die Frage wie das mit Office 365 läuft.

Microsoft bietet ja auch externe MS Exchange Konten an.

Ein aufgebohrtes Exchange 2013, das man als "normaler" Kunde so nicht kaufen kann.

Sowie viele andere Gesellschaften.

Aber IMHO noch keiner mit Ex 2013. Für Ex 2010 und Ex 2007 gibt es einen speziellen Hosting- oder Multi-Tenant-Mode.

Genau. Bei genauer Analyse kann man also herausfinden, dass von diesem Server noch andere "Kunden" senden.

Außerdem funktionieren die ABP nur bei Outlook. Andere Clients (z.B. EWS) sehen die normale GAL.

Hat ein Anwender einen Domain-joined Computer, kann er mit "schnöden" Bordwerkzeugen weitere User der Domäne finden - am leichtesten indem er Sicherheitsberechtigungen auf eine Datei setzt.

ABP sind nur eine Trennung der Adresslisten, aber keine Trennung der Organisation.

Moin,

ich kann Nils nur zustimmen. Zuerst müssen die Exchange Grundlagen sitzen. Der Betrieb einer hochverfügbaren Exchange-Struktur mit Backup, Virenscanner, Desaster Recovery, usw. ist nichts, was man nebenbei und in einem Forum lernt. Da reden wir problemlos über Monate wenn nicht sogar Jahre an Erfahrung.

Und dabei würdest Du auch erfahren, dass "Hosting" in Ex 2013 nur sehr eingeschränkt möglich ist. Es gibt unterschiedliche Adressbücher (ABP), aber das wars auch schon. Spätestens im Header eine Mail gibt es keine Trennung mehr und wer will, sieht problemlos, wer noch auf dem Exchange drauf ist. Echte Hosting-Kunden wollen i.d.R. was anderes.

Moin,

der Assistent für das neue Konto sieht komisch aus.

Bist Du sicher, dass das Outlook 2010 ist? Der Assistent sieht mir nach Outlook 2007 aus und im Hintergrund sehe ich auch "Word 2007" auf dem Desktop.

Bei Outlook 2007 musst Du in die Eigenschaften des Postfaches gehen und dann im Reiter "Erweiter" das zusätzlich Konto hinzufügen.

Das Automapping und mehrere Exchange-Konten pro Profil gibt es wirklich erst ab Ol 2010, nicht davor.

Mal davon abgesehen, dass ich das auch vom Client aus machen würde, wo ist das Problem?

Im Link wird doch bestätigt, dass es jetzt geht. Seit 2007 ist es möglich. Offiziell wirst Du das nicht finden, weil der Einsatz von Client Programmen grundsätzlich nicht vorgesehen ist - aber auch nicht unbedingt verboten.

Ok:

Get-WebServicesVirtualDirectory | fl Name,*url*

InternalNLBBypassUrl : https://FQDN/ews/exchange.asmx

Das sollte eigentlich leer sein.

Get-WebServicesVirtualDirectory  | Set-WebServicesVirtualDirectory -InternalNLBBypassUrl $null

InternalUrl                         : https://https//mail.domain.de/Microsoft-Server-Activesync

 

Hier stand der Servername und wenn ich dort die externe URL eintrage setzt der scheinbar selbst ein zweites https davo.... Kann hier der Fehler liegen?

u.U. ja. Solltest Du korrigieren. HTTPS ist IMHO Pflicht bei der Verbindung.

Ergänzend zu den anderen: Exchange nimmt sich immer 90 - 95% der RAMs. Du könntest den bei Dir verdoppeln und nach einigen Tagen wäre auch das wieder verbraucht.

Aber Exchange gibt ihn auch wieder frei, wenn ein anderes Programm ihn braucht. Daher müsst ihr Euch im Prinzip fragen, warum der Speicher nicht freigegeben wird. Übliche verdächtige sind: Outlook im Online-Mode, Virenscanner, Backup-System.

Falsch. Exchange-Zertifikate werden mit Exchange-Mitteln ausgestellt. Beim SBS mit dem Wizard. Es reicht nicht, das Zertifikat selbst zu erzeugen, es muss auch an die Exchange Services gebunden werden, usw.

Wildes rumprobieren wird Dich vermutlich irgendwann zum Erfolg führen - ist nur eine Frage der Zeit.

Aber einen letzten Versuch starten wird noch. Poste bitte die Ausgabe folgender Befehle:

Get-ClientAccessServer | fl Name,AutodiscoverserviceinternaluriGet-WebServicesVirtualDirectory | fl Name,*url*
Get-OabVirtualDirectory | fl Name,*url*
Get-OwaVirtualDirectory | fl Name,*url*
Get-EcpVirtualDirectory | fl Name,*url*
Get-ActiveSyncVirtualDirectory | fl Name,*url*
Get-ExchangeCertificate | fl Thumbprint,Services,CertificateDomains

Du hast doch sicherlich vorher ein Backup des Betriebssystems gemacht, oder? Dafür reich ja das einfach Windows Server Backup aus. Zurückspielen und das SP noch mal installieren.

Wenn das wirklich der Fehler war, hättest Du ihn vor dem zweiten Start korrigieren müssen - sonst bekommst Du den nun wieder.

Und die häufigste Ursache bei HT-Installations-Problemen ist ein in der Netzwerkkarte deaktiviertes IPv6. Das ist nicht supported und daher mag Exchange das auch nicht.

Und, was sollen wir jetzt sagen? Du zeigst und weder die Fehlermeldung, noch die Konfig oder die Outlook-Ausgabe.  :confused:

Ich kann nur sagen: Bei den URLs, die die Client bekommt, muss noch was falsch sein. Denn wären alle richtig, bekäme er die Warnung nicht.

Mehr Aussage kannst Du von uns mit den vorliegenden Infos nicht bekommen. ;)

In Deinem Link war noch ein vierter Befehl: Set-UMVirtualDirectory

Benutze die Outlook-Funktion "E-Mail-Autokonfiguration testen..." um herauszufinden, welche URLs noch verkehrt sind:

http://kb.simple-asp.de/E-Mail-AutoKonfiguration-testen_108.html

Split DNS bedeutet, das Du den gleichen  Namen intern und extern verwendest, nur mit verschiedenen IP-Adressen.

Das ist also eine organisatorische Frage. Wie man einen Windows DNS konfiguriert, dazu gibt es vermutlich 1000 HowTos! ;)

Wenn Du Split-DNS benutzt, dann wäre das eine der möglichen Lösungen.

Zu der Fragestellung "welche Namen müssen ins Zertifikat" gibt es gefühlt 1000 Beiträge alleine hier im Forum.

Und wie immer lautet die Antwort: Das Thema ist zu umfangreich für ein Forum, da man vieles über das Netzwerk, Geräte, Exchange-Konfig, DNS, usw. wissen muss.

Du musst jetzt sehen, ob Du entweder an den wichtigen Stellen Exchange ändern kannst, oder das Zert ein Fehler war und neu mit den korrekten Namen gemacht werden muss.

Moin,

dass Du keine Anleitung zum Erstellen eines Zertifikates gefunden hast, glaube ich nicht. Da gibt es hunderte im Internet, z.B. das hier:

http://www.msxforum.de/modules/publisher/item.php?itemid=124

Das einzige, was Dir keiner sagen kann, ist, was ins Zertifikat rein muss (sprich, die Domänennamen). Dafür gibt es keine allgemeingültige Lösung, da dies von Deinem Netzwerk, den Geräten, DNS-Konfig, usw. abhängt.

Du kannst aber damit beginnen, ein Zertifikat mit den gleichen Namen zu erzeugen, die auch in Deinem jetzigen drinstehen.

Nachtrag: Und an Hand des Namens reden wir vermutlich über einen SBS. Bei einem SBS gibt es nochmehr Anleitungen und einen eigenen Assistenten innerhalb des SBS.

Moin,

bevor wir weiterreden: Bring das System bitte erstmal auf einen aktuellen, supporteten Stand.

Eventuell reden wir über einen Fehler, der schon längst korrigiert wurde. Wenn nichts dagegen spricht, am besten direkt auf SP 3 aktualisieren.

Moin,

das ist normal und richtig. Request und fertiges Certifikat sind eine unzertrennbare Einheit. Durch das Löschen des Request hast Du den privaten Schlüssel entfernt und das neue Zertifikat damit unbrauchbar gemacht.

Du musst für den neuen Request daher leider ein neues Zertifikat kaufen.

Eventuell hat der Aussteller ein Key Recovery, ist bei Externen aber relativ unüblich.

Moin,

der Fehler KANN an den Zertifikaten liegen. Aus der Ferne ist dieses Problem immer schwer zu analysieren, weil zu viele Komponenten reinspielen.

Bekommen die Leute eine Zertifikats-Warnung, wenn sie auf dem neuen Server OWA starten?

Kennwort-Tresor im Client schon mal aufgeräumt?