hades

Eine sehr merkwuerdige Argumentation. Normalerweise benoetigen nur Server feste IP-Adressen. Das sind idR weit weniger Systeme als Clients vorhanden sind. Bei Clients ist normalerweise kein Serverdienst drauf, der unbedingt mit einer festen IP-Adresse angesprochen werden muss. Und Du musst eh an die o.g. Programmkonfigurationen ran. Das waere wie gesagt der beste Zeitpunkt, alle Clientsysteme auf DHCP umzustellen. Denn damit kannst Du auch alle anderen Netzwerkkonfigurationen (Adressen der DNS/WINS-Server, Router; NetBIOS-Knotentyp, WPAD etc.) zentral konfigurieren. Rechne einfach den Aufwand mal hoch, den Du bei einer spaeteren Aenderung mit einer festen IP-Vergabe hast. Wenn ein Client sein DHCP-Lease erneuert (besseres Wort: verlaengert), dann bekommt er idR dieselbe IP-Adresse wieder. Denn die Verlaengerung eines DHCP-Lease erfolgt nicht erst am Ende der Lease-Ablaufzeit, sondern bereits eher. Erst wenn ein DHCP-Lease abgelaufen ist (z.B. weil ein Client zu lange offline oder alle DHCP-Server ausgefallen sind), wird der Client eine neue IP-Adresse anfordern. Es gibt auch Wege, DHCP mit zwei oder mehr Servern ausfallsicher zu realisieren. Auch koenntest Du im DHCP mit Hilfe der DHCP-Reservierung MAC-Adressen zu IP-Adressen zuordnen und damit eine quasi-feste IP-Adresse vergeben. Netsh: Mit Netsh-Skripte kann Dein Vorhaben, IP-Adressen per remote zu aendern, durchgefuehrt werden.

Bitte nur einen Thread pro Frage aufmachen. siehe http://forum.fachinformatiker.de/windows-betriebssysteme/96242-ip-adresse-im-netz-aendern.html ~~closed~~~

1. DHCP. Hier waere die Gelegenheit, alle Clients auf DHCP umzustellen und damit die zukuenftige Administration wesentlich zu vereinfachen. 2. netsh-Skripte zur Automatisierung der Aufgabe IP aendern / auf DHCP umstellen

Und welche Art von LWL mit welchen Steckertypen handelt es sich?

Ja, das geht. Das musst Du sogar so machen, wenn mehrere Exchange Backendserver existieren und alle unter einer URL erreichbar sein sollen. Es gilt auch fuer die Konfigurationen fuer Exchange ActiveSync Server und RPC over HTTPS.

Schau mal im RAS/RRAS nach. Dort kann das Logging erweitert werden, sodass Benutzer, Dauer und uebertragene Datenmenge im System-Eventlog eingesehen werden koennen.

Die Meldung stimmt. Du gibst eine Hostadresse mit einer Class C Subnetzmaske an. Loesung1: (Sub-)Netzadresse anstelle der Hostadresse angeben oder Loesung2: Subnetzmaske 255.255.255.255 anstelle 255.255.255.0

Welche Telefone sollen damit betrieben werden? - Analog - ISDN (S0) - ISDN-TK-Systemtelefone (UPN/UP0)

Die Goldene Regel beim SBS: Bei einem SBS sollte man zuerst die zugehoerigen SBS-Assistenten nutzen, ehe man auf Alternativen ausweicht. Die Zertifikatsdienste muessen bei einem SBS2003 nicht installiert werden, da der SBS-Assistent das bzw. beide SSL-Zertifikat(e) mit Hilfe von SelfSSL ausstellt, an der richtigen Stelle einbindet und es auch auf Anhieb problemlos funktioniert. Zusaetzlich exportiert der Assistent das bzw. beide Zertifikate in eine bekannte SBS-Freigabe: Clientapps Der Assistent heisst sinngemaess "SBS mit dem Internet verbinden" und ist in der Serververwaltungskonsole unter dem Punkt Aufgaben zu finden. --- Ein SSL-Zertifikat: SBS 2003 Standard Edition Zwei SSL-Zertifikate: SBS 2003 Premium Edition

