Resolving the CRM for Outlook Permissions Error

Microsoft Dynamics CRM for Outlook (also known as the Outlook client) integrates seamlessly with Microsoft Outlook and can take the way your company does business to a new level of productivity! With that being said, it can be tricky at times to set up if you haven't followed the installation steps correctly. In today's blog, we are going to take a look at one of the possible roadblocks you may be running into that might be preventing your users from successfully connecting to the Outlook Client. Let's get started!

After downloading the correct version of the Outlook client that you need and successfully entering your CRM org information and credentials, you should see a screen in the Outlook Configuration Wizard that verifies your connection to your CRM organization, similar to the example below:

Resolving the CRM for Outlook Permissions Error

If instead you see a screen displayed like the one below. "You do not have persmission to access these records. Contact your Microsoft Dynamics CRM Administrator." In this case, you have likely encountered a snag in obtaining your desired access:

Resolving the CRM for Outlook Permissions Error

Since the error mentions permissions, you may assume that the logical first step would be to check your security roles. However, in this case, the problem is a little more complicated.

When a user is created in CRM, if their Client Access License (CAL) Information Access Mode is set to "Administrative", they will not have access to CRM data and will thereby see the error above when they try to connect Outlook to CRM. To check your setting, navigate to your user record and verify the Access Mode located under the Administration tab.

Resolving the CRM for Outlook Permissions Error

Changing the Access Mode to "Read-Write" will now allow the user to successfully connect Outlook to CRM. Please note that this setting is separate from having the System Admin security role. A user could have the System Administrator security role, but if their Access Mode is set to "Administrative", it will still prevent them from connecting to the Outlook client.

Hopefully this provides you with a place to start if you ever encounter this error when installing the CRM for Outlook client. Looking for more information about the Outlook client? Check out our blog on how to configure the Outlook client via a second federation.

Happy CRM'ing!

Exporting Data to Re-import: The Invalid Column Headings Issue

Often you'll need to export data from CRM, make changes, and then re-import the data using CRM's out-of-box capabilities. In doing this, you might receive the message "The data has invalid column headings, so you will not be able to re-import it" pop up. What is this message and how do I successfully export my data?

Exporting Data to Re-import: The Invalid Column Headings Issue

The issue actually has to do with duplicate display names. Since the export writes the display name as the column name, you cannot have duplicates because CRM doesn't know how to match up the columns again when it re-imports the data.

In the scenario below, there is an issue with a duplicate status fields; the out-of-box status and a custom status field with the same name.

Exporting Data to Re-import: The Invalid Column Headings Issue

Hopefully this will help you get past this error message and successfully export your data for re-importing. Interested in taking your CRM experience to the next level? Consider attending this year’s PowerUp in Minneapolis, MN, November 10-11 with an optional hands-on day November 12! Hosted by PowerObjects, this can’t-miss CRM event features over 60 breakout sessions and includes tracks for all experience levels. Register today!

Happy CRM'ing!

SDK Message with Id {} Does Not Exist and an Alternative Fix

SDK message errors got you down? We've got an alternative fix to take the stress away and those errors too! Let's dive in!

As you can imagine, getting this error prevents the solution from being imported. There are some suggestions to create a solution with the offending process and modify the XML, but these may not work if you have custom actions.

The alternative fix we came up with was to completely delete all processes from the solution in the target environment and re-import. This may not be ideal, especially if you are pushing to a production environment, but it will let you get the latest solution before Microsoft releases a fix. Microsoft has stated that the fix will either be in UR3 or UR4.

Note: Always perform a backup of CRM before you attempt any changes!

Hopefully this helps you temporarily bypass any roadblocks with importing solutions. Remember you can always find great blogs full of tips and tricks for working with Microsoft dynamics CRM no matter what your skill level both in the FREE CRM Book as well as our website. Thanks for stopping by the blog today, and as always!

Happy CRM'ing!

