Zephyrus

Hat jemand nun noch eine Idee?:

http://www.mcseboard.de/windows-forum-ms-backoffice-31/ssl-activesync-owa-dc-97267.html#post595466

Sollte ich das mal probieren oder bringt das garnichts?

Also meines Wissens kannst Du keine eigenen Zertifikate einer OrganisationCA für Server ActiveSync verwenden, die nicht von einer Vertrauenswürdigen, öffentlichen CA wie z.B. VeriSign und Konsorten kommt.

 

Ich nehme an, wenn Du innerhalb der Domäne den OWA machst, geht das Ganze ohne Zertifikatwarnung. Wenn Du versuchst, den OWA über das Internet zu erreichen, bekommst Du diese Zertifikat-Vertrauens-Fehlermeldung, die Du da ja bequem mit Trotzdem machen annehmen kannst.

Leider total falsch. Wenn du es richtig einrichtest und das SSL-Zertifikat deiner eigenen Zertifizierungsstelle exportierst und auf den Clients im Stammspeicher für Vertrauenswürdige blabla importierst, erscheint auch beim externen Aufruf keine Zertifikatswarnung mehr. ;)

Die zweite Anleitung hast du auch falsch verstanden und ist im Original von der Microsoft Webseite. Es ist DIE möglichkeit, OWA mit Formularbasierter Authentifizierung und SSL zu verwenden und DENNOCH ActiveSync über SSL nutzen zu können.

Link:

Exchange ActiveSync and Outlook Mobile Access errors occur when SSL or forms-based authentication is required for Exchange Server 2003

- OWA funktioniert, sowohl per Browser als auch auf den Mobilen-Geräten im Browser.

- SSL ist für owa.domain.de eingerichtet.

- Root-CA ist als Stamm-Cert auf dem Mobilen-Gerät vorhanden.

Beim synchronisieren kommt auch keine Fehlermeldung. Senden geht, empfangen nicht. Weder Mails, noch Kontakte, noch Termine.

Im System-Manager von Exchange, wenn man auf Öffentliche Ordner kommt, erscheint:

Der Servername auf dem SSL-Zertifikat ist falsch.

ID-Nr.: c103b404

Exchange-System-Manager

Das extern SSL für OWA hat aber einen richtigen Namen. Ich befürchte daher, dass ein zusätzliches SSL-Cert für den DC (Exchange) fehlt. Die Schritte für den Fehler oben habe ich übrigens schon ausprobiert, welche bei Microsoft dazu stehen.

Folgendes habe ich eben noch gefunden:

Hier die Lösung:

1. Im IIS für die Standardwebsite den Standard SSL-Zertifikat verwenden.

2. Den SSL-Port der Standardwebsite auf z.B. 445 wechseln.

3. Die Konfiguration der IIS Standardwebseite sichern.

4. Eine neue Webseite erstellen (aus Datei) die zuvor gesichete Konfigdatei einlesen.

5. Für die neue Webseite den offiziellen Zertifikat auf dem Port 443 verwenden und den richtigen hostheaderwert eintragen (z.B:owa.DOMÄNE.de )

Danach geht es.

Ich bin mir nur nicht sicher, ob ich das wagen sollte. Nicht das danach nichts mehr funktioniert.

Hi.

Ich habe eine Zertifizierungsstelle auf einem Exchange 2003 Domänencontroller installiert und darüber ein SSL-Zertifikat für OWA eingerichtet. Funktioniert sauber. Nur ist mir aufgefallen, dass im Speicher für Vertrauenswürdige Zertifikate kein SSL-Zertifikat für den Domänencontroller selbst vorhanden ist. Also keines, dass auf netbiosname.domänenname.local ausgestellt ist. Darum funktioniert scheinbar nur das senden über ActiveSync aber nicht das empfangen.

Jemand eine Idee wie ich ein SSL-Cert für nen DC einrichte ohne das SSL-Cert für den Webserver (OWA) wegzuschmeißen? Über http://netbiosname.domänenname.local/certsrv vielleicht?

