Wednesday, 23 April 2014

Dynamics CRM 2013 Yammer Configuration On-Premise

Dynamics CRM 2013 gives you the possibility to integrate CRM 2013 with Yammer enterprise social networks, this feature On-premise only works with the latest RU2 v2 patch you need to make sure you have version installed on your deployment manager.

First things first download RU2 v2 and install it on your CRM environment.

Authorize the Microsoft Dynamics CRM to use Yammer
Navigate to Settings > Administration > Yammer

Click Continue in the disclaimer window.
On the next page click on the Hyper link on step 1. Authorize Microsoft Dynamics CRM OnPremise to connect to Yammer:

You will get prompted for your yammer credentials you must be full yammer admin and yammer must be an enterprise version. The below pop-up window will appear to type your username and password. You may get the below error:

The remote name could not be resolved:

the above error relates to the fact that my servers are behind a proxy and don't have direct internet connection there are two possible solutions for this:
  • You use hosts file and point to the external IP (this will depend on your network set up)
  • Configure IIS web.config file to use your proxy (Recommended)
To fix the issue Navigate to your CRM website under: 
C:\Program Files\Microsoft Dynamics CRM\CRMWeb 

Edit the web.config file in notepad and just before the closing tag: </configuration>
copy and paste the below code:

    <proxy proxyaddress="http://myProxyIP:80" 
           bypassonlocal="true" />

You need to do this on all your front-end servers. if you manage to authenticate and approve CRM in yammer you get a Congratulations message at the bottom of the screen:

Enabling Yammer feeds
Yammer now becomes the default feed in the dashboard page but in order for users to access the yammer feeds they need to verify their account:

Note on the right-hand side I follow 4 opportunities and 1 organisation this I believe is a glitch/bug because those records are for activity feeds after I've followed the first opportunity since yammer feeds were enabled those stats were reset to 1 to the new opportunity I've just followed.

After your account is verified you should see the below screenshots:

and the yammer feed on your dashboard home screen, note that this feed is your global feed:

Just after the initial set up I see the below message when accessing opportunities:

Following the opportunity you then get access to the yammer feeds:

For every record you would like to share in yammer or access the yammer feeds of that record you will need to follow it.

I hope this was useful. I don't think yammer on RU2 v2 is free of bugs there is more to be done to improve this integration

Wednesday, 5 March 2014

Dynamics CRM 2013 Email To queue - Sink Mailbox with Exchange Server-side Synchronization

In CRM 2011 if you want to set up a queue to receive all emails sent to a specific mailbox also known as 'sink mailbox' you needed to configure the email router to process emails for specific queues it was a manual process that had to be configured on two different components CRM and Email router.

On CRM 2013 using Exchange Server-Side Synchronization to set up emails to queue is a straight-forward process:

  1. Create the queue (set an email address)
  2. Configure the Mailbox (for server-side synchronization)

1. Create the Queue
Set the email address that you want to monitor for emails.

2. Configure The Mailbox
Configure the Mailbox for Server-Side Synchronization you also need to specify a working Server Profile
Note: the service account configured on the Server Profile must have impersonation rights for the mailbox we want to monitor

Check the Queue

Hope this was helpful
Please let me know if you need assistance you can contact me on:

Friday, 28 February 2014

Outlook 2013 disabling CRM client based on loading time

If you going to roll-out Outlook 2013 and you using CRM Outlook client you should be aware of a new feature enabled by default on Outlook 2013 which will certainly cause conflicts.

Outlook 2013 ships with a feature that can disable add-ins on-the-fly based on loading times. I found that my CRM client was disabled because it loaded in 1.8 seconds:

To avoid this happening and make sure that the "always enable this add-in" is enabled by default for the CRM Outlook client we can add a registry key with the CRM add-in name under a registry folder with name: DoNotDisableAddinList


The name of the add-in crmaddin.addin can be found on the below registry key


Hope this helps.
If you need assistance please contact me on

Tuesday, 28 January 2014

Dynamics CRM 2013 ADFS 2.1 with windows 2012 - CRM Outlook client issue

If you configuring ADFS with Windows 2012 you will find that you can't configure the CRM Outlook Client. This is due to a bug in ADFS 2.1 which does not correctly set it's ADFS ActiveMexEndPoint to the correct location.

When you attempt to configure the CRM Outlook client you get:

14:44:16|  Error| Error connecting to URL: Exception: Microsoft.Crm.CrmException: Authentication failed
   at Microsoft.Crm.Outlook.ClientAuth.ClaimsBasedAuthProvider`1.AuthenticateClaims()
   at Microsoft.Crm.Outlook.ClientAuth.ClaimsBasedAuthProvider`1.SignIn()
   at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError)
   at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.DeploymentInfo.LoadOrganizations(AuthUIMode uiMode, Form parentWindow, Credential credentials)
   at Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.InternalLoadOrganizations(OrganizationDetailCollection orgs, AuthUIMode uiMode, Form parentWindow)

In CRM the information for the ADFS ActiveMexEndpoint it's hold on the FederationProvider table column: ActiveMexEndPoint this information is written every time you configure Claims-Based Authentication. On the MSCRM_CONFIG database run the following command:

select * from FederationProvider

The default url looks like this:

And you need to update it to:

To udpate the ActiveMexEndpoint run the below query on your SQL database MSCRM_CONFIG database.

update FederationProvider
set ActiveMexEndpoint = ''

Alternatively you could run the following Powershell: 

You can also apply a hotfix released specifically to correct this issue: 

If you need assistance configuring ADFS in your company feel free to contact me on:

Thursday, 16 January 2014

Dynamics CRM Office365 email relay

This article walks you through how to relay CRM email to office 365 using both Email router and a SMTP virtual server.

