Standortreplikation über S2S die 2te

[Marc]

Hallo,

ich schon wieder. Nach wie vor kämpfe ich mit dem Problem, dass ich die
Replikation eines angedachten DC's unter 2008 nicht hinbekomme.

Folgende Situation:
Ein Kunde hat eine neue Niederlassung eröffnet, welche durch 2 ISA 2006 per
S2S verunden sind. Hinter dem ISA in der neuen Niederlassung wollte ich einen
DC unter 2008 laufen lassen. Da habe ich wie gesagt das Problem, das die
Replikation nicht funktioniert, da es in den diversen Fehlermeldungen heißt,
dass der RPC Server nicht verfügbar ist.

Daraufhin habe ich zum testen den ISA selbst in der Niederlassung zum DC
gemacht, und nach Hilfestellung von Jens & Jens ;--) hat das dann auch
geklappt. Der ISA repliziert sich nun ohne Probleme mit dem DC in der
Hauptstelle.
So möchte ich das aber nicht auf Dauer haben.

Die Fehlermeldungen am 2008er Server deuten immer auf Probleme mit dem RPC
Protokoll hin. An beiden ISA's habe ich den gesamten Verkehr durch den VPN
Tunnel offen, auch an der Richtlinie selbst habe ich beim RPC Protokoll das
strikte RPC deaktiviert (an beiden ISA's).
Wenn ich am DC den Replikationsdienst neu durchsarte und am ISA in der
Niederlassung eine Protokollierung mitlaufen lasse, sehe ich dass die RPC
Anfrage auf die IP des DC in der Haupstelle verweigert wird. Bei der
Verweigerung steht aber keine Regel von der das verweigert wird. Bei DNS ist
es genauso. An der Systemrichtlinie 1 (Active Directory??) habe ich das
Netzwerk des VPN Tunnels mal hinzugefügt. Hat auch nicht geändert. War
wahrscheinlich falsch was ich versucht habe.

Ich verstehe einfach nicht, warum die DNS und RPC Anfragen an den Dc in der
Hauptstelle verweigert werden, obwohl der gesamte Datenverkehr am Tunnel
selbst und auch an den 2 Isa's jeweils Regeln erstellt wurden, die den
gesamten Datenverkehr durchlassen sollten.

Am 2008er Server ist die Firewall deaktviert, das hatte ich heute noch
nachgesehen.

Ich muss noch ergänzen, dass ich kein ISA Spezi bin und ich das Thema bei
uns übernehmen aufs Auge gedrückt bekommen habe, das ein Kollege von uns
ausgeschieden ist.

Habt Ihr da vielleicht noch eine Idee?

[Jens Baier]

Hi,

Post by Marc
ich schon wieder. Nach wie vor kämpfe ich mit dem Problem, dass ich die
Replikation eines angedachten DC's unter 2008 nicht hinbekomme.

hat das nicht schon funktioniert? Siehe anders Posting?

Post by Marc
Daraufhin habe ich zum testen den ISA selbst in der Niederlassung zum DC

oh no, why that?

Post by Marc
gemacht, und nach Hilfestellung von Jens & Jens ;--) hat das dann auch
geklappt. Der ISA repliziert sich nun ohne Probleme mit dem DC in der
Hauptstelle.
So möchte ich das aber nicht auf Dauer haben.

sehr gut!

Post by Marc
Die Fehlermeldungen am 2008er Server deuten immer auf Probleme mit dem RPC
Protokoll hin. An beiden ISA's habe ich den gesamten Verkehr durch den VPN
Tunnel offen, auch an der Richtlinie selbst habe ich beim RPC Protokoll das
strikte RPC deaktiviert (an beiden ISA's).

OK

Post by Marc
Wenn ich am DC den Replikationsdienst neu durchsarte und am ISA in der
Niederlassung eine Protokollierung mitlaufen lasse, sehe ich dass die RPC
Anfrage auf die IP des DC in der Haupstelle verweigert wird. Bei der
Verweigerung steht aber keine Regel von der das verweigert wird. Bei DNS ist
es genauso.

wenn keine regel protokolliert wird, ist es in der Regel ein routiung /
Netzwerkproblem unterhalb ISA Server oder wegen fehlender / nicht richtiger
Netzwerkregeln am ISA

Post by Marc
Ich verstehe einfach nicht, warum die DNS und RPC Anfragen an den Dc in der
Hauptstelle verweigert werden, obwohl der gesamte Datenverkehr am Tunnel
selbst und auch an den 2 Isa's jeweils Regeln erstellt wurden, die den
gesamten Datenverkehr durchlassen sollten.

ich denke, Du wirst wohl mal die gesamte Konfig posten muessten oder
Dumuesstes jemanden beauftragen, der da mal vor ort oder remote drauf guckt.
Kann nur ne Kleinigkeit sein

[Marc]

Hi Jens,

es hat insoweit funktioniert, dass die Replikation am ISA (als DC) nach
eurem Tipp funktoniert hat. Leider nicht vom Server, den ich eigentlich als
DC haben möchte.
Das mit dem ISA als DC hatte ich auch nur zum testen gemacht. Soll nicht als
Dauerlösung sein.

Hm, dann werde ich mir wohl die Netzwerkregeln noch genauer anschauen.
Fragen oder beauftragen kann ich leider niemanden. Alle ISA Jungs sind nicht
mehr bei uns greifbar. Daher muss ich das nun mit meinem Halbwissen machen.

Post by Jens Baier
Hi,

Post by Marc
ich schon wieder. Nach wie vor kämpfe ich mit dem Problem, dass ich die
Replikation eines angedachten DC's unter 2008 nicht hinbekomme.

hat das nicht schon funktioniert? Siehe anders Posting?

Post by Marc
Daraufhin habe ich zum testen den ISA selbst in der Niederlassung zum DC

oh no, why that?

Post by Marc
gemacht, und nach Hilfestellung von Jens & Jens ;--) hat das dann auch
geklappt. Der ISA repliziert sich nun ohne Probleme mit dem DC in der
Hauptstelle.
So möchte ich das aber nicht auf Dauer haben.

