schroeder750

Hy Jimmypop, mannomann, das macht mich jetzt aber langsam etwas wuschig...ganz merkwürdig... :suspect: Ich habe hier extra noch einmal unter VMWare meine Testumgebung hochgefahren und nachgesehen bzw. ein bisschen rumgetestet. Meine Umgebung: Ein stinknormal aufgesetzter NT4 PDC mit einem Exchange 5.5. Ein stinknormal aufgesetzter W2K3 DC (Standard Edition) mit Exchange 2003. Beide Server in der gleichen IP-Range. Administratorpasswörter bei beiden Domänen gleich. Trust aufgebaut, Benutzergruppen wie oben beschrieben verschachtelt. Bei mir gibt es keinerlei Probleme in dieser Hinsicht. Ich bin jetzt eben mal hergagangen und habe bei beiden Servern die Lienzierung für Windows NT Server (NT4) bzw. Windows Server (W2K3) umgestellt auf "Pro Server" und habe die Anzahl der gleichzeitigen Verbindungen original auf NULL gesetzt. Keine Reaktion... ich kann von beiden Seiten her auf die andere zugreifen, ohne Probleme... habe beide Server sogar mal neu gestartet... kein Unterschied. Ich bekomme nicht einmal mit Gewalt eine annähernd ähnliche Fehlermeldung hin ... Was mich wundert: Bei mir tauchen folgende Angaben bei Start => Einstellungen => Systemsteuerung => Lizenzierung auf: NT4: "Windows NT Server" und "Microsoft Exchange Server 5.5" W2K3: "Windows Server" und "Microsoft Exchange Server 2003" Bei mir taucht nichts von "Microsoft Backoffice" oder ähnliches auf... versteh ich momentan nicht so ganz... wo kommt das bei Dir her ? Und mal noch ein Ansatz: hast Du mal den Lizenzprotokollierdienst auf Deinen beiden Servern beendet / deaktiviert ? Wäre mal ein Versuch wert, was dann passiert... evtl. danach mal neu starten... Hast Du auf beiden Seiten das gleiche Adminpasswort ? An alle anderen: Hat noch irgendwer eine Idee ? Ich tappe, ganz ehrlich, momentan etwas im Dunkeln... :mad: Grüsse schroeder750

hmmmm... da muss ich jetzt aber auch als NICHT-SBS-Freak mal was dazwischen werfen. Schaut Euch bitte mal folgenden Thread an: http://www.mcseboard.de/showthread.php?t=73397 Hatte mich auch gewundert, habe mich da auch nochmal genauer informiert. Es scheint als hätte man 7 Tage Zeit, beide SBS nebeneinander laufen zu lassen, bevor sich das alles in Ursuppe auflöst ... In diesen 7 Tagen kann man ja nun schon einiges machen... Den neuen SBS parallel aufbauen, hieße ja, wenn ich die nicht beide in ein Netz bringen kann, daß ich Benutzerkonten, Passwörter, die ganzen Berechtigungen usw. alles wieder neu aufbauen müsste ... stöööhhnn... ganz davon ab, daß die Geschichte mit Exmerge ja auch einiges an Zeit braucht... Da wäre es doch geschmeidiger, beide parallel in ein Netz zu bringen und die Ressourcen in Ruhe rüberzumoven, oder ? Geht hier wirklich nicht drum, irgendwas besser zu wissen, ich spiele gerade nur den Assistenten zwischen verschiedenen Threads, O.K ? Wie gesagt, ich gebe diese Info auch nur so weiter (die ist von GuentherH und wenn der was sagt, glaube ich das normalerweise blind, auch wenn ich sonst Skeptiker bin :D ) (Ja Guenther, das kannst Du als großes Kompliment auffassen :D ). Ohne Garantie, aber normalerweise dürfte das doch problemlos flutschen, wenn ich es sauber plane, oder ? Hopp liebe Kollegen, bitte Wortmeldungen, ich will acmuser keine Halbwahrheiten auftischen... :D Grüsse schroeder750