The idea is to get the email router to forward all emails to the virtual SMTP server. Why use a SMTP virtual server? You can relay email to virtually any Mail server on the internet and the greatest advantage is to relay email from different senders e.g. if you have users in CRM where their primary email address is not the same as your company email address. With the virtual SMTP server you can choose where to send emails from those users.

Also and this is where we focusing our configuration is the ability for the SMTP server to relay emails to office365. Office 365 settings are the following:

  • SMTP server: smtp.office365
  • Port: 587
  • TLS 

We will go through the following items:

  1. Self-signed certificate
  2. Office365 settings
  3. SMTP server configuration
  4. SMTP domain configuration
  5. CRM Email Router
  6. Read Me

To install the SMTP server on windows 2008 or 2012 you use Windows Roles and Features control panel. Adding the new SMTP role to the server will automatically include the IIS management 6.0 mmc snap-in console to your administration tools this is required to manage the SMTP virtual server.

Note: Because Office 365 requires TLS you will need a certificate, a self-signed certificate will work perfectly.

1. Generate a self-signed certificate
Using IIS 7 console highlight the Server and click certificates:

On the right-hand side Click on create self-signed certificate. fill in the details and click finish

2. Office365 Set up
Before we configure the SMTP server we need to have an account which is allowed to connect to office365 and allowed to relay email to other users.

Navigate to and navigate to Users and Groups click on the user account you want to use.

After you click on the user account go to licenses and make sure the user account has an Exchange Online license.

The account also needs SendAs permissions on the office365 exchange online instance. To set this permission you use the following powershell commands:

$Cred = Get-Credential
$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $s
Add-MailboxPermission -User -AccessRights FullAccess
Add-RecipientPermission -AccessRights SendAs -Trustee  

you can read more about the commands on the following articles:

3. Configuring SMTP server
Open the IIS 6.0 management console and you should see the below screenshot. right click the SMTP virtual server and click properties

On the General tab you don't have to change anything here unless you want to enable logging:

Click on the Access tab, here we need to make sure the relay options allow the email router to relay email. Click On the button Relay

Below I've chosen All except the list below, you can be specific here and specify the email router IP address so only the email router can relay email.

Delivery Tab will define the general settings of the SMTP virtual server:
  • Outbound connection Port
  • Default smart host (this is the server where emails are sent to)
  • Authentication with the smart host
Click on Outbound Connections.

And change the port to 587

Click on Advanced button and type:
  • FQDN (your office 365 domain):
  • Smart Host:

Click on outbound Security and choose:
  • Basic Authentication
  • type
  • tick the TLS box

4. SMTP Domain
we need a domain to tell the SMTP server that for this specific domain we want to send this emails to that smart and this is the beauty of having a SMTP virtual server.

Click on domains and right click select new domain.

Select 'Remote domain'

Type your office 365 domain:

when your domain is created on the domain section right click and select properties:

On the below screen:
  • Tick the box to allow incoming email to be relayed to this domain
  • Choose Forward all mail to smart host
  • Click on Outbound Security

Type the user account and password for office365 and tick the box TLS.

5. Email Router configuration
Okay we are almost there :)
Now the email router needs to be configured to point at the virtual SMTP server so it can send all CRM emails to the SMTP server to be processed.

On the email router configuration create a new outgoing profile and on the Email server type your new SMTP virtual server if is located on the same server you can type localhost.

Now link your deployment with the new outgoing configuration profile.

Read Me
If you need assistance configuring office365 relay email please let me know on

Hope the article was helpful. if you need to relay email to multiple domains in office365 you can add extra domains, if you need relay email to domains outside office365 you can add a new virtual server to hold the other domains.

Wednesday, 4 December 2013

You find my posts helpful?

If you like to grab a coffee/tea and read some of my posts and you think they had value to the CRM community, please consider nominating me for MVP on the below link:

My email address:

Thanks for your help.

Nuno Costa

Friday, 22 November 2013

Dynamics CRM 2013 exchange auto-discovery

I was troubleshooting the auto-discovery process in CRM 2013 server-side synchronization and built an interesting picture on the process, if you ever need to troubleshoot the exchange auto-discovery hope this article helps.

The below diagram illustrates the steps CRM asynchronous service takes to lookup an exchange server.

  1. Queries DNS for a LDAP server
  2. Queries LDAP for SCP pointers and SCP URLs
  3. LDAP returns the data and CRM connects via HTTPS to the relevant exchange server

For troubleshooting I'm using wirehark for network traffic capture. Before you start capturing packets in wireshark first enable one of the exchange profiles to use auto-discovery make sure you have one mailbox for testing and start capturing packets with wireshark. Now enable the mailbox this will trigger verification steps and you should see successful or failure messages in CRM when you get all 3 messages go to wireshark and stop the capture.

The first protocol we may want to look at is DNS so we want to know what CRM is querying to find out the Exchange server, on the search bar in wireshark type dns

below we see a number of things happening but the first thing I've noticed it's CRM querying for an SRV record of type _ldap

if we open the packet we can see the servers that are returned based on that query.

Fine, so lets see what's happening on the ldap side, type ldap on the search bar and you should see the following conversation:

There is quite a lot going on on the above packet capture, digging into a number of packages I come across the below traces which shows me CRM is looking up:

SCP pointers

you can get more information about this on:

To test this I've copied the same filter on the packet captured with wireshark and fired the ldp tool and done the same search and also included the attributes listed on the captured packet: serviceBindingInformation and Keywords


if I run the above query I get the following results:

 so we come up with the query needed to test the LDAP query CRM will perform to lookup the exchange server. After this all queries are HTTPS and we can't see what is going one.

Hope this helps.