good point - but realize that it's somewhat of a risky business to grant lower level admins the permissions to migrate-sid-history. Although I agree with 2003 you at least have this option.
/Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Willem Kasdorp Sent: Tuesday, August 24, 2004 7:55 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] admt2.0 permissioning > for SID-History to work, the account used to migrate must be a member of the domain admins group on the TARGET domain Addition: on W2003 you have the extended right "Migrate-Sid-History" which you can use to delegate the SidHistory permissions to a lower level Admin. I've done this with limited success. It works fine from the ADMT GUI, but fails miserably from the commandline. Strange but true. Hopefully fixed with ADMT 3.0. -- Regards, Willem -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, August 24, 2004 6:56 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] admt2.0 permissioning actually, it all depends on how you run ADMT. Often you'd want to split the requirements between user/group migration and computer migration. The rules for migrating users and groups are: 1. for the PES (Password export server) to work, the account used to migrate the users must be a member of the LOCAL ADMIN group in the SOURCE domain 2. for SID-History to work, the account used to migrate must be a member of the domain admins group on the TARGET domain Both can only be fulfilled by adding a TARGET domain admin account to the local administrator group in the SOURCE domain, since you can't add a user from a different domain to the global domain admin group in your TARGET domain. Then, to migrate the computers, you need local admin rights on the clients in the SOURCE domain and appropriate permissions on the OU in the TARGET domain - this can be achieved in various ways, e.g. by using a SOURCE domain admin and then only granting permissions to add computer objects to the respective OU in the target domain. Or by first adding a group from your target domain to the local admins of your clients and then work with a TARGET domain user for the computer migration as well. /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 12:42 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt2.0 permissioning dear all, know this is real "old hat' by now but just wanted to confirm issue of permissioning for an ADMT migration of a small NT 4.0 account domain to a Windows 2000 domain. a quoted requirement is that 'sourcedomain/domain admins' is added to 'targetdomain/administrators" and vice-versa. is this a definite requirement for migration of just a 'catch all' that grants everything ?? i dont understand why the 'sourcedomain/domain admins' need to have admin privilege in the target domain - THIS IS THE BIGGEST ISSUE - the issue here surely here is the context in which the ADMT is being run - i do see why this needs Administrative rights on the desktops being migrated and an elevated level of privilege on the target domain to be able to create the necessary objects et al TIA GT List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