sehr gut!

Post by Marc
Die Fehlermeldungen am 2008er Server deuten immer auf Probleme mit dem RPC
Protokoll hin. An beiden ISA's habe ich den gesamten Verkehr durch den VPN
Tunnel offen, auch an der Richtlinie selbst habe ich beim RPC Protokoll das
strikte RPC deaktiviert (an beiden ISA's).

OK

Post by Marc
Wenn ich am DC den Replikationsdienst neu durchsarte und am ISA in der
Niederlassung eine Protokollierung mitlaufen lasse, sehe ich dass die RPC
Anfrage auf die IP des DC in der Haupstelle verweigert wird. Bei der
Verweigerung steht aber keine Regel von der das verweigert wird. Bei DNS ist
es genauso.

wenn keine regel protokolliert wird, ist es in der Regel ein routiung /
Netzwerkproblem unterhalb ISA Server oder wegen fehlender / nicht richtiger
Netzwerkregeln am ISA

Post by Marc
Ich verstehe einfach nicht, warum die DNS und RPC Anfragen an den Dc in der
Hauptstelle verweigert werden, obwohl der gesamte Datenverkehr am Tunnel
selbst und auch an den 2 Isa's jeweils Regeln erstellt wurden, die den
gesamten Datenverkehr durchlassen sollten.

ich denke, Du wirst wohl mal die gesamte Konfig posten muessten oder
Dumuesstes jemanden beauftragen, der da mal vor ort oder remote drauf guckt.
Kann nur ne Kleinigkeit sein
--
Gruss Jens
www.it-training-grote.de
www.forefront-tmg.de
https://mvp.support.microsoft.com/profile/Marc.Grote
http://blog.it-training-grote.de
.

[Dieter Rauscher [MVP]]

Hallo Marc,

Post by Marc
es hat insoweit funktioniert, dass die Replikation am ISA (als DC) nach
eurem Tipp funktoniert hat. Leider nicht vom Server, den ich eigentlich als
DC haben möchte.
Das mit dem ISA als DC hatte ich auch nur zum testen gemacht. Soll nicht als
Dauerlösung sein.
Hm, dann werde ich mir wohl die Netzwerkregeln noch genauer anschauen.

Wie sieht die Definition des internen Netzwerkobjekts am ISA aus? Welche
IP-Adressen stehen da drin?
Welche IP und welches DefGW hat der DC? Jeweils für Haupt- und
Remotestandort bitte.
Hat der DC am Hauptstandort eine Route zur Aussenstelle? Können sich die DCs
gegenseitig pingen?

Viele Grüße
Dieter

[Marc]

Hallo,

die interne Netzwerkkarte ist wie folgt eingerichtet:

IP= 192.168.21.254
GW = keines
DNS primär = 192.168.21.1 (das ist die IP des DC der zur Zeit nicht
repliziert)
DNS sekundär = 192.168.21.254

Die DNS Einträge hatte ich auch schon getauscht.

Am 2008er Server der DC sein soll ist die Netzwerkkarte so eingerichtet:
IP=192.168.21.1
GW = 192.168.21.254
DNS primär = 192.168.21.1
DNS sekundär = 192.168.21.254
Der Server hat nur eine Lan Schnittstelle.

Ich kann von dem DC in der Niederlassung sämtliche Server in der Hauptstelle
per Namen anpingen. Das funktioniert ,auch in der anderen Richtung.Auch
nslookup am DC gibt keine Fehler aus.
Das pingen auf die Servernamen klappt von jedem Server aus der Niederlassung
zu Hauptstelle.
Die S2S Verbindung habe ich wiedererwarten ohne große Probleme hinbekommen
*stolz* :--). Da habe ich mich an Ihr Buch gehalten.

