grizzly999

Hmm, Remotedesktop und Remotedesktopverbindung sind zweierlei. siehe auch GuenterH's Post, wie es richtig geht grizzly999

Ich nicht, weil ich bei mir nie ein DHCP Relay Agent auf dem RRAS einrichte :D

Hallo und willkommen im Board :) Ich verstehe nicht ganz, WAS verschwindet? Freigaben auf dem Server? Freigaben auf dem Client? Oder meintest du gemappte Laufwerke auf Serverfreigaben auf dem Client? Und was heißt verschwinden? grizzly999

"Daher Closed" vergessen :p

Hallo und willkommen im Board :) Da der Beitrag nichts mit MCSE-Prüfungen zu tun hat, habe ich den ins richtige Forum verschoben. Bitte künftig die Wahl des richtigen Forums beachten ;) grizzly999

HEY, verwette nicht meine Hüte, bevor das Konklave war :D :D

Das ist nicht korrekt. Jeder DC gibt GPOs heraus, und der Client bekommt die Policies von seinem Anmeldeserver geliefert. Den Logonserver kann man auf einem Client mit dem "set"-Befehl in einem cmd-Fenster kontrollieren. Prüfe, bei verschiedenen Clients welcher das jeweils ist. Ist es ein anderer DC als der eine da, funktionieren dann die Policies auf dem Client bzw. hat er dann keine Fehler im Log (testen mit secedit /refreshpolicy machine_policy und danach im Anwendungslog schauen). Siehe oben. Voraussetzung ist, dass DNS im AD sauber läuft, alle DCs mit ihren SRV-Records auch eingetragen sind. Ist das der Fall? grizzly999

Du meinst den Fehler 1014, wenn er nicht als DC läuft? Ja. Hatte ich in der Praxis aber noch nicht, meine installierten SBS waren immer Dc und zwei davon in einer Domäne zu installieren, auf die Idee bin ich in der Praxis noch nie gekommen :D grizzly999

Das ist korrekt, wissenaber nur die Eingeweihten :) Ich bin davon ausgegangen, dass das dort wie in 99,9999% aller anderen forests nicht gesetzt ist. Aber könnte natürlich sein ..... grizzly999

Die laufen beide in EINER Domäne :suspect: Da müssten schon bei der Installation Fehlermeldungen und eine Verweigerung gekommen sein. Ich behaupte zu hast zwei völlig unabhängige SBS-Domänen, aber selbst das dürfte in einem einzigen Netzwerk nicht möglich sein. Was jetzt? Der 2. SBS muss weg, komplett ganz einfach. Will man weitere Server haben, dann muss man da normale Serverbetriebssystem kaufen (2003 Standard Edition oder EE). Außerdem empfehle ich dringend eine Schulung zu SBS oder zumindest das Studium entsprechender Paper und Artikel zu SBS bei Microsoft und hier .:. www.SBSPraxis.de, die MCSEBoard Hilfe Seite für den Microsoft SBS Server 2003 .:. grizzly999

*ggg* :D

Das kann durchaus Fehler geben, und müsste zuerst gerichtet werden. Hängt auch ein wenig davon ab, was für ein Typ die alte Domäne ist, NT oder AD. Bei AD sollte in der alten Domäne alles in Butter sein bzgl. PDC-Emulator, DNS-Einträgen usw. grizzly999

Bzgl. DHCP und Relay Agent auf dem VPN Server: Wenn der RAS so konfiguriert ist, dass er die Adressen vom DHCP bezieht, dann tut er das und gibt diese Adresse an die Clients raus, auch OHNE DHCP-Relay Agent. Als DNS und WINS gibt er normalerweise seine eigenen raus, also die die der RAS an seiner NIC eingestellt hat. Das kann kann man in denEigenschaften des RAS-Server unter "IP" einstellen (Feld ganz unten). Nachdem der Client eine IP vom RAS erhalten hat, versucht er per DHCP Broadcast einen DHCP Server zu erreichen, um Optionen abzurufen. Diesen Broadcast leitet der RAS nicht weiter, wie es ein jeder Router nicht tut. Mit dem DHCP Relay Agent allerdings werden diese Braodcasts allerdings an den DHCP weitergeleitet (dazu muss aber zusätzlich in den Eigenschaften von DHCP-Relay Agent die IP des DHCP Server eingetragen werden), und der Client bekommt jetzt Optionen wie DNS-Server, WINS-Server, DOmänenname, Knotentyp usw. vom DHCP geliefert, außer dem DG natürlich, das bleibt wie es ist. grizzly999

