grizzly999

Wenn du den NT DC als zweiten einschaltest, deaktiviert er sein Netzwerk, weil er einen anderen PDC (den PDC-Emulator von W2k3) findet. Wenn du den SBS als zweiten einschaltest -> sorry, keine Ahnung, noch nicht versucht, weil unprofessionell, und ich nur professionell arbeite. grizzly999

Beschreibe dein Problem mit dem TS genauer: Zitat: "Ich bekomme keine verbindung" ist keine Fehlerbeschreibung, sondern ein Zustandsmeldung. Für Zustandsmeldungen sind hier im Board aber Magier und Hexen zuständig. Sind aber alle im Urlaub :rolleyes: grizzly999

Nun, es gibt die Möglichkeit, als Hauptbenutzer zu arbeiten, da hat man erweiterte Rechte. Oder aber für Applikationen, die hier "Probleme" machen, suchen, wo es klemmt (Berechtigungen auf Registry-Keys oder Dateisystem) und das dann korrigieren. Allerdings, wenn der Rechner die Domäne wechselt, dann haben die anderen Domänen-Admins auch lokale Adminrechte und können nach Belieben lokale Admins hinzufügen und entfernen. Das steht dann nicht in mehr unter deiner Kontrolle, außer DU bist der auch der Domänen-Admin der neuen Domäne. grizzly999

Außerdem unnötiges Doppelposting :mad: http://www.mcseboard.de/showthread.php?threadid=48485 Als Erweiterung zu Thorgoods Hinweis: Lese dir doch auch gleich mal alle Boardregeln durch, bevor hier alle MODs lauter Arbeit mit deinen Threads haben: http://www.mcseboard.de/rules.php?s= Danke grizzly999

Umbenennen bedeutet auch "Löschen", so widersinnig das klingen mag. Daher brauchst du zum Umbenennen die Löschberechtigung. Ja, auch dann. Es gibt aber eine Gruppenrichtlinie, die anstatt des Erstllers die Administratorengruppe als Besitzer eines neu erstellten Objekts einträgt. Damit ist dein Problem aber nicht gelöst, der Benutzer braucht immer noch die Löschberechtigung, um einen Ordner umzubennen. grizzly999

Nein, Admin ist Admin und das ist auch gut so und gewollt so. Wenn der rechner in einer anderen Domäne ist, dann gehört der zu DIESER Verwaltungseinheit und nicht mehr zu deiner. Such is IT-Life (nicht nur bei Microsoft :wink2: ) grizzly999

@AGuersch: Sehr sinnige Antwort auf die gestellte Frage. Du bist sicher, dass du hier richtig bist :rolleyes: grizzly999

Hmm, ich würde jetzt sagen, wenn sich beide Domänen in getrennten Subnetzen befinden und nur per Router erreichen, und nur einfacher Datentransfer per xcopy oder so, ja. Replizierender WINS oder andere NetBIOS-Namensaulösung netzübergreifend darf nicht stattfinden. grizzly999

Da das nicht ganz so viel mit MCSE-Allgemein zu tun hat, verschiebe ich den mal. grizzly999

Technisch würde das natürlich gehen, lizenzrechtlich müsste das auch ok. sein, wenn man die EvalVersion nach Ablauf deinstalliert. Zertifikate dürften vom Ablauf nicht betroffen sein, Textfiles, die ich damit erstellt habe, muss ich ja danach auch nicht vernichten :D grizzly999

Ja, da hast du recht, das habe ich nicht dazugeschrieben, weil das Arbeiten an einer EE in meinen Umgebungen schon selbstverständlich geworden ist :o Und nein, da ist dann Ende der Fahnenstange, die SE kann nur mit V1 Vorlagen arbeiten, und bei denen ist IMHO der private key nie als exportierbar markiert, womit man ihn dann auch aus dem Computer nicht herausbringt. Als Alternative fällt mir nur ein: 1.) Deine Lösung (Client zuerst in die Domäne, dann rausnehmen) 2.) Wenn noch ein Server da ist, dort eine eigenständige Zertifizierungsstelle aufbauen, Zertifikate (am leichtesten über den Webbrowser) anzufordern und dabei den private key als exportierbar markieren. Der VPN-Server braucht dann eben auch so einZertifikat nebst Root-CA-Zert. Sorry, mehr habe ich im Moment nicht anzubieten. grizzly999