Daher verstehe ich nicht, warum der DC in der Hauptstelle eine Route zu der
Niederlassung braucht? Die beiden ISA's haben eine Netzwerkregel "Route" vom
jeweils internen Netzwerk zum Netzwerk was den VPN Tunnel darstellt.

Habe ich da etwas falsch verstanden?

Post by Dieter Rauscher [MVP]
Hallo Marc,

Post by Marc
es hat insoweit funktioniert, dass die Replikation am ISA (als DC) nach
eurem Tipp funktoniert hat. Leider nicht vom Server, den ich eigentlich als
DC haben möchte.
Das mit dem ISA als DC hatte ich auch nur zum testen gemacht. Soll nicht als
Dauerlösung sein.
Hm, dann werde ich mir wohl die Netzwerkregeln noch genauer anschauen.

Wie sieht die Definition des internen Netzwerkobjekts am ISA aus? Welche
IP-Adressen stehen da drin?
Welche IP und welches DefGW hat der DC? Jeweils für Haupt- und
Remotestandort bitte.
Hat der DC am Hauptstandort eine Route zur Aussenstelle? Können sich die DCs
gegenseitig pingen?
Viele Grüße
Dieter
--
Dieter Rauscher
MVP Forefront
Website: http://www.msisafaq.de
Blog: http://msmvps.com/rauscher/
Buch: http://www.msisafaq.de/buch/
.

[Maximilian von Zweydorff]

Hallo Marc,

Post by Marc
Hallo,
IP= 192.168.21.254
GW = keines
DNS primär = 192.168.21.1 (das ist die IP des DC der zur Zeit nicht
repliziert)
DNS sekundär = 192.168.21.254
Die DNS Einträge hatte ich auch schon getauscht.
IP=192.168.21.1
GW = 192.168.21.254
DNS primär = 192.168.21.1
DNS sekundär = 192.168.21.254
Der Server hat nur eine Lan Schnittstelle.

Die 192.168.21.254 (Dein ISA) brauch nirgendwo als DNS drin stehen.
Dafür hast Du ja Deinen DC. Da sollte DNS richtig konfiguriert
sein/werden. Was sagt denn Dein DC im EventLog bzgl. der Replikation?

Gruß
Max

[Marc]

Hallo,

im Log von vom Dateireplikationsdienst steht folgendes:

Der Dateireplikationsdienst kann die Replikation von SRV03-DC nach
ELS-SRV-DC für c:\windows\sysvol\domain mit DNS-Namen SRV03-DC.slr.de nicht
aktivieren. Es wird ein neuer Versuch gestartet.
Mögliche Ursachen für diese Warnung sind:

[1] Der DNS-Name SRV03-DC.slr.de von diesem Computer konnte nicht
ausgewertet werden.
[2] Der Dateireplikationsdienst wird auf SRV03-DC.slr.de nicht ausgeführt.
[3] Die Topologieinformationen in den Active Directory-Domänendiensten
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.

Im Log vom Verzeichnisdienst folgendes:

Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden
schreibbaren Verzeichnispartition.

Verzeichnispartition:
DC=slr,DC=de
Quellverzeichnisdienst:
CN=NTDS
Settings,CN=SRV03-DC,CN=Servers,CN=St-Leon-Rot,CN=Sites,CN=Configuration,DC=slr,DC=de
Adresse des Quellverzeichnisdienstes:
866c8db4-1927-467e-b625-2087f1b8bff0._msdcs.slr.de
Standortübergreifende Übertragung (falls vorhanden):
CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=slr,DC=de

Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst
replizieren, solange das Problem nicht behoben ist.

Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann
und ob eine Netzwerkverbindung besteht.

Zusätzliche Daten
Fehlerwert:
1722 Der RPC-Server ist nicht verfügbar.

und

Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition
festgestellt.

Verzeichnispartition:
CN=Configuration,DC=slr,DC=de

Es gibt für die Konsistenzprüfung nicht genügend
Standortskonnektivitätsinformationen, um eine umfassende
Gesamtstruktur-Replikationstopologie zu erstellen. Zudem besteht die
Möglichkeit, dass mindestens ein Verzeichnisserver mit dieser
Verzeichnispartition nicht in der Lage war, die
Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an
nicht zugreifbaren Verzeichnisservern.

