[axplains]

Hello everyone,

I have a (perhaps trivial) question, but I could not find a straightforward answer anywhere...

I am migrating a W2K3 domain to a new one, using ADMT 3.

Following the steps in the provided guide, I have arrived to this point:
- migrated all global groups
- migrated users
Now it is the time to "translate local user profiles" with the "Security Translation Wizard" in ADMT.
That is, select the "Computer objects" in order to translate their user profiles.

Problem is: the wizard asks to select computers FROM THE TARGET DOMAIN. They are not there obviously, they still belong to the source domain.

So my doubts are:
- should I join the computers to the target domain before running the Security Translation?
- Join them afterwards?
- Or the operation will be made automatically by ADMT next step, "Computer Migration Wizard"?
- Or simply log on the target domain with the migrated user profiles while the workstation is in the source domain?

It is not specified in ADMT users guide, so I don't understand at what moment the workstations should join the target domain.

Thanks a lot in advance to anyone willing to help.

Axplains

[Akila]

I know how frustrating it could be that things are not exactly in the Guide.
any way your problem is very simple, It's is actually not a problem at all, but how ADMT works.

ADMT would security translate only computers that were already migrated (Computer object) to the new domain (and of course the groups and users should had been migrated before hand), that is why you see what you see.

You got two options , or I would start with what you should not do.
Don't dis/rejoin the computer to the new domain manually.

your options are :
1) Migrate the computer using the Computer migration wizard, still in the wizard you would be asked if you would like to security translate during the migration (by seeing all those check boxes you could tick , registry, shares, profiles, etc).
2) Migrate the computer using the Computer migration wizard, do not Translate the security in that step (untick all those check boxes you could tick - leaving them empty. -registry, shares, profiles, etc-), after your done migration the computer object, you can run the security translation wizard to translate the migrated computer (since it is in the new domain now).

NOTE: Security translation wizard does not only responsible for the Security,profiles,etc adjustment , but it is also responsible for the Dis/Rejoin the computer from the old domain into the new domain as from the Computer eyes.
The computer migration wizard (alone) is only responsible for migrating the AD Computer Object only.
Hope I answered your deeds.

[axplains]

Thank you very much for your clear explanation.

I understand and it makes sense; I had followed the ADMT guide, where Security Translation is before Computer Migration...

I tried the first method you suggested: the process went OK until the "Agent dialog" tries to pre-check and install the Agent into the computer.
It fails with the message:
"Unable to access server service on the machine 'computer.sourcedomain.com'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. Access is denied".

The "Domain admins" group of the target domain is in the "Administrators" group of the source domain. Is this not enough to grant rights to the computer?
In fact I can not access the "\\computer.sourcedomain.com\admin$" share from the target domain... while I still can from the source.

Am I missing something? Should I modify something else in the rights of the computer being migrated?

Thank you again for the patience.

Axplains

[gforceindustries]

Originally Posted by axplains

The "Domain admins" group of the target domain is in the "Administrators" group of the source domain. Is this not enough to grant rights to the computer?
In fact I can not access the "\\computer.sourcedomain.com\admin$" share from the target domain... while I still can from the source.

The Administrators group is a local group. They may be members of the Administrators group on the DC, but you need to make sure they are also members of the Administrators group on workstations too.

The default members (I believe) of Administrators are Administrator and Domain Admins.

[Akila]

Originally Posted by axplains

Thank you very much for your clear explanation.

I understand and it makes sense; I had followed the ADMT guide, where Security Translation is before Computer Migration...

I tried the first method you suggested: the process went OK until the "Agent dialog" tries to pre-check and install the Agent into the computer.
It fails with the message:
"Unable to access server service on the machine 'computer.sourcedomain.com'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. Access is denied".

The "Domain admins" group of the target domain is in the "Administrators" group of the source domain. Is this not enough to grant rights to the computer?
In fact I can not access the "\\computer.sourcedomain.com\admin$" share from the target domain... while I still can from the source.

Am I missing something? Should I modify something else in the rights of the computer being migrated?

Thank you again for the patience.

Axplains

there are few things you need to make sure of.
1) ADMIN$ must be shared on all machines you want to migrate.
2) Disable Hibernation/Sleeping modes on the PC or Migration would fail (could be done using Group Policy)
3) Disable any kind of Firewall/Anti-Virus on the workstations during Migration.

for the rest of your problems please follow the Procedure I wrote on how to prepare your environment for Migration.
http://www.petri.co.il/forums/showthread.php?t=26101
That would sort out all your problems.

[gforceindustries]

Originally Posted by Akila

Disable Hibernation/Sleeping modes on the PC or Migration would fail (could be done using Group Policy)

Custom ADM template required, unless Akila knows something I don't.

[axplains]

Thanks Akila and Gforce.

I solved the problem by putting the target domain's "Administrator" user in the computer's local "Administrators" group.
(I did not create any ad hoc users and groups for migration purposes, just used the standard "administrator" accounts for simplicity and because we have no particular security issues).

I already read Akila's guide in the past and it is very helpful but synthetic (at least for me) in respect of the ADMT guide, which seemed to describe the necessary steps more in detail.

It is the first time I am trying this: I have searched for a "idiot proof" step by step guide with all the actions explained from beginning to end.
But none of the articles I found was so detailed... so there's always some part I am not so smart to figure out myself...

Now I am in doubt for the next step indicated by the ADMT manual: at this point, it says I should "remigrate" accounts again from the source to the target domain.
At this point, is it of any use?

(Note: I am not migrating password using PES, just resetting the passwords after the migration).

Again, thanks to both of you.

Axplains

[Akila]

re migrating accounts mainly needed if you have a long period of migration process that by the time you think your done, on the source domain, Admins made changes to groups and users as for permissions, group membership or any kind of changes that were not included on the objects when you 1st migrated them.
I personally never remigrated objects, since all our migrations toke place as what called a "Cut-Over" day , meaning we migrated everything in one weekend.
So we did not have to remigrate anything, since nothing changed on the source domain from the initial migration to the final stage (done migrating everything I need to migrate).

[axplains]

Thank you very much.

In fact, I did it, tried to logon to the new domain and everything works.

Now I need to smooth out all the minor issues...
Thanks a lot again for your help and patience.