Aufklärung kurz, präzise und prägnant: Es kann nur einen SBS in einer Domäne geben! grizzly999

Ja, für das Tool braucht man die Namensauflösung zwischen den Domänen und den Trust als Grundvoraussetzung. Dann allerdings bietet das ADMT Tool auch an, Roaming Profiles bei der Benutzermigration entsprechend "mit zu migrieren". grizzly999

Häh? 2 SBS im selben Netz als DC usw usw?? Und dann ncoh NLB. Wie bitte soll das gehen? Kläre uns bitte auf...... Danke grizzly999

Hallo und willkommen im Board :) Das galube ich dir nicht, mit den Sekunden usw., sorry. Denn die Standortverknüpfungen, die das Replikationsintervall für DCs über Sites hinweg vorgeben, kann man nicht unter 15 min Intervall einstellen :suspect: grizzly999

1.) Das Gateway bekommt der Client sowieso nicht vom DHCP, das ist entweder die eigene Client IP (VPN) oder die VPN IP des Servers. 2.) Der RAS Server braucht den installierten DHCP Relay Agent, mit der VPN Schnittstelle als NIC, damit er die DHCPNachrichten der Clients an den DHCP weiterleiten kann. 3.) Warum sind bei dir beide NICs im selben Netz. Die interne NIC muss in einem anderen Netzwerk sein :suspect: grizzly999

Für eine Usermigration samt Roaming Profiles in eine neue Domäne/forest nimmt man ein Migrationstool wie ADMT von Microsoft (oder Löhnware von Quest u.a.), aber nichts manuell machen. Das ist nur Gepfriemel und fehlerbehaftet. grizzly999

Du Armer!! Hier bei meiner Migration am Wochenende zum Glück nur 5 Windows 2000. Weil mit ADMT 2.0 von der 2003 CD gings das mit den 2000ern nicht, nur mir ADMT 3.0, und ADMT 3.0 hat das dann bei Windows 2000 nicht richtig ordentlich gemacht. Mag aber sein, dass das am ServicePack der 2000er lag, oder an sonst was, keine Ahnung, es tat nicht was es sollte das Tool. Ist völlig richtig, das mit dem neuen Profil, schließlich steht im Profil die alte SID drin. SID-History nützt da nichts, da bei Profil die primäre SID des Users zählt, und keine SID aus der SID History, und die prmäre SID hat sich geändert. Yep. Und dabei insbesondere auswählen, dass die lokalen Profile migriert werden sollen. Aber wie oben gesagt, das konnte hier das ADMT V3.0 nicht auf den 2000 Rechnern. Alles wunderbar mit dem Wizard, alle Meldungen Passed Passed Successful usw., aber dann Profile am Montagmorgen von Hand umschießen :cry: grizzly999