Benutzeraktion
Führen Sie einen der folgenden Schritte aus:
- Veröffentlichen Sie genügend Informationen über Standortkonnektivität,
sodass die Konsistenzprüfung eine Route ermitteln kann, durch die die
Verzeichnispartition diesen Standort erreichen kann. Diese Option wird
empfohlen.
- Fügen Sie von einem Verzeichnisdienst mit derselben Verzeichnispartition
auf einem anderen Standort ein Verbindungsobjekt zu einem Verzeichnisdienst
mit der Verzeichnispartition an diesem Standort hinzu.

Wenn keine dieser beiden Tasks den Problemzustand behebt, überprüfen Sie die
bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht
zugreifbaren Verzeichnisserver identifizieren.

Was mir auch noch aufgefallen ist, ist wenn ich an dem DC in der
Niederlassung \\<DCHaupstelle>\Sysvol ausführe klappt das nicht, endet in
einem Fehler das auf das Verzeichnis nicht zugegriffen werden kann. Gehe ich
an den 3ten Server in der Niederlassung oder an den ISA und führe das aus,
komme ich sofort auf das Sysvol Verzeichnis des DC in der Hauptstelle.

An allen Servern in der Niederlassung habe ich den ISA als DNS
herausgenommen, und nur den DC als DNS eingetragen.

Warum ich von 2 Servern auf das SYSVOL des DC in der Hauptstelle komme und
von einem nicht hängt mir nun definitiv zu hoch. Die Firewall am DC habe ich
auch schon abgeschaltet, an der kann es nicht hängen. Wenn ih also von 2
Servern auf das SYSVOL zugreifen kann und von einem nicht, dann kann das doch
eigentlich nicht am ISA oder dessen Konfig hängen oder????

Post by Dieter Rauscher [MVP]
Hallo Marc,

Post by Marc
Hallo,
IP= 192.168.21.254
GW = keines
DNS primär = 192.168.21.1 (das ist die IP des DC der zur Zeit nicht
repliziert)
DNS sekundär = 192.168.21.254
Die DNS Einträge hatte ich auch schon getauscht.
IP=192.168.21.1
GW = 192.168.21.254
DNS primär = 192.168.21.1
DNS sekundär = 192.168.21.254
Der Server hat nur eine Lan Schnittstelle.

Die 192.168.21.254 (Dein ISA) brauch nirgendwo als DNS drin stehen.
Dafür hast Du ja Deinen DC. Da sollte DNS richtig konfiguriert
sein/werden. Was sagt denn Dein DC im EventLog bzgl. der Replikation?
Gruß
Max
.

[Maximilian von Zweydorff]

Servus Marc,

Post by Marc
Was mir auch noch aufgefallen ist, ist wenn ich an dem DC in der
Niederlassung \\<DCHaupstelle>\Sysvol ausführe klappt das nicht, endet in
einem Fehler das auf das Verzeichnis nicht zugegriffen werden kann. Gehe ich
an den 3ten Server in der Niederlassung oder an den ISA und führe das aus,
komme ich sofort auf das Sysvol Verzeichnis des DC in der Hauptstelle.
An allen Servern in der Niederlassung habe ich den ISA als DNS
herausgenommen, und nur den DC als DNS eingetragen.

Du Kannst noch jeweils den anderen DC als 2nd DNS hinzufügen.

Mach bitte einmal folgenden Tests:

1. Deaktiviere den RPC-Filter im RPC-Protokoll, falls es dann
funktioniert, mach Ihn wieder an und geh zu Schritt 2.

2. Was sind denn im ISA für NICs verbaut? Broadcom?
Auf jeden Fall die neuesten NIC-Treiber einspielen. Dann deaktiviere auf
dem Internal Interface in der Niederlassung "Receive Side Scaling" auf
der NIC. (Device Manager --> NIC --> Properties --> etc.)

Gruß
Max

[unknown]

hi marc,
ich war ein paar tage offline (fehlendes netzteil) und kann deshalb erst
jetzt reagieren. es gibt ja schon einige anregungen und antworten von den
geschätzten kollegen.

Post by Marc
Alle ISA Jungs sind nicht
mehr bei uns greifbar. Daher muss ich das nun mit meinem Halbwissen machen.

halb so wild, dem kann abgeholfen werden, hier erstmal ein empfehlenswerter
buchtipp:
http://www.msisafaq.de/Buch/2006/index.htm
darüber hinaus habe ich mir sagen lassen, das es recht kompetente trainer in
dem bereich isa/tmg geben soll, falls du sowas mal anstreben solltest.

[Marc]

Hallo Jens, hallo Maximilian,

erst mal danke für eure Mühen.
Jens, langfrisitig gesehen strebe ich natürlich eine Schulung im Bereich
TMG/ISA an, gearde da es ja scheinbar in Zukunft eines meiner Themen sein
soll. Literatur habe ich mir schon besorgt, das ISA Server 2006 Buch aus der
Microsoft Press von Herrn Rauscher. Da habe ich mich auch sehr daran
gehalten, als ich die S2S Verbindung eingerichtet habe. Sonst hätte das eh
nie hinbekommen.

