Cannot Login to a Previously working Microsoft CRM IFD
A previously working IFD deployment of CRM 2016 (but could be CRM 2015 or CRM 2013). About 1 year after you set the system up, you start receiving: An error has occurred. Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.
When researching this error, we suspected what it was, and related to an article we covered here: http://www.interactivewebs.com/blog/index.php/crm-2013/microsoft-crm-2013-or-2015-event-id-1309-adfs-ifd-resolution/
However we never found and EVENT ID 1309 or anything close to that in our logs. The closest error we found (and we are not even certain that it was pointing as a result fo this problem) was the error: EVENT ID 415
The SSL certificate does not contain all UPN suffix values that exist in the enterprise. Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices. For more information, see http://go.microsoft.com/fwlink/?LinkId=311954.
This problem arises from a Certificate Rollover that the ADFS server does about 1 month out from your 1 year anniversary. The problem is that the ADFS certificate rolls over, but the CRM configuration does not pickup that new certificate.
o locate your ADFS Certificates, navigate to the ADFS Console. Under “Service”, click on “Certificates”, where you will find a Primary and Secondary certificate. If the current date is close to the date of your Primary certificate “Effective Date”, it’s safe to assume that this is the underlying issue.
To resolve this issue:
1. Navigate to the ADFS Console >> Trust Relationships >> Relying Party Trusts. 2. Right click on the trust and select “Update from Federation Metadata…” a. If there are two trusts, do them both. This may be a case where you have one for Internal and External.
3. Open Command Prompt. Be sure to right-click and “Run as Administrator”. a. From within CMD, type “iisreset”.
4. Open “Services” and restart the “ADFS” service.
a. If ADFS does not start, be sure to check the “Windows Internal Database” service and make sure it is started, and then try restarting the ADFS service.
If these initial steps do not resolve your issue for any reason, continue with the following steps below:
5. Navigate to “CRM Deployment Manager”. a. Run “Configure Claims-Based Authentication” wizard, upper right hand corner. b. Click “Next” all the way through the wizard, nothing needs to be changed here.
6. Run “Configure Internet Facing Deployment” wizard. a. Click “Next” all the way through the wizard, nothing needs to be changed here either.
7. Now, perform Steps 1-4 again as outlined above. a. Update Federation Metadata b. IISReset c. Restart ADFS Service
Your users should be able to log-in to Dynamics CRM again. I hope you find this helpful and that it resolved your issue.
After upgrading Microsoft CRM from earlier versions we found that the global search function when enabled failed to return any results, and once the index for the global search had run over a 24-hour period, the in-line search function for any entity would cause a crash and SQL error message to be displayed on page.
In our particular instance this CRM environment had been upgraded from much earlier versions of CRM and included an attempt to solve some upgrade issues by dropping indexes. Initially our thoughts were that the dropping of the indexes were responsible for the problems. However it appears retrospectively that was a fragmentation of indexes that cause the issue. I cannot be exactly sure why the maintenance procedure that is run on the SQL Server did not rebuild and reorganise the indexes sufficiently that the global social function. However the following solution did work for us.
the reference provided by Microsoft was helpful, but not as helpful as we would have liked. We ended up running the following query that automatically rebuilt all the indexes.
DECLARE @TableName VARCHAR(255) DECLARE @sql NVARCHAR(500) DECLARE @fillfactor INT SET @fillfactor = 80 DECLARE TableCursor CURSOR FOR SELECT OBJECT_SCHEMA_NAME([object_id])+’.’+name AS TableName FROM sys.tables OPEN TableCursor FETCH NEXT FROM TableCursor INTO @TableName WHILE @@FETCH_STATUS = 0 BEGIN SET @sql = ‘ALTER INDEX ALL ON ‘ + @TableName + ‘ REBUILD WITH (FILLFACTOR = ‘ + CONVERT(VARCHAR(3),@fillfactor) + ‘)’ Exec (@sql) FETCH NEXT FROM TableCursor INTO @TableName END CLOSE TableCursor DEALLOCATE TableCursor GO
After doing this, we were then able to turn on the global search and weight the relevant period of time for it to complete the indexing. It appears to have fixed our problem with both global search returning valid results, and in-line search no longer broken when global search was unable.
CRM 2016 Import Upgrade from CRM 2015 Failure: Timeout expired
On attempting to upgrade a Microsoft CRM Dynamics 2015 Database to CRM 2016 (without service pack) you receive a Failure: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding..
This happens at the System Check stage.
There are a bunch of suggestions online from earlier releases of CRM like 4.0 etc suggesting that you may need to change the timeout settings on the settings with some DWord changes in the registry. In this case it is not the cause.
Microsoft has again released an initial version of their software with some significant bugs. The biggest of these being that you cannot import your CRM 2015 database to upgrade to CRM 2016 if it has a Full Text Catalogue. Something that is likely if you have been using the improved searching functions of CRM 2015.
All care and no responsibility with this one. The prudent process would be to either upgrade an existing CRM 2015 environment in place, which form all reports will correctly update the CRM database in question to CRM 2016 without error. Alternatively you can wait the months that are likely required for Microsoft to get around to releasing a patch for this problem.
1. Fresh on CRM 2016 SQL Server. Restore your backup of your CRM 2015 database.
2. On the SQL manager, select the Database in question, and select “New Query” (our 2015 dates restore is CRM_MSCRM)
3. In the new Query window. Paste the following code and click Execute.
Print‘ALTER FULLTEXT INDEX ON [dbo].’+@TableName+‘ Add (‘+@ColumnName+‘)’
fetchnextfrom e into @ColumnName
fetchnextfrom d into @KeyIndex, @object_id
fetchnextfrom c into @TableName, @UniqueID
4. When the query executes successfully. Copy to the Clipboard all of the “Message” output in the bottom half of the screen to your clipboard.
5. Now Expand the “Storage / Full Text Catalogues” section of the Database in question and select Properties.
6. Select Table / Views
7.Using the the little Left pointing arrow. Click it as many times as needed to move all the items on the right to the left.
8. Once finished, select he Script Dropdown and select “Script Action to New Window” (or just click on OK both actions should work)
You should see a Progress script Completed Successfully.
9. Now Close all the Management for the SQL Server. This is Important.
10. Upgrade your CRM database the normal way using the Microsoft Dynamics Deployment Manager / Organisations / Import Organisation
Skip through the steps here as you normally would Noticing that it no longer stalls on the recheck before upgrade.
11. Once the upgrade has finished and you have your database imported and upgraded to CRM 2016, Open the SQL manager for the database in question again, and run a new query against the database as we did in step 3 above.
This time however we are going to paste the output we captured to clipboard in step 4 above, and run that output as a script.
Click Execute again. And you should be rebuilding the database indexes to a state that will function with the new CRM upgraded database.
P.S. Microsoft. You suck balls at initial releases!
How to Set Up Microsoft CRM 2016 IFD on Windows 2012 R2 Server
We already have a popular post for the configuration of IFD setup with CRM 2015, CRM 2013, CRM 2011. Now we are updating this post to support CRM 2016.
Microsoft have a compatibility listing for CRM 2016 here: https://support.microsoft.com/en-us/kb/3124955
The Development Setup
Once again we are running this configuration as a test environment for development. As such we will be running, we are running the server on a Hyper V server. A single VM machine, that is running a fully patched version of:
Windows 2012 R2 SP2 64 Bit – (MSDN File: en_windows_server_2012_r2_x64_dvd_2707946)
SQL 2014 R2 64 Bit – SQL Server 2014 Standard Edition x64 – (MSDN File: en_sql_server_2014_standard_edition_x64_dvd_3932034) – Patched to SP2
Microsoft Dynamics CRM Server 2016 – en_microsoft_dynamics_crm_server_2016_x86_x64_dvd_7171743
NOTE: The Domain we have used for setup with this dev server is: iwebscrm16.com You can substitute your domain in place throughout these step by step IFD instructions CRM 2016.
Getting Windows Server Ready
1. Install and Update Windows 2012 R2.
2. From the Server Manager – Add Roles and Features
3. Role-Based or Feature-Based instilllation
4. Select the Server from the Pool (usually the default option)
5. Scroll Down and Select Web Server IIS
6. Add Features
And .NET 3.5 Features
7. Next / Next
8. under Web Server Roles (IIS) Use the default options, but add under Performance – Dynamic Content Compression
9. Next / Install
10. Update Window Server again as there is likely a restart update available.
11. After Restart. Ensure that you turn off the IE enhanced security. It’s Crap and no one benefits from it. This is done in the Server Manager under Local Security.
SQL 2014 Setup
1. First Up have the Windows Server Join the Domain you will be using.
2. Reboot and login with the domain admin account.
3. Start the SQL Install Disk
4. Click Instillation / New SQL Server Stand Alone
5. Enter Product Key / Next
6. Agree to Terms / Next
7. use Microsoft Update / Next
8. Ignore the Windows Firewall Warning at this Stage
9. Select SQL Server Feature Instillation / Next
10. Select: Database Engine Service / Full Text Indexing / Reporting Service Native / Management Tools Basic and Complete / Next
11. Leave Default Name
12. Server Configuration Default and Next
13. Windows Authentication Mode / Add Current User (Remembering we are logged in as a Domain Admin domain/administrator)
14. Install and Configure / Next
16. After Completion, Check again for Windows Updates and Reboot. (At the time of writing this blog, the SP 1 for SQL 2014 will be installed if your install disks do not already have this. Like everything Microsoft, it’s not super reliable until they SP1 their product!).
Getting your Active Directory OU Ready
1. Login to your Active Directory Domain Controller as a Domain Administrator
2. Using the Active Directory Users and Computers, Select the Root and Create a new OU named something like Microsoft CRM 2016
3. Log Out of the Active Directory Domain Server.
Installing CRM 2016
During the install, we were asked to install services associated with the services required for CRM 2016.
We Selected all options on install:
Select “Create New Deployment” and enter theServer Name as the SQL server.
If you are not sure of the name, Right Click “This Computer” from the start menu, and select Properties:
Browse to the OU we created in the Steps Above Getting the AD OU Ready, and select the OU we created there. “CRM 2016″
We selected the default account for authority. Note that the blog referenced above suggests a dedicated account for security. As we are setting up a dev environment we did not bother with this.
Create a new Website with port 5555
As we intend to set up the Email Router service on this server later, we set this server “VSERVER06” in this instance as the server for email router service, or you can leave this blank.
We set “CRM2016″ As the default initial test environment deployment.
Reporting Server defaulted to the server name/reportserver
We received a few warnings about the install:
For a deployment that is more secure, the Microsoft Dynamics CRM Sandbox Processing Service should be run under a least-privileged domain user account that is not shared by other Microsoft Dynamics CRM services on this computer.
For a deployment that is more secure, the Microsoft Dynamics CRM VSS Writer Service should be run under a least-privileged domain user account that is not shared by other Microsoft Dynamics CRM services on this computer.
Data encryption will be active after the install or upgrade. We strongly recommend that you copy the organization encryption key and store it in a safe place. For more information, see http://go.microsoft.com/fwlink/?LinkId=316366.
The only one of real interest in our Dev environment would be the last item. making a backup of data encryption keys is always a good idea.
Test that your CRM setup is working. Go to the local computer name (ours is vserver12) on the correct port: http://vserver12:5555
Because we were were logged in as the server administrator, we were able to load, but may take some time to fire up the various server requirements.
Apply a Wildcard SSL Certificate
In CRM, the accessing of deployments is handled by the sub domains. So if we call a deployment (known as organisation) “business1″ we will access that as: https://business1.domain.com:444 (note the the :444 will be because of how we set up Internet Facing Deployment.
For testing, we purchased a standard Wildcard SSL certificate that applied that to the IIS Server
In our case we registered a test domain: iwebscrm16.com and set the SSL wildcard to: *.iwebscrm16.com and applied that cert to the server. The services we used for purchasing the wildcard certificate were starts.com who provide a very cost effective certificate services. Once authenticated, certificates are free to issue.
Application for a certificate
Here, I will be a wildcard certificate, for example, describes how to create a certificate:
1) Open IIS Manager
2) Click the server name in the main screen double click Server Certificates
3) In the right panel, click Create Certificate Request…
4) fill in the following diagram each column, click Next
5) Cryptographic Service Provider Properties page change the Bit Length to at least 2048 click Next.
6) In the File Name page, enter C: \ req.txt , and then click Finish. (You can save it any place you like, with any name)
7) Open the certificate in Notepad, and copy the contents.
This is the text that is pasted into the Start SSL Certificate request page to generate the certificate:
8) After you finish generating the certificate text in StartSSL.com (Note that Start SSL is no longer an SSL certificate provider, we suggest ssl2buy.com) you get a bunch of code that looks similar to the request code. Copy that generated code
9) Paste the code back into a new Text / Notepad Document on the Web server, but call it something that ends in .cer (not .txt).
10) back to the IIS Manager, click No. 3) Step graph Complete Certificate Request …
11) Select the the file you created at point 9 above to complete the request.
12) Click OK. Note: We did get an error message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) In this instance, it turned out to be a crappy Microsoft Error. After doing some research, we found that it was likely meaningless and the cert installed correctly. We rebooted the machine and logged in again, to find that the CERT was there installed as we wanted it to be.
Binding site for the default SSL certificate
1) Open IIS Manager.
2) In the Connections panel, expand Sites , click Default Web Site.
3) In the Actions pane, click Bindings.
4) In the Site Bindings dialog box, click Add.
5) Type select HTTPS.
6) SSL Certificate , select the certificate you just created *. contoso.com , and then click OK.
Ours is *.iwebscrm15.com
7) Click Close.
For the CRM 2016 binding site SSL certificate
This is in effect repeating the above process like you did for the default certificate, but using a different port (444 for example). This way you are binding the same certificate to the two websites in your IIS instance.
1)Open IIS Manager.
2) In the Connections panel, expand Sites , click CRM Web Site.
3) In the Actions pane, click Bindings.
4) In the Site Bindings dialog box, click Add.
5) Type select HTTPS.
6) SSL Certificate , select the certificate you just created *. contoso.com .
7) Port to select a different 443 (e.g. 444 ) and port number, and then click OK
8) Click Close.
We are going to add a few DNS “A” records so that the records listed in point 1-4 below in DNS Goal are resolving correctly to the IP address of your CRM server.
There are two ways you can achieve the desired result. But first lets understand the desired result.
We make the assumption that your server is running at least one static IP address.
Because this is Internet Facing, that IP needs to be accessible to the world.
That same IP can be used for access to your server both internally on the matching we are playing with, and externally form anyone on the net.
Lets Get Basic
Start a Command Prompt, and work out what your IP address of the server is.
Click START > RUN > CMD
Type IPCONFIG – Enter
Under the name: IPv4 Address is a number that looks like: 188.8.131.52
That is Your IP Address of the Server.
The DNS Goal
Make sure that when you PING xxx.domain.com that it points to that IP address. Both for the world and for you when you do that on your server.
(xxx is the sub domain that we are about to configure.)
To configure CRM, we need some sub domains to point to the server IP. Adding records in DNS like this:
Your ORG name. org.domain.com (Where ORG is the CRM deployment name of your organization or organizations), e.g.
crm2016.iwebscrm16.com (We usually set up a dev environment with CRM2016 being the year of the version. Just something we select to do).
adfs.domain.com (used for reference to the ADFS server)
one for the root domain so that domain.com points to the same server. (This is for the ADFS logout URL)
We have two setup here: CRM and CRM2016. So we need to configure crm.iwebscrm16.com and crm2016.iwebscrm16.com (Not necessary but our choice for this instance).
DNS The Easy Way!
The really easy way to solve all this (now we have explained the background) is to simply create a * A record that points to the machine we are using to set up the CRM system.
You must be able to ping all of those names and get the correct server IP address. Both from computers on the internet, and from the server. At the command prompt, type “ping sts1.iwebscrm15.com” for example with our config. Ping them all to be sure you get them correct.
Note: If you have added the DNS records, but still encounter name resolution problems, you can try running on the client ipconfig / flushdns to clean up the cache. You can also click the DNS server root and click CLEAR CACHE so that the server is responding with the latest updates.
Note: Don’t bother proceeding past this step if you cannot ping your sub domains internally and externally correctly.
You need to set the firewall to allow the CRM 2013 and the AD FS 3.0 port used by the incoming data stream. HTTPS (SSL) is the default port 443.
For Initial setup testing etc. We recommend just turning the thing off. Better start from a place where it does not muck you around, then turn it all back on after you are successful.
1) In Windows 2012 I can’t frigging work out how to find anything. Literally! But most things you can search for. As is the case here if you search for “Firewall”. Select the firewall option:
2) Select Turn Windows Firewall on or off
4) Turn Off or On Firewall
Just turn it all off for now. (Remember to come back, turn it on and allow access for the unusual port 444 that you configured earlier for the SSL on the CRM site. But for testing and setting up… the last things you want is to be banging your head agains a firewall.
Just a reminder that at this point we have been keeping snapshots on our Hyper-V environment to allow us to fail back to a location and try again. This is really useful for the setup of something like this that has a lot of moving parts.
Configure the internal access Claim-based authentication requires the following steps:
Install and configure AD FS 3.0
Set Claims-based authentication configuration CRM 2016 server.
Set the Claims-based authentication configuration AD FS 3.0 server.
Test claims-based authentication within the access.
Install and configure ADFS 3.0
This article uses Active Directory Federation Services (AD FS) 3.0 to provide a security token service (security token service or STS ).
Note: AD FS 3.0 will be installed to the default site, so install AD FS 3.0 , you must have CRM 2016 installation in the new site. (Remember we said that earlier)
IIS Looks like this if it is correctly installed:
If you only see the default website with CRM installed in that. Start AGAIN! – We are working with the process as shown here.
Install ADFS Server Role
From Server Manager – Add A Server role for: Active Directory Federation Services
Click Install at the last step.
After if Finishes:
Click the Configure the Federation Services on this server.
Configure AD FS 3.0
1 Click on Configure the federation service on this server.
2 In the AD FS 3.0 Management page , click AD FS 3.0 Federation Server Configuration Wizard .
3 In the Welcome page , select Create the first federation server in a federation server farm, and then click Next.
4 Select next to continue with the current administrator (must be a domain admin).
5 Choose your SSL certificate (the one we created and imported above i.e. *.iwebscrm15.com ) ,add a Federation Service name ( Selecting the second one for the dropdown in this instance iwebscrm15.com, don’t select the one with the wildcard in the name, so not the *.iwebscrm15.com for example.), then Select a Service Display Name for your business – selecting the one that is NOT starting with a *, then click Next.
6 Open PowerShell and run the following command: “Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)”
If you don’t you will se the error: Group Managed Service Accounts are not available because the KDS Root Key has not been set.
7 We specified the Administrator account for the service account, as security is not our primary concern here with a Dev environment. You could and probably should use a defined account for a production environment.
7 Create a database on this server using Windows Internal Database (or you can use SQL instance in the step below), click Next.
Or use the local SQL instance etc if you have one. (Because we have SQL installed on this same server. We are using this SQL instance for the database host.
Note that this will create two new databases in SQL.
8 Review Options click Next
9 Pre-requisits checklist, click Configure
10 You should see a message that “This Server was successfully configured
11 Close out the Instillation progress window
Verify the AD FS 3.0 is working
Follow the steps below to verify that the AD FS 3.0 is working :
1 Open Internet Explorer.
Under Internet Options
Security / Local Intranet
Sites / Advanced
Add *.domain.com to the websites. In our case here we added: *.iwebscrm16.com
Close all this down when added.
2 Now we need browse to the the federation metadata in Internet explorer to test access is working.
Use this URL below as an example to browse to your own server. Remembering that we set up a DNS entry earlier for “ADFS’ on your domain, thus you should be able to browse to the URL below replacing our domain name with yours and have it access the server we are configuring.
(Replace your domain name in place of ours iwebs16.com)
3. to ensure that no certificate associated with the warning appears, and you can view the certificate to be sure it is showing.
Check the certificate is correct and working by clicking on the padlock looking thing and viewing certificate.
Take another Snapshot!
Claims-based authentication configuration CRM 2016 server
After you install and configure the AD FS 3.0 , we need to configure the Claims-based authentication before setting CRM 2016 binding types and the root domain.
1 Open the CRM Deployment Manager.
2 In the Actions pane , click Properties .
3 Click the Web Address page.
4 In the Binding Type , select HTTPS .
5. Change the Server name to the internalcrm.domain.com:444 format. In our case here. internalcrm.iwebscrm16.com:444
6. Then Apply
7. Then OK to close
8 In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Claims-Based Authentication.
9 Click Next on the Welcome page
10 On the Specify the security token service page, enter the Federation metadata URL, in our case because we setup a DNS record for “adfs” we are going to use that: https://adfs.iwebscrm16.com/federationmetadata/2007-06/federationmetadata.xml Note: that this is the same URL we tested ADFS was set up correctly on in the steps above. Also note that the step of adding the domain to internal sites in the IE security settings that we did above is an important one! If you can’t hit that URL on the web browser of the server and get a clean XML defined page, then you deployment will not work.
11 Click Next then select the certificate that we created perviously for the *.domain connection
12 Select Next Note: At this point it is possible to get an error something along the lines of “Encrypted Certificate Error”. This is implying that the account used to run CRM does not have access to the Private Key of the certificate being used. Skip forward to point 25 below, and add the service accounts that CRM is using to the private key of the certificate to be used. This will ensure that this next configuration step has access to the certificate. Then come back to this point and continue.
13 Select Apply (BUT – NOT FINISH)
14 IMPORTANT – Click View Log File
15 Scroll to the end, and Copy the URL from the bottom of the file.
This will be used in the next configuration. Note: that this is different to the URL used in step 4 above, as it represents the internal URL. Subtle but vital (and the cause of frustration the first 10 times we tried this). In our case the URL looked like this: https://internalcrm.iwebscrm16.com:444/FederationMetadata/2007-06/FederationMetadata.xml
16 Click Finish.
Set the CRM AppPool account and the Microsoft Dynamics CRM Encryption certificate.
17 Right Click the Start Button and select RUN
18 Type MMC and enter
19 Select File / Add/Remove Snap-in
20 Select Certificates and Add
21 Select Computer Account
22 Local Computer is selected, so click Finish
23 Expand the console tree / Personal / Click Certificates
24 Right click the certificate we used for the CRM endpoint, and select All Tasks / Manage Private Keys
25 Select Add
Note here: If you do not have the “adfssrv and drs” accounts listed, you will have problems. The solution though is to do this at this point:
Open Powershell as Administrator and run: dir Cert:\LocalMachine\My\
Then using the thumbprint of the Certificate related to this install, run the following command again in Powershell: Set-AdfsSslCertificate -Thumbprint19A0100267EB5D2FC0132260995F6D38C40EBEA1
This will add the two above mentioned accounts to the security of the certificate. This we found in one setup was not automatically done and caused us a large headache.
26 Select Advanced
27 Select Find Now
28 Scroll Down and Find the NETWORK SERVICE Account
29 Select OK / OK
Ensuring that the NETWORK SERVICE has Read Access
Note: We have used the NETWORK SERVICE account here because that is the one associated with the CRMAppPool used in IIS by default for the Microsoft Dynamics CRM Website that was automatically configured with the CRM setup.
If you are using another account for running the application pool, then you should ensure that this account has access to the encryption certificate. Some details can be found here.
30 Validate that you can browse to the URL above. If you cannot view this in a browser, then have a look again at your permissions on the certificate in relation to the account on the application pool in IIS for CRM. Read above: Claims-based authentication configuration CRM 2016 server.
The URL Above that we are checking is the one from the View Log step, that we said to copy.
Once you can browse this URL, you are done if it fails, then repeat the process till you can access the URL on the server in question. Note: Often it is confusion over the port :5555 that defaults in CRM Deployment Manager Web settings and the HTTPS Port :444 that we defined in the binding for the Microsoft CRM Dynamics Website. So double check that you have the correct port set in the Deployment Manager, then run the steps again following that setting.
Checkpoint the Hyper-V at this point.
Claims-based authentication configuration AD FS 3.0 server
Start AD FS 3.0 Management. In the Navigation Pane, expand Trust Relationships, and then click Claims Provider Trusts. Under Claims Provider Trusts, right-click Active Directory, and then click Edit Claims Rules.
In the Rules Editor, click Add Rule, In the Claim rule template list, select the Send LDAP Attributes as Claims template, and then click Next
Step10: Create the following rule
Claim rule name: UPN Claim Rule (or something descriptive) Attribute store: Active Directory LDAP Attribute: User Principal Name Outgoing Claim Type: UPN
Click Finish, and then click OK to close the Rules Editor
After you enable claims-based authentication, you must configure Dynamics CRM Server 2016 as a relying party to consume claims from AD FS 3.0 for authenticating internal claims access.
Add Relying Party Trusts to AD FS
Start AD FS Management. Select Trust Relationships / Relying Party Trusts. Then On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.
On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL you copied earlier from the log file during the creation of the CRM Claims Based Authentication. e.g. https://internalcrm.iwebscrm16.com:444/FederationMetadata/2007-06/FederationMetadata.xml – Note it is probably still open in your browser in the background.
On the Specify Display Name page, type a display name, such as CRM Claims Relying Party, and then click Next.
Click Next on the multi-factor authentication options.
On the Choose Issuance Authorisation Rules page, leave the Permit all users to access this relying party option selected, and then click Next.
On the Ready to Add Trust page Click Next
On Finish Page, click the checkbox option to Open the Edit Claim Rules, Next, and then click Close.
The Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule.
In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.
Create the following Rule #1 Claim rule name: Pass Through UPN (or something descriptive) Incoming claim type: UPN Pass through all claim values
In the Rules Editor, click Add Rule, in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next
Create the following Rule #2
Claim rule name: Pass Through Primary SID (or something descriptive) Incoming claim type: Primary SID Pass through all claim values
In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.
Create the following rule #3
Claim rule name: Transform Windows Account Name to Name (or something descriptive) Incoming claiming type: Windows account name Outgoing claim type: Name Pass through all claim values
Click Finish, and when you have created all three rules, click OK to close the Rules Editor.
Enable Forms Authentication
AD FS in Windows Server 2012 R2, forms authentication is not enabled by default.
Open the AD FS management console and click Authentication Policies. Under Primary Authentication, Global Settings , Authentication Methods, click Edit.
Under Intranet, enable (check) Forms Authentication.
So now we have claims setup for CRM.
Add the ADFS server to the Local intranet zone.
We previously added the *.domain.com or in our case, *.iwebscrm16.com to the Local intranet zone in Internet explorer on the server. If you have not done this you should do it now. Then:
1. Open Internet Options Select the Advanced tab. Scroll down and verify that under Security Enable Integrated Windows Authentication is checked.
2. Click OK to close the Internet Options dialog box.You will need to update the Local intranet zone on each client computer accessing Microsoft Dynamics CRM data internally.
Specify the security token service
1 Open a command line tool .
2 Enter the following command : ( application, in your own environment, substitute the name of the name of the command line )
“setspn -a http/sts1.iwebscrm16.com fserver4\VSERVER40”
– Note – remove the “ “
fserver4\VSERVER12 = the domain / machine name of the server.
c: \> iisreset
Probably good to do a Snapshot again!
Configure Internet-Facing Deployment in CRM Deployment Manager.
1 Open the CRM Deployment Manager.
2 In the tree structure , right-click Microsoft Dynamics CRM , and then click Configure Internet-Facing Deployment.
3 Click Next.
4 Fill in the correct domain information for the Web Application
Thus we use:
Web Application Server Domain: iwebscrm16.com:444
Organization Web Service Domain: iwebscrm16.com:444
Web Service Discovery Domain: dev.iwebscrm16.com:444
Leave the Default option for the Internet Facing Server Location
System Checks work
IFD Summary looks like this. Then Apply
9. Open a command line tool, run: iisreset
ADFS Relying Party Trust for the IFD Endpoint
Effectively you are creating the third Relying party trust in your deployment and the second that you have manually set up at this point. We are doing this again as this is now for the IFD endpoint.
Step 1: Start AD FS Management. On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.
Step 2: On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL to locate the federationmetadata.xml file. This federation metadata is created during IFD Setup.
For example, https://auth.iwebscrm16.com:444/FederationMetadata/2007-06/FederationMetadata.xml (Remember to replace your domain for ours)
Type this URL in your browser and verify that no certificate-related warnings appear.
Step 3: On the Specify Display Name page, type a display name, such as CRM IFD Relying Party, and then click Next
Step4: On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.
Step 5: On the Ready to Add Trust page, click Next, and then click Close.
Step 6: If the Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule
Step 7: In the Claim rule template list, select the Pass Through or Filter an Incoming Claimtemplate, and then click Next.
Step 8: Create the following rule#1
Claim rule name: Pass Through UPN (or something descriptive)
Incoming claim type: UPN
Pass through all claim values
Step 9: In the Rules Editor, click Add Rule, and in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next
Step 10: Create the following rule#2
Claim rule name: Pass Through Primary SID (or something descriptive)
Incoming claim type: Primary SID
Pass through all claim values
Step 11: In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.
Step 12: Create the following rule #3
Claim rule name: Transform Windows Account Name to Name (or something descriptive)
Incoming claim type: Windows account name
Outgoing claim type: Name
Pass through all claim values
Click Finish, and when you have created all three rules, click OK to close the Rules Editor.
Now, you should see three Relying Party Trusts in the ADFS Trust Relationships.
Step 13 – Change Port
Open Powershell and run this command
Set-ADFSProperties –nettcpport 809
Restart the ADFS in Services
Restart IIS in CMD
Browse to the URL: https://sts1.iwebscrm16.com/adfs/services/trust/mex (replacing the iwebscrm16.com with your domain). You should be abel to hit this URL and get a result looking like this:
Test External Access to CRM 2016 with IFD
Now, you should use the claims certified external access CRM 2016 a. In IE the browser CRM 2016 external address (for example: https://crm2016.iwebscrm16.com:444/main.aspx ), you should have success with login.
Problems We Encountered
While developing this blog post we encountered many small errors along the way. We have reverted to CheckPoints and fixed the instructions to allow you to avoid them. One thing we would say is that when resolving errors, it is most likely associated with the AD FS IFD login. When this happens, the AD FS Event Log is your best friend. Hit the Event ID errors up in google and resolve as best you can. Checkpoints are also your friend here!
Turn the Firewall Back On
As you may expect, this is a rather important last step
1. Turn on all Firewall Settings as they were at the start
2. Click Advanced Settings
3. Click Inbound Rules / New Rule
4. Select Port / Next
5. Select TCP and Specify Port 444
6. Allow the Connection
7. Domain, Private and Public all ticked.
8. Give it a name like: CRM Port 444
And you are about finished. Remember if in the future you are mucking with something and getting no place. Turn off the Firewall as a starting point. Banging heads with firewalls is a waste of time!
Remember to test access again externally!
Your Feedback and Our Services
Please post a comment or note if you have anything to add about these notes. We welcome feedback that helps us improve them.
If you have a need for CRM 2016 Developer Services, we offer professional services and support for CRM 2016. This includes upgrade services for upgrading from any of the past CRM releases to new ones. We also write custom plugin solutions and are specialists with advanced web services and portals that connect to CRM for many applications. http://www.interactivewebs.com/crm and websites.
We got the ADFS login screen as expected, but on trying to login we received an error:
Activity ID: 00000000-0000-0000-0400-0080020000f4
Relying party: CRM IFD Relying Party
Associate with two errors in the ADFS Event Log.
Event ID: 111
Additional Data Exception details: System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’. Parameter name: claimType at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result) at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
Event ID: 364
Encountered error during federation passive request.
Exception details: Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’. Parameter name: claimType at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result) at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken) — End of inner exception stack trace — at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context) at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler) at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
System.ArgumentException: ID4216: The ClaimType ‘* Name’ must be of format ‘namespace’/’name’. Parameter name: claimType at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result) at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result) at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
This was caused because we initially had the Transform of Windows Account Name to Name was initially set as * Name rather than just Name. So we updated it (and the instructions above to allow people to not experience this problem.
Update the Relying Party Trusts / Edit Claim Rules / Transform Windows Account Name to Name – Change the name value form * Name to Name
Restart ADFS Service and IIS. And you should resolve these errors.
CRM 2015 and CRM 2016 IFD will Automatically Logout the user with a Message:
Your session in Microsoft Dynamics CRM is about to expire. To continue working, you must sin in again.
By Default this setting is 60 minutes, and the message will pop up around 20 minutes before logout.
Any unsaved changes will be lost as your session ends.
To extend the automatic logout time in CRM 2015, we must extend the time set in ADFS 3.0 using the PowerShell command. First we need to know the name that was used to set up the Relying Party Trust in ADFS.
1. Open Server Manager and from the Tools menu select ADFS Management
2. in AD FS management, open Relying Party Trusts and find the Display name for the CRM IFD Relying Party Trust
In this case, we have called the Relying Party Trust – “CRM IFD Relying Party” as we keep things simple when we create things. Using the exact name for the title of the trust as we created it. But really it could be anything. One distinguishing feature is that the URL identifier is going to be optioning to the URL that displays in the browser window when you are in the process of login into your IFD CRM.
3. Start PowerShell
4. Check you have the correct name of the Relying Party Trust by typing the following command.
Get-ADFSRelyingPartyTrust -Name "relying_party"
Where you replace the “relying_party” with the name you identified in Step 2 above. In our case the command will be: