Configuring Outlook Client for Microsoft Dynamics CRM via a Second Federation

One of the great things about Microsoft Dynamics CRM is the ability to configure an ADFS server to be able to login via different domains. The configuration is done through a claims trust. Once the configuration is complete, users are then able to navigate to the CRM URL and simply click which federation they want to log into.

While this feature is extremely useful, the CRM Outlook client does not allow for the ability to choose domains as you would through a normal web browser. Today's blog, however, will show you exactly how this can be achieved by making an addition to the local workstation registry.

Before you begin, you will first need to know the Home Realm URL of the ADFS server you want to configure with the Outlook client. Once you have this, simply follow the steps below on the workstation that you are configuring the Outlook client for. Let's get started!

            1. Open the registry editor.

Warning: editing the registry should only be done by an experienced user as system errors can occur if done incorrectly. If you are not comfortable using the registry editor, it is recommended that you seek additional assistance from your IT staff.

To find the registry editor, search for 'regedit' on your device and then open.

Configuring Outlook Client

2. Open the registry key following the path HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoft.

Configuring Outlook Client

3. Right-click on Microsoft, select New Key, and add MSCRMClient.


Configuring Outlook Client

4. You should then see the MSCRMClient under Microsoft.

Configuring Outlook Client

5. Right-click on MSCRMClient, select New and then String Value.

Configuring Outlook Client

6. Type in HomeRealmURL.

Configuring Outlook Client

7. Right-click on HomeRealmURL and select Modify.


8. Enter in the Value data of the federated ADFS. The URL must end in /adfs/service/trust/mex.
    Then select OK.


     9. Close the registry editor.

   10. To configure CRM for Outlook, follow the steps included in the blog Install Dynamics CRM 2015 for Outlook.

*Please note that in an enterprise environment it is suggested that the value be set through a group policy.

That's all it takes! If you need further assistance on how to accomplish any steps or instructions in this blog or if you want to learn more, you can view the official documentation from Microsoft or seek help from our CRM support desk.

Thanks for stopping by our blog today! And as always, happy CRM'ing!

Fixing the Plugin Registration Tool Error in Dynamics CRM

PowerWebForm is one of our nineteen Dynamics CRM PowerPack add-ons. It is a great tool that allows you to develop custom web forms and post them on a website. It then lets you capture information from the web form and instantly pull that information directly into your CRM.

Though unlikely, you may encounter an issue after installing PowerWebForm where the web form data is not being written back into CRM. This is caused by an error with the CRM Plugin Registration Tool.

Here is what the error looks like when you try to access the organization through the CRM Plugin Registration Tool:

Plugin Registration Tool Error in Dynamics CRM

This is a known issue with ADFS 2.1 on a Windows 2012 server. The WS-Metadata Exchange (MEX) endpoint configuration and Microsoft issued a hotfix for it. You can verify the issue by looking at the value contained in the ActiveMexEndpoint row of the FederationProvider table of the Dynamics CRM database.

Here is what the incorrect entry looks like:


After installing the hotfix, the correct entry looks like:


Once you have installed the hotfix, run through the Claims-Based Authentication and IFD wizards respectively, and perform an IIS reset. Now you can check for the correct entry above in the Federation Provider table.

This should solve the issue with the Plugin Registration Tool error in Dynamics CRM.

For more helpful Dynamics CRM tips keep checking our blog!

Happy CRM'ing!

Are You Getting an Error Accessing CRM via ADFS 3.0?

Have you ever attempted to access Microsoft Dynamics CRM via ADFS 3.0, and encountered an error like the one below?

Error Accessing CRM via ADFS 3.0

"An error occurred. Contact your administrator for more information."

Using ADFS 3.0 and accessing CRM will result in the error you see above. This is due to the way ADFS 3.0 handles security—it doesn't utilize IIS anymore. To resolve the error, follow these steps:

  1. Open your ADFS 3.0 management console and click Authentication Policies, then click Edit.
    Are You Getting an Error Accessing CRM via ADFS 3.0?
  2. Make sure you have the sections highlighted in the screenshot below checked within your security settings.
    Are You Getting an Error Accessing CRM via ADFS 3.0?
  3. Restart ADFS service and attempt to access CRM again.

That's it! Of course, if your issues persist, you can always contact the pros at PowerObjects for help.

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!

ADFS 3.0 and Microsoft Dynamics CRM

Active Directory Federation Services (ADFS) is a common part of Dynamics CRM implementations because it allows for secure, supported, and efficient claims-based authentication into Dynamics CRM environments, as well as a secure SSL encrypted Internet Facing Deployment. It is also required for many of our most popular PowerPack add-on components for Dynamics CRM.

The most common ADFS deployments have been of the ADFS 2.x variety, and once the configuration principles are understood, it is a lot less daunting to set up. Now, with the release of ADFS 3.0, there are some new things to keep in mind when implementing ADFS with CRM/Office 365.

The AFDS configuration process for CRM more or less the same as it stands now, with a few tweaks here and there. More updates and findings will inevitably follow as ADFS 3.0 and its new features are used with Dynamics CRM, and your friendly neighborhood CRM experts at PowerObjects will be here to explain them for you!

Happy authenticating and 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.

Office 365 – Login with Local Domain Credentials – No Need for ADFS

