RobertWi

Ok, Exchange 2003 ist dann doch zu lange her. Aber danke für die Info.

Ich nutze grundsätzliche keine AV für Postfächer (gesetzt, man hat keinen übermäßigen OWA- oder POP/IMAP-Zugriff). Den Zugriff macht Outlook, den Transport ein SMTP-Scanner. Und wenn Viren in einem Postfach sind und nicht angefasst werden, sollen sie dort ruhig liegen. Den ersten Grund lieferst Du (Lizenzen), der zweite Grund ist, dass alle AV negative Auswirkungen auf die Performance haben.

Moin, das Senden mit sekundären Adressen ist ein Top3-Thema auf der Wunschliste der Kunden an die Microsoft-Entwickler. Leider wird sich hier auch in Exchange 2013 nicht viel ändern. Vielleicht mit dem nächsten Server, nach dem jetzt die ÖO gut sind. :) Aber ich sehe kein Problem mit einem zweiten Postfach. Richtig konfiguriert ist das für den Benutzer vollkommen unsichtbar.

Moin, richte einen zweiten virtuellen SMTP-Server ein und konfigurieren den entsprechend.

Ehrlich gesagt hat niemand die Lust einen eventuellen Fehler zu suchen, der in zwei Service Packs und 6 weiteren RU eventuell schon behoben wurde. Also: Erstmal durchpatchen, dann wieder melden!

Ok, danke für die Info. Eine Routine-Überprüfung des Verbindungsstatus und der DB-Einstellung hätte das gezeigt. Aber das sagt sich aus der Ferne natürlich sehr leicht. :)

Moin, Outlook benutzt für den Cache den sog. LegacyExchangeDN, nicht die E-Mail-Adresse. Weitere Infos auch zu den möglichen Problemen findest Du hier in diversen Abschnitten: MSXFAQ.DE - LegacyExchangeDN

Moin, wenn Du ein Zertifikat erstellst, bietet entweder das Werkzeug (bei Exchange "New-ExchangeCertificate" mit "-PrivateKeyExportable $false") oder später die unterschreibende CA die Möglichkeit, den Export des privaten Schlüssels zu verbieten. Das ist eine Sicherheitsfunktion. Deine Sicherung könnte "abhanden" kommen und jemand anders damit erfolgreich einen identischen Server aufbauen. Bei Systemen mit hoher Sicherung verhindert man mit dem Verbot eine Kompromittierung und im Falles eines Problemes muss halt ein neues Zertifikat erstellt werden.

Nö, leider normale. Outlook speichert bestimmte Eigenschaft des Empfängers und fragt nicht mehr nach, ob die sich verändert haben, wenn man den Empfänger aus dem Cache nimmt. Erst das löschen und neusuchen aus der GAL führt dazu, dass Outlook wieder fragt die eventuelle Änderungen findet.

Moin, sind die Replikate auf dem alten Server wirklich entfernt worden. Es kann leider wirklich ein wenig dauern, bis die Replikation durch ist. Und wenn Du die Connectoren bereits entfernt hast, wird sie vermutlich nie fertig werden (die ÖO-Replikation geschieht mit Mails). Dann wird Dir nichts anderes übrig bleiben, als die ÖO-DB mit ADSIEDIT manuell zu löschen. Danach klappt dann auch die Deinstallation.

Moin, Da ist keine. Da das ein Selfsigned ist, ist er vermutlich so erstellt worden, dass man den privaten Schlüssel nicht exportieren kann. Außerdem ist es eh abgelaufen und damit wertlos und muss auch nicht exportiert werden. Ungetestet: get-exchangecertificate | export-exchangecertificate .....

Jo, das sieht nach einem Berechtigungsproblem aus. "Zugriff verweigert" ist da ziemlich eindeutig. Neben den Links von tesso kannst Du auch die Berechtigungen mit dem alten Verzeichnis vergleichen.

Moin, und die Ressourcenbuchungsautomatik ist auch wirklich in den PF aktiviert?