Error When Activating/Deactivating Accounts or Contacts in CRM 2013

If you recently upgraded to Microsoft Dynamics CRM 2013 from CRM 4.0 and are getting an error when attempting to activate or deactivate a contact or account record, we may have the solution for you!

So what does this particular error look like? When attempting to activate or deactivate the record, you may receive a Generic SQL Error message alert box, and when you download the log file from the user interface, you may find the following output:

Deactivating Accounts or Contacts in CRM 2013

"Unexpected Error. An error has occurred."

This is a pretty standard error and doesn't tell us much by itself. So what should you do?

1. Try running a trace on the CRM server. You may find the following error message in the stack trace, with the relevant parts are highlighted below. (NOTE: You can find steps on how to enable tracing on the CRM server here.)

[Date/Timestamp] Process: w3wp |Organization: CRMOrganizationID |Thread: TreadID |Category: Platform.Sdk |User: UserGUID |Level: Error |ReqId: GUID | VersionedPluginProxyStepBase.Execute ilOffset = 0x65

    at VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context) ilOffset = 0x65

    at Pipeline.Execute(PipelineExecutionContext context) ilOffset = 0x65

    at MessageProcessor.Execute(PipelineExecutionContext context) ilOffset = 0x1C5

    at InternalMessageDispatcher.Execute(PipelineExecutionContext context) ilOffset = 0xE4

    at ExtensiblePlatformMessageDispatcher.Execute(PipelineExecutionContext pluginContext) ilOffset = 0x0

    at ExtensiblePlatformMessageDispatcher.UpdateWithInvocationSource(BusinessEntity entity, FilterExpression filter, Int32 invocationSource, ExecutionContext context) ilOffset = 0xCE

    at ExtensiblePlatformMessageDispatcher.Update(BusinessEntity entity, FilterExpression filter, ExecutionContext context) ilOffset = 0x5

    at BusinessProcessObject.UpdateWithPipelineAndExtensions(IBusinessEntity entity, ExecutionContext context) ilOffset = 0x78

    at AccountService.Update(IBusinessEntity entity, ExecutionContext context) ilOffset = 0x37


>Web Service Plug-in failed in SdkMessageProcessingStepId: {32750CB3-CFDC-DB11-8341-0019B9204DA9}; EntityName: account; Stage: 30; MessageName: Update; AssemblyName: Microsoft.Crm.Extensibility.InternalOperationPlugin, Microsoft.Crm.ObjectModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35; ClassName: Microsoft.Crm.Extensibility.InternalOperationPlugin; Exception: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

Inner Exception: System.InvalidCastException: Specified cast is not valid.

at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(Guid id)

at Microsoft.Crm.BusinessEntities.TriggersExtension.ExecuteTriggers(BusinessEntity entity, ArrayList triggers, OperationType operationType)

at Microsoft.Crm.BusinessEntities.BusinessProcessObject.DoUpdate(IBusinessEntity entity, FilterExpression filter, ExecutionContext context)

In this case, you can see that the user is attempting to perform the action against the account entity using the out-of-the-box plugin (Microsoft.Crm.Extensibility.InternalOperationPlugin).

2. If you look at the "Inner Exception" message, you will want to pay close attention to the top line. This indicates the last thing CRM was attempting to do when the error occurred (at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(Guid id)). This last method in the error message tells us that there is an issue with the addresses assigned to the account in question. This information is stored in the CustomerAddressBase table in the organization database.

3. Upon further investigation, you might that there's a record missing from the CustomerAddressBase relating to the account record in the ParentId field in the table. By default, there should be at least two records for each ParentId entry differentiated by CusomterAddressId. This is then further differentiated by AddressNumber 1 and 2. As you might have figured out, 1 is for the Address 1 fields and 2 is for the Address 2 fields relating to the ParentId record.

