Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ADMT User -> local admin rights

46 views
Skip to first unread message

sven....@creo-imagonem.de

unread,
Sep 18, 2002, 5:43:21 AM9/18/02
to
Hi @All,

To mirate from NT4 to Win2000 AD the ADMT Help says:

"The user used to run ADMT must have local administrator rights on the
workstations."

There are two sollutions in ADMT help too which both will not work for
me:

1.

- Cross Certify the old and new Domain (ok)

- Logon with the "NT4Domain\Administrator" to run ADMT --> No
sufficient
rights to run ADMT !!!

I have tryed to Add the "NT4Domain\Administrator" to the new
"Win2000ADDomain\Domain-Admins" Group, and bunch of other things to
obtain
more Rights -> no chance !


2.

Walk to each Local Machine to add "Win2000ADDomain\Domain-Admins" as
Local
Administrator ?!? (Is ok to migrate a small number of Clients ( 5 ?)
but
not more!)


Is there a sollution ?


Thanks for help....

Sven

Robert Pieroth

unread,
Sep 18, 2002, 2:00:38 PM9/18/02
to
<sven....@creo-imagonem.de> wrote

> To migrate from NT4 to Win2000 AD the ADMT Help says:
>
> "The user used to run ADMT must have local administrator rights on the
> workstations."
>
> There are two sollutions in ADMT help too which both will not work for
> me:
<snipped>

Hi sven, this is a german newsgroup!

Verify the following, may be you can make the things work (copied from
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr.asp)

However, if you need to clone users or groups, you need to set up the
environment as described in the "Configuration Requirements" section of the
description of ClonePrincipal. In order for ClonePrincipal & ADMT to work
properly, the following conditions must be met:
* The target domain must be running Windows 2000.
* The target domain must be running in Windows 2000 native mode.
* Source domain may be running:
*** Windows NT 4.0 (Service Pack 4 or later).
* For Windows NT 4.0 source domains: Modify the registry on the
source PDC, adding the DWORD value TcpipClientSupport to
HKLM\SYSTEM\CurrentControlSet\Control\LSA.
This value must be set to 1 to enable the Security Accounts Manager
(SAM) operations required for cloning to take place over remote procedure call (RPC).
* A trust must be created from the source domain to the target domain.
** The user carrying out the migrations must have membership of the
Domain Admins group in the target domain to clone.
** The user carrying out the migrations must also have administrator privileges
in the source domain; this can be achieved by adding the Domain Admins
group from the target domain to the Administrators group in the source domain.
* A local group must be created in the source domain called srcDomainName$$$,
where srcDomainName is the name of the source domain, that is, if the domain is
called Redmond, the group would be called Redmond$$$.
* Auditing of success and failure of account management operations must be enable
in both the source and target domains.

Best wishes
Robert Pieroth

Sven....@creo-imagonem.de

unread,
Sep 20, 2002, 5:33:38 AM9/20/02
to
Hallo Robert,

danke für die Info. Ich habe keine Ahnung wie ich auf den Trichter
gekommen bin hier Englisch zu posten. Sorry....