Hy acmuser, da Du ja beide Server eine Zeit lang parallel laufen lassen wirst (nehme ich mal an, bin nicht so der SBS-Spezi :D ) haben ja beide verschiedene Namen. Somit entfällt es, die Datenbanken einfach vom alten Server zu nehmen und dem neuen "unterzujubeln"... Man wiederspreche mir bitte, wenn es beim SBS so nicht funktioniert, beim "Standard" Server und Exchange wäre hier folgende Vorgehensweise angebracht: - Installation des neuen Exchange in die gleiche Organisation wie der alte Exchange - Einrichten der Replikation der öffentlichen Ordner - Verschieben der Postfächer auf den neuen Server (Outlook-Einträge ändern sich bei der ersten Anmeldung automatisch und von selber) - Verlagern der Konnektivität (SMTP-Connector) auf den neuen Exchange - Deinstallation des Exchange auf dem alten Server bei bestehnder Verbindung zum alten. Die gleichen Vorgänge bezüglich fsmo-Rollen und Global Katalog Server sollen natürlich bezogen auf die DC-Funktionalitäten auch gemacht werden. Wie schon gesagt, bin nicht so der SBS-Mensch, mal warten ob ein Widerspruch von unseren SBS-Freaks kommt :D Grüsse schroeder750

Hy jimmypop, ... wenn Du nicht bald das "Siezen" sein lässt, bin ich beleidigt... :D Wir werden mit sehr hoher Wahrscheinlichkeit nicht geschäftlich zusammenkommen und hier im Board wird normalerweise geduzt. Alles klar ?? :D :D :D O.K. Los geht das: W2K3 Server installieren. Dabei am Besten die Lizenzierung "per Server" einstellen. IP-Adresse am besten eine freie aus der Range, in der sich auch die NT4-Domäne bewegt. Wir einigen uns jetzt mal drauf, daß die neue Domäne mit fqdn "domaene.de" und mit NetBios-Namen "DOMAENE" heißen soll. IP-Range ist die 192.168.50.x / 255.255.255.0. Du änderst die Einträge dann auf die echten... Nachdem der Server installiert wurde, den netten Assistenten zum Konfigurieren des Servers schroff abwürgen und den haken setzen, daß er sich auf ewig raushalten soll... Anschließend rechte Maustaste auf den Arbeistsplatz, Eigenschaften, Computername, Ändern, Weitere. Hier als primäres Suffix "domaene.de" eingeben. Eigenschaften Netzwerkumgebung, TCP/IP-Protokoll: Hier den W2K3 Server selber als DNS-Server eintragen. Danach eine Managementkonsole starten (mmc), das Snap-In "DNS" hinzufügen und zuerst eine neue primäre Reverse-Lookupzone erstellen. Netzwerkkennung (192.168.50) eingeben (Falls ein 255.255.0.0-Netz, halt nur die ersten beiden Zahlen eingeben und das vorletzte und das letzte Feld freilassen). Vorerst sichere und nicht sichere dynamische Updates zulassen. Das gleiche mit der Forward-Lookupzone. Hier als Name der zone den Namen der späteren Domäne, also "domaene.de" eingeben. Anschließend aus dem Unterverzeichnis \Support\Tools der W2K3-Server CD die Support Tools installieren. Immer nur auf "weiter", Standardinstallation... Server neu starten. Nach dem Neustart den "netdiag" aus den Support-Tools ausführen und mal schauen, ob soweit nichts haarsträubendes gemeldet wird. Nochmal einen Ping -a auf die IP-Adresse des Servers loslassen, schauen ob der fqdn (server.domaene.de) sauber zurückgemeldet wird. Wenn das alles geht, dann Start-Ausführen-"dcpromo" Hier angeben, daß eine neue Domäne, eine neuer Domänencontroller für die erste Domäne erstellt werden soll usw... müsste immer der oberste Punkt sein... Fqdn eingeben "domaene.de", als NETBIOS-Name müsste jetzt automatisch "DOMAENE" vorgeschlagen werden. Falls Du in der neuen Domäne noch den Zugriff von aussen via RAS planst, angeben, daß mit Windows NT 3.5x / 4.0 kompatible Berechtigungen gesetzt werden sollen, Kennwort für Verzeichnisdienstwiederherstellung vergeben und GUT GESICHERT DOKUMENTIEREN. Durchlaufen lassen, Neustart, anmelden, "dcdiag" aus den Support-Tools staretn und hier mal die Ergebnisse ansehen. Dann mal noch auf den NT4 PDC pingen (Name und IP mit -a davor). Wenn hier alles sauber funktioniert, wieder am Anfang dieses Threads anfangen und wenn Dann alles sauber durchgelaufen ist, Info geben, O.K ? Sooo, ich mach jetzt Wochenende. Viel Erfolg !!!! ;) ;) Grüsse schroeder750