Moin, und ich schreibe schon "wenn Du uns die GENAUEN Fehlermeldungen aus dem Event-Log" = PLURAL, weil mit dem Mount mehrere Fehlermeldungen erscheinen und der echte Fehler erst in der zweiten oder dritten Meldung steht. Kann es sein, dass die Partitionen nicht NTFS formatiert sind? (tesso war schneller) Außerdem bitte prüfen, ob die administrativen Freigaben E$ / D$ / usw. exisitieren.

Moin, ich hatte das mit "Standard"-Vorlage so missverstanden, dass Du eine Vorlage mit dem Namen "Standard" meintest und nicht die Vorlagen, die standardmäßig eingerichtet sind. Wenn ich die Vorlage "Subordinate Certificate Authority" kopiere, dann ist es egal, welchen Type ich danach auswähle: Ich kann bei Signatur alles auswählen, aber nichts bei Verschlüsselung. Gefordert wird die, wir bereits festgestellt, vollkommene widersinnige Verwendung von: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign Das würde bedeuten, dass ich bei "Schlüsselverwendung" die folgenden Checkboxen ankreuzen müsste: #1 - Signatur - Digitale Signatur (= Digital Signature) #3 - Signatur - Signieres des Zertifikates (= Certificate Sign) #5 - Verschlüsselung (Schlüsselvereinbarung) (= Key Agreement) #6 - Verschlüsselung (Schlüsselverschlüsselung) (= Key Encipherment) #7 - Verschlüsselung (Benutzerdaten...) (= Data Encipherment) Aber es kristallisiert sich immer mehr heraus, dass wohl die Anleitung von Cisco falsch ist. Der CSR, den die Cisco-Tools erstellen, passt nicht zu den Anforderungen. Der CSR für diesen Abschnitt enthält nämlich nur Digital Signature, Key Encipherment, Data Encipherment, Key Agreement. Von Certificate Sign ist im CSR gar keine Rede. Und die vier erst genannten lassen sich so konfigurieren (na ja fast, Key Agreement und Key Encipherment schließen sich eigentlich gegenseitig aus). Der zweite CSR (für CAPF) enthält nur Digital Signature, Certificate Sign und von Key Encipherment ist nichts zu sehen. Und diesen CSR kann man wunderbar z.B. mit der von Dir genannten Vorlage abbilden. Durch Zufall (!) haben sie dann herausgefunden, dass die letzten Zertifikate mit 80 % der Telefone funktionieren. Nur auf einem einzelnen Typen gehen sie nicht - und genau mit diesem Typen wurden vorher alle Versuche gemacht. Nun kümmert sich der Cisco-Support um die Angelegenheit. Ich habe einen ganz schönen Hals, weil mich das Thema in den vergangenen zwei Wochen eine zweistellige Stundenanzahl gekostet hat (und Dich ja auch einige Zeit) und nun könnte alles eine unglückliche Verkettung sein: Falsche Docu und fehlerhafte Geräte. Und eigentlich hat alles genau so funktioniert, wie wir uns das auch denken und hätte mit den Standard-Vorlagen erschlagen werden können. Ab morgen bin ich erst mal drei Tage bei einem anderen Kunden. Ich berichte dann mal.

Ich weiß, dass Du es mit Deinem ersten Abschnitt gut meinst und Du mir quasi das gleiche erzählst, was ich in den vergangenen Woche dem Kunden erzählt habe. Also lass es an der Stelle gut sein, das hilft jetzt konkret leider nicht weiter. Das Kopieren einer vorhandenen Vorlage ins Format 2003 brachte leider nichts. edit: Das mit der "Standard"-Vorlage habe ich missverstanden. Zu viele Fenster gleichzeitig offen. :)

Du hast gelesen, dass die CA nicht vertrauenswürdig ist?! Das Risiko ist also überschaubar, da rein intern (und dort noch nicht Inbetrieb, außer für fünf Webserver). Hat er ja. Er zeigt mir den Guide von Cisco und sagt: So sollen die aussehen. Und leider sehen sie nach der CA von Windows nicht so aus. Ok, das kann ich aus dem Kopf nicht sagen. Da hier aber eine homogene Win 2008 R2 Umgebung ist, habe ich mit hoher Wahrscheinlichkeit eine 2008-Vorlage erstellt.

