ADMT 2 security translation problem

Discussion in 'Server Migration' started by Wendy Derman, Jul 30, 2004.

  1. Wendy Derman

    Wendy Derman Guest

    We are migrating a 2000 native mode domain into a 2003 domain that's running in 2000 native mode, using ADMT 2.

    We have successfully migrated all groups and users, complete with SID histories.

    We're having a very strange problem with computer migrations. From my computer, using an account called scdadmin to run the migration tool, everything works fine. The agent gets dispatched to the computers, security translation runs, all is well.

    From every other computer we have tried, also using the scdadmin account, the tool only works partially. The agent gets dispatched, the domain affiliation gets changed. But security translation doesn't work. When watching the agent detail, the "Changed" column is just filled with 0's. There are no errors reported in dctlog, it simply doesn't change things. We'll then go back to my computer, run it exactly the same way (using just the security translation wizard this time, since the computer itself gets successfully migrated), and it works.

    We really need to get it working on other computers besides mine. We tried rebuilding their computers from scratch, with me watching.. they did everything exactly right. We even tried putting the network cord I'd had on my computer into theirs.. same results. What could possibly be different between my computer and theirs that would make this happen?
    Wendy Derman, Jul 30, 2004
    1. Advertisements

  2. Hi Wendy,

    Thanks for your posting here.

    Do you mean that run the ADMT tool on two different computers to perform
    Security Translation?

    ADMT stores all of its history in a locally installed database, Protar.mdb.
    If several copies of ADMT are installed throughout a domain, a new
    Protar.mdb file is installed with each copy of ADMT. So ADMT will no longer
    have any information about which objects have been migrated on another

    I would recommend that you install ADMT 2.0 on a target domain controller
    and run each migration from that one server.

    Have a nice day!

    Bob Qin
    Product Support Services
    Microsoft Corporation

    Get Secure! -

    When responding to posts, please "Reply to Group" via your newsreader so
    that others may learn and benefit from your issue.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Bob Qin [MSFT], Aug 2, 2004
    1. Advertisements

  3. Wendy Derman

    Wendy Derman Guest

    Bob, thank you very much. We did not do exactly what you suggested.. we copied protar.mdb to the workstation from which we wanted to run ADMT. Then everything worked.

    Since you work at Microsoft, would you be able to pass along this feedback? It would be very useful if this information was added to the troubleshooting section that comes with the ADMT help file, and also the migration requirements page. Once I knew a file name to search for, I did find mention of this issue in the Best Practices page. But we spent 2 days banging our heads against the wall on this problem before we posted to this newsgroup, and although we looked through the built-in help that comes with ADMT, we never thought to look at a Best Practices page for the solution. :)

    The reason we did not want to run it from a DC is this: my company is made up of about a dozen different divisions, all of which operate nearly as separate companies. We have a single domain, with each division getting their own OU. I am the domain admin. I am actually a veteran of ADMT 1, and migrated several of those divisions in using that tool. Because of the requirements of running ADMT 1 on a domain controller, I was stuck being with every division for their full migration. I was thrilled to learn that ADMT 2 allowed you to install on any machine in the domain, and that workstations could be migrated with only OU-level privileges. That meant that most of the work of migrating this new division could be done by them, without my assistance required. We did the initial migration of groups and users using my laptop, because of the SID history migration requiring domain admin privileges. Then the plan was to let them do all their workstation migrations by themselves. I thought that SID history was stored in Active Directory along with the objects themselves, so I didn't think about a file being stored locally on my laptop.

    Anyways, it is working now, and I am grateful for the help!
    Wendy Derman, Aug 3, 2004
  4. Hi Wendy,

    Thank you for your feedback regarding the protar.mdb file. We review all
    customer comments regularly and provide them to our development team for
    consideration in future product releases.

    In fact, it is not normal action so that we put this information into the
    Best Practices section. It is recommended that you perform some test in the
    lab network and contact us though online help, newsgroup... to get ready
    for your migration plan.

    The following document also mentions this information.

    How to use a SID mapping file with the ADMT tool to perform a resource
    domain migration to Windows Server 2003

    Thank you again for using our newsgroup!

    Bob Qin
    Microsoft Online Partner Support

    Get Secure! -

    When responding to posts, please "Reply to Group" via your newsreader so
    that others may learn and benefit from your issue.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Bob Qin [MSFT], Aug 4, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.