Ich habe alle Voraussetzungen nochmals geprüft. Soweit scheint alles OK zu
sein. Wenn ich das richtig verstanden habe muss sich der Administrator aus
der AD Domain (-> Account unter dem ich ADMT ausführe) lokal an den
Arbeitsstationen der alten Domain anmelden können. Da ich den AD Admin
aber nicht der alten Globalen Gruppe "Domain Admins" zuordnen kann bleibt
mir doch nur noch die Möglichkeit ihm im Benutzermanager -> Richtlinien
-> Benutzerrechte alle Rechte einzuräumen. Wen ich mich aber dann mit dem
AD Admin versuche auf einer Arbeitsstation (Win2000 Prof und XP Prof)
anzumelden scheint das zwar im ersten Moment zu funktionieren
("Benutzerdefinierte Einstellungen werden geladen..." taucht auf) aber
dann bleibt windows eine Ewigkeit hängen :-( . Irgendwann komme ich
dann auf den Desktop. Jetzt sollte ich doch z.B. auf die lokale
Benutzerverwaltung zugreifen können. Leider Fehlanzeige. Es wird ein Admin
Login gefordert. -> Keine lokalen Adminrechte.

Grober überblick über mein bisheriges Vorgehen:

- Win2000 Server SP3 installieren (gemischter Modus)
- Treiber einbinden
- alle Warnungen und Fehler im Ereignislog soweit möglich wegkonfigurieren
- AD konfigurieren
- restliche Fehler im Ereignislog wegkonfigurieren
- nach einem Neustart habe ich ein vollständig blaues Ereignislog
- Voraussetzungen für ADMT konfigurieren (Trusts, ...) ("netdom verify "
bestätigt die Trusts)

- noch im gemischten Modus testen ob der AD Admin lokale Rechte auf den
Arbeitsstationen hat :-(

In der Zwischenzeit habe ich das AD mal in den einheitlichen Modus
geschaltet um zu sehen was der ADMT Benutzermigrations-Assistent sagt
(Migration testen und später migrieren):

- ich komme bis zum Punkt "Zielkontainer für Benutzer wählen. Hier bekomme
ich mit durchsuchen kein Auswahlfenster (nur 5 Sekunden die Eieruhr).
- aus irgend einem Grund habe ich dann noch mal die Trusts mit netdom
verify überprüft: Jetzt bekomme ich kein "success" sonder Pfad zur Domäne
\\CREO-IMAGONEM nicht gefunden.

Was mache ich falsch ????

Grüsse,

Sven

Robert Pieroth

unread,
Sep 21, 2002, 8:25:02 AM9/21/02
to
<Sven....@creo-imagonem.de> schrieb

> danke für die Info. Ich habe keine Ahnung wie ich auf den Trichter
> gekommen bin hier Englisch zu posten. Sorry....

Hi Sven!

> Ich habe alle Voraussetzungen nochmals geprüft. Soweit scheint alles OK zu
> sein. Wenn ich das richtig verstanden habe muss sich der Administrator aus
> der AD Domain (-> Account unter dem ich ADMT ausführe) lokal an den
> Arbeitsstationen der alten Domain anmelden können.

Für ADMT ist die Einstellung (aus der Hilfe von ADMT - Kapitel "Vor dem
Durchführen einer Migration zwischen Gesamtstrukturen"):

Sicherheitsanforderungen:

Das Benutzerkonto, mit dem Sie sich beim Ausführen des Active Directory-
Migrationsprogramms anmelden, muss über die folgenden Berechtigungen verfügen:
- Domänenadministratorrechte in der Zieldomäne
- Mitglied der Gruppe Administratoren in der Quelldomäne
- Administratorrechte auf jedem Computer, der migriert wird
- Administratorrechte auf jedem Computer, auf dem die Sicherheit konvertiert wird

Die letzten beiden Punkte sind das, worauf Du ansprichst, denke ich... Diese lokalen
Adminrechte auf Clients brauchst Du nur dann, wenn Du auch Computerkonten
migrieren (verschieben willst). Zu diesen Punkten sagt die Hilfe im ADMT weiterhin:

Administratorzugriff auf die Objekte, die migriert werden sollen,
erhalten Sie auf zwei Arten:
* Erstellen einer temporären bidirektionalen Vertrauensstellung zwischen
der Zieldomäne und der Quelldomäne. Durch das Erstellen einer bidirektionalen
Vertrauensstellung können Sie das Programm ausführen, während Sie als
Administrator der Quelldomäne angemeldet sind. Dieses Konto verfügt bereits
über Administratorrechte für die Objekte, die Sie von der Quelldomäne migrieren.

* Fügen Sie ein Konto zur lokalen Gruppe Administratoren auf allen Arbeitsstationen
und Mitgliedsservern hinzu, die migriert werden sollen. Verwenden Sie dieses Konto
zur Anmeldung, während Sie das Programm ausführen. Der Prozess kann mithilfe der
Skripterstellung und ADSI (Active Directory Service Interfaces) automatisiert werden.

Du könntest als Lösung (um volle Dom-Admin Rechte in beiden Domänen zu bekommen)
also so vorgehen:
Erstelle eine bidirektionale Vertrauensstellung (siehe oben) und füge wechselseitig jeweils
die Dom-Admins der einen Domäne bei den Administratoren der anderen Domäne rein.
Integriere (wie oben zu lesen) das Dom-Admin Konto oder die Dom-Admin Gruppe der
W2K-Domäne in die lokale Administrator-Gruppe der Clients in der NT-Domäne. Weil das
recht viel Aufwand ist steht da oben der Hinweis auf "Scripterstellung" (z.Bsp. mit dem
Befehl "Net localgroup ...").
Vielleicht funktioniert alternativ dazu auch das (selber noch nicht probiert):
Die NT4-Dom-Admins sind ja automatisch in der lokalen Admins-Gruppe der NT4Clients -
durch dieselben Anmeldeinformationen könnte die Sache evtl. auch funktionieren, daher:
Am NT-PDC ein Domänen-Admin Userkonto anlegen, das bezüglich Anmeldename und
Passwort identisch ist zu dem W2K-Domänen-Admin, der die Migration macht.
(Gib hier ggf. mal Rückmeldung ob das schon reichte...)

Weitere Hinweise:
Bei "Netdom move" gewährleistet man die passenden Rechte beim jeweiligen
Programmaufruf einzeln mit den Parametern "/UserD" (Admin in Zieldomain)
und "/UserO" (Admin auf zu migrierender Maschine). Man könnte insofern auch
mit NetDOM die Computer migrieren, statt mit ADMT.

Hier im HowTo für ADMT ist es nochmal genau zu lesen, wo das Tool dann
ausgeführt werden muß:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q260871
You should run ADMT from the primary domain controller (PDC) that
is the Flexible Single Master Operation (FSMO) role holder in the target domain.
Also am W2K-DC ausführen, der PDC-Emulator ist.

> sondern Pfad zur Domäne
> \\CREO-IMAGONEM nicht gefunden.

Achte auch auf saubere Namensauflösung! Z.Bsp. durch einen
Domänen-Eintrag in der LMHOSTS der beiden PDC's zum jeweils anderen:

{IP-Adresse} {NT4-PDC-Name} #DOM:CREO-IMAGONEM

Auch eine Reverse-Lookupzone im W2K-DNS sollte vorhanden sein, wie man
in der Hilfe vom ADMT (unter Problemlösungen) lesen kann.
--
Viele Grüße
Robert Pieroth

0 new messages