Moin, vielleicht hätte ich dazusagen sollen, dass wir intern schon über den "Sinn/Unsinn" diskutiert haben und der Kunde entschieden hat, dass diese Frage später beantwortet wird. Zuerst müssen die Cisco-Dinger laufen, denn hier kostet die Consulting-Firma mit jedem Tag richtig Geld. Und hier schieb Cisco halt die Schuld ziemlich einfach auf die Windows CA, fertig. Und da ich kein Gegenteil beweisen kann, bin ich nun im Zugzwang. Korrekt. Aber da sind im Kasten "Signatur" entweder die beiden oberen Punkte aktiv und anwählbar, oder die beiden unteren - aber nie alle gleichzeitig. Oder zumindest habe ich noch nicht die Stelle gefunden, an der man erreichen kann, dass alle vier Kästchen angeklickt werden können. Und das gleiche gilt für den Kasten darunter - "Verschlüsselung". Ich kann entweder die erste Option "Schlüsselvereinbarung" oder die zweite Option "Schlüsselverschlüssel" auswählen. Aber nicht beide gleichzeitig. Beide Optionen will aber der komischer Cisco-Guide haben. :( Ich habe in einem dritten Versuch (oder war es der vierte oder fünfte...) Zertifikate erstellt, die so viel von dem enthielten, was technisch in der CA ging. Diese Dinger bringen Fehler, mit denen nun direkt ein Ticket bei Cisco aufgemacht wurde. Erste Reaktion: Eigentlich sind die Zertifikate ok, dann ist das eventuell doch ein Fehler im Gerät (oh wunder, und die Zertifikate entsprechend garantiert NICHT dem CA-Guide von Cisco, sind aber trotzdem ok?!). Damit bin ich im Augenblick auf "hold" und warte, was beim Cisco-Support rauskommt. Wenn Du noch eine Idee hast, da trotzdem raus damit. Ich fürchte, dass wird noch nicht das Ende gewesen sein.

Moin, danke für die Info. Wie gesagt: NICHT über den Sinn diskutieren. Mein Wissen bei Cisco geht gegen 0 und ich kenne nur die offizielle Anleitung und die Aussage, dass die bereits mehrfach testweise ausgestellten Zertifikate alle nicht funktionieren. Ich persönlich finde es wie Du vollkommen sinnlos, wenn ein für den Tomcat verwendetes SSL-Zertifikat auch "Certificate Sign" können soll. Nur leider fehlt mir das Wissen und die Möglichkeit, um das Gegenteil zu beweisen. Das einzige was ich weiß: Die ausgestellten Zertifikate entsprechen nicht den Vorgaben und funktionieren nicht.

Ja, stimmt. Wenn man im IPhone die erste Eingabemaske durchhat und den Server angeben muss, wird dort auch eine IP-Adresse genommen. Ist aber IMHO nicht protkollstandard, eben wegen der Zertifikatsprobleme (wobei man bei SAN-Zertifikaten auch IP-Adressen eintragen kann, habe ich aber noch nie probiert).

Ja habe ich, schon ganz oft. Und auch problemlos gelöst. Wie, verrate ich Dir aber erst, wenn Du uns die GENAUEN Fehlermeldungen aus dem Event-Log schreibst! ;) Oder anders ausgedrückt: Wir sind hier zwar gut, aber keine Hellseher. ;)

Moin, wie sweigl schon schreibt, ist das Problemlos möglich. Eventuell musst Du Dich mal näher mit Exchange beschäftigen und die Unterschiede zwischen Mailbox-Daten (= lokal auf einem Server) und E-Mail-Adresse (=zentral im AD gespeichert) beschäftigen.

Active Sync mit IP? Oder wo "Zugriff erfolgt über die iP-Adresse"? EAS mit IP geht IMHO nicht, nur mit FQDN.

Dann: Ja, natürlich ist das ein anderes Zertifikat. Es gibt keine zwei identischen Zertifikate, es sei denn, man Exportiert und Importiert eins.

Klar: How-To - Exchange Server 2010 - Zertifikat erstellen in Exchange 2010 - msxforum Eine CA ist eine Zertifizierungsstelle, die stellt Zertifikate aus. Möglicherweise musst Du Dich erstmal mit den Basics beschäftigen, das wird aus einem Forum heraus nicht möglich sein.