4. So now to answer the question: "How do I fix this?" Well, the easiest way is to create a new record and merge the needed data over to a new record except for the address information. For the address portion, we suggest manually entering it into the new record's address information section or the merge will not work. You can take this same process one step further to identify any further records that may be affected by this particular issue by running the following query within SQL Server Management Studio.

select Name as
'Account Name',
from CustomerAddressBase where ParentId = AB.AccountId)

from AccountBase AB

where (select
from CustomerAddressBase where ParentId = AB.AccountId)
< 2

select FullName as
'Contact Name',
from CustomerAddressBase where ParentId = CB.ContactId)

from ContactBase CB

where (select
from CustomerAddressBase where ParentId = CB.ContactId)
< 2

In instances where these steps do not resolve the issue, we would encourage you to reach out to our support team as there may be additional issues causing this issue.

Happy CRM'ing!

Error with ADFS/IFD URL in Dynamics CRM

Many of our clients have Microsoft Dynamics CRM on premises and Internet Facing Deployment (IFD) / Active Directory Federated Services (ADFS). We often see a minor missing step with the setup of ADFS, which could lead to an error. For instance, you may find that the web interface works fine, but applications that use the web services to authenticate return this error:

"There was no endpoint listening at http://xxxxxx/adfs/services/trust/13/username that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."

If you see this, one potential cause could be an incorrect federation service identifier URL.To verify that this is the cause, please check the following:

  1. In ADFS administration, go to the Server Properties and verify the server URL is set to https and also displaying the full ADFS URL. If your ADFS server runs on a non-standard port, be sure to also specify the port. It would look something like this:

    Error with ADFS/IFD URL

  2. Now perform an iisreset and restart ADFS services on the ADFS box.
  3. Re-run the claims configuration wizard in CRM.
  4. Do an iisreset in CRM.
  5. Re-run the IFD configuration wizard in CRM.
  6. Do another iisreset in CRM.

If these steps don't correct the error, make sure that your port number is listed after the domain in the ADFS setup as well.

Hopefully following these steps will resolve your issue. If not, the friendly experts at PowerObjects would be happy to help troubleshoot any further issues!

Happy CRM'ing!

Duplicate Key Row Error during Upgrade to CRM 2013

Greetings fellow CRMers!

Nothing spoils the excitement of upgrading your CRM 2011 organization to CRM 2013 like a lousy error. If you've experienced this key row error, we'll tell you how to keep it from ruining your day.

This particular error occurs while the upgrade wizard is processing the upgrade. It may not be flagged as a concern during the validation portion, but the upgrade may fail and the error within the log will state:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Data.SqlClient.SqlException: Cannot insert duplicate key row in object 'MetadataSchema.AttributePicklistValue' with unique index 'ndx_AttributePicklistValue'. The duplicate key value is (c5157c5f-9375-446c-8e8b-1659c0c5d54c, 5, 0, <uniqueorgid>, Jan 1 1900 12:00AM).

Reason for the Error

This error is due to a few "extra" user CAL license types in the caltype field on the systemuser entity. Specifically the extra CAL types are "Employee Self Service" and "Device Employee Self Service." These CAL types do not show up on the License Type Option Set on the user form, but you can see them if you look at the caltype field on the systemuser entity. This option set is locked so you cannot remove these options in the CRM field configuration.

Duplicate Key Row Error while upgrading to CRM 2013

In SQL, you can verify these values by running this query against your organization database:

select * from metadataschema.AttributePicklistValue where Optionsetid = 'c5157c5f-9375-446c-8e8b-1659c0c5d54c'

The results will show more than the standard five license types.

Resolving the Error

NOTE: This blog describes removing values from the CRM organization database using SQL server to solve a very specific issue. As always, make sure you have a good database backup before following these steps.

To resolve the issue, take the following steps.

  1. Take a backup of your database.
  2. Run the following query:

    delete from MetadataSchema.AttributePicklistValue where Value > '4' and Optionsetid = 'c5157c5f-9375-446c-8e8b-1659c0c5d54c'