Aber zurück zum Problem:
Ich habe den RPC Filter nun mal deaktiviert und noch das SP1 für den ISA
2006 nachgezogen. Hat leider was das Problem angeht nichts gebracht.
Was ich aber nun gemacht habe: Mit PortQuery (ein Tool von MS) habe ich mir
die Domains und Trusts prüfen lassen. Hier das Ergebnis:

=============================================

Starting portqry.exe -n 192.168.11.10 -e 135 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 135 (epmap service): FILTERED
portqry.exe -n 192.168.11.10 -e 135 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 389 -p BOTH ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 389 (ldap service): FILTERED

UDP port 389 (unknown service): LISTENING or FILTERED

Using ephemeral source port
Sending LDAP query to UDP port 389...

LDAP query response:


currentdate: 11/26/2009 20:17:34 (unadjusted GMT)
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=slr,DC=de
dsServiceName: CN=NTDS
Settings,CN=SRV03-DC,CN=Servers,CN=St-Leon-Rot,CN=Sites,CN=Configuration,DC=slr,DC=de
namingContexts: DC=slr,DC=de
defaultNamingContext: DC=slr,DC=de
schemaNamingContext: CN=Schema,CN=Configuration,DC=slr,DC=de
configurationNamingContext: CN=Configuration,DC=slr,DC=de
rootDomainNamingContext: DC=slr,DC=de
supportedControl: 1.2.840.113556.1.4.319
supportedLDAPVersion: 3
supportedLDAPPolicies: MaxPoolThreads
highestCommittedUSN: 2470403
supportedSASLMechanisms: GSSAPI
dnsHostName: SRV03-DC.slr.de
ldapServiceName: slr.de:srv03-dc$@SLR.DE
serverName:
CN=SRV03-DC,CN=Servers,CN=St-Leon-Rot,CN=Sites,CN=Configuration,DC=slr,DC=de
supportedCapabilities: 1.2.840.113556.1.4.800
isSynchronized: TRUE
isGlobalCatalogReady: TRUE
domainFunctionality: 2
forestFunctionality: 2
domainControllerFunctionality: 2


======== End of LDAP query response ========

UDP port 389 is LISTENING

portqry.exe -n 192.168.11.10 -e 389 -p BOTH exits with return code 0x00000000.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 636 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 636 (ldaps service): FILTERED
portqry.exe -n 192.168.11.10 -e 636 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 3268 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 3268 (msft-gc service): FILTERED
portqry.exe -n 192.168.11.10 -e 3268 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 3269 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 3269 (msft-gc-ssl service): FILTERED
portqry.exe -n 192.168.11.10 -e 3269 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 53 -p BOTH ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 53 (domain service): FILTERED

UDP port 53 (domain service): LISTENING
portqry.exe -n 192.168.11.10 -e 53 -p BOTH exits with return code 0x00000000.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 88 -p BOTH ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 88 (kerberos service): FILTERED

UDP port 88 (kerberos service): LISTENING or FILTERED
portqry.exe -n 192.168.11.10 -e 88 -p BOTH exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 445 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 445 (microsoft-ds service): FILTERED
portqry.exe -n 192.168.11.10 -e 445 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 137 -p UDP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

UDP port 137 (netbios-ns service): LISTENING or FILTERED

Using ephemeral source port
Attempting NETBIOS adapter status query to UDP port 137...

Server's response: MAC address 0015c5fa5684
UDP port: LISTENING
portqry.exe -n 192.168.11.10 -e 137 -p UDP exits with return code 0x00000000.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 138 -p UDP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

UDP port 138 (netbios-dgm service): LISTENING or FILTERED
portqry.exe -n 192.168.11.10 -e 138 -p UDP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 139 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 139 (netbios-ssn service): FILTERED
portqry.exe -n 192.168.11.10 -e 139 -p TCP exits with return code 0x00000002.
=============================================

Starting portqry.exe -n 192.168.11.10 -e 42 -p TCP ...


Querying target system called:

192.168.11.10

Attempting to resolve IP address to a name...


IP address resolved to srv03-dc.slr.de

querying...

TCP port 42 (nameserver service): FILTERED
portqry.exe -n 192.168.11.10 -e 42 -p TCP exits with return code 0x00000002.

Wie man hier sieht, werden nach wie vor die Ports 135, 138, 139 gefiltert.
Nur weiß ich nicht warum. Am ISA sehe, ich wenn ich eine Protokollierung
mitlaufen lassen, das der Port 135 verweigert wird. Es wundert mich nur, dass
da kein Name der Regel steht, die die Kommunikation über 135 blockt. Ich sehe
nur Port 135 und verweigerte Verbindung.
Aber warum???????

Ich steh im Wald.

