locked
Unable to Disable Users RRS feed

  • Question

  • CRM 2011 has been running fine in multiple environments for 6 months but now when I try to disable a user, I receive the following error (in each environment):

    'SystemUser' entity doesn't contain attribute with Name = 'issyncwithdirectory'. (Error code 2147217149)

    I've found nothing about this. Any ideas????

    Thanks,

    Dave

    Friday, February 17, 2012 3:22 PM

Answers

  • Reapplying the update seemed to do the trick (after bouncing the server)! Now I can enable/disable users. So, a bug exists within the rollup process; otherwise, ALL orgs within a single instance would have been updated with the new columns.
    • Marked as answer by DavidCRM Friday, February 17, 2012 4:46 PM
    • Unmarked as answer by DavidCRM Friday, February 17, 2012 5:10 PM
    • Marked as answer by DavidCRM Friday, February 17, 2012 5:11 PM
    • Edited by DavidCRM Tuesday, February 21, 2012 6:08 PM
    Friday, February 17, 2012 4:46 PM

All replies

  • Hi 

    Did you recently moved to UR 5 for CRM 2011

    I found this link which mentions a similar problem (not exactly similar though), and lists a solution as well.

    http://www.dynamicsconsulting.de/2012/01/18/update-rollup-5-issue-with-systemsettings-organization-entity-doesnt-contain-attribute-with-name-isuseraccessauditenabled/

    See if that helps you.

    Friday, February 17, 2012 3:33 PM
  • UR 5 and 6 are installed. The solution doesn't make any sense.

    "Installed UR5 on the Deployment Server Role as well which wasn´t the case (was missed).
    This run of UR5 Installation updated the Database and the CRM schemas correctly.
    Webforms and Database is matching again and we are able to update SystemSettings again."

    ???
    Friday, February 17, 2012 3:39 PM
  • is this CRM Online or are you using Office 365?  You can have a look at this article to see if it provides some insight.

    http://msdn.microsoft.com/en-us/library/hh670617.aspx#data_sync 


    Regards, Donna


    Friday, February 17, 2012 4:14 PM
  • Neither - this is on-premise.

    Some organizations within the same environment have the entity attribute and others do not. Very strange...

    Friday, February 17, 2012 4:22 PM
  • Hi

    What I concluded from the blog is:

    If  it is a multi server deployment, in that case you need to apply update rollup 5 server component on all the servers.

    Second, as you mentioned, you are having both Rollup 5 and 6. I am not clear with this. All rollups are cumulative

    So if you are having Rollup 6 installed, then it includes all fixes of rollup 1-6. Also ensure, that your client and servers are on same rollup version.

    • Marked as answer by Donna EdwardsMVP Friday, February 17, 2012 4:52 PM
    • Unmarked as answer by DavidCRM Friday, February 17, 2012 5:10 PM
    • Marked as answer by Donna EdwardsMVP Friday, February 17, 2012 5:25 PM
    • Unmarked as answer by DavidCRM Tuesday, February 21, 2012 5:28 PM
    Friday, February 17, 2012 4:28 PM
  • All servers were updated. Yes, both 5 and 6 WERE installed (5 was installed when it was released and then 6 was installed when released) - I mentioned 5 because it was in response to the question asked.

    Some organizations within the SAME instance include the entity attribute and others do not.

    Friday, February 17, 2012 4:34 PM
  • UPDATE: I reapplied RU6 in my dev environment and now the org that did not include the issyncwithdirectory User attribute (and islicensed attribute) has the attributes. However, I still receive the same error when trying to enable/disable users.
    • Marked as answer by DavidCRM Friday, February 17, 2012 4:46 PM
    • Unmarked as answer by Donna EdwardsMVP Friday, February 17, 2012 4:53 PM
    • Marked as answer by DavidCRM Friday, February 17, 2012 5:11 PM
    • Unmarked as answer by Donna EdwardsMVP Friday, February 17, 2012 5:25 PM
    Friday, February 17, 2012 4:43 PM
  • Reapplying the update seemed to do the trick (after bouncing the server)! Now I can enable/disable users. So, a bug exists within the rollup process; otherwise, ALL orgs within a single instance would have been updated with the new columns.
    • Marked as answer by DavidCRM Friday, February 17, 2012 4:46 PM
    • Unmarked as answer by DavidCRM Friday, February 17, 2012 5:10 PM
    • Marked as answer by DavidCRM Friday, February 17, 2012 5:11 PM
    • Edited by DavidCRM Tuesday, February 21, 2012 6:08 PM
    Friday, February 17, 2012 4:46 PM
  • I am not sure why you would unmark an answer that helped you get to the solution you needed.  The solution was to apply UR 6 to all your environments and then reboot your server(s) 

    CRMDevlpr states in his response:

    "So if you are having Rollup 6 installed, then it includes all fixes of rollup 1-6. Also ensure, that your client and servers are on same rollup version."

    The reason I marked that as the answer is because you went back and installed UR 6 on a machine that did not have the rollup.  I think giving credit to CRMDevlpr for that response is the right thing to do. 

    Please keep in mind that people who respond to help you with your solution are volunteering their time.  Acknowledging their assistance by marking the suggestion they provided when the suggestion is the answer to the issue is the right thing to do on several levels.


    Regards, Donna

    Friday, February 17, 2012 5:25 PM
  • Donna,

    The Rollup WAS applied to ALL servers and clients (hence SOME of the Orgs had the additional columns and others didn't - within the SAME instance). So there is a bug within the rollup process itself and the suggestion  was NOT the solution.

    Suggesting a rollup be applied to ALL servers is a no-brainer because it's part of the rollup process.
    • Edited by DavidCRM Tuesday, February 21, 2012 5:31 PM
    Tuesday, February 21, 2012 5:30 PM
  • Here is the challenge for people that view this post.  The reply that you marked as Answered references "that"  reference;

    "That seemed to do the trick (after bouncing the server)! Now I can enable/disable users."

    What is "That" referring to? 

    In reviewing your responses, it looks like your issue was resolved by reapplying UR6 to your dev environment and then rebooting the server.  Maybe it is possible that something didn't go quite right with the initial install and reapplying the UR fixed it.  That was why I marked both the post that suggested to apply the same UR to all environments and your post stating to reboot your server.  From the outside looking in, it seems that the combination fixed the issue but I could be missing something.

    Just fyi, "Suggesting a rollup be applied to ALL servers is a no-brainer because it's part of the rollup process.", some people might miss this step so it doesn't hurt to remind.  Reappling the rollup to one of your environments seems to have fixed the issue.  It would be nice if you could consider giving CRMDevlpr credit for his suggestion as I think the two replies (yours and CRMDevelpr) work together to provide an outsider looking in with a possible solution to this issue.

    Thank you for your time, consideration and participation in the forums.


    Regards, Donna


    Tuesday, February 21, 2012 5:56 PM
  • No problem. I reworded the Answer so it makes sense on its own.
    Tuesday, February 21, 2012 6:07 PM
  • Hi,

    I have the same issue. Does anybody found a solution for this? I encounter this problem since I installed RollUp6.

    Thank you,

    Leo

    Tuesday, March 13, 2012 9:49 AM
  • Hi Leo,

    Ensure that the database updates are all applied on the organizations.

    Open the Deployment Manager (Start --> Programs --> CRM --> Deployment Manager).

    In the deployment manager, check if the organization that you're facing an error has Update Available in the last column.

    If it's showing as Available, right-click on that organization and update it.

    If you're facing an error like "Existing SQL Server connections to the Microsoft Dynamics CRM databases must be closed before setup can continue.", stop the Sandbox service and both of Async services.

    That solved a problem for our case.

    Friday, March 23, 2012 6:34 AM