Daim

Servus, es sollte generell in der IT auf Sonderzeichen verzichtet werden, um von vornherein sich keine Stolpersteine (auch in die Zukunft blicken) vor den Weg zu legen. Es gibt mit Umlauten Probleme, siehe diesen Artikel. Dort gilt das "oe" als ö (englische Tastatur). Man kann sich dann z.B. mit "Müller" sowie "Muller" anmelden. An account name conflict occurs when you upgrade a Windows NT 4.0 primary domain controller to a Windows 2000 domain controller Wohingegen in einigen AD-Attributen werden auch die Umlaute wie die normalen Vokale behandelt (ü=u, ö=o usw.). Windows logon behavior if your user name contains characters that have accents or other diacritical marks Eine direkte technische Hürde gibt es nicht. Man bekommt/oder wird aber an vielen Stellen an Probleme stoßen, z.B. in einem CMD-Fenster bei der Ansprache des Objekts oder bei Dritt-Anbietertools usw. usf.

Servus, die GPO-Protokollierung lässt sich leider nicht so ohne weiteres einstellen. Du könntest die Option "Verzeichnisdienstzugriff überwachen" um Domänen-GPOs zu überwachen sowie die Option "Objektzugriffsversuche überwachen" auf den entsprechenden Ordner einstellen. Besser wäre hier auf Dritt-Anbieter Tools zu gehen, wie z.B. von NetIQ: NetIQ: Monitoring your IT environment from a service perspective to maximize application and service availability.

Servus, soweit ich weiß, kann man in einer Windows Server 2003er Umgebung, zwei Lizenzserver in der Enterprise Konfiguration parallel laufen lassen. Jeder Server bekommt die Hälfte der CALs. Wenn nun auf einem der Server die CALs zu ende gehen, verweist er automatisch auf den zweiten Server: Aber das liest du bitte genauer in diesem Whitepaper nach: http://download.microsoft.com/download/2/f/2/2f2dc861-d567-4492-ae88-81afafa2d08d/Terminal%20Server%20Licensing.doc

Du solltest zuerst die neue Domäne erstellen und anschließend mit ADMT die User sowie Clients in die neue Domäne migrieren. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Nach der Migration der Dateien, sollten ohnehin die ACLs der neuen Domäne angepasst werden. Was soviel bedeutet, neu vergeben werden.

Merke: Du solltest AUCH die Links lesen, die man dir postet. Dort wird deine Frage beantwortet ;) . Nein. Lese zuerst den Artikel bezgl. der FSMO-Rollen. Die FSMO-Rollen werden eben für besondere Funktionen gebraucht. Wenn z.B. der Träger der FSMO-Rollen crashen und somit die FSMO-Rollen nicht zur Verfügung stehen würden, dann würde erstmal die Domäne weiterhin funktionieren. Folgende Beispiele: - Ohne den PDC-Emulator, kann man nicht mehr auf die GPOs bearbeiten ohne die Zeitsynchronisation ist gestört. - Ohne den RID-Master, können die DCs (wenn sie ihre 500 SIDs verbraucht haben) keine Objekte mehr erstellen. - Eine Schemaerweiterung ist ohne den Schema-Master nicht möglich. usw. Wenn nun also der DC der die FSMO-Rollen innehat crashen würde, so müsste man die Rollen "mit Gewalt" (per seize) auf einen anderen DC verschieben. Das wird aber auch in dem o.g. Artikel erwähnt.

Wenn es sich um lokale Profile handelt, dann schon. Denn zum Migrieren der Benutzerprofile, musst du im ersten Schritt das Benutzer- und im zweiten das Computerkonto migrieren. Beim zweiten Schritt werden du die lokalen Ressurcen übersetzt. Handelt es sich um servergespeicherte Profile, so kannst du diese mit "xcopy -o" auf den neuen Server kopieren. Anschließend trägst du den neuen Pfad in den Benutzereigenschaften des Benutzerkontos ein.