Jeder darf in der FAQ lesen, die ist öffentlich .... :wink2: grizzly999

Oder das Setup mit einer Vollversion wurde mit Disketten gemacht, die von einer Eval-Version erstellt wurden: http://support.microsoft.com/default.aspx?scid=kb;en-us;173507 grizzly999

Zeitraum für die Beurteilung? engl.: period for evaluation -> Eine Evaluierungsversion würde ich sagen, die verhält sich auch so :suspect: grizzly999

Hallo und Willkommen im Board :) Auch wenn Microsoft die Installation weiterer Server und DCs hier erlaubt, es ist immer noch SBS, und dazu gehört auch, dass der SBS als erster Server bleibt und FSMO-Roles da drauf bleiben müssen. Lies doch einfach mal die SBS-FAQ durch (deine Frage Bereich "Product Information"), da klären sich bestimmt viele Fragen ;) http://www.microsoft.com/windowsserver2003/sbs/techinfo/overview/generalfaq.mspx grizzly999

Mit einer eigenständigen Zertifizierungsstelle wäre das jetzt kein Problem. Bei einer Unternehmenszertifierungsstelle können ja nur Security Principals, in dem Fall Computer aus dem AD ein Zertifikat anfordern. Aber mit *räusper* "etwas" Aufwand ist das auch machbar: Da ich jetzt leider keine ausführliche Anleitung schreiben kann, nur kurz in Stichworten das Vorgehen: - in der Zertifizierungsstelle eine Kopie der IPSec-Richtlinienvorlage erstellen. Dabei bei den Anforderungsverbeitungen den privaten Schlüssel als exportierbar erlauben. - diese neue Vorlage zur Anforderung freigeben - wichtig: einige Minuten warten! - Mittels einer selbsterstellten MMC (Zertifikate->Lokaler Computer) ein Zertifikat anfordern. Dabei die neue Vorlage auswählen - Nach Erhalt der Zertifikats kann dieses mit samt dem privaten Schlüssel exportiert werden - Auf dem Zielrechner importieren - Rootzertifikat auf Zielrechner importieren nicht vergessen HTH grizzly999

Das ist seit 2003 ein riesiges Problem geworden der Zeitdienst, ich kenne kaum eine Domäne, die nicht voll mit diesen Fehlern ist. Traurig, aber wahr. Es gibt einen Pre-SP1 Patch, der die Fehler auf wenige Meldungen reduziert und die Synchrionisation dann anscheindend trotz der Fehlermeldung dann halbwegs anständig läuft: http://support.microsoft.com/default.aspx?scid=kb;en-us;830092 grizzly999

Jo, den hatten wir schon, und ist in der Versenkung verschwunden. Wir haben das bereits intern diskutiert und beschlossen: Da alles sehr spekulativ ist, und was da alles an "Schon-Aburteilungen" kursiert, die evtl. bis nahe an "Verleumdung" reichen, juristisch wie auch moralisch fragwürdig und zudem totale Spekulation sind, insbesondere, da Microsoft sich noch nicht geäußert hat, werden wir hier im Board solchen Spekulationen keinerlei Nährboden gewähren und diese Threads schliessen. Wir danken für aller Leute Verständnis, aber wer sich an Spekulationen beteiligen möchte, dem stehen andere Boards im Internet zur Verfügung ;) grizzly999

