Jump to content

RAS/VPN Problem


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Na dann versuche ich einfach mal mein Glück.

 

DNS ist Voraussetzung für einen DC mit AD, darauf baut das AD ja auf. Es sei denn das einer bestehenden Domain ein zweiter DC hinzugefügt wird dann kann man bei Assistenten entscheiden Onkel DNS für den Server installiert werden soll oder man den vorhanden DNS den bestehenden Server nutzen möchte. So sind jedenfalls meine Erfahrungen

Link zu diesem Kommentar
Richtig.

Jeder DC im Netzwerk kann Benutzer verwalten.

Mir gefällt die Antwort nicht 100% :)

Schließlich kann jeder Memberserver & Client ebenfalls die Benutzer auf einen DC verwalten (über die Verwaltungstools - und greift darüber auf einen DC zu).

 

Ein DC ist ein Verzeichnisdienstserver - hier liegt eine Datenbank - Das Active Directory.

Hier gibt es nochmal verschiedene Rollen für die Funktionen, diese laufen meistens auf einem Server, können aber auch einmalig verteilt werden (Ausnahme globaler Katalog)

 

Grüße Admin

 

PS: Ein "Memberserver" verhält sich wie ein Client, er ist Mitglied dieser Domäne - ähnlich wie deine Workstation. Im Regelfall splittet man seine Dienste im Netz (Exchange, MSSQL, IIS usw) auf verschiedene Server - Mitgliedsserver. Macht ja kein Sinn das jedes System auch ein Domaincontroller ist :)

Link zu diesem Kommentar
Off-Topic:

DNS ist Voraussetzung für AD. Ein DNS Server muss aber nicht zwingend auf einem DC installiert werden.

Wir haben auch Kunden mit AD und DNS auf Linux Bind Servern.




Mir gefällt die Antwort nicht 100%.
Schließlich kann jeder Memberserver & Client ebenfalls die Benutzer auf einen DC verwalten (über die Verwaltungstools - und greift darüber auf einen DC zu).
Grüße Admin


Das Verwalten macht dann der Admin auf dem Memberserver / Client und nicht dieser selbst. Sunny meinte wohl das verwalten der AD Datenbank und nicht das bearbeiten der Benutzerkonten mit Verwalten.
Link zu diesem Kommentar
Mir gefällt die Antwort nicht 100% :)

Schließlich kann jeder Memberserver & Client ebenfalls die Benutzer auf einen DC verwalten (über die Verwaltungstools - und greift darüber auf einen DC zu).

 

Ich kann das Active Directory auf einem DC über die Verwaltungstools auf einem Memberserver verwalten. Wir wollen aber jetzt nicht Haare spalten, oder?

 

Im Regelfall splittet man seine Dienste im Netz (Exchange, MSSQL, IIS usw) auf verschiedene Server - Mitgliedsserver. Macht ja kein Sinn das jedes System auch ein Domaincontroller ist :)

 

Mit Ausnahme des SBS! :)

Link zu diesem Kommentar

Hm das mit Exchange auf einen Member Server ist nicht ganz richtig.

Sowie ich festgestellt habe lässt sich der Exchange 2007 sowie der 2010er nur auf DC's mit AD aufsetzen.

 

Ich hatte es anfangs mal versucht einen Exchange 2007 sp3 auf ein 2008R2 Client bzw. Wie ich jetzt weis Member Server, zu installieren doch das hat das Setup gleich bei der SystemUntersuchung

verweigert da der Server ein Client und somit kein AD besaß.

Link zu diesem Kommentar

Exchange 2010 System Requirements: Exchange 2010 Help

Installing Exchange 2010 on Directory Servers

 

For security and performance reasons, we recommend that you install Exchange 2010 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2010. After Exchange 2010 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.

Link zu diesem Kommentar

Ahja gut zu wissen, weil ich das noch nicht versucht habe.

Nur mich wundert es das der Exchange bei der installertion nach einen AD verlangt zumal ja auch AD in einigen Schritten für die Exchange installertion vorbereitet werden muss. Zumal ja auch während der Installertion und der Vorbereitung auch diverse Änderungen im AD vorgenommen werden.

 

Ich hatte mir ja nun, bevor ich die ganze Sache in Angriff genommen hatte, das Lehrmaterial von Video2Brain zum Thema Exchange und Win2008r2 sowie divers Fachliteratur reingezogen.

Worin ja fast immer die Basis ein DC mit AD war und von Member-Server nie die Rede war.

 

Wenn ich jetzt vom theoretisch gesehn, den Exchange auf einen Member-Server setze muss doch der Member-Server bestimmte Rechte bzw. Administrative Rechte besitzen um Änderungen im AD vornehmen zu können, weil im Grunde ist doch der Member-Server doch eigentlich nur ein Client. :confused:

 

Ich glaube so langsam zweifel ich an der Fachliteratur wenn ich das hier alles so lese. :rolleyes::rolleyes:

Link zu diesem Kommentar
Wenn ich jetzt vom theoretisch gesehn, den Exchange auf einen Member-Server setze muss doch der Member-Server bestimmte Rechte bzw. Administrative Rechte besitzen um Änderungen im AD vornehmen zu können, weil im Grunde ist doch der Member-Server doch eigentlich nur ein Client. :confused:

Im Fall von Exchange ist es der angemeldete Benutzer, der während der Installation und hinterher bei der Administration über die notwendigen Rechte im AD verfügen muss.

 

Ich glaube so langsam zweifel ich an der Fachliteratur wenn ich das hier alles so lese. :rolleyes::rolleyes:

Vielleicht war es auch nur ein etwas zu harter Einstieg gleich mit RRAS, Exchange und Hyper-V loszulegen. ;)

Fast jedes dieser Themem hat seine Besonderheiten und kleinen Fallstricke.

Link zu diesem Kommentar

Naja nen harter Einstig würde ich mal nicht sagen, eher ein ziehmlicher Unterschied zwischen Server 2003 und 2008r2

da ich ja vorher ein 2003er betrieben hab, der unteranderen Problemlos mit zwei NIC´s gearbeitet hat. Da gab es nicht das Problem das der DNS sich auf localhost umbenannt und seine IP änderte.

 

Zumal ich das ganze jetzt als Member-Server laufen hab und das ganze jetzt bei VPN Verbindung nicht mehr localhost bei DNS ausgibt sondern gleich UNKNOWN.

 

Ich hab bei mir im RAS drei Schnittstellen drin, einmal Intern, dann die LAN-Verbindung und eine Loopback die auch die 127.0.0.1 IP hat. Es scheint so als wenn bei VPN Einwahl immer auf die loopback IP gegangen wird, ich kanns mit irgendwie auch nicht erklären. Ich hab das ja nun genau nach der Anleitung gemacht.

Link zu diesem Kommentar

Hast Du den Workaround denn auch schon probiert?

As a workaround for this issue, you can configure the remote access connections to use a static pool of IP addresses that is on a different IP subnet than the local computers. In this case, local computers will not try to connect to the PPP adapter if it registers in DNS or WINS because the PPP adapter is on a different IP subnet.

 

To specify a static address pool in the Routing and Remote Access console, right-click ServerName, click Properties, click the IP tab, click Static address pool, and then click Add. Add a range that does not use the same IP subnet as the local computers. For example, if the local computers are using the 10.0.0.0 subnet, add a static pool that uses the 172.168.0.0 subnet. If the Routing and Remote Access server is running ISA Server 2000, you must add this subnet to the Local Address Table. This scenario is most common on Small Business Server 2000.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...