... kleines Zwischenupdate: auch beim Kunden funktioniert die lokale Anmeldung auf diese Art und Weise. Da ist jetzt erstmal der Druck ein wenig raus. Werde demnächst über weiteres berichten, wenn ich wieder vor Ort war ;) Grüsse schroeder750

...hast Du denn mal die Dinge durchgeführt, die in dem Artikel stehen, den Velius genannt hat ? Das sieht mir ja nun schon danach aus, als könnte es Dein Problem lösen... Falls das nicht geholfen hat: wo klemmts ? Grüsse schroeder750

Hy ftaute, mal was generelles, nicht speziell dazu, wie Du den "BDC" wieder fit bekommst: Das AD liegt automatisch als Kopie auf jedem DC vor. Wenn Du also einen zweiten DC mittels dcpromo erstellt hast, hat dieser alle Informationen, die er benötigt, um den "Chef" zu spielen. Er DARF nur die 5 fsmo-Rollen nicht übernehmen, da dies einem anderen DC vorenthalten ist. Raucht Dir dieser andere DC nun ab, kannst Du die 5 fsmo-Rollen auch "gewaltsam" auf dem verbleibenden DC zum Laufen bringen. Dies erledigst Du mit "ntdsutil" und dem "seize"-Befehl. Anschließend solltest Du dem DC noch eine Kopie des globalen Katalogs gönnen (Sollten eh mehrere DCs haben) und alles ist vorerst wieder in Butter. Falls Du übrigens dann den defekten DC wieder zum Laufen bekommst, kann es natürlich sein, daß es knallt, weil ja nun zwei DCs jeweils die fsmo-Rollen für sich beanspruchen. Offiziell sollte man den ersten DC dann dauerhaft aus dem Verkehr ziehen, ich habe es jedoch mehrmals getestet und frech beiden DCs mit fsmo-Rollen wieder hochgefahren. Die haben sich unter W2K3 immer friedlich geeinigt ... bei W2K kann das kritischer sein... Mach Dich in der Materie hier im Board mal etwas schlauer, im Desaster-Fall kann man mit wenigen Befehlen die Rollen verlegen und erstmal in Ruhe durchschnaufen ... :D Wäre ärgerlich, wenn Du den ersten DC nicht mehr ans Laufen bekommst und ihn neu aufsetzen musst, weil Du ihn unter diesem Namen nicht mehr als DC ins AD bekommst, ohne die Einträge, die auf seinen Namen laufen, vorher aus dem AD manuell rauszuschnippeln... Sollte es soweit kommen, meld Dich nochmal oder bemüh die Boardsuche, das Thema hatten wir schon ein paar mal... Aber jetzt erstmal ran an die Reparatur des ersten DCs ... nicht gleich so schwarz sehen :D Grüsse schroeder750

Hy hutz, ... eine Systemwiederherstellung von WAS genau ? Den systemstate auf dem DC vom Vortag wieder eingespielt ? Wenn dies der Fall ist und es danach wieder funktioniert hat, dann hat doch definitiv jemand (ein lieber Kollege...?) was an den policies oder ähnlichem gedreht ... Wenn dies mal auf einem PC passiert, O.K... aber plötzlich auf allen möglichen Rechnern ? da wurde doch an zentraler Stelle gefummelt... Ist irgendwas geändert worden ? Jetzt kannst Du natürlich im Nachhinein versuchen, herauszufinden, was es genau war, das dürfte jedoch, da dieser Zustand ja nun nicht mehr anhält, nach etlichen Stunden Sucherei im Sande verlaufen ... Oder Du kannst mal drüber nachdenken, wer denn alles so die Berechtigungen hat, am AD oder an den Domain policies rumzudrehen und DORT ansetzen ... Is ja klar, daß keiner der Kollegen ir-gend-was gemacht hat, stimmts ? :D Ganz ehrlich, steck die Energie nicht in die Fehlersuche, jetzt wo es wieder funktioniert... wenn sowas passiert, sollte man sich mal mit den Kollegen zusammensetzen und die generelle Administrationsstrategie besprechen ... :suspect: Grüsse schroeder750