Post by unknown
hi marc,
ich war ein paar tage offline (fehlendes netzteil) und kann deshalb erst
jetzt reagieren. es gibt ja schon einige anregungen und antworten von den
geschätzten kollegen.

Post by Marc
Alle ISA Jungs sind nicht
mehr bei uns greifbar. Daher muss ich das nun mit meinem Halbwissen machen.

halb so wild, dem kann abgeholfen werden, hier erstmal ein empfehlenswerter
http://www.msisafaq.de/Buch/2006/index.htm
darüber hinaus habe ich mir sagen lassen, das es recht kompetente trainer in
dem bereich isa/tmg geben soll, falls du sowas mal anstreben solltest.
--
gruss, jens mander...
www.aixperts.de
www.forefront-tmg.de
www.hentrup.net
|<-|
.

[unknown]

huhu marc,

Post by Marc
Literatur habe ich mir schon besorgt, das ISA Server 2006 Buch aus der
Microsoft Press von Herrn Rauscher. Da habe ich mich auch sehr daran
gehalten, als ich die S2S Verbindung eingerichtet habe. Sonst hätte das eh
nie hinbekommen.

jau, kamma uneingeschränkt empfehlen. wir hoffen alle auf ein passendes werk
zu tmg von den herren. ;-)

Post by Marc
Wie man hier sieht, werden nach wie vor die Ports 135, 138, 139 gefiltert.
Nur weiß ich nicht warum. Am ISA sehe, ich wenn ich eine Protokollierung
mitlaufen lassen, das der Port 135 verweigert wird. Es wundert mich nur, dass
da kein Name der Regel steht, die die Kommunikation über 135 blockt. Ich sehe
nur Port 135 und verweigerte Verbindung.
Aber warum???????

hast du mal die diagnoseprotokollierung zu deiner problematik
dazugeschaltet. dort sollte dir angezeigt werden, welche regel wann wie und
wo gezogen hat
(http://www.isaserver.org/tutorials/ISA-Server-2006-Service-Pack1-New-features-enhancements.html)?!

Post by Marc
Ich steh im Wald.

green it? ;-)

[Marc]

Hi Jens, hi Maximilian,

Jens, das mit der Diagnoseprotokollierung war mir neu, danke für den Hinweis.
Was ich nun gemacht habe:

Ich habe eine Datenverkehrssimulation gemacht. Als Quelle habe ich den Dc in
der Niederlassung mit dem 135, 137 und 139 angegeben. Als Ziel habe ich den
DC in der Hauptstelle angegeben. Das Ergebnis war, das der Datenverkeher mir
als Zugelassen ausgegeben wird.
Hier habe ich mal das Protokoll der Simulation. Werdet Ih daraus schlau?

27.11.2009 11:27:46 fffcb872 Firewall service Der Firewalldienst führt die
Regelauswertung aus.
2 27.11.2009 11:27:46 fffcb872 Firewall service Protokoll: NULL
3 27.11.2009 11:27:46 fffcb872 Firewall Engine Paketeigenschaften:
Quell-IP-Adresse: 192.168.21.1 Quellarraynetzwerk: Intern Ziel-IP-Adresse:
192.168.11.10 Zielarraynetzwerk: SLR_to_ELS
4 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft nur Regeln,
die dem Protokoll NULL zugeordnet sind.
5 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "[System] MS-Firewallsteuerung-Kommunikation mit ausgewählten Computern
zulassen".
6 27.11.2009 11:27:46 fffcb872 Firewall service Der Quellport stimmt nicht
mit der Regel überein.
7 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "Von St.Leon alles auf".
8 27.11.2009 11:27:46 fffcb872 Firewall service source stimmt nicht mit dem
Paket überein.
9 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "Nach St.Leon Rot alles auf".
10 27.11.2009 11:27:46 fffcb872 Firewall service Die Regel "Nach St.Leon Rot
alles auf" stimmt mit dem Paket überein. Das Paket wird zugelassen.
11 27.11.2009 11:27:46 fffcb872 Firewall service Das Paket wurde von der
Regel "Nach St.Leon Rot alles auf" zugelassen.
12 27.11.2009 11:27:46 fffcb872 Firewall service Der Firewalldienst führt
die Regelauswertung aus.
13 27.11.2009 11:27:46 fffcb872 Firewall Engine Paketeigenschaften:
Quell-IP-Adresse: 192.168.21.1 Quellarraynetzwerk: Intern Ziel-IP-Adresse:
192.168.11.10 Zielarraynetzwerk: SLR_to_ELS
14 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server sucht nach einer
anwendbaren Netzwerkregel.
15 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Lokaler Hostzugriff".
16 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
17 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Lokaler Hostzugriff".
18 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
19 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "VPN-Clients zum internen Netzwerk".
20 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
21 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "VPN-Clients zum internen Netzwerk".
22 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
23 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Internetzugriff".
24 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
25 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Internetzugriff".
26 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
27 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Intern ELS nach Alcatel".
28 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
29 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Intern ELS nach Alcatel".
30 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
31 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "TK ELS nach St.Leon Rot ".
32 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
33 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "TK ELS nach St.Leon Rot ".
34 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
35 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "SLR_to_ELS an internes Netzwerk".
36 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
37 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "SLR_to_ELS an internes Netzwerk".
38 27.11.2009 11:27:46 fffcb872 Firewall service Quelle und Ziel des Pakets
stimmen mit Quelle und Ziel der Netzwerkregel "SLR_to_ELS an internes
Netzwerk" in umgekehrter Richtung überein.
39 27.11.2009 11:27:46 fffcb872 Firewall service Die Netzwerkregel
SLR_to_ELS an internes Netzwerk stimmt mit Quelle und Ziel überein. Ein
NAT-Verhältnis wurde angegeben.