This will get rid of the extra license types that were preventing you from upgrading, and it should be clear sailing afterward.

If you are facing an issue upgrading your CRM organization to CRM 2013, we'd love to help you through it! Contact us for support, or, if you'd like to sit back and relax, we'll do it all for you.

Happy CRM'ing!

Sitemap Error After Removing a Managed Solution from CRM 2011

Greetings, fellow CRMers! After removing a managed solution, have you received the following error when attempting to login to the CRM website?

Removing a Managed Solution

If you have, look no further for the solution.

This particular error is due to a leftover sitemap reference to a deleted entity. Keep in mind that CRM will normally remove all references from the sitemap when removing a solution. If CRM is unable to do so, it will throw an error and prevent the solution from being removed. However, instances have occurred where this is not the case when removing a managed solution.

Here's how to remedy a situation like this step by step:

  1. Download the SiteMap Editor Tool which is part of the XRM Toolbox from CodePlex:
  2. Once you have downloaded and extracted the above tool, you will see a screen like the one shown below.Removing a Managed Solution
  3. Within the above window, click on SiteMap Editor.Removing a Managed Solution
  4. For the purposes of this demonstration, let's say you want to connect to a CRM On-Premise organization. However, this tool also works with CRM Online. Enter in the server name and login information and then click Get Orgs. Select the organization from the drop-down and click OK.Removing a Managed Solution
  5. Once the tool connects, click Load SiteMap.Removing a Managed Solution 
  6. Important! Make sure you back up a copy of your sitemap before you edit it. Once you have clicked Load SiteMap, you will have an option to save a copy of the sitemap locally. Please click Save SiteMap before editing it.Removing a Managed Solution
  7. Once you have saved a copy locally of the sitemap, you can then proceed to remove the leftover reference. In this instance, I created a test reference to highlight how to locate the leftover sitemap entity reference and named it reference AATest. Once I located the SubArea in question which references the entity that no longer exists, I clicked Delete. After I have confirmed that the entity was not referenced in any other areas or groups, I published the changed by clicking Update SiteMap.

Removing a Managed Solution

After reloading refreshing the browser, the sitemap was able to load properly and I was able to login to CRM as usual.

If you want to know how to modify the sitemap without using the tool mentioned above, check out our blog All About Sitemap Editing in CRM 2011. If you need any additional help with the above steps or would like us to fix it for you, please do not hesitate to reach out to our support staff.

Happy CRM'ing!

Using Scribe Online with SQL 2000

Do you still have SQL 2000 server database in use? Are you trying to connect to that database with Scribe Online?

You should be able to successfully connect using out-of-the-box SQL connection from Scribe Online. But when you try to use this connection in the solution maps, you will get the following error: "Error: Agent cannot retrieve metadata. Unable to retrieve metadata. Unknown property DateLastModified."

Scribe Online with SQL 2000

Even though the connection is successful, you will not be able to use that connection, since SQL 2000 is not supported with Scribe Online.

The solution is to use an ODBC DSN connection. ODBC DSN must be created on the Scribe Agent server being used on that solution.

The driver you select for your ODBC connection depends on the operating system of the computer on which the Scribe Online On-Premise Agent is installed. For a 32-bit (x86) operating system, use 32-bit drivers. For a 64-bit (x64) operating system, use 64-bit drivers. Only system DSNs are supported with Scribe Online.

If you need help with this or any other issue related to Dynamics CRM, you can always contact PowerObjects for support.

Happy CRM'ing!

Import Sequence Number and the Dynamics CRM Outlook Client

Are you getting a generic error when attempting to configure the Dynamics CRM Outlook Client? Because there isn't an actual error message visible from the workstation, it can be a bit frustrating to determine what is causing this issue. If you have access to the CRM server, the error logs can help point you in the right direct.

One possible scenario is that the Searchable attribute of the Import Sequence Number field is set to No.

Import Sequence Number and the Dynamics CRM Outlook Client