Da hast du was falsches gelernt (oder vielleicht nur falsch verstanden?!) Den GC zur Überprüfung universaler Gruppenmitgliedschaften benötigt der Domänencontroller bei der Anmeldung - und nun Achtung - nur wenn: - man ein Mehrdomänenmodell hat - die Domäne des Benutzers mindestens im 2000 pur Modus läuft. Läuft die Domäne in diesem Mehrdomänen-Forest in einem der niedrigeren Function Levels, kann der Benutzer nicht Mitglied einer UG sein. Hat man ein Eindomänenmodell, auch in den höheren Functional Levels, hat sowieso jeder DC die vollen Informationen durch die Replikation und es wird kein GC für die Anmeldeüberprüfung benötigt. Und außerdem: Da jeder DC in einem Eindomänenmodell komplett ALLES repliziert, was im AD vorhanden ist, wie soll da ein mehr an Replikationsverkehr entstehen, wenn man verteilte GCs hat?! Da hat jemand Nonsens erzählt. In einem Eindomänenmodell bezgl. der Anmeldung (!!) ==> absolut korrekt Yep. Bei Anwendungen, die auf einen GC zugreifen, wie z.B. Exchange, und der tut das sehr häufig, sieht das anders aus, denn der tut das auch in einem Eindomänenmodell. Hat ja auch nichts mit der Anmeldung zu tun. Völlig richtig, siehe oben. Bei der Anmeldebestätigung an einer Domäne im mind. Windows 2000 pur Functional Level in einem Mehrdomänenmodell wird durchaus ein GC benötigt, bei dem der DC, der die Anmeldung entgegennimmt, überprüfen kann, in welchen UGs der Benutzer ist. Dazu sucht er einen GC über den DNS und verbindet sich mit diesem. Ist ein GC am Standort vorhanden, wird dieser als oberster in der Liste vom DNS geliefert. Ansonsten gibt es einen von einem anderen Standort. Das erzeugt natürlich WAN-Verkehr. Will man diesen WAN-Verkehr ein wenig reduzieren, kann man für den Standort ohne GC das UG-Caching einschalten. Dann muss der DC immer noch einen GC connecten, speichert sich dann aber die UGs des abgefragten Benutzers zwischen, standardmäßig für 8h. Bei der nächsten Ameldung des Users muss der DC dann nicht mehr den GC connecten (für diesen speziellen User, für andere User womöglich schon). Das reduziert den WAN Verkehr ein wenig und dieser User bekommt auch eine Anmeldung, falls die Leitung down sein sollte. Alternativ zum UG-Caching gibt es zwei Möglichkeiten: 1.) Einen GC an den Standort stellen. MAcht dann zusätzlichen GC Replikationsverkehr. Dazu ist folgendes zu sagen: Das ist zwar richtig, aber man sollte sich auch gewahr sein, dass der Replikationsverkehr über Sites hinweg im allgemeinen mächtig überschätzt wird. Wenn man nicht eine Domäne a' la Daimler oder HP hat, wieviele Änderungen finden dann im GC am Tag wirlich statt, und wieviel wird dann repliziert. Ich schätze, das wird bei Euch wie bei vielen anderen im KB-Bereich sein :suspect: Und der Replikationsverkehr wird um ca. 70-80% komprimiert(!!). Von daher sprich in den allermeisten Domänen wenig gegen einen GC an der Site. 2.) Man kann die Notwendigkeit eines GCs bei der Anmeldung per Registry deaktivieren, allerdings gibt es dann evtl. nicht die korrekten Gruppenmitgliedschaften in das Access Token der User. How to disable the requirement that a global catalog server be available to validate user logons Alles klar, wenn noch Fragen sind, her damit :) grizzly999

Dann entpackst du sie eben mit Winimage (Gilles Vollant software) ;) grizzly999

Ja, sieht nicht ganz so gut aus. Möglichkeiten, die es u.U. noch gäbe, liegen außerhalb des Boardbereichs, sprich verstoßen gegen die Boardregeln, da ist vielleicht google dein Freund ;) Bitte an alle: auch nichts in dieser Richtung posten. grizzly999

Also zusammenfassend: -Die Dateien sind vor einiger Zeit mit einem Zertifikat (auf deinen Namen ausgestellt) verschlüsselt worden. Die hattest du auch selber und absichtlich verschlüsselt?! -Jetzt hast du eine Zertifikat in deinem Zertifikatsspeicher, das auch auf deinen Namen lautet, das am 04.05.2007 ausgestellt wurde, und einen anderen Fingerabdruck hat?! -Der Rechner ist nicht in einer Domäne und war es auch nicht. -Eine Sicherung des Systems von früher gab es nicht. Eine Sicherung nur des privaten Schlüssels deines alten Zertifikats gibt es auch nicht. grizzly999

Aus dem Internet Explorer? Nein, ich meine, wenn du auf die Datei gehst, rechte Maustaste Eigenschaften, Allgemein, Erweitert, dort ist das Häkchen bei "Verschlüsselt" gesetzt, korrekt? Unter "Details" kann man dort sehen, wer die Datei entschlüsseln kann und dahinter der Fingerabdruck des Zertifikats (Zahlen- und Buchstabenfolge). Im eigenen Zertifikat, nachzuschauen mit certmgr.msc, kann man die Details des eigenen Zertifikats sehen. Das unterste Feld ist das mit dem Fingerabruck des Zertifikats. Stimmen die beiden Finerprints überein? grizzly999