Im Moment scheint das Alles etwas verworren - insbesondere versuchen wir gerade das Pferd von hinten aufzuzäumen.

Vergiss' bitte was ich über Virtualisierung gesagt habe - das ist hier Overkill und mit der vorhandenen Hardware schlecht realisierbar.

... ok, jetzt nochmal ganz von vorne:

Du brauchst eine komplette NTDS-Infrastruktur mit Exchange und ISA.
Zu bedienen sind 15-20 Postfächer und (angenommen) ebenfalls Clients in dieser Größenordnung.

Normalerweise würde ich dafür 4 kostengünstige exakt gleiche P4-Maschinchen (i875, Raptor-Raid1 an ICH5R, CSA-NIC) nehmen:
PDC, BDC, Mail und ISA.
Falls PDC ausfällt, wird der BDC zum Betriebsmaster gemacht.
Falls BDC ausfällt, reparieren und wieder reinstecken.
Falls Mail oder ISA ausfallen, wir der BDC zurückgestuft und die Platten umgesteckt (MTTR ca. 10 Minuten).

Hier soll aber vorhandene Hardware verbaut werden.

Ich habe mich gerade nochmal schlau gemacht: ES-2003 sollte klaglos auf einem Win2k3-DC laufen.
Mit den Vorgängerversionen war das alles andere als einfach.

Also:
ISA & RAS kommt auf den P3.
NTDS, DNS, DHCP, WINS, IIS und Exchange landen auf dem Xeon.