Buenos dias, als Faustregel gilt: Idalerweise sollte in JEDER Domäne (eine logische Komponente des Active Directory) min. zwei Domänencontroller existieren. Abhängig von der Größe, Anzahl der Standorte und Design der Gesamtstruktur kann es natürlich notwendig werden, weitere DCs hinzuzufügen. Warum sollten nun min. zwei DCs pro Domäne existieren? Ganz einfach: Das bei einem DC-Crash die Domäne mit samt den Benutzerkonten weiterhin ohne Ausfall besteht. Des Weiteren funktionieren Applikationen/Dienste weiter, die auf von der Domäne abhängig sind. Des Weiteren gibt es fünf FSMO-Rollen (Flexible Single Master Operations) ab einer Windows 2000 Domäne. Diese wären: - Schemamaster (kann nur einmal in der Gesamtstruktur existieren) - Domänennamenmaster (kann nur einmal in der Gesamtstruktur existieren) - PDC-Emulator (kann nur einmal pro Domäne existieren) - Infrastrukturmaster (kann nur einmal pro Domäne existieren) - RID-Master (kann nur einmal pro Domäne existieren) Diese Betriebsmaster-Rollen haben eine besondere Rolle in der Gesamtstruktur bzw. Domäne. Wenn z.B. der Schemamaster nicht erreichbar wäre, könnte man kein Schemaänderung vornehmen. Oder falls der Domänennamenmaster nicht mehr erreichbar wäre, könnte man keine Domäne in dem Forest hinzufügen usw. So hat jeder der fünf FSMO-Rollen seine /besondere/ Rolle. Dann gibt es noch den Global Catalog - GC. Dieser zählt aber nicht als einer der FSMO-Rollen. Der globale Katalog hat keine eigene Datenbank, und auch keine eigenen Bereiche innerhalb der Datenbank. Innerhalb einer Domäne sind die Informationen sofort auch über den GC verfügbar, die Informationen aus fremden Domänen werden über die normale Replikation auf die Server übertragen. Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Wer oder was ist das denn?