Die Simualtion habe ich an beiden ISAs gemacht, bei beiden wird der
Datenverkehr als Zugelassen angegeben.
Maximilian, die Option die Du meinst habe ich nicht, da alle Server in der
Niederlassung virtualisiert sind.

Post by unknown
huhu marc,

Post by Marc
Literatur habe ich mir schon besorgt, das ISA Server 2006 Buch aus der
Microsoft Press von Herrn Rauscher. Da habe ich mich auch sehr daran
gehalten, als ich die S2S Verbindung eingerichtet habe. Sonst hätte das eh
nie hinbekommen.

jau, kamma uneingeschränkt empfehlen. wir hoffen alle auf ein passendes werk
zu tmg von den herren. ;-)

Post by Marc
Wie man hier sieht, werden nach wie vor die Ports 135, 138, 139 gefiltert.
Nur weiß ich nicht warum. Am ISA sehe, ich wenn ich eine Protokollierung
mitlaufen lassen, das der Port 135 verweigert wird. Es wundert mich nur, dass
da kein Name der Regel steht, die die Kommunikation über 135 blockt. Ich sehe
nur Port 135 und verweigerte Verbindung.
Aber warum???????

hast du mal die diagnoseprotokollierung zu deiner problematik
dazugeschaltet. dort sollte dir angezeigt werden, welche regel wann wie und
wo gezogen hat
(http://www.isaserver.org/tutorials/ISA-Server-2006-Service-Pack1-New-features-enhancements.html)?!

Post by Marc
Ich steh im Wald.

green it? ;-)
--
gruss, jens mander...
www.aixperts.de
www.forefront-tmg.de
www.hentrup.net
|<-|
.

[unknown]

hi marc,

Post by Marc
Ich habe eine Datenverkehrssimulation gemacht. Als Quelle habe ich den Dc in
der Niederlassung mit dem 135, 137 und 139 angegeben. Als Ziel habe ich den
DC in der Hauptstelle angegeben. Das Ergebnis war, das der Datenverkeher mir
als Zugelassen ausgegeben wird.

das klingt ja schonmal gut - versuche aber mal nicht den
datenverkehrssimmulator zu nehmen, sondern nur die diagnoseprotokollierung.
bei dem simmulator wird kein einziges bit verschickt. also die
diagnoseprotokollierung einschalten, dann den sync (der ja nicht funzt)
händisch anwerfen. nach dem fehler die diagnoseprotokollierung ausschalten
und nachschaun, wo welches regelwerk was geblockt hat.

Post by Marc
Maximilian, die Option die Du meinst habe ich nicht, da alle Server in der
Niederlassung virtualisiert sind.

das von max erwähnte rss ist (auch aus vms) raus, wenn du ein aktuelles
patchlvl hast (vom os). siehe dazu auch folgenden blogeintrag von uns
dieter:
http://msmvps.com/blogs/rauscher/archive/2007/03/28/windows-server-2003-service-pack-2-und-isa-server.aspx

[Maximilian von Zweydorff]

Servus Marc,

Post by Marc
Ich habe den RPC Filter nun mal deaktiviert und noch das SP1 für den ISA
2006 nachgezogen. Hat leider was das Problem angeht nichts gebracht.
Was ich aber nun gemacht habe: Mit PortQuery (ein Tool von MS) habe ich mir

Wie schauts bzgl. Deaktivierung "Receive Side Scaling" aus, hast Du es
schon getestet?

Gruß
Max

[Marc]

Hallo Jens, hallo Maximilian,

Jens, danke für den Hinweis mit der Datenverkehrsimulation und
Protokollierung. Das war mir neu.

