RUM unable to join the computer to the target domain

Hi guys.

 

I am doing a Intra-Forest migration with QMM/AD, I was able to setup the QMM tool and clone users successfully. With RUM I am able to discover, and process computers with no problem.

When I move the computer to the target domain, RUM shows the move as successful but when the user try to login he received the error:

"The security database on the server does not have a computer account for this workstation trust."

I have the same behaviour in my LAB and PROD environment. Not sure if I Am missing a setting or if Intra-Forest require additional setting.

I am using QMM 8.13

The workstation to migrate is win7 x64

  • Show us a copy of the RUM logs.

    Did you copy the computer account before you moved the PC with RUM? Or, did you let RUM create the computer object?
  • This issue is related to the SPN on the workstation object. The source workstation object need to be disabled or deleted during the move operation. Looks to me like this is failing. Check the Domain Credential configured in the RUM Console, and verify it has Full Control over the computer object in question.
  • In reply to Jeff Shahan:

    I ran into the same issue today doing the same thing.. Found this article which nailed it: support.quest.com/.../181337
    Works fine moving to the default /Computers OU then I manually move. Major PIA. When I pre-staged using QMMAD, RUM gave me a ton of Kerberos errors and would not enable the computer object. Investigating post-RUM scripts that may help in moving.
  • In reply to eric_bergstrom:

    Eric, Try this.

    1. Using a migration session, migrate the computer object
    2. Target the OU you want to create them in. 
    3. Skipping the SPN attribute
    4. All other options the default 

    This will create a disabled Computer object in AD in the OU you want. 

    Now using RUM, Move the computer and leave the OU blank. IT will join to the existing Computer object and enable it. 

     

  • In reply to Jeff Shahan:

    Good advice, Jeff. Once I get through the pilot and the dust settles, I'll try it out. Stay tuned...Eric
  • In reply to Jeff Shahan:

    I should <hopefully> be able to test this process today..Waiting on the customer.
  • In reply to Jeff Shahan:

    Ok. So far, things look better with this approach. I did notice that after the first reboot, the same error cropped up but after waiting about 5 minutes, rebooting, everything came up as expected and the user can log on.