... was heißt hier "nicht lachen" ?? Was meinst Du, wieviele Kunden ich habe, die erst ab der Migration auf W2K / W2K3 durch uns einen DNS haben ? NT4-Netz ohne DNS ist fast sowas wie ein Standard :D Viel Erfolg bei der Migration !!! Grüsse schroeder750

Vorsichtig noch... einen Hintergedanken bitte im Kopf behalten: Wenn ein neuer DHCP-Sever aufgebaut wird, mit der gleichen Range wie der alte (der ja dann abgeschaltet wird), bitte darauf achten, daß dieser keine IPs vergibt, die von Clients über eine evtl. längere Leasedauer vom alten Server beansprucht werden. Will damit sagen, die Leasedauer der IPs für die DHCP-Clients VORHER auf kürzeste Zeitspanne setzen. (Ist ein Tag, glaube ich ...). Bestenfalls Freitags den alten DHCP-Server abschalten und den neuen aufbauen, dann kommen am Montag keine Clients, die noch eine IP beanspruchen, die sie vom alten Server mit längerer Leasedauer bekommen haben... Oder Variante 2: Ins Logonscript den ipconfig /release und den ipconfig /renew einbauen, daß sich jeder Client auf jeden Fall direkt eine neue IP vom neuen DHCP-Server holt... Mannomann, ich glaube, das war jetzt sehr umständlich beschrieben, oder ? :D Grüsse schroeder750

Hy, WAS genau kannst Du nicht pingen: auf den Namen oder die IP ? Ist der Server im DNS sauber eingetragen ? Grüsse schroeder750

moin moin, noch ein paar Anmerkungen zum drüber nachdenken, das erspart späteres Nachkonfigurieren: - evtl. DNS ändern (wie schon von Schweizi angemerkt) - WINS evtl. ändern - Wie sieht es mit eventuell vorhandenen hosts / lmhosts auf den anderen Servern / den Clients aus ? Nicht das hier irgendwo der PDC mit der alten IP fest verdrahtet ist... - Anwendungen, bei denen auf den PDC zugegriffen wird und zwar nicht über den Namen, sondern die IP ? Evtl. im Programm versteckt ? Die laufen dann auch ins Leere ... - Evtl. Druckerfreigaben über die IP ? ... Tscha, mehr fällt mir momentan auch nicht ein... Grüsse schroeder750

Hy Christoph, habe das jetzt endlich mal in einer sauberen Umgebung testen können, hast wirklich recht, das funzt wunderbar, einfach die Namen der lokalen User anzugeben, auch wenn der DC selber damit im Moment nichts anfangen kann. Der Client interpretiert es dann entsprechend und erlaubt/verbietet die lokale Anmaledung. Danke für diesen Tip, daß es so funktioniert, hätte ich nicht erwartet. Super !!! Und danke auch nochmal für den letzten Tip, das werde ich dann mal in Ruhe durchschauen, wenn ich beim Kunden draussen bin... Grüsse schroeder750

... lass Dich jetzt aber nicht von mir einschläfern, Du hast noch was zu tun !!! Oooooommmmm... :D @Data1701: Wenn Du das Dokument eh schon in den Fingern hast, würde ich mich drüber freuen, wenn Du es mir auch mal mailen könntest. Habe das schon des öfteren so durchgezogen, bin aber immer auf der Suche nach neuen Ideen oder Anregungen. Vielleicht habt Ihr ja was anders gemacht als ich in meinen Trampelpfaden ... würde mich freuen ;) Grüsse schroeder750