This field is required for the Outlook Client synchronize functionality to execute properly.

NOTE: A CRM user with either System Administrator or System Customizer security role is necessary to perform the steps below.

  1. To determine if this is causing the issue, set the Searchable field to Yes, then publish your configurations in CRM.
  2. Attempt to configure the Outlook Client again.
  3. If this does not resolve your issue, check to see if the CRM server and Outlook Client are on the same Update Rollup. Gaps in the Update Rollups can also cause this type of issue.

For additional troubleshooting ideas, you can read up on all of our blogs on the Dynamics CRM Outlook Client. As always, if you need additional assistance with Dynamics CRM, don't hesitate to reach out to PowerObjects, the 2012 and 2013 Dynamics CRM Partner of the Year!

Happy CRM'ing

Dynamics CRM Email Router Troubleshooting 101 – Outgoing Emails

One of the great features of Microsoft Dynamics CRM is the ability to send out automatic notification emails triggered by certain actions, such as creating an account, closing a case, adding a note to a case, or converting a lead. This is done using the email router. So what happens when you have a CRM environment with a working email router setup, and then something breaks? Instead of simply restarting the server (which may fix the problem), you would be better off to first identify the real issue. This Dynamics CRM email router troubleshooting guide will show you how to troubleshoot step-by-step a previously working email router environment, configured for outgoing emails.

Step 1: Determine if there is a problem with sending emails from CRM

Issues that stem from the email router may be reported with only vague details. For instance, you could have user call to say that "emails are not working," and you will have to determine whether the problem is specific to your CRM email router, Microsoft Outlook, Microsoft Exchange, or something else.

Let's say, for example, Mike calls the help desk to with an issue where a work order was generated in CRM, but Bob was not notified. In this case, Mike is counting on a workflow to an automatically email to specified users when a work order is created or changed. If Mike is an advanced user, he might recognize the issue and ask, "Can you check the email router? It doesn't appear to be sending out emails." But that might not be the case with everyone.

No matter how the issue is first brought up, the thing to you need to determine first is whether the issue is related to emails coming out of CRM. Sometimes other things can be confused with an email router problem, such as networking, Outlook (offline mode, junk folder), or Exchange (password change, email address change). So first you'll want to check whether the user still has network connectivity and is still receiving emails.

Step 2: Determine if the issue is specific to just one user, or across all users.

There are two different paths for troubleshooting a user-related issue depending on whether it affects just one user or the whole organization, so you'll want to determine that right away. There are two quick ways to determine this:

The second method is preferred, since it cuts down on additional variables that could be causing the issue. For example, the asynchronous service could stop working, and your users may not be able to tell if they are testing it all the same way—by creating a record that triggers a workflow that sends an email. If the async is down, no emails will be generated, even if the email router is functioning correctly.

If you can successfully send and receive an email activity manually created within CRM, it's likely a user issue. Proceed to step 3. Otherwise, go to step 9, since it is likely a server issue instead.

Step 3: If you've determined this is a use-related issue, check whether the user's outgoing profile is set to "email router."

Go to Settings > Administration > Users, and open the specific user who reported the issue. Scroll down to a dropdown box called "E-mail access type – Outgoing." If it is not already set, change it to e-mail router and save the record.

Dynamics CRM Email Router Troubleshooting 101 – Outgoing Emails

Step 4:
Check whether the user has Approve access.

You should still be in the user record from the last step. In the ribbon, click Approve E-mail. Once this is done, give it at least a few minutes to determine if emails are coming through.

Dynamics CRM Email Router Troubleshooting 101 – Outgoing Emails

Alternatively, you can remove the requirements for having to approve emails for all users and/or queues. You can do this by going into Settings > Administration > System Settings, and in the email tab, "Process emails only for approved users/queues."

Dynamics CRM Email Router Troubleshooting 101 – Outgoing Emails

Step 5: Check if the email activity exists in CRM.

