Daim

Off-Topic:Sag doch sowas nicht. Aber Ende nimmt das jeder noch wahr. ;)

Servus, versuche es mal mit SUBST. Microsoft Corporation

Servus Edgar, korrekt. Mit ABE werden nicht die Freigaben, sondern, die sich darin befindlichen Verzeichnisse ausgeblendet, auf denen der entsprechende Benutzer keinen Zugriff hat.

Dann sollte dir dieser Artikel dabei helfen: Yusuf`s Directory - Blog - LDIFDE - LDAP Data Interchange Format Data Exchange Mach das. Sagen wir es mal so, es war --> für mich <-- nicht klar. ;)

Es liegt vielleicht am heutigen Mittwoch oder das es schon etwas später ist oder ich heute nicht ganz auf der Höhe bin... aber ich habe den Hintergrund immer noch nicht verstanden. Wie dem auch sei, du kannst z.B. mit CSVDE oder LDIFDE die Benutzer aus der einen Domäne exportieren und in einer neuen Domäne importieren. Das sind aber nicht die identischen Benutzerkonten. Es sind Benutzerkonten die den Ggleichen Namen sowie die gleichen Attribute besitzen (sofern es die standardattribute sind), aber die "neuen" Benutzerkonten bekommen in der neuen Domäne eine neue Objekt-GUID sowie Objekt-SID. Daher sind das dann "andere" Benutzerkonten. Skriptbasiert funktioniert das ganze natürlich auch. Ich habe zwar noch keinen Durchblick in diesem Szenario... aber LDIFDE wäre eine Möglichkeit.

Moin, du möchtest in eurer Abteilung einen einzelnen DC, quasi in einer neuen Struktur/Domäne aufstellen und dieser soll sich nur die Benutzerinformationen von der bestehenden Domäne ziehen? Falls ich richtig liege lautet die Antwort: Negativ. Das ist so nicht möglich. Testet ihr in eurer Gesamtstruktur einiges aus? Falls ja, dann sollte das natürlich in einer entsprechenden Testumgebung durchgeführt werden und nicht in der produktiven Umgebung. Wenn du nun sagst; "Ich benötige aber die produktive Umgebung", dann ziehe dir einen DC in eine VM und schotte diese VM von der produktiven Umgebung ab. Dann kannst du mit der VM testen. Natürlich sollte die VM auch sicher aufbewahrt werden, denn dieser hält z.B. alle Kennwörter der Umgebung. Was möchtest du denn erreichen?

Servus, ganz easy. ;) Gehe in der Suchmaske auf Ansicht. Dort kannst Du zusätzliche Spalten einblenden. Wähle dort die Spalte "X-500 definierter Name" aus, denn dann siehst du den Pfad direkt in der Suchmaske und musst nicht in die Eigenschaften der Benutzern gehen. Tattaa... ;) Oder aber auch diese Variante: faq-o-matic.net » Den LDAP-Pfad eines AD-Objekts anzeigen

Servus, der globale Katalog hält die Informationen einer Gesamtstruktur vor. Wird der GC auf einem DC aktiviert, werden die Informationen (genauer, die Domänenpartition) der anderen Domänen, auf den DC repliziert. Es werden also ALLE Objekte von den anderen Domänenpartitionen in den GC repliziert. Dabei findet die GC-Replikation mit einer niedrigeren Priorität als die standardmäßige AD-Replikation statt. Es werden alle Objekte - aber nur mit den wichtigsten Attributen und nicht allen - der Gesamtstruktur in den GC repliziert. Bis die Replikation des GC abgeschlossen wurde, hängt hauptsächlich von der Umgebung, Replikationstopologie, Bandbreite und die Anzahl an Objekten ab. Erst wenn die GC-Replikation abgeschlossen wurde, gibt sich der GC als solcher im AD bekannt. Du kannst z.B. eine Abfrage mit LDP auf dem DC durchführen und kontrollieren, ob der Eintrag "isGlobalCatalogReady" auf TRUE gesetzt ist. Oder du überprüfst das Verzeichnisdienstprotokoll und suchst nach der EventID 1119. Auch dann ist der GC bereit. Danach gibt sich der DC im AD als GC bekannt. Falsche Formulierung. Der GC kann und wird nur auf einem DC aktiviert. Jetzt kommt es darauf an, ob auf diesem DC der KDC aktiv ist - was standardmäßig der Fall ist. Dann authentifiziert die gleiche Maschine den Benutzer. Auch kommt es auf die Umgebung an. Handelt es sich um einen Single-Domänen Forest (es existeirt nur eine Domäne in der Gesamtstruktur), so kann sich der Benutzer auch dann anmelden, wenn KEIN GC zur Verfügung steht. Siehe auch: Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Richtig. Wenn eine Gesamtstruktur aus mehreren Domänen besteht und auf einem Domänencontroller, der Windows Server 2003 ausführt, die Option "zwischenspeichern universeller Gruppenmitgliedschaften" aktiviert ist, werden die Informationen zu den universellen Gruppenmitgliedschaften aller Benutzer von dem DC zwischengespeichert. Jeder Benutzer erhält dann eine aktuelle zwischengespeicherte Liste seiner universellen Gruppenmitgliedschaften. Der DC - der z.B. an einem Standort steht - müsste keine Verbindung zu einem GC aufbauen. In der Praxis bietet es sich aber in vielen Umgbungen an, auf jedem DC den GC zu aktivieren. Es kommt eben auf die Umgebung an, den die Replikationslast des GCs ist nicht so gewaltig wie es oft diskutiert wird.

Warum wählst du dann nicht als Desgin den Single-Domänen Forest? Denn jede Domäne sollte idealerweise auch zwei DCs betreiben. Bildest du aus jedem Unternehmen eine eigene Gesamtstruktur, bräuchtest du idealerweise bei vier Strukturen, acht DCs. Da wäre mir ein Single-Domänen Forest sehr viel lieber. Ich betone, um ein (Fein-) Konzept zu erstellen müsste man sich die ganze Angelegenheit vor Ort anschauen. Daher wäre ein externer Dienstleister evtl. zu rate zu ziehen.

Dann wäre ein Single-Domänen Forest für die Administration das einfachere Desgin. Wie bereits erwähnt ist das so in einer Gesamtstruktur so nicht möglich, ohne das die Struktur "zerschrotet" wird. Denn standardmäßig werden innerhalb einer Gesamtstruktur transitive bidirektionale Vertrauensstellungen erstellt die du nicht ohne weiteres entfernen kannst. Du könntest lediglich mit ADSIEdit "mit Gewalt" den Trust aufheben, aber was passiert dann mit der AD-Replikation? Lange Rede kurzer Sinn.... vergiss es. Und wie! Das kann man machen. Vom Design her, hast du dann ein hohes Maß an Sicherheit. Die Administration erhöht sich dabei erheblich. Denn wenn sich ein Benutzer "irgendwie" höhere Rechte verschaffen sollte, ist lediglich - wenn - dann nur die EINE Gesamtstruktur "in Gefahr" und nicht alle weiteren. Nein, nichts. Das funktioniert auch.

Was ich aber auch für sehr wichtig halte, ist die Namenskonvention der Domänen. Denn was passiert, wenn die Firma übermorgen erneut firmiert oder verkauft wird? Soll dann nur wegen dem Namen die Struktur neu aufgebaut werden? Für die Wahl des Domänen-Namens, gibt es ebenfalls mehrere Varianten: 1. Der Active Directory-Name lautet so wie die Internetdomain. 2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt. Bedeutet, wenn der Inet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". 3. Der Active Directory-Name ist ein anderer als die Inet-Domain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.). 4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net. Dabei sollten natürlich beide Domains beim ISP registriert werden. 5. Die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ. ISO 3166 – Wikipedia 6. Es wird ein abstrakter Name gewählt, der nicht unbedingt eins zu eins dem Firmennamen lautet. Darüber sollte m.E. nachgedacht werden. Möglich ist es, man muss die Anforderungen abwägen. Einwandfrei. So macht das am meisten spass. ;)

Moin, exakto mundo. Das Konstrukt kann man machen. Aber was war der Grund für dieses Design? Über das Design einer Gesamtstruktur kann man viel diskutieren. Bei dem Design muss wie so oft - das Ziel - klar vor Augen sein. Was will man erreichen? Bei deinem vorgeschlagenen Design hättest du also am Ende vier Domänen in einer Gesamtstruktur. Eine Root-Domäne und weitere drei Sub-Domänen, vermutlich die auf gleicher Ebene sind. Wer administriert denn die Root- sowie Sub-Domänen? Ist es die gleiche IT-Abteilung oder haben die Sub-Domänen ihre eigenen EDV-Leute? Falls es die gleichen EDVler sind, die die Root- sowie Sub-Domänen administrieren, wäre ein Single-Domänen Forest für die Administration das einfachere Design. Ist hier eine hohe Sicherheit gefragt? Dann könnte man die Ressourcen in eine eigene Gesamtstruktur stecken, so das also zwei Gesamtstukrutren die mit einer Gesamtstrukturvertrauensstellung (von mir aus mit einer selektiven Authentifizierung) verbunden wären. Bei deinem Design steckst du die File-Server (neben dem Echange-Server) in die Root. Bei diesem Design trifft man in der Praxis oftmals den Fall, dass gerade die Root-Domäne leer ist, sich also dort ausser den beiden Root-DCs nichts befindet. Aber natürlich kann man dort die File-Server plazieren, damit alle Sub-Domänen darauf Zugriff haben. Ich schreibe mal ein paar Punkte auf, die mir in den Sinn kommen. Der Nachteil bei mehreren Domänen wären: - Bei mehreren Domänen ist der adminstrative Aufwand Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte. - Dadurch entstehen hohe Hardware- sowie Lizenzkosten. - Jeder DC sollte/muss vor Ort physikalisch geschützt sein. - Jede Domäne muss gesichert werden (Backup). Bei mehreren Domänen wären die Vorteile: - Wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. - Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. - Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden (was mit Windows Server 2008 obsolet ist). Der Vorteil einer Domäne wäre z.B.: - Das man nur eine DNS-Zone/Domäne verwalten muss. - Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration. Ich persönlich tendiere gerne zu dem Einen-Domänen-Modell (Single-Domain Forest), aber das kommt immer auf die Gegebenheiten darauf an. Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen, mit dem ihr zusammen die Randbedingungen absteckt. ... to be continued.

Servus, die Zeitsynchronisation in einer AD-Umgebung funktioniert folgendermaßen: Den PDC-Emulator der Root-Domäne lässt man gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen. Auf der Firewall müsste der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie sollte nur innerhalb einer Gesamtstruktur synchron sein. Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem Logon-Server, also dem DC bei dem sich der Client anmeldet/authentifiziert. Wenn Du am w32time nichts gemacht hast, hast Du eine komplette Zeitsynchronisation. Die PDC-Emu. der Child-Domänen holen sich wiederum ihre Zeit, vom PDC-Emu der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur. Auf dem PDC-Emulator der Root-Domäne wäre folgender Befehl auszuführen: w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES Überprüfe anschließend das Eventlog. Wenn Du am w32time nichts gemacht hast, hast Du eine komplette Zeitsynchronisation. Du musst nur darauf achten das an den Clients sich die Zeit nicht mehr als 15 mins abweicht, denn dann verweigert w32time seinen Dienst. Hier müsstest Du dann von Hand erstmal nachstellen. Du kannst an einem XP-Client auch diesen Befehl händisch eingeben "w32tm /config /update /syncfromflags: DOMHIER". (<-- nach dem Doppelpunkt folgt kein Leerzeichen)

Ja, dass wäre eine Möglichkeit. Eine andere Möglichkeit wäre, wenn ein Netzwerkkabel im Client stecken würde, aber kein DC verfügbar wäre. Oder DNS-Probleme bzw. falsche Firewalleinstellungen auf dem Client etc.

Servus, dabei gibt es mehrere Möglichkeiten: - Die Scripting-Guys stellen folgende Variante vor Yusuf`s Directory - Blog - Wo ist der User angemeldet ? - Über ein Logon/Logoff-Skript Yusuf`s Directory - Blog - Anmeldungen protokollieren - Oder einer anderen Variante des Logonskripts faq-o-matic.net » Wie finde ich heraus, welcher Benutzer an welchem PC arbeitet? Aber die bequemste Variante, finde ich über das DNS. Wenn du das im DNS eingerichtet hast, kannst du danach den Benutzernamen anpingen udn erhälst somit die IP-Adresse: Wolfgang on the Road: 72: Wo ist der Benutzer angemeldet?

Aloha, die Zahl 10 steht für die zu zwischenspeichernden Benutzerkonten. Das bedeutet, es werden standardmäßig 10 (max. 50) Benutzerkonten lokal gecachet. Wenn sich die ersten 10 Benutzer EINMAL erfolgreich an der Domäne authentifiziert haben, können sie sich das nächste Mal lokal, mit ihren zwischengespeicherten Benutzerinformationen (also ohne eine Verbindung zum DC/Netzwerk) anmelden. Mit den zwischengespeicherten Benutzerinformationen kann sich dann der Benutzer auf ewig anmelden. Das ist in der Hilfe und auf diversen Seiten leider sehr unglücklich formuliert. Dieser Artikel berichtigt die Hilfe zu der GPO. "Interactive Logon: Number of Previous Logons to Cache" Help Topic Contains Incorrect Information

Das hat auch Claus nicht behauptet. Er schrieb "...bestimmt nicht zu Longhorn", also der BETA-Version des Windows Server 2008 ;) . Ochh... das ist doch schon ein alter Hut. Lieber etwas zu Windows 7 ;) .

Servus, schau an... schau an... wen man hier nicht alles trifft. Unsern Flo springt hier ja auch rum. ;) Gruß, Yusuf

Warum diesen Aufwand, wenn es mit einem einzigen A-Record im DNS erledigt ist?

Seit Windows Server 2003 kannst du einen DC umbenennen, was ich zwar vermeiden würde, da immer wieder Probleme auch bei der Umbenennung auftauchen können - aber technisch ist es möglich und ich habe es bereits mehrfach erfolgreich durchgeführt. Dabei würde ich dir die Variante mit NETDOM ans Herz legen. Denn das Tool ändert den Namen "sanfter", als das die GUI es tut. faq-o-matic.net » Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen? Die IP-Adresse kannst du ebenfalls ändern: Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

Servus, in dem du die Domäne mit NTDSUTIL - Metadata Cleanup händisch aus dem AD entfernst. How to remove orphaned domains from Active Directory

Ich habe dir dazu in meiner vorherigen Antwort, im ersten Absatz bereits die Antwort geliefert. Und um mehr RAM zu adressieren benötigt man nicht zwingend die 64Bit Version, sondern die 32Bit Enterprise Version kann ebenfalls mehr wie 4GB RAM adressieren. Wobei in der Zukunft ohnehin nur 64Bit Server laufen werden, denn ab Windows Server 2008 R2 - sofern es eine R2 Version geben wird, ansonsten das nächste Server Release - wird es keine 32Bit Version des Server-Betriebssystems mehr geben. Es wird nur noch 64Bit Versionen existieren. Die Hardware der letzten 3-4 Jahre ist bereits 64bittig.

Da wo es Sinn macht 32Bit und da wo es Sinn macht 64Bit ;) . Die DCs müssen ja nicht auf 64Bit laufen, zumindest wenn es sich nicht um unzählige Benutzer in der Domäne handelt. Nein, dass wird funktionieren. Du kannst ja in einer Windows Server 2008 Umgebung alle Versionen von Mitgliedsserver (NT/2000/2003) in der Domäne betreiben. Auch Windows Server 2000 sowie 2003 DCs können in einer Windows Server 2008 Domäne betrieben werden - sofern - es der Domänenfunktionsmodus dies zulässt.

Moin, richtige Entscheidung. Für 120 Clients reicht locker eine einzige Domäne, es sei denn, es gibt trifftige Gründe für das einrichten weiterer Domänen. Das Werkzeug das du dafür benötigst lautet ADMT. Wenn es finanziell keinen Unterschied macht, würde ich - sofern es die Umgebung unterstützt (eingesetzte Applikationen) - bereits jetzt auf Windows Server 2008 migrieren. Denn dann kann auch seitens der IT beireits Know-How für den Windows Server 2008 aufgebaut werden. Yusuf`s Directory - Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Moin, dann führe doch den Proces Monitor von Sysinternals/Microsoft aus, während du das Programm startest. Danach schaust du worauf das Programm alles in der Registry zugreift und passt die Rechte an den entsprechenden Stellen an.