Hy Thomas, sorry, wenn ich jetzt hier die Spassbremse mache, aber die Wahrscheinlichkeit, daß der Chipsatz vom Board vom neuen Rechner passt ist leider nicht allzu hoch... Ich gönne es Dir ja, daß es passt, aber arg von Erfolg gekrönt sein, wird es wahrscheinlich nicht ... da wird Dich eher ein Bluescreen erwarten, weil die HAL nicht passt... :( Gerade bei solchen Servern wie dem Exchange ist es ja nun nicht unbedingt angesagt, herumzuexperimentieren. So ein Wochenende, an dem man sich solche Aktionen vornimmt, wird ruckzuck ziemlich kurz, glaub es mir ... Wenn Du schon neue Hardware holst, kannst Du das doch ganz gelassen und in Ruhe angehen... stress Dich nicht ... Neuen Exchange mit anderem Namen im laufenden Betrieb neben den alten stellen, in der gleichen Organisation hochziehen, die Replikation der öffentlichen Ordner anwerfen und anschließend immer wieder ganz geschmeidig Postfächer auf den neuen Exchange moven. Die Outlooks sind dann zwar auf den alten Exchange konfiguriert, bekommen aber bei der ersten Anmeldung vom alten Exchange mitgeteilt, daß ihre Postfächer nun auf dem neuen liegen. Der Eintrag für den Exchange wird dann automatisch geändert ... absolut stressfrei. Den alten Exchange musst Du dann nur lange genug laufen lassen, bis es alle Outlooks mitbekommen haben, bevor Du ihn dann sauber vor den Augen des neuen deinstallierst ... Falls es bei einigen Aussendienstmitarbeitern aus welchen Gründen auch immer nicht funktionieren sollte mit dem automatischen Umtragen im Outlook, kannst Du immer noch einen Alias im DNS setzen, der Anfragen auf den Namen des alten Exchange auf die IP des neuen umleitet. Diese Outlooks musst Du natürlich dann irgendwann mal umkonfigurieren, aber daß mit dem Alias kannst Du ja auch stressfrei ein Weilchen stehen lassen... Beim Replizieren der öffentlichen Ordner auch die versteckten systemordner nicht vergessen und vor der Deinstallation des alten Exchange die Replikation so legen, daß nur noch Replikate auf dem neuen vorgehalten werden... Denk mal in Ruhe drüber nach, bei einer vernünftigen Planung läuft das echt geschmeidig und stressfrei über die Bühne ... :D Oder habe ich das falsch verstanden und Du tauschst NUR DIE CPU aus ? Dann vergiss mein Gesabbel ... :D Grüsse und viel Erfolg !!! schroeder750

... kein Problem :D Wünsche Dir jedenfalls ein schönes langes Wochenende !! Grüsse schroeder750

Puha... habe ich so auch noch nicht gemacht... Würde mal als erster Ansatz von folgendem ausgehen: Wenn Du ein Postfach verschieben willst, muss ja in der anderen Domäne der jeweilige Benutzer auch vorhanden sein. Ein einfaches Neuanlegen dürfte hier nicht reichen, Du musst wohl die Benutzer incl. SID-History rüberschieben... Da gibt es das Active Directory Migration Tool, das habe ich bisher allerdings nur eingesetzt, um Benutzer von NT4 nach W2K3 zu migrieren... ob das zwischen zwei W2K3-Domänen hinhaut ... weiß auch nicht... Des weiteren müssen ja, so wie ich das sehe, die Exchangeserver zumindest mal in der gleichen Organisation sein, damit man die Postfächer moven kann... auch hier ein großes Fragezeichen ... :mad: Worum geht es denn genau ? Habt Ihr eine Firma aufgekauft und müsst nun alles verheiraten ? Grüsse schroeder750

Hmmm... haut bei mir zwar nicht hin, aber ich scheine eh noch ein anderes Problemchen in meiner Testumgebung zu haben... werde da mal sauber was neues, nacktes aufbauen... und dann wieder berichten, O.K ? Hieße aber in letzter Konsequenz auch, daß ich mit diesem Eintrag alle lokalen User aller Workstations, die zufällig gleich heißen, aussperre, richtig ? Jetzt muss ich bei dem Kunden nur nochmal nachsehen, warum ich überhaupt diesen kleinen Kunstgriff machen musste, an diesem Punkt in der default domain policy überhaupt etwas zu konfigurieren... Als nichts konfiguriert war (standard) konnten sich ja die User der alten NT4-Domäne nicht mehr an den Rechnern anmelden, sobald diese ihr Computerkonto in der neuen Domäne hatten. Ist ja auch ein absolut untypisches Verhalten... die User der NT4-Domäne sind ja definitiv Mitglied der lokalen Gruppe der Benutzer der AD-Struktur... Wenn die alte Domäne gestorben ist und der Trust gekillt wurde, kann ich ja dann theoretisch wieder alles auf "nicht definiert" setzen, dann wird ja eh niemand mehr ausgesperrt... aber bis dahin ... :mad: O.K. danke Dir aber schonmal für Deine Hartnäckigkeit mir zu helfen !!!! :) Ich melde mich wieder !! Grüsse schroeder750