Wieso "falsch konfigurierter" Exchange, das verstehe ich nicht. Meine AD-Domäne hat meinen offiziellen Internetnamen, mein Exchange ist deshalb aber nicht falsch konfiguriert und einen Sicherheitsverlust habe ich darurch überhaupt nicht, welchen auch?! Nein, das ist kein Graus, dafür ist eine email Adresse doch da, dass sie andere bekommen. Wo ist der Sicherheitsverlust?! Den potentiellen "Sicherheitsverlust", der bei MS immer in allen Unterlagen angesprochen wird, begründet sich in den Szenarien immer da drauf, dass diese Unternehmen in den Beispielaufgaben ihren eigenen Internet-DNS Server in ihrer DMZ hosten, und bei unvorsichtiger Replikationseinstellung plötzlich im DNS mit dem ja offiziellen DNS-Namen in der DMZ plötzlich interne Ressourcen auftauchen. Also selbst große Firmen hosten meist ihren eigenen DNS nicht mehr, sondern der steht beim Provider. Und wer dennoch in so einem Fall seine interne DNS-Zone auf den DNS in der DMZ replizieren lässt ...... also IMHO ist das ziemlich an den Haaren herbeigezogen. Probleme kann es bei der Namensauflösung geben, wenn z.B. bei einem Mehrdomänenmodell der eigene DNS der Root-Domain (die den offiziellen Namen hat) nicht erreichbar ist. Dann versucht der untergeordnete DNS den DomänenNamen beim Provider aufzulösen und trägt dessen DNS im DNS-Cache ein -> Panne. Probleme können entstehen, wenn von externen Mitarbeiten auf interne Postfächer zugegriffen werden soll, und die aber eine funktionierende Internetnamensauflösung haben und dann nicht beim Firmenmailserver landen, sondern bei dem vom Provider (wenn dort ein SMTP gehostet wird). Probleme können entstehen, wenn man im Proxy angibt, den Proxy für den lokalen Domänennamen (FQDN) zu umgehen, aber dann auf die Homepage mit diesem Namen im Internet über den Proxy muss. Usw. Aber das sind alles keine Sicherheitsrelevanten Probleme, sondern eher "pragmatische" Probleme, wie ich sie oben bezeichnet hatte. Aber wenn es wirkliche (komkrete) Sicherheitsprobleme außer dem oben genannten fiktiven DNS-Problem bei der Verwendung des offiziellen DNS-Namens im AD gibt, dann her erzählen .... ;) grizzly999

Wie schon gesagt, RDP => Application Layer ;) grizzly999

Der W2k Server als weiterer DC geht, allerdings muss er vorher zum Memberserver heruntergestuft und damit diese Domäne gelöscht werden, bevor er in die SBS Domäne aufgenommen werden kann. Eine Synchronisation der Homeverzeichnisse ginge z.B. über DFS. grizzly999

Hmm, thebig redet aber immer von einem LAN-Proxy und Also zwei verschiedene Proxy-Eintragungen innerhalb EINES IE kenne ich nicht, und eine LAN-Proxy auch nicht. Thebig sollte uns noch etwas genauer erklären, was er meint ....... (taptaptap) grizzly999

Sorry, aber in meinen Browsern war es seít der IE-Version 4.0 immer nur ein Proxy. Welche getunte Version setzt du ein? :suspect: grizzly999

Ich tippe drauf, dass du beim Client mit einem Netzwerkmonitor ICMP-Fragementation required Pakete finden würdest, weil die MTU zu groß ist. Setze mal auf dem Client und evtl. auf dem Server in der Registry die MTU runter. Beginne mit 1492. wenn das nicht klappt, probiere es mit 14 und sogar mit 1300. Der RegistryKey ist hier zu finden: http://support.microsoft.com/default.aspx?scid=kb;de;314053 grizzly999

Hallo und Willkommen im Board :) Da du W2k hast, kann es ja nur sein, dass an dem entsprechenden Rechner die Registry-Keys für den AutoAdminLogon gestezt sind. welche das sind, findest du hier: http://www.mcseboard.de/showthread.php?threadid=26841 Schau doch da mal rein und setze dann den AutoAdminLogon auf 0 grizzly999