To find the corresponding email that was supposedly created in CRM that the user claims he or she did not receive, start an advanced find and change "Look for:" to email messages.

Under the criteria, select Direction Equals Outgoing.

Dynamics CRM Email Router Troubleshooting

Now click on Results in the ribbon.

Once you have the list of outgoing email activities in CRM, click on the Modified On column to sort, then search for the email that the user did not receive. You may also want to specify additional criteria in the advanced find to further narrow it down.

If the email activity does not exist, then the problem is not the email route. Instead, it's likely a failure in the process or a user-related error within CRM, such as:

If the email activity does exist, you'll need to examine the status reason of the email activity. Proceed to the next step.

Step 6: Does the Status Reason show as Sent?

If the status reason shows as sent, that means the email router successfully sent the email through SMTP or Exchange, and the issue most likely lies outside of the email router.

Step 7: Does the email activity show as Sending?

An email activity should only be in sending status for a short time. If it is in perpetual sending mode, you may see the "Number of delivery attempts" repeatedly going up (ideally, this number should not be higher than 1.) You'll need to verify that the sender of the email has access to the server sending the emails. Also check the error logs on the email router server to determine if a specific reason is causing it to fail.

Step 8: Does the email activity show as Pending Send?

An email activity in pending send is one that does not have a means to be delivered, which could mean various things. Since we have already checked that the user reporting the issue is set to use the email router, we should double check that the sender of the email has that set as well.

Open the email activity and check the sender of the email. Whether it is a queue or a user, it should have outgoing set to email router and access approved. See steps 3 and 4 on how to set this.

If the email was generated from a workflow where the owner of the workflow is different than the sender of the email, then the sender needs to have all emails on your behalf set.

  1. Login to CRM as the sender of the email.
  2. Go to File > Options.

    Dynamics CRM Email Router Troubleshooting 101 – Outgoing Emails

  3. Go to the email tab and check "Allow other Microsoft Dynamics CRM users to send e-mail on your behalf."

    Dynamics CRM Email Router Troubleshooting

    Note: it may be beneficial to have this setting for all users. Since having every user log in to CRM to change their personal options can be tedious, you can update all users at once through two different methods. If you have direct data base access, you can run a SQL update query, in the orgname_MSCRM database:

    update usersettings

    set issendasallowed = 1

    If you are using CRM Online, or do not have database access, you can also set this setting by downloading the user settings utility, available free from Codeplex. This allows you to manage user settings, including the allow email setting, through a web interface.

If the email activity is still in pending send status after these steps, login to the email router server, open the email router configuration, go to the tab for "users, queues, and forward mailboxes," and click load data. Check if the sender of the email appears in the list, then click Test Access. Make sure it succeeds. Then click the Publish button, and see if the email gets sent. If not, proceed to the next step.

9) Check the email router service.

First, check if the service "Microsoft Dynamics CRM Email" is running. If not, then start the service. If the service does not start, check if it is running under a service account, and if so, update the password to make sure it is correct. You may also try running the service as local system.

If this is not the case, then go to the following folder: C:program filesmicrosoft dynamics CRM EmailService

Rename the file Microsoft.Crm.Tools.EmailAgent.SystemState.xml to something else (like .old). Then attempt to restart the service.

Note: If you have incoming profiles set up, there are further considerations to take before renaming this file, since it keeps track of the last threshold date. Essentially, if this date is lost and you have queues setup, all previous emails will be re-created in CRM.

If it still doesn't start, it is possible the config file is corrupt. Sometimes this happens after a rollup update, but it is not a common error. To fix it, rename the following file to something else: Microsoft.Crm.Tools.EmailAgent.xml. Then run a repair on the email router installation, which will recreate that file, and attempt to start the service again.

10) Test access to the organization.

If the service is running correctly, open the email router configuration, go to the tab for "users, queues, and forward mailboxes," and click load data. If you receive an error message, verify that the account specified in the deployment can successfully login to the organization.