A few weeks ago, Microsoft released a new version of DirSync. For those of you don't know, Dirsync is a tool that enables you to easily sync your Active Directory users and changes to Azure Active Directory.

The biggest change that we saw in this new version is password synchronization. With the newest version of the Dirsync software installed, you are now able to sync password hashes from your local Active Directory to the cloud, thus enabling users to login with corporatelocal domain credentials without the need for an ADFS server. The best part is that if you have installed and set up Dirsync already, there is just one more box to click to enable password synchronization.

Office 365 Single Sign-On - No ADFS

The password synchronization feature works by sending a hashed value of passwords from your local domain out to the Azure Active Directory environment. A couple key notes about this new feature:

What does this mean? It means this is very secure.

The benefits of this new solution from Microsoft are twofold:

  1. Smaller companies that run a few servers are able to run the Dirsync application anywhere in their environment, EXCLUDING the domain controller. This eliminates the associated costs of a separate Active Directory Federated Services (ADFS) server.
  2. There is cost and time savings realized by your IT department avoiding patching, maintenance, and troubleshooting of an ADFS server.

We tested and successfully implemented the solution. In the test, we used two Windows Azure virtual machines running Windows Server 2012 – one domain controller and one server to run DirSync – and a new Office 365 trial account.

DirSync's standard sync interval is three hours, but you can run manual syncs or even change the sync interval.

Manual Sync:


Change sync interval:

Navigate to:
C: Program FilesMicrosoft Online Directory SyncMicrosoft.Online.DirSync.Scheduler.exe.Config
Edit the tag <add key="SyncTimeInterval" value="3:0:0" />

The values in this tag follow the format hours : minutes : seconds. Also note that the synchronization process can take some time depending on how much information needs to be synced.

When passwords are changed in the local Active Directory, we were able to use the new password to log in to Office 365 within 30-60 seconds.

We also explored what happens when accounts are deleted. After DirSync is enabled, any account that is deleted within Active Directory will be deleted in the Online Service Portal after the next directory synchronization. If you try to re-create the account in Active Directory after this, there will be a new account in Office 365, and the account will not be mapped back to the old account in the cloud. Accounts created within AD cannot be deleted on the cloud side, but you still assign and remove licensing for the online dashboard.

Looking for more nitty-gritty details on this solution? Checkout this recently published TechNet article:

Still have questions? See if they are answered in this wiki:

Need help configuring DirSync? Just give a call and we'll be glad to help.

Happy CRM'ing!

ADFS and Single Sign On: Working with Non-IE Browsers (Chrome, Firefox, Safari)

Active Directory Federation Services (ADFS) is a great option to enable single sign on with Microsoft Dynamics CRM Online and other applications. If you are using ADFS with a portal or other application (pretty soon CRM too), you want to make sure the login mechanism works with all browsers and NOT just IE.

A small glitch is that browsers such as Chrome and Firefox do not support ‘enhanced protection’ when using windows authentication. So what does this mean?

It means that if you log in with ADFS from a non-IE browser, it will not work. You will see this authentication failure in the application log:

An account failed to log on.

    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -

The good news is that the fix is easy. Simply turn off Enhanced Protection for Windows Authentication in IIS in the adfsls folder.

Log in to your ADFS server. In IIS, expand adfs, then right click on the ls subfolder.

Double click on authentication, then in the advanced properties for windows authentication, turn off ‘enhanced protection’.

ADFS and single sign on

There you go! ADFS and single sign on for non-IE browsers.

Happy CRM'ing!

How to Register a Dynamics Application with ADFS

During a recent project, we began developing an application that would use the WebAPI. The application is for a client that is using Dynamics 365 On-Premises. For this setup, we used ADFS 4.0 and Dynamics 365. There is a lot of documentation from Microsoft on this process, if you are familiar with CRM development there are usually some slight differences for doing things in a Dynamics Online versus On-Prem environment. However, sometimes the documentation for on-premises misses a step or two.

The majority of the steps to get an application registered with Active Directory can be found here on MSDN, we're just missing one small detail that can cause some non-descript ADFS errors like this:

In the article, it fails to mention the fact that we need to grant Application Permissions to the application within ADFS. Fortunately, this is a pretty easy thing to do. Just open a PowerShell prompt on your ADFS server and enter the following:

Grant-AdfsApplicationPermission -ClientRoleIdentifier "clientid" -ServerRoleIdentifier "Dynamics URL" -ScopeNames openid

After running the command, you should get a token the next time that you attempt it.

Once we started using the Web API with our API testing console, we examined the token and observed that the token was not issuing a refresh token to use. Microsoft recommends refreshing the token with every call, so this was a problem. Fortunately, this was a problem that a few minutes of research could solve; see the PowerShell below to allow the issuance of the refresh token.

Set-AdfsRelyingPartyTrust -TargetName "RelyingPartyFromADFS" -IssueOAuthRefreshTokensTo AllDevices

If you're still not receiving a refresh token as part of an authentication response after making this change, make sure that the SSOLifetime parameter is greater than the TokenLifetime by running the Get-ADFSProperties PowerShell. A refresh token will not be issued otherwise.

For more Dynamics 365 troubleshooting, how-tos, and tips – check out our blog!

Happy Dynamics 365'ing!