• State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 20 subscribers
  • Views 6830 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Migration Manager for AD 8.14 RUM console error 0x0000005 Access is denied.

will1710
over 5 years ago

After running Discovery, 3 of 5 computers are returning this error:

4/5/2019 4:03:12 PM 3132 Remote computer's operating system: Windows 7 Enterprise Edition x64, build 7601, Service Pack 1.
4/5/2019 4:03:12 PM 3132 Agent returned warnings during discovery.
4/5/2019 4:03:12 PM 3132 Warning: Log path \\CSDS-04720\QuestResourceUpdatingLogs$\ is not accessible. Error 0x00000005. Access is denied. .
4/5/2019 4:03:12 PM 3132 Warning: Configuration path \\CSDS-04720\QuestResourceUpdatingConfigs$\ is not accessible. Error 0x00000005. Access is denied. .
4/5/2019 4:03:12 PM 3132 Warning: The Quest Migration Manager RUM Controller Service is not accessible. Error 0x00000005. Access is denied. .
4/5/2019 4:03:12 PM 3132 Discovery completed successfully.

Meanwhile, of the remaining 2, 1 had Discovery succeed with no errors, and 1 is returning RPC not available.

My credentials are correct and the migrating account has local admin rights to workstations.  

I've seen this error once before and could only get around it by doing an agent-less migration.  I'm a little worried that I create the problem, but I don't really think so  Last week, I removed the inheritance block for the OU that the RUM console machine is in, which resulted in the source target migrating account losing local admin rights.  At that point I saw this access denied error for the first time.  I restored rights and have since migrated another half-dozen computers with the agent, except for that one workstation which I eventually had to do agent-less.  

So, is this likely to be a problem on the target workstation?  Or a problem on my console?  Does it just happen sometimes?

Parents
  • 0 over 5 years ago

    This error message is telling you that the computer agent can not connect to the console share. So from the workstation, logged on as the service account, can you map to \\CSDS-04720\QuestReaourceUpdatingConfigs$ ?

    This means that the service account for this domain must be a member of the local server administrators group, the firewall on the console server must have the file and print services rule open on the firewall as well. If you only have a one-way trust and the service e account can’t be a member of the consoles local group, create a local server account with the same name and password. 

  • 0 over 5 years ago in reply to Jeff Shahan

    I migrated the other computer agentless; today I've found another one, that I can get to and log into.

    I am logged in as the migrating account.  If I go to \\name\QuestResouceUpdatingConfigs$ it connects and prompts for credentials, then returns "access denied".  Which explains the error.

    But I can't figure out why the error is happening.  The migrating account is in the local admins group.  I even disabled the firewall on the console machine and still get Access Denied.  What else am I missing?  Both computers have been restarted multiple times.

  • 0 over 5 years ago in reply to will1710

    For future readers: I finally figured this out, late today.

    It wasn't an authentication issue at all.  It was DNS.

    If I enter the target computer into the collection as an IP address, then Discovery, Pre-Process, and Move worked fine.  Rename doesn't work with IP address (no errors, oddly, but it didn't rename), so then I had to add a second entry with the NetBIOS name and target domain, which worked for Rename, Post-Process, and Cleanup.  Apparently our DNS issues only extend to the source domain. 

    Adding the console computer into the HOSTS file on the target machine also worked.

Reply
  • 0 over 5 years ago in reply to will1710

    For future readers: I finally figured this out, late today.

    It wasn't an authentication issue at all.  It was DNS.

    If I enter the target computer into the collection as an IP address, then Discovery, Pre-Process, and Move worked fine.  Rename doesn't work with IP address (no errors, oddly, but it didn't rename), so then I had to add a second entry with the NetBIOS name and target domain, which worked for Rename, Post-Process, and Cleanup.  Apparently our DNS issues only extend to the source domain. 

    Adding the console computer into the HOSTS file on the target machine also worked.

Children
No Data