locked
Importing a CRM 2011 database into CRM 2013: You must map your Active Directory user account... RRS feed

  • Question

  • Getting this error:

    "You must map your Active Directory user account to at least one enabled Microsoft Dynamics CRM User who has the System Administrator security role before the organization can be imported."

    I am within the same domain but the new CRM is on a different server as is SQL. 

    The admin user is mapping to a different AD account on the new server and there is another user in the list which I believe is an old admin.  One user account is disabled in the old CRM and I have added this to the new server as active for the moment.

    This error is not telling me which account is the problem (I am guessing the Admin User here!?) and it is not telling me what the problem actually is?

    Does anyone have experience of this?

    Tuesday, February 4, 2014 5:00 PM

Answers

  • Got this working.

    Went back to the old CRM:

    1. the administrator has been disabled.  The user was enabled again.
    2. Some users were non Read-Write users (i.e. Administrative). These were changed to Read-Write Access Mode.

    The migration happened easily after that.

    Not sure which of these fixed the problem, may have been both.

    Also for information, I was logged into the server as the new crmadmin all along.  I have seen posts recommending logging in as the old admin user from the previous system.  Didn't have to.

    One last thing I did though was add the old admin user to the Deployment Manager Admins. Again not sure if this had an effect.

    Wednesday, February 5, 2014 1:01 PM

All replies

  • The AD user account that you are logged into the deployment manager with, and performing the import with is not mapped to a user in the CRM database.

    When you start the import process and get to the user mapping table, make sure that the account you are using is mapped to a CRM user record that is active in the org you are importing.  The CRM user also needs to have the sys admin security role assigned.

    Technically when importing the organization, you only need to have a single user mapped (the user doing the import of course).  This prevents you from importing the organization and then later finding out you are unable to log into it afterwards and also ensures that the person who imported is a sys admin in CRM and can assign security roles.

    Most companies will use a specific AD account that is thought of as a service account in CRM.  This account is what is used to install CRM and what the admin can log in as to install rollups or import organizations.  This prevents someone installing CRM with their personal AD account, and then later leaving the company, their AD record deleted and causing issues in CRM when it comes time to redeploy or reinstall CRM.


    Jason Peterson

    Tuesday, February 4, 2014 5:13 PM
  • When the new CRM was setup, we created a crm-admin user and logged in to the server as that user.  We then conducted the install so I am indeed running the deployment wizard as the crm-admin as well as logging in to CRM with that user.

    I will use your reply to check through my settings though in case I have missed something or there has been a change behind the scenes that I haven't spotted.

    Tuesday, February 4, 2014 5:26 PM
  • Reading your answer again: are you saying that the new crm-admin account that we have created for the new server, must also be present in the old database? 

    It isn't at the moment since we are using a new set of AD users for the 2013 deployment?

    Tuesday, February 4, 2014 5:40 PM
  • Hi. Map old admin of crm 2011 to your crm 2013 user That should solve your problem
    Tuesday, February 4, 2014 7:07 PM
  • Got this working.

    Went back to the old CRM:

    1. the administrator has been disabled.  The user was enabled again.
    2. Some users were non Read-Write users (i.e. Administrative). These were changed to Read-Write Access Mode.

    The migration happened easily after that.

    Not sure which of these fixed the problem, may have been both.

    Also for information, I was logged into the server as the new crmadmin all along.  I have seen posts recommending logging in as the old admin user from the previous system.  Didn't have to.

    One last thing I did though was add the old admin user to the Deployment Manager Admins. Again not sure if this had an effect.

    Wednesday, February 5, 2014 1:01 PM