Was ich jetzt gemacht habe:
vom ISA in der Niederlassung habe ich eine Simulation ausgeführt. Und zwar
habe ich von der Quell IP des DC in der Niederlassung an Port 135,137 und 139
an den DC in der Haupstelle mit den gleichen Ports mir den Datenverkehr
prüfen lassen. Und das jeweils an beiden ISA's (mit entsprechenden
Einstellungen). An beiden ISA's wird der Datenverkehr vom DC in der
Niederlassung zum Dc in der Hauptstelle als "Zugelassen" ausgegeben.

Hier habe ich mal das Diagnoseprotokoll des Tests:

1 27.11.2009 11:27:46 fffcb872 Firewall service Der Firewalldienst führt die
Regelauswertung aus.
2 27.11.2009 11:27:46 fffcb872 Firewall service Protokoll: NULL
3 27.11.2009 11:27:46 fffcb872 Firewall Engine Paketeigenschaften:
Quell-IP-Adresse: 192.168.21.1 Quellarraynetzwerk: Intern Ziel-IP-Adresse:
192.168.11.10 Zielarraynetzwerk: SLR_to_ELS
4 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft nur Regeln,
die dem Protokoll NULL zugeordnet sind.
5 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "[System] MS-Firewallsteuerung-Kommunikation mit ausgewählten Computern
zulassen".
6 27.11.2009 11:27:46 fffcb872 Firewall service Der Quellport stimmt nicht
mit der Regel überein.
7 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "Von St.Leon alles auf".
8 27.11.2009 11:27:46 fffcb872 Firewall service source stimmt nicht mit dem
Paket überein.
9 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Regel "Nach St.Leon Rot alles auf".
10 27.11.2009 11:27:46 fffcb872 Firewall service Die Regel "Nach St.Leon Rot
alles auf" stimmt mit dem Paket überein. Das Paket wird zugelassen.
11 27.11.2009 11:27:46 fffcb872 Firewall service Das Paket wurde von der
Regel "Nach St.Leon Rot alles auf" zugelassen.
12 27.11.2009 11:27:46 fffcb872 Firewall service Der Firewalldienst führt
die Regelauswertung aus.
13 27.11.2009 11:27:46 fffcb872 Firewall Engine Paketeigenschaften:
Quell-IP-Adresse: 192.168.21.1 Quellarraynetzwerk: Intern Ziel-IP-Adresse:
192.168.11.10 Zielarraynetzwerk: SLR_to_ELS
14 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server sucht nach einer
anwendbaren Netzwerkregel.
15 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Lokaler Hostzugriff".
16 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
17 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Lokaler Hostzugriff".
18 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
19 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "VPN-Clients zum internen Netzwerk".
20 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
21 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "VPN-Clients zum internen Netzwerk".
22 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
23 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Internetzugriff".
24 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
25 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Internetzugriff".
26 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
27 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "Intern ELS nach Alcatel".
28 27.11.2009 11:27:46 fffcb872 Firewall service Die Ziel-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
29 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "Intern ELS nach Alcatel".
30 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
31 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "TK ELS nach St.Leon Rot ".
32 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
33 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "TK ELS nach St.Leon Rot ".
34 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit dem in der Netzwerkregel angegebenen Ziel überein.
35 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server evaluiert die
Netzwerkregel "SLR_to_ELS an internes Netzwerk".
36 27.11.2009 11:27:46 fffcb872 Firewall service Die Quell-IP-Adresse im
Paket stimmt nicht mit der in der Netzwerkregel angegebenen Quelle überein.
37 27.11.2009 11:27:46 fffcb872 Firewall service ISA Server prüft die
umgekehrte Richtung der Netzwerkregel "SLR_to_ELS an internes Netzwerk".
38 27.11.2009 11:27:46 fffcb872 Firewall service Quelle und Ziel des Pakets
stimmen mit Quelle und Ziel der Netzwerkregel "SLR_to_ELS an internes
Netzwerk" in umgekehrter Richtung überein.
39 27.11.2009 11:27:46 fffcb872 Firewall service Die Netzwerkregel
SLR_to_ELS an internes Netzwerk stimmt mit Quelle und Ziel überein. Ein
NAT-Verhältnis wurde angegeben.
Datensatz Uhrzeit Kontext Protokollquelle Nachricht

Werdet Ihr daraus schlau?

Maximilian, die Option die Du mir genannt hats habe ich nicht, da sämtliche
Server virtualisiert sind.

Gruß
Marc

Post by Maximilian von Zweydorff
Servus Marc,

Post by Marc
Ich habe den RPC Filter nun mal deaktiviert und noch das SP1 für den ISA
2006 nachgezogen. Hat leider was das Problem angeht nichts gebracht.
Was ich aber nun gemacht habe: Mit PortQuery (ein Tool von MS) habe ich mir

Wie schauts bzgl. Deaktivierung "Receive Side Scaling" aus, hast Du es
schon getestet?
Gruß
Max
.