Servus, das ist genau ein Domänencontroller zu wenig. Ja, Exchange 2007 darf produktiv nur auf 64Bit laufen. Lediglich für Test- und Schulungszwecke kann man für 120 Tage die 32Bit Version von Exchange installieren. Worauf man allerdings verzichten sollte, nämlich einen Exchange auf einem DC zu installieren. Das wird seitens Microtosft nicht empfohlen. Technisch funktioniert das. Aber wenn einmal Exchange installiert wurde, darf ab diesem Zeitpunkt der Server in seiner Rolle nicht verändert werden. Das bedeutet, installiert man einen Exchange auf einem Memberserver, dann darf zu einem späteren Zeitpunkt der Memberserver nicht zum DC gestuft werden. Das gleiche gilt auch im umgekehrten Fall. Der DC auf dem das Exchange installiert ist, sollte nicht heruntergestuft werden. Das wird von Microsoft nicht supportet. Du solltest zwei DCs in der Domäen betreiben und desweiteren, würde ich den Exchange 2007 auf einem Memberserver installieren. Warum kannst du den DC nicht hochstufen? Das interpretierst du aus dem Artikel aber falsch. Du musst bevor du einen 2003er DC in eine 2000er Domäne hinzufügen möchtest, zuerst das Schema aktualisieren. Genau das steht in diesem Punkt 4. Dazu führst du eben das ADPREP auf deinem 2000er Schema-Master aus. 2. Leider kann ich diese aber nicht vorbereiten weil Exchange 2k das verhindert. (Siehe Link Punkt 7.) Du musst eben vorher zuerst das Schema "korrigieren". Siehe dazu: Yusuf`s Directory - Blog - Das Active Directory Preparation Tool - ADPREP Ja klar, genau so funktioniert das auch. Aber da eben dein neuer Server ein Windows Server 2003 ist und du diesen in deiner 2000er Domäne als DC nutzen möchtest, musst du vorher das Schema aktualisieren. Aktualisieren auf Exchange 2007

Das macht aber das ADMT automatisch. Das ADMT ändert nicht die ACLs der Freigaben oder Dateien, sondern legt einen neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SID-History zu. Streiche "vielleicht". OK. In dieser Situation kann man natürlich mit den beiden Kommandozeilen-Tools gezielter die einzelnen Attribute mitnehmen. @gelbeseiten Prima. Freut mich :) .

Das sollte man schon als Administrator wissen... Es ist genau so wie ich es vermutet hatte. Die Domäne FIRMA (firma.intern) stellt die Root-Domäne dar und die Domäne STANDORT (standort.firma.intern) ist eine Sub-Domäne. Somit kannst du die Root-Domäne FIRMA nicht entfernen, da du ansonsten die Domäne STANDORT quasi zerstörst. Eine Möglichkeit wäre, migriere beide Domänen mit ADMT in eine neue Domäne.

Salut, ja, dass kann man machen. Ahaa... du willst quasi die Server "vom Rest" abschotten in dem du die Server alleien in eine eigene Domäöne stellst. Solch eine Frage/Anforderung liest man eher selten, finde ich aber als eine tolle Aufgabe ;) . Da könnte man fast philosophieren. Früher wurde seitens Microsoft verkündet, dass die Domänen-Grenze die Sicherheitsgrenze darstellen würde. Später hat man erkannt, dass nicht die Domäne, sondern die Gesamtstruktur die Sicherheitsgrenze darstellt. Ich sehe es sowohl als auch und im übrigen, es wird zu heiß gegessen wie es gekocht wird. 1. Die Domäne stellt die Grenze für administrative Fehler bzw. die Aufgabengrenze der Administratoren dar. 2. Die Gesamtstruktur ist die Grenze der Sicherheit, gegen Angriffe von aussen. Daher sollte man sich überlegen, ob man die Server in eine Sub-Domäne oder wie in deinem Fall nach meiner Meinung besseren Variante, einen eigenen Single-Domänen Forest erstellt. Das ist es in der Tat. Bevor ICH eine Domäne umbenenn - was ohnehin nur in der Gesamtstrukturfunktionsebene Windows Server 2003 funktioniert - setze ich sie neu auf. Das kann man machen, ist aber ein steiniger Weg. Wenn dich der Name der Domäne stört, würde ich eine Neuinstallation (bei nicht so einer großen Umgebung) empfehlen. Was die Sicherheit der Server betrifft, sollte man den Gedanken einer eigenen Gesamtstruktur für die Server nicht ausser Acht lassen.

Servus, es handelt sich also um eine Gesamtstruktur? Stellt die Domäne FIRMA die Root-Domäne dar? Wenn die Domäne FIRMA die Root-Domäne der Gesamtstruktur ist, kannst du diese nicht entfernen, denn ansonsten verlierst du deine gesamte Gesamtstruktur und somit auch die Domäne STANDORT.

Das ganze funktioniert aber nicht als USER. Noch nicht einmal den Container NetServices bekommt man als User auf der Workstation zu sehen.

... und was machst du mit den Profilen? Was machst du mit den ACLs in den Freigaben? Es gibts nichts einfacheres als ADMT. Wenn aus irgendeinem Grund das ADMT nicht eingesetzt werden dürfte/könnte, dann käme CSVDE oder LDIFDE in Frage. Nein, beide Komandozeilen-Tools sind im Windows Server 2003 Out-of-the-Box enthalten.

Doch, es bleiben trotzdem lediglich "kleinere Handgriffe" übrig. Stell dir nur mal vor, dass du KOMPLETT das ganze Diagramm samt den ganzen Informationen (Domänen, jeder DC, Site-Links, Inter-Site, Intra-Site etc.) händisch erstellen müsstest... und das bei 94 Sites :shock: . Dann würde ich viel Spass wünschen ;) .

Servus, du möchtest quasi eine Domäne auflösen. Dabei muss die ganze Domäne in die andere überführt werden. Dann kannst du entweder: - eine Migration mit ADMT der DomäneB in DomäneA durchführen - oder du erstellst eine ganz neue Domäne und migrierst beide Domänen in die neue Domäne. Das ist natürlich mit mehr Aufwand verbunden. Die wenigste Arbeit hast du mit der ersten Variante. Mit dem ADMT werden die Benutzer- sowie Computerkonten (Clients und Memberserver) migriert. Es werden aber die die DCs migriert. Dieses müsstest du aus der alten Domäne demoten (herunterstufen) und in der neuen Domäne erneut promoten (heraufstufen). Damit man mit ADMT migrieren kann, ist eine Namensauflösung sowie eine Vertrauensstellung notwendig (die Insider bekommen das auch ohne einen Trust hin). Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Das muss du dann ggf. mit dem Hersteller noch verifizieren. ADMT ist dein Freund.

Zu 1. Bitte ;) . Zu 2. OK, so genau ahtte ich das bisher nicht untersucht. Der XP-Client kann ja standardmäßig NTLM sowie Kerberos und wenn in der Domäne NTLM läuft, dann sollte das auch funktionieren. Allerdings wundere ich mich trotzdem, dass keine Anzeichen diesbezüglich irgendwo bestehen bzw. protokolliert werden. Denn die Fehlermeldungen aus diesem Artikel sollten das Problem protokollieren, was nicht passiert: Resetting computer accounts in Windows 2000 and Windows XP Das will natürlich nicht viel heißen... Aber nun gut, wenn ich die Zeit finde (in diesem Leben), werde ich dem einmal nachgehen und einige Tests durchführen.

Bei NT sind es 7 Tage und ab Windows 2000 sind es standardmäßig alle 30 Tage. Effects of machine account replication on a domain Das kann ich so nicht bestätigen, zwar ohne Quellen-Angabe aber dafür die eigene praktische Erfahrung. Im Büro arbeite ich an einem Desktop PC. Ich habe aber auch ein Firmen-Laptop das hauptsächlich daheim auf dem Wohnzimmer-Tisch steht. Wenn ich das Laptop alle 180 Tage (eher länger) mal mit in die Firma nehme, dann hatte ich noch nie Probleme mich ganz normal an der Domäne anzumelden. Des Weiteren konnte ich mich auch ganz normal in der Domäne bewegen konnte. Die Ereigniseinträge blieben ebenfalls schweigsam. Danach müsste der Client aber erneut in die Domäne joinen.

Buenos dias, siehe (runter scrollen): Yusuf`s Directory - Blog - Computerkonto löschen Nein, wird er nicht. Der Client versucht dann sofort beim booten ein neues Computerkonto-Kennwort beim DC anzufordern.