Du brauchst die genaue (Sub-)Netzadresse und Subnetzmaske des Zielnetzes (bzw. die einzelnen Adressen der Systeme), die ueber den Cisco per VPN erreicht werden sollen. - RRAS-Dienst auf dem Windows 2000 Server aktivieren (sollte bereits mit dem aktivierten IP-Forwarding der Fall sein) - RRAS (Startmenue -> Verwaltung -> Routing and Remote Access) konfigurieren: -- Eintraege unter Server -> IP-Routing -> Statische Routen hinzufuegen --- entweder das gesamte Zielnetz + Subnetzmaske mit der Gatewayadresse Cisco oder --- einzelne Systeme mit der Subnetzmaske 255.255.255.255 und der Gatewayadresse Cisco - Standardgateway auf dem Windows 2000 Server aendern: Dort die Adresse des DLink eintragen - RRAS-Dienst (bzw. den gesamten Server) neustarten Das ist wie gesagt keine MS-Empfehlung, RRAS+DC auf einer Maschine zu betreiben.

Einsehen: Zum Einen auf jedem Windowssystem, dass mit DHCP konfiguriert ist, mit dem Befehl ipconfig /all. Dort dann die Zeilen Lease erhalten und Lease laeuft ab. Zum Anderen auf dem DHCP-Server selbst, Eigenschaften des DHCP-Bereiches (oder in den Eigenschaften des DHCP-Servers selbst ... hab einen DHCP-Server gerade nicht vor mir) Aendern: Auf dem DHCP-Server an oben beschriebener Stelle.

Stimmt schon, aber der DC ist durch das aktivierte IP-Forwarding ein Router. Und damit sind Teile des RRAS --- Routing and Remote Access Services --- aktiv. Ich wuerde an Deiner Stelle das gesamte Gebilde ueberdenken. Fragen, die sich mir aufwerfen: Warum haben der DC und die Clients oeffentliche IP-Adressen? - Fuer beide sollten Adressen aus einem der privaten Adressbereiche (10.0.0.0/8, 172.16.0.0/12 bzw. 192.168.0.0/16) genutzt werden. - Fuer Server- bzw. Diensteveroeffentlichungen wird klassischerweise eine DMZ aufgebaut, um die Sicherheit des restlichen Netzwerks nicht zu gefaehrden. - Fuer weniger Sicherheitsbewusste, es kann auch mit Portweiterleitungen auf einem Router gearbeitet werden. Warum muss ein Domain Controller routen? - Ein DC sollte nur die Aufgaben eines DC (sowie fuer das ActiveDirectory benoetigte Netzwerkdienste) haben - Der Cisco Router ist bereits mit einer Schnittstelle in einem privaten Netzwerkbereich (die Subnetmasken fehlen in Deiner Zeichnung und damit die Netzgroessen) - Der Cisco Router kann --- mit entsprechenden Zugriffslisten ausgestattet --- so eingeschraenkt werden, dass er z.B. nur den Unix Server erreicht. Auch beim Unix Server die Platzierung und Netzadressierung ueberdenken. Der Cisco Router kann --- je nach Modell --- auch als VPN-Server eingesetzt werden: - Warum wird ein zusaetzlicher (qualitativ um Klassen billiger) D-Link Router eingesetzt, wenn die bestehenden Internetkomponenten von Cisco sind, die mit einem Anruf beim zustaendigen Service (T-Com bzw. andere) konfiguriert werden koennen?

Das ist eher ein IIS- als ein Exchangeproblem. Funktioniert der Zugriff ueber die Localhost-IP https://127.0.0.1/exchange ? Wie hast Du das Zertifikat erstellt, ueber eine eigene Zertifizierungsstelle, bei einem Drittanbieter bestellt (z.B. bei Verisign, Thawte...) oder ueber SelfSSL (aus dem IIS6.0-Ressourcekit)? Hast Du das SSL-Zertifikat in die Standardseite importiert? Ist der SSL-Port auf der Standardseite eingetragen (Default: 443)?