Hmmm... ist der Nachrichtendienst in der Domäne eingeschaltet ? Ließe sich sowas nicht über einen Eintrag im Logonscript realisieren ? "Net send %USERNAME% "Willkommen in der Domäne BlaBla" oder ähnliches ? Da schonmal nachgeschaut ? Vielleicht ist der Admin ein kleiner Perfektionist, der sich an solchen Sachen verkünstelt ? Nur so als fixen Ansatz ... Grüsse schroeder750

Moin Christoph35, zuerst wieder einmal Dank für Deine Bemühungen :D Und ich denke, jetzt kommen wir auch langsam zu dem Punkt, den ich meine: Und genau DA klemmt es bei mir: Du sagst "Mitglied der lokalen Gruppe Users". Ich hoffe, damit meinst Du die lokale Gruppe auf dem CLIENT, nicht die lokale Gruppe der Domäne... WIE bitte gibst Du diesen lokalen Benutzer, der ja nun auf ir-gend-einer Kiste, die zufällig Mitglied der Domäne ist in der Default Domain Policy bei Deny logon locally ein ? Genau daaaaa klemmt es bei mir :D :D Ich habe eben mal die default domain policy geöffnet, da bekomme ich doch nirgendwo diesen lokalen User eines Rechners aufgelöst, wenn ich ihn eingeben will ... Klar, ich kann da per Hand einfach den namen des Benutzers reinpinseln und OK klicken, mit dieser Info kann der DC jedoch überhaupt nix anfangen, der kennt diesen User ja nicht ... Buuuäääähhh... ich raffe es einfach nicht Gib mir´n Schubs in die richtige Richtung ... :wink2: Grüsse schroeder750

@GuentherH: Wow, danke Dir für die Info ! Das hab ich bisher nicht gewusst da ich mit SBS erst recht wenig zu tun hatte. D.h: wenn ich auf einen SBS migrieren will, baue ich mir im Vorfeld ne gute Planung zurecht und habe dann ab Installation 7 Tage Zeit, an der Kiste zu arbeiten, wie an einem normalen Server ? - Gut zu Wissen !! Und der umgekehrte Weg ? Eine Migration von einem bestehenden SBS, der schon ein paar Monate oder Jährchen vor sich hingedümpelt hat ? Kann ich es da auch irgendwie erreichen, daß ich einen Trust (wenn eben auch nur für ein paar Tage) aufbauen kann ? Würde mich mal brennend interessieren ;) Danke schonmal für die Info !! Grüsse schroeder750

Moin moin, hauerha...habe kaum die Augen auf und sehe, was hier abgeht... locker bleiben Jungs... :D Zum NewSid nochmal: Ich kann verstehen, daß es Leute gibt, die es nicht gerne einsetzen. Keine Einwände von mir... Ich muss jedoch zur Ehrenrettung von NewSid sagen, daß ich es regelmäßig einsetze, wenn ich mir größere Testumgebungen unter VMWare (Workstation) aufbaue. Ich habe hier jeweils ein einziges erbärmliches Template für meine Server und klone die Dinger x Mal um sie dann zusammen im Netz einzusetzen. Is immer sauber gelaufen... Klonen mit NewSid natürlich BEVOR ich irgendwas mit dcpromo oder ähnlichem mache, klar... Ich kann aber meinen Vorrednern nur zustimmen, einen weiteren Server manuell aufzusetzen ist ja nun Soooo ein großer Akt nicht. Besonders wenn es um eine produktive Umgebung geht. Wenn man ein genzes Rudel von 20 Servern aufsetzen muss, dann kann man sich Gedanken über Automatismen machen, aber für einen Server ... ;) Zur Faulheit: Da kann ich allerdings JeffRoc zustimmen, bin da genauso gestrickt... Manchmal stecke ich auch mehr Energie in die Gedanken, wie ich es am Einfachsten machen kann und merke gar nicht, daß ich es in der Zeit auf konventionelle Weise schon lange durchgezogen hätte... Aber ich denke, da ist dann oftmals mehr die technische Neugierde im Vordergrund. Wenn man Dinge teilweise umständlicher macht und sich festbeißt, ist das für mich der beste Nährboden um was zu lernen. Auch wenn dabei die Kiste mal vor die Wand fährt... solange das nichts produktives beeinträchtigt... warum nicht ? :D ... Und jetzt wünsche ich Euch einen schönen Tag und seid lieb zueinander :D :D :D Grüsse schroeder750