Installationsreihenfolge in ganz groben Zügen:
1. XEON:
Win2k3
DNS, kein Stammserver! (dafür brauchst Du mal kurz einen funktionierendes Internet und einen externen DNS - sonst gibt's Handarbeit)
AD/NTDS (NICHT den Assistenten nehmen)
DNS auf AD-integriert umstellen.
- Alle notwendigen NTDS-Einstellungen vornehmen (Betriebsmaster/GC, Standorte, Subnetze, GPOs usw.) und ausgiebig testen (dcdiag).
DHCP - und diesen in AD authorisieren
WINS - ggf. Wins und WinsR Lookup im DNS einstellen
- nochmal ausgiebig mit dcdiag und netdiag testen und alle Fehler ausmerzen.
IIS
Deine Zertifikatsstelle hatten wir ganz vergessen - die könntest Du hier jetzt einrichten.
Forrestprep
Domainprep
ES2k3EE

2.P3
Win2k3
zur Domäne hinzufügen und 2! mal booten.
ISA installieren

- Jetzt bleibt nur noch der ganze Kleinkram ...
DHCP-Optionen (statische Routen nicht vergessen)
NTP-Server
Proxy-Einstellungen (das kommt in die GPO)

- zum Schluß den ES ausgiebig mit MS-BPA quälen.

Noch ein paar Bemerkungen:
Bei obigen Vorgängen ist Ruhe und Geduld recht hilfreich - besser mal eine Kaffe trinken.
Bei groben Änderungen (z.B. am Katalog) kann es ein paar Minuten dauern, bis sich NTDS wieder beruhigt hat.

Win2k3 und ES2k3 müssen die gleichen PatchLevel (ServicePacks) haben - ich habe da zuerst recht lange nach "merkwürdigen" Fehlern gesucht, bis mir das auffiel.

Falls Du Wartungsdienste (z.B. ES-Backup) mit einem lokalen User-Account laufen lässt, gibt's gerne mal Fehlermeldungen wegen gesperrter Dateien (Registry bzw. Profil) - das ist zwar nicht gefährlich aber auch nicht besonders schön.
Mit UPHclean (User Profile Hive CleanUp) sind auch die Fehlermeldungen weg.

mfg, Thomas

Zitat von »aqua--modder«

Nur rein aus Neugierde: was ist so schlimm an dem Assistenten vom DNS-server?

Nicht der Assistent vom DNS ist gemeint (gibt's da überhaupt einen?), sondern der Assistent zur Einrichtung des Domänencontrollers bzw. der Domäne.

Ich verwende das Ding schon lange nicht mehr, daher kann ich mich auch nur noch teilweise an den Murks erinnern, den er unter 2000 verbrochen hat:
1. Es werden ungefragt irgendwelche Adressräume (iirc eines der 10.x  Netze) vergeben.
2. Der DNS wird als Stammserver (AD-integriert) für obiges Netz eingerichtet.

Bis das alles für Dein Netzwerk zurechtgebogen ist, vergehen einige Stunden - in dieser Zeit hat man das dreimal selber gemacht.

mfg, Thomas

Edit: (danke Leif - das hatte ich echt überlesen)

Zitat

Also intern erstelle ich dann die Domäne intern.meinedomäne.net, wenn ich das richtig verstanden habe.

nimm bitte "meinedomain.local"

In irgendeiner RFC (die ich jetzt natürlich gerade nicht finde) stehen die empfohlenen Domänen-Namen für interne Netze drinnen.

Zitat

Muss ich dann eine Forward und Reverse Lookupzone erstellen, oder reicht nur eine Forwardzone? Das, mit dem DNS ist ein wenig unklar.

Du mußt nur eine Forward-Lookup-Zone haben - für kleine Netze reicht das auch.
Die Reverse-Zone tut allerdings nicht weh und ist für ein einzelnes Subnetz auch schnell eingetippt.

mfg, Thomas

Zitat von »aqua--modder«

intern.meinedomäne.net

auch wenn mich tom jetzt hauen wird
aber du koenntest auch meinedomaene.loc nehmen
wird gerne gemacht falls du naemlich sonst irgendwann mal ne hp haben moechtest auf intern.meinedomaene.net wirst du naemlich routing probs bekommen und musst dann wieder zwischen intern und extern unterscheiden (am einfachsten mit nem virt. rechner namens www)

Zitat von »aqua--modder«

so, das Netz heisst jetzt meinedomain.local.
Soweit funktioniert auch alles.

Sehr schön.

Zitat

Habe Exchange auch schon "mitgeteilt", dass dieser die smtp-adresse "meindomain.net" nutzen soll.

Wo/wie hast Du ihm das denn mitgeteilt?
BTW: Grundregel Nr.1 aller ES-Installationen: "Du sollst niemals am virtuellen Standardserver für SMTP herumschrauben!"

Zitat

Das klappt auch alles, jedoch weigert sich der exchange jetzt zu senden. empfangen geht. Die Mails bleiben alle in der Warteschleife hängen

Wenn Du empfangen kannst, dann sind die Empfänger-Richtlinien soweit mal ok, und der SMTP-Connector läuft offensichtlich auch.

Jetzt gibt's noch zwei Möglichkeiten wo das stecken bleibt:
1. Der SMTP-Connector "versteht" sich nicht mit Deinem Provider (falls Du relay'st). Dazu solltest mal den BPA bemühen und die Logs studieren.
2. Das Zeug geht garnicht erst raus.
Wie hast Du das denn jetzt bei dem ISA eingerichtet? Eine Route (besser) oder zwei Serverregeln (umständlich)?
Auch hier hilft die Überwachung - einfach mal kurz eine Regel machen (Quell-IP = Mailserver) und Log begutachten.

... und immer wieder netdiag und BPA laufen lassen.
Sobald da etwas angemeckert wird, diesem Fehler auf den Grund gehen und ausmerzen.

mfg, Thomas

Edit: Das hatte ich ganz vergessen: Hier findest Du die Exchange-FAQ aus dem UseNet - da stehen viele nützliche Dinge drinnen und die häufigsten Fehler werden auch behandelt.

Zitat von »aqua--modder«

empfängerrichtlinien\default policy:

an default-policies sollte man nicht herumbasteln - die sind ganz gut so, wie sie sind.
Generell sollte man zusätzliche Policies erstellen und diesen - je nach Standort / Subnetz / Benutzergruppe entweder Vorrang geben, oder in der Evaluierungsreihenfolge nach hinten stellen.
Das gilt für alle Stellen wo es Policies gibt - also ganz besonders auch für GPOs.

Zitat

- SMTP-Adresse hinzugefügt
- diese als "@meinedomain.net" benannt
- aktivieren von "Diese Exchange-Organisatiom ist für die gesamte E-Mail-Übermittlung an diese Emailadresse verantwortlich"
- diese als Hauptadresse ausgewählt

soweit mal ok

Zitat

- bei "@meinedomain.intern":
- deaktivieren von: "Diese Exchange-Organisatiom ist für die gesamte E-Mail-Übermittlung an diese Emailadresse verantwortlich"

Warum?

Zitat

- deaktivieren vom Häckchen vor "meinedomäne.local"

Damit beseitigst Du alle (automatisch angelegten) Adressen in der NTDS-Domäne (Stichwort: Globale Adressliste).

Zitat

Danach habe ich den SMTP-connector auf "meinedomain.net" gesetzt

Jetzt kommt der spannende Teil ...
Welchen Connector hast Du wohin "gesetzt"?

Zitat

Das Zustellen auf "benutzername@meinedomain.net" hat danach funktioniert

im ISA ist eine Serververöffentlichung für den SMTP-server gesetzt, der extern lauscht und an den Exchange die Anforderungen sendet.

Eben - in diese Richtung funktionierts ja bereits.
... und wo ist die Gegenrichtung?

Zitat

zusätzlich ist eine Zugriffsregel gesetzt von exchange nach extern über DNS-Protokoll.

Grmpf.
Nachdem Dein Exchange auf dem Domaincontroller läuft, sollte dieser Rechner schon längst über alle DNS-Informationen verfügen.

Zitat

In der Warteschlange steht "Der Remoteserver hat auf einen Verbindungsversuch nicht reagiert"

Welcher Remote-Server?
... das hatte ich schon mal gefragt: Relay über Deinen Provider - ja, oder nein?

Zitat

P.s: habe in ein paar foren gelesen, man soll die default policy nicht angreifen, sondern eine neue SMTP-adresse einrichten. könnte das hinhauen?

siehe oben.
Das sind aber nur "kosmetische" Unterschiede.
Wenn man nur ein kleines Domänchen mit 3 Rechnern hat, kann man auch in den Defaults herumtippen.

mfg, Thomas

Zitat von »aqua--modder«

... Ich habe heute den wahren Schuldigen gefunden!!!
Es ist der verdammte ISA-SErver

Jaja, der ISA und seine Zicken - ich fühle mit Dir.
Ich hab' mir gerade gestern auch wieder mal die Haare gerauft.

Zitat

habe folgende Einstellungen für den ISA:

- SMTP-Server-Veröffentlichung auf Externe IP
- SMTP Regel von intern nach extern

Ist hierbei etwas falsch?

Das stimmt schon so .... allerdings (ich nehme an, da liegt der Hund begraben):
Der ISA hat eine etwas gewöhnungsbedürftige (sehr strikte) Abarbeitung der Firewall-Regeln.
Behalte einfach im Geiste die Grundregel: "Drop hat Vorrang".
Wenn das SMTP-Packet aufgrund einer früheren (in der Evaluierungsreihenfolge weiter vorne) Regel bereits gesperrt wurde, kann das durch eine spätere Regel nicht mehr aufgehoben werden.
D.h. wenn Du bereits eine "Internet-Zugriffs-Regel (i.d.R. Standardregel #1) definiert hast, die HTTP/FTP/DNS usw. für "intern" nach "Extern" erlaubt, muß das SMTP-Protokoll hier mit hinein.

Zitat

Ich habe hin und wieder mal Hinweise gefunden, dass der ISA den Exchange als Secure NAT client behandeln muss.

Ich halte nicht sehr viel von den diversen MS-Sicherheits-Extensions, da das ohne hochverfügbare Authentifizierungsstellen eine sehr wackelige Angelegenheit wird.
Wenn z.B. der Kerberos auch nur mal kurz zickt, fliegen sofort reihenweise Services auf die Schnauze - dafür reicht dann schon der Reboot eines DCs nach einem MS-PatchDay.
Wenn Du dafür sorgst, daß Dein LAN "vertrauenswürdig" ist, sind diese Maßnahmen auch ziemlich überflüssig.

BTW: In einem vertrauenswürdigen LAN kannst Du ggf. auch die SMB-Verschlüsselung (GPO) abstellen.

mfg, Thomas