Nimm einen Virenscanner mit aktuellen Virendefinitionen und scanne das System. Nimm Adaware, SpyBot SD und lasse sie auch auf das System los. Erstelle mit HiJackThis ein Logfile und lasse es auf www.hijackthis.de auswerten.

- Melde Dich z.B. bei www.dyndns.org an - Dort Hosteintrag erstellen z.B. meinserver.dyndns.org - Clientsoftware runterladen, installieren, Kontodaten von dyndns.org und den Hostnamen eingeben, fertig Alternativ zum letzten Punkt: - Daten des Dyndns-Kontos und den Hostnamen im Router eingeben Damit wird dann Dein Internetzugang unter einem festen Namen (meinserver.dyndns.org) erreichbar. Die zum festen Namen zugeordnete IP-Adresse wird durch den Dyndns-Client bzw. durch den Router aktualisiert.

Auf dem Windows Server 2003: - Aktiviere und konfiguriere den Routing and Remote Access-Dienst (RRAS) -- Mit dem RRAS kannst Du entweder VPN-PPTP oder VPN-L2TP/Ipsec nutzen Auf dem Router: - Konfiguriere Portweiterleitungen mit dem internen Ziel Windows Server -- benoetigte Ports/Protokolle: --- fuer PPTP: TCP-Port 1723 eingehend, GRE-Protokoll (Protokollnr. 47) --- fuer L2TP/ipsec: UDP-Port 500, UDP-Port 1701, UDP-Port 4500 (alle eingehend) Und falls keine feste oeffentliche IP-Adresse verwendet wird: Einen Anbieter fuer DynDNS verwenden (www.DynDNS.org, www.No-IP.info etc.)

Dann schau Dir IPcop an. Dort kann z.B. squid als Proxy integriert werden. www.ipcop.org

Microsoft empfiehlt aus Sicherheitssicht, einen DC und den RRAS-Dienst (Router/VPN-Server/RAS) nicht zusammen auf einer Maschine zu betreiben.

Nimm Filemon und Regmon (gibt es bei www.sysinternals.com) und untersuche beim Starten der Anwendung(en) die Zugriffe auf das Dateisystem und auf die Registry und vergib die benoetigten Berechtigungen.

Das ist eher ein Fall fuer einen zentral eingerichteten Proxy. Du musst die Nutzer ueber Filtermassnahmen informieren.

Dochdoch. Es gibt dort je nach Betriebssystem und DHCP-Dienst/-daemon Standardwerte.

Der bessere Weg ist es, auf die Vergabe von lokalen Adminberechtigungen zu verzichten und nur die benoetigten Berechtigungen zu vergeben. Ansonsten, wenn es sich nicht vermeiden laesst: Bei Einsatz einer Windows 2000/2003-Domaene: zentrale Gruppenrichtlinien Dort der Punkt eingeschraenkte Gruppen.

Ich meine nicht Deinen internen DNS-Server. Ist auf Deiner festen IP ein MX-Eintrag gesetzt? Funktioniert die Namensaufloesung Name zu oeffentliche IP (Forward DNS-Zone) und oeffentliche IP zu Name (Reverse DNS-Zone)? Wie meldet sich Dein Exchange Server, wenn Du ihn per telnet ansprichst (z.B. lokal auf dem Exchange Server mit telnet 127.0.0.1 25)? Ist dieser Name auch in der DNS-Zone zur oeffentlichen IP zu sehen?

Das kann mehrere Ursachen haben. - Reverse DNS-Eintraege nicht konfiguriert bzw. nicht aktuell - Verwendung von dyn., oeffentlicher IP-Adresse + direkter Email-Versand (kein Smarthost)

Geht nicht. Bei Windows Server 2003 wird der SQL Server 2000 mit SP3 oder hoeher bzw. der SQL Server 2005 unterstuetzt. siehe http://www.microsoft.com/sql/howtobuy/windowsnetsupport.mspx