For on-prem environments, the quickest way to check is in the deployments tab. Open the configured deployment and copy and paste the URL into a browser, still on the email router server, while logging in as the user specified in the deployment.

If you cannot login, then verify that the user still has access, along with the system administrator security role. Possible reasons for failure to connect are:

If you can login through a browser, check if the user is in the privUserGroup security group, within active directory.

For CRM Online, attempt to login through the regular CRM URL in the email router server. Some possible reasons why it would suddenly fail to stop working are similar to an on-prem environment. A change in the deployment configuration could be a migration from CRM Online Live-ID to Office 365, in which the discovery URL changes.

One last thing to check is if you can still create a discovery service. You can test this by going to Settings > Customization > Developer Resources, and click on the URL below discovery service. This will bring up a new page that starts with "DiscoveryService Service" at the top. Click on the link at the top, just to the right of svcutil.exe, which should bring up an XML page. If you see a 500 error in the XML, then the Discovery service needs to be repaired before the email router will start working. As a quick fix, try an iisreset on the front end application server.

11) If you can successfully load data, then click on test access.

If an error message is received, verify that the connection to the SMTP server is still valid with correct access, and that the SMTP service is running. The error messages here are usually very accurate, and will say the exact error (such as unable to relay, impersonation failure, etc.)

If access is succeeding but no emails are being sent, there are two things to check:

12) Additional considerations.

If you've gone through these steps and are still having trouble, consider having PowerObjects help provide some support. We're happy to help!

Happy CRM'ing!

Error: Can't Login to CRM After Windows Update to ADFS 2.0

After applying recent Windows Updates to your ADFS 2.0 environment within Windows Server 2008, you may experience an issue affecting all users who attempt to log in to Microsoft Dynamics CRM. Users will not be able to login, and instead will receive the following error message:

"There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem."

Additionally, when looking at the Event Viewer under AD FS logs, you will see the following error:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)

   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)

   at Microsoft.IdentityModel.Configuration.SecurityTokenServiceConfiguration.CreateSecurityTokenService()

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateSTS()

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateDispatchContext(Message requestMessage, String requestAction, String responseAction, String trustNamespace, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext)

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)


The problem with the recent Windows Updates can be attributed due to incompatibility with the version of AD FS 2.0. The specific updates that caused this problem are as follows:




Apply Update Rollup 3.0 for ADFS. You can download and install from the following location:

Alternatively, uninstalling the recent Windows Updates will also correct the issue.

Additional Notes:

This issue only affects Windows Server 2008. We have not seen this problem happening for Windows Server 2012.

As always, if you need assistance, PowerObjects can help—just contact us.

Field Is Not Unique Error when Importing a Solution in CRM 2011

If you have production CRM environment and development/test/UAT environment(s), you have probably encountered a situation where you may need to create fields manually separately in both environments. If you do this and then later import a solution from Test to Production, you may see an error in the solution import claiming that field with the specified name already exists, or that 'Column names in each table must be unique. Column name x in table yy is specified more than once.'

This is usually result of schema of the field being different. It could be string in one CRM and option set in another. A trickier problem is when the schema name of the field differs by capitalization, for example po_testfield and po_TestField. Capitalization is ignored when checking if the field already exists, but for some reason it is not accepted as same field and be updated with new metadata.


Here are two screenshots of same field in two different CRMs. Even if the name of the field is same for both 'po_testfield', the schema name is different for 'po_testfield' vs 'po_TestField'. Importing a solution containing this field will result in above error.

Field Is Not Unique Error in Dynamics CRM

Field Is Not Unique Error


To fix this issue, delete the field in test and recreate it with matching schema name. After that, the field should be recognized as a same field and will not result in error in the subsequent imports.

More information regarding best practices of CRM 2011 solutions can be found in the following blogs:

And of course, if you are still experiencing issues or have additional questions, you can always reach out to the CRM experts at PowerObjects!

Happy CRM'ing!