Hallo zusammen, einige werden es bereits mitbekommen haben. Microsoft hat vor kurzem ein aktualisiertes Tool herausgebracht, womit man sich ein Visio-Diagramm über die bestehende Active Directory Gesamtstruktur auf Knopfdruck erstellen kann. Aber liest doch einfach selbst ;) . Yusuf`s Directory - Blog - Active Directory Topology Diagrammer - ADTD

Servus, naja, ich bin zwar kein Exchange-Experte, aber ich antworte trotzdem ;) . Ich antworte mal ohne mir die Links angeschaut zu haben. Produktiv ja. Es besteht jedoch die Möglichkeit zu Test- und Schulungszwecken die 32Bit Version von Exchange für 120 Tage zu nutzen. Aber nach 120 Tagen läuft Exchange trotzdem weiter ;) . Jein. R2 gibt es sowohl in der 32Bit, als auch in der 64Bit Version. Wenn du R2 installierst (egal ob mit einer oder beiden CDs), dann läuft dein System mit einem Windows Server 2003 mit SP1. Ohne die CD2, läuft das System eben ohne die R2-Features. Natürlich lässt sich Exchange installieren. Genau so sieht es aus. R2 gibt es als 32Bit und 64Bit Version. Alle meine R2-Systeme laufen auf 32Bit.

Idealer wäre es, wenn man das direkt auf der Ziel-Maschine ausführt.

Servus, erkläre das mal genauer. Führst du das dsquery direkt auf dem DC aus ? Es gibt ja noch einen anderen Weg wie man "alte" Computerkonten entdeckt. In dem eine Abfrage gestartet und überprüft wird, wann der Client zuletzt sein Computerkonto-Kennwort geändert hat. Siehe: Yusuf`s Directory - Blog - Computerkonto löschen

Das ist dann aber auch ein "lokales" Problem der nicht standardmäßig auftritt. Weder das eine, noch das andere Problem von dir, habe ich jemals - mit sicherlich über 1.000 DC-Installationen (Produktiv+Testumgebung+VMs) - noch nie gehabt. Da liegt dann irgendwo der Hase im Pfeffer begraben. Das ist aber kein Normalzustand und ich kann mich nur wiederholen, es ist egal ob der Server vorher Mitglied der Domäne ist oder nicht. Völlig korrekt. Nein, ist es natürlich nicht. Nur gilt es eben die Fehlerquelle herauszufinden. Deine Logs wurden zwar noch nicht freigeschaltet, aber führe auf dem ersten DC sicherheitshalber das DCPROMO /v aus. DCPROMO findest du in den Windows Support Tools.

Das hat an dieser Stelle mit der Installation des DNS auch nichts zu tun. Das sieht zumindest von hier aus richtig aus. Der Link beschreibt das was es zu tun gilt, mehr gibt es nicht zu beachten. Das Benutzerkonto das du im Assistenten angibst ist der Domänen-Admin ? Du meinst, ob der Server vor dem promoten zum DC Mitglied der Domäne sein darf, also ein Memberserver ? Das ist "Jacke wie Hose", spielt keine Rolle. Dann kontrolliere doch mal das DCPROMOUI.LOG, welche Meldungen dort protokolliert wurden. Evtl. stehen dort weitere Hinweise. Yusuf`s Directory - Blog - Debug Protokollierung