Hy Christoph, danke Dir fürs testen !!! Eben gehts ans Eingemachte... Ich hake da aber trotzdem nochmal nach: Dein Benutzer "tuser1" ist ja, wie Du schreibst, ein Domänenbenutzer... na klar ist der Mitglied der Gruppe "Users" (ist ja die lokale Domänengruppe, im deutschen heissen die ja "Benutzer"). Bis dahin alles ganz logisch. Komme ja selbst ich mit :D Nur der Schluss, daß man auch auf lokale Benutzer des Clients berechtigen kann ist mir in diesem Moment schleierhaft. Du hast die Berechtigungen in der Domain Policy auf eine lokale Domänengruppe vergeben und mit einem Domänenbenutzer getestet, d.h. bei der Anmeldung am Client mit dem Benutzer "tuser1" hast Du ja unten die Domäne angegeben gehabt, sehe ich das richtig ? Jetzt sei doch so gut und lege lokal auf Deinem Testclient mal einen Benutzer an, der z.B "tuser2" heißt und erklär mir, wie Du dem Benutzer verbieten willst, sich lokal am Rechner anzumelden, also unten in der Anmeldemaske den lokalen Rechnernamen ... Nicht das wir aneinander vorbeireden, ich meine keinen Domänenbenutzer einer lokalen Gruppe der Domäne, sondern wirklich einen lokalen Benutzer auf einem Rechner, so wie ich ihn auch zu Hause auf meinem XP ohne Domäne anlegen kann. Sorry, ich weiß ich nerve, aber ich habe echt immer noch kein Ergebnis, das ich erkennen könnte... Ganz davon ab werde ich hier echt noch wahnsinnig in meiner Testumgebung. Ich habe hier einen W2K-Client, da gibt es ja noch kein "gpupdate". Ich hatte irgendwas von "ipsec /refreshpolicy" in Erinnerung, aber das kennt der Client auch nicht. Ich habe die Domäne samt Rechner jetzt schon den ganzen Tag am Laufen, so daß sich die policy auch von selbst durchrepliziert haben müsste, auch den Client neu gestartet, wenn Du aber meinst, der Testbenutzer, dem ich ausdrücklich verboten habe, sich an der Domäne anzumelden, bekommt auf die Finger gehauen... Fehlanzeige ... Grüsse schroeder750

Moin sisifus, ein kleiner Grund, der gegen einen SBS spräche, wäre die Frage, wie Du die Migration auf die neuen AD-Strukturen durchziehen willst. Eine saubere Parallelmigration ist ja nun nicht drin, da der SBS ja keinen Trust unterstützt. InPlace-Migration mit einem SBS... habe ich noch nicht gemacht, kann ich nichts dazu sagen... Ich denke aber, daß es bei Deiner handlichen Userzahl eher unwichtig sein wird, da Du ja notfalls die paar Accounts händisch anlegen kannst... Dies nur so als kleiner Einwurf zum Nachdenken ;) Grüsse schroeder750

Sorry, hat sich jetzt mit Christoph ein wenig überschnitten. @Christoph35: Ach soooo, mit dem Migrationsassistenten meinst Du den vom ADMT zur Benutzermigration... jetzt wird mir einiges klar... :D Soweit waren wir ja noch gar nicht. DEN setze ich natürlich auch später ein, aber wir müssen doch erstmal die Grundlagen schaffen... Wenn ich die entsprechenden Berechtigungen und den Trust untendrunter nicht habe, fahre ich doch mit dem Assistenten auch vor die Wand...oder hast Du schon erfolgreich mit dem Assistenten migriert, ohne die Vorarbeiten zu machen ? Das würde mich jetzt wirklich wundern... Ich denke, Jimmypop hat hier noch ein Problem, daß lange vorher kommt, da passt ja schon der Zugriff aus der einen in die andere Domäne nicht... Schaun mer mal weiter ... :D Grüsse schroeder750