Tag: CRM 2015

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.

The Problem

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.

The Fix

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.

When upgrading from CRM 2013 to CRM 2015 you get an error: Microsoft.Crm.CrmException: Database having version 7.0.1.129 is not supported for upgraded.

Cause:

This is usually because there is already a database that exists with the same ID. You will need to delete that Organisation in CRM deployment manager before upgrading the new organisation from the same name.

While importing a solution to CRM 2011, CRM 2013, or CRM 2015 you receive an error

Fields that are not valid were specified for the entity

The Cause

The cause of this is likely that one of the attributes that you are importing (from a dev environment) already exists in the CRM instance, but with a different attribute.

For Example:

In your Live Environment

Within Accounts, you create a new attribute called “Friendly Cusomter” and mark it TEXT

Publish and all is well and good.

In you Dev Environment

Within Accounts, you create a new attribute called “Friendly Customer” and make it a PICK LIST

in other words, the same name for the attribute, but a different kind of field.

Then try to export from DEV and import to LIVE. You get the error.

The solution

You have to remove the conflicting fields from the destination (live in the example above) CRM system.

Microsoft gives you some help here, in the form of an XML dump file. What you need to do is open that file in something like DreamWeaver that has the ability to apply “Source Formatting”. This makes the file pretty to read.

From

To

Then do a search for the text “errortext” and start clicking next / next till you get to some text with an attribute and an error message.

In our case:

<Cell ss:StyleID=”s137″ name=”ErrorText”> <Data ss:Type=”String”>Attribute new_leasecustomer is a Picklist, but a Boolean type was specified.</Data> </Cell>

This gives the name of the attribute at fault.

<Cell ss:StyleID=”s137″ name=”ErrorText”> <Data ss:Type=”String”>Attribute new_leasecustomer is a Picklist, but a Boolean type was specified.</Data> </Cell>

And the error on the import will tell you the Entity that it failed the import on. Again in this case it was the ACCOUNT entity.

So we just removed that attribute from any forms and views, then deleted the attribute (be sure that your live data is not relying on data entered here by users as you will loose it). Publish the entity. Then test the import again.

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.

The Fix

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:

Get-ADFSRelyingPartyTrust -Name “CRM IFD Relying Party“

The result should look something like this if you get it correct.

5. Not type the command to set the time you want to set for Auto Logout.

When attempting to login to a newly configured Organisation you may receive an error looking like this.

An error occurred

An error occurred. Contact your administrator for more information.

Activity ID: 00000000-0000-0000-1400-0080010000ff

Error time: Sat, 28 Mar 2015 07:37:45 GMT

The Cause

Because IFD (Internet Facing Deployment) uses the AD FS Authentication it requires an additional step after using the CRM Deployment Manager to setup a new Organisation to then register at login with the AD FS setup.

Basically it is saying that you have set up the org, but not gin figured the authentication login settings in AD FS.

Error Message installing CRM 2015 Reporting Extensions

When installing Microsoft Dynamics CRM Reporting Extension Setup you receive an error message: The SQL Server Reporting Services account is a local user and is not supported. This is during the System Checks.

In our instance this was with MS CRM 2015 on SQL 2014 on the same server in a test environment.

The Solution

The fix is easy.

1. Open the SQL 2014 Reporting service configuration Manager

2. Connect to your Server.

3. Select the Service Account

4. Select the Local System account and apply with the appropriate security levels.

That’s about it. Run the setup process again and you should be good to go.

CRM 2015 Outlook Performance

After installing the Microsoft CRM 2015 and client, you may notice that the connection over the internet is slow and not as desired. One likely reason for this is that WCF communication is not compressed, and the outlook client is using that to talk to the CRM server.

Assuming that your current environment is configured correctly with Windows 2012 R2 and IFD, then you can simply update the server to support WCF compression and improve performance for CRM 2015 and outlook.

Enable compression by manually updating the ApplicationHost.Config

1. On the CRM Server Navigate to: C:\Windows\System32\Inetsrv\Config\applicationHost.config and open it with notepad.

2. Search for the Section: “<dynamicTypes>” and in that section you should fine an entry that looks like this: <add mimeType=”application/x-javascript” enabled=”true” />

We already have a popular post for the configuration of IFD setup with CRM 2013 and CRM 2011. Now we are updating this post to support CRM 2015.

Microsoft have a compatibility listing for CRM 2015 here: http://support.microsoft.com/kb/3018360

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:

Installing CRM 2015

During the install, we were asked to install services associated with the services required for CRM 2015.

We Selected all options on install:

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.

IMPORTANT

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:

We set “CRM2015” 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 First

Test that your CRM setup is working. Go to the local computer name (ours is vserver06) on the correct port: http://vserver06:5555

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 2015 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.

DNS configuration

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: 66.34.204.220

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.

crm2015.iwebscrm15.com (We usually set up a dev environment with CRM2015 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 CRM2015. So we need to configure crm.iwebscrm15.com and crm2015.iwebscrm15.com (Not necessary but our choice for this instance).

Test DNS

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.

Firewall configuration

You need to set the firewall to allow the CRM 2015 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.

Configuration Claim-based authentication –internal access

Configure the internal access Claim-based authentication requires the following steps:

Configure AD FS 3.0

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 (we suggest using the 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.

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: *.iwebscrm15.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.

https://adfs.iwebscrm15.com/federationmetadata/2007-06/federationmetadata.xml (Replace your domain name in place of ours)

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.

Claims-based authentication configuration CRM 2015 server

After you install and configure the AD FS 3.0 , we need to configure the Claims-based authentication before setting CRM 2015 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. You can most likely select Apply at this point, and the default internal address for the CRM will work fine. We however we had you created a new A record in the DNS for “internalcrm” and pointed it to this new server. This allows us to user a clear path for the internal URL.

6 For example, internalcrm.iwebscrm15.com:444 for our install. (you can use your own domain internalcrm.domain.com:444)Note: We use the :444 as this is the HTTPS binding that we applied to the Microsoft Dynamics CRM Website in IIS

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.iwebscrm15.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 NextNote: 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.iwebscrm15.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

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 2015 server.

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.

Claims-based authentication configuration AD FS 3.0 server

After completion of the previous step, the next step we need AD FS 3.0 to add and configure the statement provider trust ( claims Provider trusts ) and the relying party trust ( Relying Party trusts ).

After you enable claims-based authentication, you must configure Dynamics CRM Server 2015 as a relying party to consume claims from AD FS 3.0 for authenticating internal claims access.

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.

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.iwebscrm15.com:444/FederationMetadata/2007-06/FederationMetadata.xml

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.

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.iwebscrm.com:444/FederationMetadata/2007-06/FederationMetadata.xml (Remember to replay 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.

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

Click Finish

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

Click Finish

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.

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.

Test External Access to CRM 2015 with IFD

Now, you should use the claims certified external access CRM 2015 a. In IE the browser CRM 2015 external address (for example: https://crm2015.iwebscrm15.com:444/main.aspx ), you will see the following pages:

Enter the user name password in the format “domain\username” and pass. You should get in fine.

This should be done routinely as it will only pop it’s head up at a later date.

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 2015 Developer Services, we offer professional services and support for CRM 2015. 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