Steige da nicht mehr durch :(

Es kommt keine Zertifikatswarnung. SSL ist korrekt eingerichet und das Root-Cert auch auf dem PDA vorhanden. Dennoch klappt keine einzige Synchronisation. :suspect: :(

Nach einem Reboot gibt es endlich wieder Fehlermeldungen:

Es konnte keine Zertifikatkette für das Zertifizierungsstellenzertifikat 0 für ExchSrv01 erstellt werden. Eine Zertifikatkette wurde zwar verarbeitet, endete jedoch mit einem Stammzertifikat, das beim Vertrauensanbieter nicht als vertrauenswürdig gilt.

Dabei ist mir aufgefallen, dass wenn ich OWA über HTTPS aufrufe und mir das Zertifikat ansehe, nur das Webserver-Zertifkat im Zertifizierungspfad aufgelistet wird und nicht darüber noch die Zertifizierungsstelle, so wie es eigentlich müßte.

Woran kann das liegen?

Ja, Geräte wurden schon mal platt gemacht aber das hilft nicht. Vom Provider wird dort nichts geblockt, dass weiss ich ganz genau. Den setzen wir bei mehreren Projekten ein. ;)

Folgendes habe ich eben aber noch gefunden:

ActiveSync uses the following ports:

990 (RAPI)

999 (Status)

5678 (Legacy Replication)

5679 (Legacy Replication)

5721 (Desktop Passthrough)

26675 (AirSync)

Die werden wir an der Firewall mal freischalten und schauen was passiert. Eine andere Idee habe ich mittlerweile nicht mehr. Dachte bisher auch das Port 443 (SSL) reicht.

Hi.

Ich habe hier ein merkwürdiges Phänomen mit einem Exchange 2003 Server und ActiveSync.

SSL ist korrekt eingerichtet. Wenn man OWA aufruft, erscheint keine Zertifikatswarnung mehr. Das Server-Cert sowie das Cert der CA auf dem Server sind exportiert und auch auf den PDA's installiert. Auch von dort per Browser läuft OWA ohne Fehler.

Im Eventlog von Exchange unter Anwendung sowie System stehen keinerlei Fehlermeldungen mehr drin, die auf ein Synchronisationsproblem schließen lassen. Ist auch nicht der erste Exchange 2003 den ich damit ausrüste, sprich ich weiss schon wie es geht.

Wenn ich die Synchronisation über den PDA starte, zeigt er mir von dem jeweiligen Postfach auch die korrekt Größe an (also z.B. 0 von 360 Mails synchronisiert), legt auf dem PDA auch schon die Ordnerstruktur an aber überträgt nicht die Inhalte. Weder Mails, Kontakte noch Kalendereinträge.

ActiveSync auf dem PDA startet die sync und überall erscheint 1/xxx und er bricht ab. Aber keine Fehlermeldung. Haben es schon mit mehreren Geräten getestet. Dem Provider der PDA's ist das Problem bekannt, allerdings keine Lösung.

Das passiert sowohl bei USB sync im LAN, als auch bei der Wireless Sync über GPRS. Domain und Exchange sind auch erreichbar.

Es wurde auch ein virtuelles /Exchange Verzeichnis angelegt, damit ActiveSync UND Formularbasierte Authentifizierung über OWA gleichzeitig möglich ist. Habe einen anderen Exchange 2003 hier wo das ohne Probleme funktioniert.

Nur wenn keine Fehlermeldungen mehr erscheinen, weder auf dem Exchange noch auf dem PDA, komme ich nicht mehr weiter. Postfachname, Passwort, Domäne, etc. auch schon alles überprüft. Wäre da was falsch, würde es auch eine Fehlermeldung geben.

Sprich, der PDA versucht zu synchronisieren, schafft es aber aus irgendeinem Grund nicht, gibt aber auch keinen Fehler dazu raus. Jemand eine Idee?

PS: Der PDA hat aktuellste Firmware inkl. MSFP.

keiner eine idee? :suspect:

Hi.

Ich bastel immer noch fröhlich an folgendem Szenario:

Windows 2003 Server

- Active Directory (mein.server.tld (leider als Domain & Domäne genommen...)

- IIS

- ISA 2004

- Exchange 2003

- Outlook WebAccess

- RPC over HTTPS

- SSL inkl. eigener Zertifizierungsstelle

Wenn ich den Server wie folgt aufrufe:

https://mein.server.tld/exchange

erscheint:

Das Sicherheitszertifikat wurde von einer Firma ausgestellt, die Sie als nicht vertrauenswürdig eingestuft haben. Überprüfen Sie das Zertifikat, um festzustellen, ob Sie der ausstellenden Institution vertrauen möchten.

Die beiden anderen SSL-Hinweise sind mit grünen Haken versehen. Klicke ich auf "JA" komme ich auch auf die OWA-Seite. Der ganze aufruf dauert ca. 10 Sekunden, denke aber das liegt nur daran, dass er den RPC-Proxy starten musste. Einloggen in OWA funktioniert und ich sehe auch meine Mails.

Im Event-Log sind auch keine Fehlermeldungen und es steht dort auch "Der RPC-Proxy wurde gestartet".

Ich habe im ISA eine Regel erstellt inkl. Listener, der auch alle Pfade enthält zu:

/rpc/*

/exchange/*

/exchweb/*

/public/*

etc.

Alles nach einer Anleitung von Seiten wie msisafaq.de und isaserver.org, etc. Da ich auf OWA rauf komme, scheint das ja soweit auch richtig zu sein. Leider etwas langsam bis dann OWA erscheint aber ab da gehts dann.

Das einzige was noch nicht rennen will, ist der Client Zugriff von Outlook (RPC over HTTPS). Habe im Outlook auch unter Verbindung den Haken gesetzt und den Server als RPC Proxyserver eingetragen. (Dazu gabs auch im MCSE/MCSA Buch von Microsoft Press einen Artikel.) Sollte also auch richtig sein. Habe parallel dazu auch auf den ganzen Webseiten dazu gelesen.

Wenn ich nun https://mein.server.tld/rpc/rpcproxy.dll aufrufe, erhalte ich wie oben auch die SSL-Warnung aber die unteren beiden Haken sind grün, also genau wie oben beschrieben. Jetzt erscheint ein Login-Fenster. Wenn ich nun nur so dreimal ok drücke, komme ich auf eine 401.1 Seite. Gebe ich meine Benutzerdaten an, muss ich das nur einmal machen und es erscheint:

Fehlercode 64: Host ist nicht verfügbar

Hintergrund: Die Verbindung mit dem Webserver ging verloren.

Ich habe intern den IIS (Stichwort SocketPooling) von 0.0.0.0 gelöst und auf 192.168.10.10 gebunden. Habe das auch im ISA als IP angegeben für Intern in der Regel. Also für den Server, den ich veröffentlichen möchte. Nur scheint das Routing da irgendwie schief zu gehen.

In der Windows HOSTS Datei habe ich auch 192.168.10.10 mein.server.tld eingetragen, ansonsten gabs eine schicke Proxykettenschleife vom ISA.

Ich weiss nun nicht mehr weiter. Das einzige was mir noch einfällt wäre DNS-Split statt das mit der HOSTS Datei zu versuchen. Habe dazu was auf msisafaq.de gefunden.

Hat von euch noch jemand einen Tipp?

Hier ein paar Links:

Troubleshooting RPC over HTTPS (Part 2)

Search for rpc over https

Socket Pooling in Windows Server 2003

MSXFAQ.DE - Clientzertifikat/SMIME

Okay, bin schon weiter gekommen. Für alle die ebenfalls danach suchen hier der Hilfreiche Link, wie man das abstellt:

Reichwein IT-Services

:shock: :wink2: :p :D ;)

Siehe:

Socket Pooling W2k3

Habe ich bei mir gemacht und als Interne IP 192.168.10.10 genommen.

Habe zwar zwei Netzwerkkarten drin aber nur eine am Switch angeschlossen und aktiv. Daher habe ich die interne (192.168.10.10) mit an die Netzwerkkarte gebunden.

(Einstellungen der Netzwerkkarte -> Reiter erweitert und zusätzlich hinzufügen)

Hab in der Windows Hosts Datei dann 192.168.10.10 auf localhost gelenkt.

per \\192.168.10.10 kann man auch zugreifen und sieht die typischen Ordner, genau wie wenn man \\localhost halt macht.

Trotzdem lässt sich die Default Webseite des IIS nun nicht mehr starten und im InetMGR (Start -> Ausführen -> inetmgr) auch nicht auf die 192.168.10.10 binden. Bzw. binden schon aber ich kann die Seite nicht starten. Allerdings auch nicht mehr, wenn ich die externe IP benutze.

Sinn und Zweck des ganzen ist, dass sich der Web-Listener des ISA 2004 (Port 80 & 443) nicht mit dem des IIS in die Quere kommt. Infos dazu gibts hier:

MSXFAQ.DE - ISA-Server und SSL

Bin grad etwas Ratlos. :suspect:

Hier noch ein paar Informationen:

1.) OWA über HTTPS funktioniert.

2.) Wenn ich auf dem Server https://name/rpc eingebe, erhalte ich einen Promt für Username und Passworteingabe. Das ganze endet dann bei Fehler 401.3 (siehe auch RPC over HTTP/S Error 401.3 after Windows 2003 SP1)

3.) Hier habe ich mich überall durchgewühlt:

Configure RPC over HTTP/S on a Single Server

Exchange RPC über HTTPS

MSXFAQ.DE - RPC over HTTP

Speziell SSL:

1. MSXFAQ.DE - CA installieren

2. MSXFAQ.DE - IIS SSL einrichten

In C:\WINDOWS\system32\LogFiles\HTTPERR\ steht in dem einen Logfile fast nichts drin, bzw. der letzte Eintrag ist fast 1 Tag her. Ich hatte aber den ganzen Tag das ganze versucht, müßte doch mehr drin stehen?

Alle Server/Programme sind up2date.

Hallo.

Ich habe mir einen Testserver aufgesetzt (Windows Server 2003) auf dem ein Exchange 2003 zusammen mit ISA 2004 läuft. Nun habe ich etliche HowTo's und Microsoftartikel zu RPC über HTTPS ausprobiert, jedoch kann ich mit meinem Outlook Client mich nicht über RPC verbinden.

SSL und eine echte Domain dafür habe ich ebenfalls eingerichtet, eine Zertifikatsstelle ist installiert. Der RPC-HTTP-Proxy ist ebenfalls installiert. Das AD ist reines 2003 (alle 3 Roles). Die RPC-Firewallregel im ISA habe ich 1:1 wie im Webcast von Microsoft dazu gemacht. Bin langsam etwas am Ende mit den Nerven und sitze da schon 3 Tage dran.

Hat jemand noch eine Idee woran es liegen kann oder ein paar weitere gute Links zu dem Thema? :suspect: :(

>Ist das eine eigenständige Maschine oder ist sie in einer Domäne?

Sowohl als auch. Ist mir schon bei mehreren Rechnern aufgefallen.

Hat damit also nix zu tun.

>Wird die Einstellung evtl. von einer Gruppenrichtlinie überschrieben?

Nein.

Ist auch nur mit diesem neuen Patch so, wo der Rechner runter gefahren wird und dann 5 Updates beim runterfahren installiert werden. Mir scheint als werden die einem aufgezwungen.

Hallo.

Wie kann es sein, dass die automatischen Updates von Windows XP Professional automatisch starten, obwohl der Knopf "Benachrichtigen, aber nicht automatisch downloaden und installieren" gesetzt ist? Wird einfach ignoriert.

Bei ner Workstation ist das ja noch nicht ganz so gravierend aber beim Server....

Hat M$ da schon wieder was kaputt gepatcht?

Hallo.

Bei meinem Exchange-Testserver kann ich nur Universal-Gruppen anlegen, wenn ich auf Verteiler klicke. Sicherheit kann ich bei Universal im AD nicht auswählen, dabei läuft Exchange 2003 im Einheitlichen Modus. Woran kann das liegen?

Hey wow, das ist ja genau wonach ich gesucht habe. Vielen herzlichen Dank :p ;) :)

Hallo.

Ich möchte auf einem Exchange-Server zwei unterschiedliche Domains (erste-domain.de und zweite-domain.de) verwalten. Außerdem sollen die Mailuser von erste-domain.de auch nur alle anderen im Outlook sehen, die auch zu erste-domain.de gehören. Mit zweiter-Domain genauso.

Wie realisiert man sowas? Über OU's? Gruppenrichtlinien? Ich suche schon seit Tagen aber finde dazu irgendwie nichts.

Die Konsistenzüberprüfung (KCC) hat ermittelt, dass fortlaufende Versuche, eine Replikationsverbindung mit dem folgenden Domänencontroller herzustellen, immer wieder fehlgeschlagen sind.

 

Versuche:

1579

Domänencontroller:

CN=NTDS Settings,CN=Northwood,CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=einedomain,DC=net

Zeitraum (Minuten):

94591

 

Das Verbindungsobjekt für diesen Domänencontroller wird ignoriert, und eine neue temporäre Verbindung wird hergestellt, damit die Replikation fortgesetzt werden kann. Die temporäre Verbindung wird entfernt, sobald die Replikation mit diesem Domänencontroller wieder aufgenommen wird.

 

Zusätzliche Daten

Fehlerwert:

1256 Der Remotecomputer ist nicht verfügbar. Weitere Informationen zur Behebung von Netzwerkproblemen finden Sie in der Windows-Hilfe.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Ich möchte den alten DC auch eigentlich nicht wieder anschalten. Das einzige wo ich ihn derzeit noch drin sehe ist unter "Active Directory-Benutzer und -Computer". Dort unter "Domain Controllers". Ich habe da die Option auf löschen zu drücken, weiss aber ehrlich gesagt nicht ob das richtig/ok wäre und wie die Konsequenzen aussehen würden. Die Tombstone-Zeit ist zwar noch nicht erreicht aber so langsam wird die Zeit doch knapp und ich würde das ganze jetzt gerne abschließen. Hat jemand ein paar Tips wie es weiter geht, bzw. was ich nun machen sollte? Bin leider auch ins kalte Wasser geschmissen worden, was diesen Kram angeht und kämpfe mich da tapfer durch. ;)

(Ist nicht toll aber ich kann's nicht ändern)

Hi Leute,

ich habe mal eine kleine Frage:

Vor ein paar Wochen habe ich eine Exchange 2003 Migration samt AD auf einen neuen Server (neue Hardware) gemacht. Lief auch soweit problemlos ab und läuft derzeit alles auch. Der neue Server hat alle Roles die er braucht, etc.

Nur den alten habe ich zwar abgeschaltet aber noch nicht aus dem AD entfernt. Deswegen meckert mein Event-Log auch jeden Tag fröhlich und erinnert mich daran, dass noch Arbeit zu tun ist :D

Avalon für c:\windows\sysvol\domain mit DNS-Namen Northwood.einedomain.de nicht aktivieren. Es wird ein neuer Versuch gestartet.

Mögliche Ursachen für diese Warnung sind:

 

[1] Der DNS-Name Northwood.einedomain.de von diesem Computer konnte nicht ausgewertet werden.

[2] Der Dateireplikationsdienst wird auf Northwood.einedomain.de nicht ausgeführt.

[3] Die Topologieinformationen im Active Directory dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert.

 

Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

Active Directory konnte den folgenden DNS-Hostnamen des Quelldomänencontrollers nicht zu einer IP-Adresse auflösen. Dieser Fehler verhindert die Replizierung von von Hinzufüge- bzw. Löschvorgängen oder Änderungen im Active Directory zwischen einen oder mehreren Domänencontrollern in der Gesamtstruktur. Sicherheitsgruppen, die Gruppenrichtlinie, Benutzer und Computer und deren Kennwörter werden dadurch inkonsistent zwischen den Domänencontrollern, solange dieser Fehler nicht behoben wird. Eventuell wird auch die Anmeldungsauthentifizierung bzw. der Zugriff auf Netzwerkressourcen, beeinflusst.

 

Quelldomänencontroller:

Northwood

Fehlgeschlagener DNS-Hostname:

83fd6430-2f89-4ec1-8cb6-0c58331e7077._msdcs.einedomain.de

 

Anmerkung: Standardmäßig werden nur maximal 10 DNS-Fehler innerhalb eines Zeitraums von 12 Stunden angezeigt, auch wenn mehr als 10 Fehler aufgetreten sind. Setzen Sie den folgenden Registrierungswert auf 1, um alle individuellen Fehlerereignisse zu protokollieren:

 

Registrierungspfad:

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client

 

Benutzeraktion:

 

1) Wenn der Quelldomänencontroller nicht mehr funktioniert bzw. dessen Betriebssystem unter einem anderen Computernamen oder NTDSDSA-Objekt-GUID neu installiert wurde, entfernen Sie die Metadaten des Quelldomänencontrollers mit dem Programm NTDSUTIL.EXE entsprechend der im MSKB-Artikel 216498 dargelegten Schritte.

 

2) Bestätigen Sie, dass auf dem Quelldomänencontroller Active Directory ausgeführt wird, und dass auf diesen über das Netzwerk zugegriffen werden kann, indem Sie "NET VIEW \\<Quell-DC-Name>" oder "PING <Quell-DC-Name>" eingeben.

 

3) Stellen Sie sicher, dass der Quelldomänencontroller einen gültigen DNS-Server für die DNS-Dienste verwendet, und dass der Host- bzw. CNAME-Eintrag des Quelldomänencontrollers richtig registriert ist, indem Sie die für den DNS erweiterte Version von DCDIAG.EXE, verfügbar unter http://www.microsoft.com/dns, ausführen.

 

dcdiag /test:dns

 

4) Stellen Sie sicher, dass dieser Zieldomänencontroller einen gültigen DNS-Server für die DNS-Dienste verwendet, indem Sie die für den DNS erweiterte Version des Befehls DCDIAG.EXE folgendermaßen auf der Konsole ausführen:

 

dcdiag /test:dns

 

5) Weitere Informationen zur Analyse von DNS-Fehlern erhalten Sie unter KB 824449:

http://support.microsoft.com/?kbid=824449

 

Zusätzliche Daten

Fehlerwert:

11004 Der angeforderte Name ist gültig, es wurden jedoch keine Daten des angeforderten Typs gefunden.

 

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.