Get-CrmSetting : The term ‘Get-CrmSetting’ is not recognized as the name of a cmdlet

Problem

While trying to run the OAuth provider setup in Microsoft Dynamics CRM, to configure among other things the Post-instillation setup to allow connectivity by devices and applications. I was banging my head on a problem following the instructions:

Configure the OAuth provider

 

Follow these steps to configure the OAuth provider in Microsoft Dynamics 365.

  1. Log on to the Microsoft Dynamics 365 server as an administrator.

  2. In a Windows PowerShell console window, run the following script.

     
    $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings
    $ClaimsSettings.Enabled = $true
    Set-CrmSetting -Setting $ClaimsSettings
    
    
Found on this page: https://msdn.microsoft.com/en-us/library/hh699726.aspx#BKMK_WS2012R2 
 
I was getting in the Power Shell: 
PS C:\Users\administrator.FSERVER4> $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings

Get-CrmSetting : The term ‘Get-CrmSetting’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if
a path was included, verify that the path is correct and try again.
At line:1 char:19
+ $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings
+ ~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-CrmSetting:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

Driving me nuts!

 

The Fix

Turns out from these instructions found here: https://msdn.microsoft.com/en-us/library/dn531010.aspx

That an additional step is required:

Dynamics 365 server setup

 

To configure the Dynamics 365 server to enable federated claims, follow these steps.

Configure claims settings

  1. Log on as administrator on the Dynamics 365 server that hosts the deployment service role and open a Windows PowerShell command window.

  2. Add the Dynamics 365Windows PowerShell snap-in (Microsoft.Crm.PowerShell.dll). More information: TechNet: Administer the deployment using Windows PowerShell

     
    Add-PSSnapin Microsoft.Crm.PowerShell
    
  3. Enter the following Windows PowerShell commands.

     
    $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings
    $ClaimsSettings.Enabled = $true
    Set-CrmSetting -Setting $ClaimsSettings
    
    
 Note the step 2: 

Add-PSSnapin Microsoft.Crm.PowerShell

Now it works!

Screenshot 2017 01 10 14 36 47

Microsoft CRM IFD The SSL certificate does not contain all UPN suffix values that exist in the enterprise – Cannot Login

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.

adfs2

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.

adfs3

3. Open Command Prompt. Be sure to right-click and “Run as Administrator”.
a. From within CMD, type “iisreset”.

adfs4

4. Open “Services” and restart the “ADFS” service.

adfs5

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.

adfs6

6. Run “Configure Internet Facing Deployment” wizard.
a. Click “Next” all the way through the wizard, nothing needs to be changed here either.

adfs7

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.

ZenDesk to Microsoft CRM integration password change

Changing your password in ZenDesk may affect your Microsoft CRM integration

 if you are to upgrade or change the password that you utilise in your ZenDesk system for the account that has been set to synchronise data with the Microsoft CRM platform, you will notice that the synchronisation may not function correctly or may only perform a one-way synchronisation. 

You will remember from the instructions that you likely followed in your initial configuration: http://www.interactivewebs.com/blog/index.php/zendesk/zendesk-to-crm-2015-integration/  

 that part of these configuration settings is to set up your password and username in the SETTINGS / ZD Personal Settings –  area of your Microsoft CRM system.

 Below is an extract from the vendor’s configuration portal found here

Step 2: Setting up new security roles

The Zendesk integration introduces two new security roles to Microsoft Dynamics CRM that must be assigned before you can proceed to the next step:

  • Zendesk – Read configuration settings – grants the user  access to Zendesk ticket details in read-only mode  To gain access to create/edit Zendesk tickets functionality directly from Microsoft Dynamics CRM, these users must have a valid Zendesk liecense and enter their own personal Zendesk credentials on the ZD Personal Settings page.
  • Zendesk administrator – grants access to the global Zendesk Settings page and the Zendesk Entity mappings .  Have full access to create/edit Zendesk tickets directly from Microsoft Dynamics CRM.

By default, all users can view Zendesk ticket information in Microsoft Dynamics CRM if the panels are enabled.

To enable the roles, do the following:

  1. In Microsoft Dynamics CRM, select Settings System Administration Users .
  2. In the Users page, click New if you need to add new users. 
    If you are editing a list of existing users, select the user you want to modify and click on the Manage Roles button.
  3. In the Add Users dialog box, select the role for the group you want to configure. 
    The two new roles created by the Zendesk integration are at the bottom. Click Next to select and assign the users to a particular role and to send email invitations.  Make sure you give yourself the Zendesk administrator role for now so you can complete the setup.

Users are now configured to use the Z endesk for Microsoft Dynamics CRM integration!  If you have pre-existing users, you can simply add the appropriate roles to each of your uses.

Note: For users with the Zendesk – Read configuration settings permission, they can individually add their own credentials by navigating to Settings->ZD Personal Settings in Microsoft Dynamics and clicking the New button to add credentials. Enter the Zendesk User ID andPassword then save the record and it will be applied when they access Zendesk tickets. The password will be encrypted so others cannot see the value. 
Part3-4.png

CRM 2013 IFD Setup with ADFS 3.0 on Windows 2012 R2 Hosted Setup

We already have a popular post for the configuration of IFD setup with CRM 2011, and recently we updated this blog to support CRM 2015 here: 

http://www.interactivewebs.com/blog/index.php/crm/how-to-set-up-crm-2015-ifd-on-windows-2012-and-adfs-3-0/

Many of you may find that better for setting up CRM 2013 than this blog, as the data is mostly exactly the same as this blog, but some of the order of things is better described.

Upgrading from CRM 2011 to CRM 2013 and need help? InteractiveWebs offer professional Microsoft CRM Upgrade Services and Support.

The Existing Setup

Because this is a test environment, 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 2012 R2 64 Bit – (MSDN File: en_sql_server_2012_standard_edition_with_service_pack_2_x64_dvd_4351706)
  • Microsoft CRM 2013 64 Bit – (MSDN File: en_microsoft_dynamics_crm_server_2013_sp1_x86_and_x64_4330464)

How to Install CRM 2013

We pretty much followed a combination of these instructions: http://blogs.msdn.com/b/niran_belliappa/archive/2013/11/05/step-by-step-installing-dynamics-crm-2013-on-windows-server-2012.aspx

But we needed some additional steps for the ADFS 3.0. They are mentioned below.

We then Patched the Server to latest updates, then ran SP1 for CRM 2103. http://support.microsoft.com/kb/2941390

Importantly

When we setup CRM, we selected the option to NOT use the default website, but configure a new one with the default settings of port 5555. This is necessary as you will see later.

Backup First

In all things Microsoft world, it is vital what you establish a working point to avoid unnecessarily installing things all over again. To get things working we have started fresh over 4 times.

Hyper V is great for this, as we just stopped the server, and made a copy of the VHD file. Then when it is time to start all over, it is just a matter of restoring from copy/backup.

Test First

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

We called our Deployment of CRM – “CRM2013″ So the URL redirects to: http://vserver07:5555/CRM2013/main.aspx

and after being prompted for login, we are in and testing.

Screenshot 2014 07 05 16 16 21

 

Apply a Wildcard SSL Certificate

In CRM, the accessing of deployments is handled by the sub domains. So if we call a deployment “business1″ we will access that as: https://business1.domain.com

For testing, we purchased a standard Wildcard SSL certificate that applied that to the IIS7 server.

We uses Start SSL who provide cheap as you find on the net (free) but requires you to jump through a LOT of hoops to get familiar with issuing certificates.

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…

image

4) fill in the following diagram each column, click Next

image

5) Cryptographic Service Provider Properties page change the Bit Length to 2048 click Next.

Screenshot 2014 07 05 18 50 18

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.

Screenshot 2014 07 05 18 53 05

This is the text that is pasted into the Start SSL Certificate request page to generate the certificate:

Screenshot 2014 07 05 18 55 03

8) After you finish generating the certificate text in StartSSL.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.

So that we completed the wildcard certificate request, and import of the new .CER certificate, ready for use.

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.

image

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.

image Ours is interactivewebs.com

7) Click Close.

For the CRM 2013 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).

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

 Screenshot 2014 07 05 19 22 30

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.

  1. We make the assumption that your server is running at least one static IP address.
  2. Because this is Internet Facing, that IP needs to be accessible to the world.
  3. 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

image

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:

Screenshot 2014 07 05 19 28 02

  1. sts1.domain.com
  2. auth.domain.com
  3. dev.domain.com
  4. Your ORG name.  org.domain.com (Where ORG is the CRM deployment name of your organization or organizations), e.g.
  5. internalcrm.domain.com (used later for internal definition of the CRM server access).
  6. adfs.domain.com (used for reference to the ADFS server)
  7. one for the root domain so that domain.com points to the same server. (This is for the ADFS logout URL)

Screenshot 2014 07 10 18 04 02

We have two setup here: CRM and CRM2013. So we need to configure crm.iwebscrm.com and crm2013.iwebscrm.com.

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.

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.

image

Note: Don’t bother proceeding past this step if you cannot ping your sub domains internally and externally correctly.

Firewall configuration

You need to set the firewall to allow the CRM 2013 and the AD FS 2.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) Control Panel

2) Search Firewall

3) Check Firewall Status

4) Turn Off or On Firewall

Screenshot 2014 07 05 19 33 53

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.

Configuration Claim-based authentication internal access

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

  • Install and configure AD FS 3.0
  • Set Claims-based authentication configuration CRM 2013 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

CRM 2013 with a variety of STS provider ( STS Provider ) together. This article uses Active Directory Federation Services (AD FS) 3.0 to provide a security token service (security token service ).

Note: AD FS 2.0 will be installed to the default site, so install AD FS 3.0 , you must have CRM 2013 installation in the new site. (Remember we said that earlier)

IIS Looks like this if it is correctly installed: image

If you only see the default website with CRM installed in that. Start AGAIN!

Install ADFS Server Role

From Server Manager – Add A Server role for: Active Directory Federation Services

Screenshot 2014 07 05 19 39 54

After if Finishes:

Screenshot 2014 07 05 19 41 52

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.

Screenshot 2014 07 05 19 43 52

4 Select next to continue with the current administrator (must be a domain admin).

Screenshot 2014 07 10 16 34 34

5 Choose your SSL certificate (the choice of a certificate created *.domain.com ) ,add a Federation Service name ( for example , sts1.contoso.com), and Select a Service Display Name for your business – selecting the one that is NOT starting with a *, then click Next.

Screenshot 2014 07 10 16 36 32

6 Open PowerShell and run the following command: “Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)”

 Screenshot 2014 07 10 16 40 55

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 Create a database on this server using Windows Internal Database, click Next.

Screenshot 2014 07 10 16 43 30

Or use the local SQL instance etc if you have one.

Screenshot 2014 07 31 22 00 47

8 Review Options click Next

Screenshot 2014 07 10 16 44 45

9 Pre-requisits checklist, click Configure

Screenshot 2014 07 10 16 45 44

10 You should see a message that “This Server was successfully configured

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.

2 Enter the federation metadata of the URL , for example:

https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

(Where sts1.contoso.com represents the DNS A record we setup earlier.  sts1.yourdomainname.com)

3. to ensure that no certificate associated with the warning appears, and you can view the certificate to be sure it is showing.

Screenshot 2014 07 31 18 22 17Screenshot 2014 07 31 18 23 18

Claims-based authentication configuration CRM 2013 server

After you install and configure the AD FS 3.0 , we need to configure the Claims-based authentication before setting CRM 2013 binding types ( Binding type ) and the root domain (root Domains) .

Following these steps to set up CRM 2013 bound for the HTTPS and configure the root domain address :

1 Open the CRM Deployment Manager.

2 In the Actions pane , click Properties .

Screenshot 2014 07 10 17 07 03

3 Click the Web Address page.

4 In the Binding Type , select HTTPS .

Screenshot 2014 07 10 17 09 07

5. You can most likely select Apply at this point, and the default internal address for the CRM will work fine. We however 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, *. contoso.com wildcard certificate, you can useinternalcrm.contoso.com:444 as the network address.

Screenshot 2016 01 10 22 03 10

7 Click OK.

8 In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Claims-Based Authentication.

Screenshot 2014 07 10 17 59 37

9 Click Next on the Welcome page

10  On the Specify the security token service page, enter the Federation metadata URL, such as https://adfs.fabrikam.com/federationmetadata/2007-06/federationmetadata.xml. In our case because we setup a DNS record for “adfs” we are going to use that: https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

Screenshot 2014 07 10 18 08 28

11 Click Next then select the certificate that we created perviously for the *.domain connection

Screenshot 2014 07 10 18 07 28

12 Select Next 

Screenshot 2014 07 10 18 09 58

13 Select Apply then Finish

Screenshot 2014 07 10 18 10 31

Screenshot 2014 07 10 18 11 45

14 IMPORTANT – Click View Log File

15 Scroll to the end, and Copy the URL from the bottom of the file.

image– 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://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

16 Click Finish.

17 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 2013server.

18. Once you can browse this URL, you are done here.

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

Configure claims provider trusts

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.

Screenshot 2014 07 10 18 27 02

 

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

Screenshot 2014 07 10 18 27 33

 

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

Screenshot 2014 07 10 18 34 58

Click Finish, and then click OK to close the Rules Editor

After you enable claims-based authentication, you must configure Dynamics CRM Server 2013 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. So that will be https://internalcrm.domain.com/FederationMetadata/2007-06/FederationMetadata.xml. This is the same internalcrm A recored that we checked earlier in the process.

Screenshot 2014 07 10 18 38 23

On the Specify Display Name page, type a display name, such as CRM Claims Relying Party, and then click Next.

Screenshot 2014 07 10 18 40 57

Click Next on the multi-factor authentication options.

Screenshot 2014 07 10 18 41 35

On the Choose Issuance Authorisation Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

Screenshot 2014 07 10 18 41 44

On the Ready to Add Trust page, click the checkbox option to Open the Edit Claim Rules, Next, and then click Close.

Screenshot 2014 07 10 18 42 10

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.

Screenshot 2014 07 10 18 42 52

In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.

Screenshot 2014 07 10 18 44 21

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.

Screenshot 2014 07 10 18 44 59

Screenshot 2014 07 10 18 50 07

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

Screenshot 2014 07 10 18 50 26

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

Screenshot 2014 07 10 18 51 11

Screenshot 2014 07 10 18 51 23

In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.

Screenshot 2014 07 10 18 51 59

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

Screenshot 2014 07 10 18 53 05

Click Finish, and when you have created all three rules, click OK to close the Rules Editor.

Screenshot 2014 07 10 18 53 20

So now we have claims setup for CRM.

ADFS 3.0 Extra Steps

To say these steps are “fucking important” is to under estimate the value I place in the 2 weeks it took me to resolve the ADFS 3.0.

Enable Forms Authentication

AD FS in Windows Server 2012 R2, forms authentication is not enabled by default.

1. Log on to the AD FS server as an administrator.

2. Open the AD FS management console and click Authentication Policies.

3. Under Primary Authentication, Global Settings, Authentication Methods, click Edit.

4. Under Intranet, enable (check) Forms Authentication.

Screenshot 2014 08 02 18 06 40

 

Add the ADFS server to the Local intranet zone.

1. In Internet Explorer, click Tools, and then click Internet Options.

2. Click the Security tab, click the Local intranet zone, and then click Sites.

3. Click Advanced.

4. In Add this website to the zone, type the URL for your AD FS server, for example, https://sts1.contoso.com.

5. Click Add, click Close, and then click OK. 

6. Select the Advanced tab. Scroll down and verify that under Security Enable Integrated Windows Authentication is checked.

7. 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. To use Group Policy to push this setting to all domain-joined internal client computers do the following.

 

Test claims-based authentication within the access

You should now be able to use the claims certified to the internal access CRM 2013

1 Open the Deployment Manager.

2 Expand the Deployment Manager node , and then click onOrganizations .

3 Right-click your organization , and then click Browse . so you can open the CRM web page of ( for example:https://internalcrm.contoso.com:444 ).

image

Screenshot 2014 08 02 18 10 57

Trouble Shooting

If the CRM web page can not be displayed, then run the following iisreset and then try again.

image

If the CRM web page still does not show, then you may need to setup AD FS 3.0 server setup a SPN (Service Principal Name) . Re-run the Claims-Based Authentication Wizard, and then browse to the Specify the security token service page, note the AD FS 3.0 server in the Federation metadata URL in the name. (In this case sts1.interactivewebs.com )

http://blogs.msdn.com/b/crm/archive/2009/08/06/configuring-service-principal-names.aspx

image

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 )

c: \> setspn -a http/sts1.interactivewebs.com fserver4\VSERVER08$

fserver4\VSERVER08 = the domain and machine name of the server.

image

c: \> iisreset

3 and then re-access the Microsoft Dynamics CRM Server 2013 site, so you should be able to successfully access to the CRM 2013 Web page.

http://technet.microsoft.com/en-us/library/gg188614.aspx

If you receive ADFS – sts1 errors.

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. Reference number: xxx

And or if you look in your log files under ADFS 2.0 You will see errors like this.

image

In our case, this was because we used the external Metadata URL and not the Internal URL that we should have copied from the “View Log File” When configuring the Claims Based Authentication. Step 14 in the section above.

image

image

Note the difference between this:

https://internalcrm.interactivewebs15.com:444/FederationMetadata/2007-06/FederationMetadata.xml

and the original meta data check we did with:

https://sts1.interactivewebs15.com/federationmetadata/2007-06/federationmetadata.xml

We incorrectly figured it would be pulling the same XML data. It does NOT!

Configuration Claim-based authentication external access

Open to the CRM 2013 Data Claims-based authentication of external access, you need to do the following steps:

1 complete contents of the previous section: Configuring Claim-based authentication- internal access.

2 for the IFD configuration CRM 2013 server.

3 for the IFD configuration AD FS 3.0 server.

4 Test claims-based authentication external access.

The IFD configuration CRM 2013 server

When opening Claims certified internal access, you can open by IFD external claims visited. The following describes using the IFDConfiguration Wizard to configure, if you want to learn how to use PowerShell to be configured, refer to the English original.

1 Open the Deployment Manager.

2 In the tree structure , right-click Microsoft Dynamics CRM , and then click Configure Internet-Facing Deployment.

Screenshot 2014 08 02 18 14 52

3 Click Next.

Screenshot 2014 08 02 18 15 20

4 Fill in the correct domain information for the Web Application, Org, and Discovery Web services. Remembering here that in our case: *.interactivewebs.com was the name of the wildcard certificate used, and that PORT 444 was the port we configured for the CRM Web Instance in the bindings for IIS.

Thus we use:

  • Web Application Server Domain: interactivewebs.com:444
  • Organization Web Service Domain: interactivewebs.com:444
  • Web Service Discovery Domain: dev.interactivewebs.com:444

Note – Enter the domain name, rather than the server name .

  • If the CRM installed on the same server or servers are installed in the same domain, then the Web Application Server Domain and Organization Web Service Domain should be the same .
  • Web Service Discovery Domain must be a Web Application Server Domain as a subdomain like the  “dev.” that we setup in DNS earlier.
  • domain name must be on the SSL certificate name

Domain examples :

  • Web Application Server Domain: contoso.com: 444
  • Organization Web Service Domain: contoso.com: 444
  • Web Service Discovery Domain: dev.contoso.com: 444

Screenshot 2014 08 02 18 16 57

For more information on the website, please refer to Install Microsoft Dynamics CRM Server 2013 on multiple computers(http://go.microsoft.com/fwlink/?LinkID=199532 )

5 In the Enter the external domain where your Internet-facing servers are located input box , enter for your internet to CRM 2013 server located outside the domain of information, and then click Next.

Screenshot 2014 08 02 18 18 00

You must specify the domain specified in the previous step Web Application Server Domain sub-domains . default , will be “auth.” added to the Web Application Server Domain before.

Domain examples :

  • External Domain: auth.contoso.com: 444

6 In the System Checks page , if there is no problem, click Next.

Screenshot 2014 08 02 18 18 43

7 In Review your selections and then click Apply page , confirm your input , and then click Apply.

Screenshot 2014 08 02 18 19 12

8 Click Finish .

Screenshot 2014 08 02 18 19 37

9. Open a command line tool, run: iisreset

The IFD configuration AD FS 3.0 server

After you have enabled IFD on the Microsoft Dynamics CRM Server 2013 you will need to create a relying party for the IFD endpoint on the AD FS server. (Steps below are from the MSDN Blog.

Step6: 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.

image

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

Type this URL in your browser and verify that no certificate-related warnings appear.

image

Step8: On the Specify Display Name page, type a display name, such as CRM IFD Relying Party, and then click Next

image

Step9: On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

image

Step10: On the Ready to Add Trust page, click Next, and then click Close.

image

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

image

Step12: In the Claim rule template list, select the Pass Through or Filter an Incoming Claimtemplate, and then click Next.

image

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

image

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

image

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

image

Step16: In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.

image

Step17: 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  (Note that “* Name”  without the “” is required to be typed)

Pass through all claim values

Click Finish, and when you have created all three rules, click OK to close the Rules Editor.

image

Test claims-based authentication to access external

Now, you should use the claims certified external access CRM 2013 a. In IE the browser CRM 2013 external address (for example: https://org.contoso.com:444 ), you will see the following pages:

Screenshot 2014 08 02 18 24 18

Enter the user name password, log CRM 2013.

Screenshot 2014 08 29 01 02 28

Fix the MEX Endpoint

When you browse externally to the URL: https://sts1.iwebscrm.com/adfs/services/trust/mex

Where “sts1.yourorg.com” replaces ours… you should see an XML endpoint return. We found that after setup of CRM 2013 in the above mentioned environment there was a conflict with the Sandbox port 808 and this caused the failure of the service, giving a 503 error for /adfs/services/trust/mex

The solution is simple: Run the following command in PowerShell

Set-ADFSProperties –nettcpport 809

Then restart ADFS from the Services, or restart the server. Reference: http://www.interactivewebs.com/blog/index.php/crm-2013/adfsservicestrustmex-returns-503-on-crm-2013-windows-2012-ifd-mex-endpoint-fix/

 

Microsoft CRM Restore Database Failed Only Enterprise edition of SQL Server supports partitioning

Upgrading from CRM 2011 to CRM 2013 you cannot restore SQL on a Non Enterprise Server

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)Database ‘Org_MSCRM’ cannot be started in this edition of SQL Server because it contains a partition function ‘AuditPFN’. Only Enterprise edition of SQL Server supports partitioning. Database ‘Org_MSCRM’ cannot be started because some of the database functionality is not available in the current edition of SQL Server. (Microsoft SQL Server, Error: 905)

CAUSE

When Microsoft Dynamics CRM 2011 is installed using a Microsoft SQL Server Enterprise edition, a partition is created for the auditing functionality of Dynamics CRM 2011. The AuditBase table uses partitioning which is only available for Microsoft SQL Server Enterprise.RESOLUTIONUse the following Steps and Script to remove the partitioning. The following script recreates all the indexes on the Primary partition and then drops the partition.
Be sure to have a database backup of the ‘Org_MSCRM’ before performing the following steps. 

Fix

1. Restore the ‘Org_MSCRM’ database to a Microsoft SQL Server Enterprise edition. It is recommended to backup and restore the database instead of running the script on the production database.

2. Run the following script against the restored database.

 

IF EXISTS (SELECT name FROM sys.partition_schemes WHERE name='AuditPScheme') BEGIN SELECT CASE WHEN ind.type != 1 THEN 'DROP INDEX [dbo].[AuditBase].' + QUOTENAME(ind.name) + ' ' ELSE ' ' END + 'CREATE ' + CASE is_unique WHEN 1 THEN 'UNIQUE ' ELSE '' END + ind.type_desc + ' INDEX ' + QUOTENAME(ind.name COLLATE SQL_Latin1_General_CP1_CI_AS ) + ' ON [dbo].' + QUOTENAME(OBJECT_NAME(object_id)) + ' (' + REVERSE(SUBSTRING(REVERSE(( SELECT name + CASE WHEN sc.is_descending_key = 1 THEN ' DESC' ELSE ' ASC' END + ',' FROM sys.index_columns sc JOIN sys.columns c ON sc.object_id = c.object_id AND sc.column_id = c.column_id WHERE OBJECT_NAME(sc.object_id) = 'AuditBase' AND sc.object_id = ind.object_id AND sc.index_id = ind.index_id ORDER BY index_column_id ASC FOR XML PATH('') )), 2, 8000)) + ')' + CASE WHEN ind.type = 1 THEN ' WITH (DROP_EXISTING = ON) ON [PRIMARY]' ELSE ' ' END as Script INTO #indexesScript FROM sys.indexes ind JOIN sys.partition_schemes ps on ind.data_space_id=ps.data_space_id WHERE OBJECT_NAME(object_id) = 'AuditBase' AND ps.name = 'AuditPScheme' AND is_unique_constraint = 0 SELECT * FROM #indexesScript DECLARE @recreateScript nvarchar(max) DECLARE indScript CURSOR FOR SELECT Script FROM #indexesScript OPEN indScript FETCH NEXT FROM indScript INTO @recreateScript WHILE @@FETCH_STATUS = 0 BEGIN BEGIN TRANSACTION t1 Execute sp_executesql @recreateScript IF @@ERROR > 0 BEGIN ROLLBACK TRAN t1 declare @message varchar(max) set @message = 'Audit history recreate index failed. SQL: ' + @recreateScript RAISERROR (@message, 10,1) END ELSE BEGIN COMMIT TRAN END FETCH NEXT FROM indScript INTO @recreateScript END DROP PARTITION SCHEME AuditPScheme DROP PARTITION FUNCTION AuditPFN CLOSE indScript DEALLOCATE indScript DROP TABLE #indexesScript END

 

3. Once the script is complete you can backup the database and now you should be able to restore the database to a Microsoft SQL Server Standard edition.

Update ADFS SSL Certificates Microsoft CRM 2013 2015 and 2016 IFD

How to Update SSL Certificates for AD FS 3.0 in CRM IFD

Introduction

Microsoft Dynamics CRM can be configured to use SSL (Secure Sockets Layer). For this to work, an SSL certificate is required.

Certificates can be purchased from certificate providers and will expire after a certain period of time. Once this time has elapsed, Microsoft Dynamics CRM will no longer work until the certificate is updated.

This article describes the process to update the certificate for Microsoft Dynamics CRM

Installing the new certificate

You will need to import your certificate into the local certificate store on each CRM server that uses web services, and the AD FS server if claims-based authentication is enabled.

CertificateStore

Instructions on how to import a certificate can be obtained from your certificate provider.

Note: Problems may occur if you do not remove the old certificate.

Add permission to the certificate

It is necessary to grant specific permissions to the certificate to allow service accounts access.

Manage Private Keys

The following steps show how to add permissions to the certificate.

  1. Open the Certificate Console on the server.
  2. Check out the Microsoft Wiki for help
  3. Navigate to (Local Computer) > Personal > Certificates
  4. Right click the new certificate. Go to All Tasks > Manage Private Keys
  5. Add following permissions
    • AD FS Server: CRMAppPool Account = “Read”
    • AD FS Server: ADFSAppPool Account = “Full”
    • CRM Server: CRMAppPool Account = “Read”
    • In our case we were using the NETWORK SERVICE account and need to add the Read permissions
       Screenshot 2016 07 07 23 39 44

Update IIS (Internet Information Services) to use the new certificate

On the Microsoft Dynamics CRM website, the certificate bindings will need to be updated.

IIS Select Certificate

The following steps show how to bind the new certificate using IIS 8.

  1. Log on to the Microsoft Dynamics CRM Server.
  2. Open IIS.
  3. Locate the Microsoft Dynamics CRM website.
  4. Right click the website and click Edit Bindings.
  5. Select HTTPS and click Edit….
  6. Select the new certificate and click OK to save the settings.
  7. Close all open windows.

Reconfigure Claims-Based Authentication

The Microsoft Dynamics CRM application will need to be updated to use the new certificate.

Claims Setting

The following steps show how to reconfigure claims-based authentication.

  1. Open Deployment Manager
  2. Click Configure Claims-Based Authentication to open the wizard
  3. Click Next on the Welcome page
  4. Click Next on the Token Service page
  5. Select the new certificate on the Select Certificate page
  6. Click Next to complete the configuration

Update AD FS (Active Directory Federation Services)

In AD FS, the Service Communication certificate will need to be updated.

ADFS Certificate

The following steps show how to update the Service Communication certificate in AD FS 2.0.

  1. Open AD FS 2.0
  2. Navigate to AD FS 2.0 > Service > Certificates
  3. Click Set Service Communications Certificate
  4. Select the certificate and click OK

Update Relying Party Trusts

The Relying Party Trusts in the AD FS Management needs to be checked that the Relying Party Trusts are not showing an ! next to the listed Claims Relying Party Trust and the IFD Relying Party.

If they are, or even just to be safe. Click on each separately and the “Update from Federation Meta Data”

Screenshot 2016 07 07 23 43 26

Once these have both been updated you can move onto the last task.

Final Tasks

To finish the process, all affected services will need to be restarted.

IISRESET

The following steps should be completed once the certificate has been updated.  It may also be necessary to follow these steps if problems occur during any of the previous tasks.

  • Perform an IISRESET on each server
  • Restart the AD FS service on AD FS server
  • Update Relying Party metadata
    1. Open AD FS 2.0
    2. Navigate to AD FS 2.0 > Trust Relationships > Relying Party Trusts
    3. Right click each relying party and select Update from Federation Metadata
    4. Click Update

Microsoft CRM 2013 or 2015 Event ID 1309 ADFS IFD Resolution

When attempting to login to an IFD deployment of CRM 2013 or 2015 you receive an event Error: 1309 looking like this:

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 7/01/2016 12:08:14 AM
Event time (UTC): 6/01/2016 1:08:14 PM
Event ID: 0daeff15a8f24e939623db80c40522d5
Event sequence: 3
Event occurrence: 2
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/2/ROOT-1-130965592186041416
Trust level: Full
Application Virtual Path: /
Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\
Machine name: VSERVER07

Process information:
Process ID: 2300
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: SecurityTokenException
Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Request information:
Request URL: https://auth.iwebscrm.com:444/default.aspx
Request path: /default.aspx
User host address: 58.175.75.97
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 29
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: True
Stack trace: at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

UPDATE

On later version of CRM like CRM 2016 SP1 and using ADFS 3. This error appeared differently. We blogged this here: http://www.interactivewebs.com/blog/index.php/crm/microsoft-crm-ifd-the-ssl-certificate-does-not-contain-all-upn-suffix-values-that-exist-in-the-enterprise-cannot-login/

The cause

This is likely happening after updating the ADFS Token Signing Certificates in an IFD deployment of Microsoft CRM Server. In our case we had recently updated the ADFS signing certificate using the PowerShell command:

Update-AdfsCertificate -CertificateType Token-Decrypting -Urgent
Update-AdfsCertificate -CertificateType Token-Signing -UrgentSet-ADFSProperties -AutoCertificateRollover $false 

After doing that we found that the IFD deployment would not allow login to the CRM server for external users, with the above error being logged.

The Fix

Microsoft Dynamics CRM error: The issuer of the security token was not recognized by the IssuerNameRegistry – Solved

“The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.”
Or…

adfs1

If your Microsoft Dynamics CRM users are seeing the above errors when attempting to log-in, you may have an ADFS Certificate issue. ADFS generates new certificates about a month prior to certificate expiration, however, Dynamics CRM does not recognize them until you take a few steps to resolve the issue.

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

adfs2

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.

adfs3

3. Open Command Prompt. Be sure to right-click and “Run as Administrator”.
a. From within CMD, type “iisreset”.

adfs4

4. Open “Services” and restart the “ADFS” service.

adfs5

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.

adfs6

6. Run “Configure Internet Facing Deployment” wizard.
a. Click “Next” all the way through the wizard, nothing needs to be changed here either.

adfs7

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.

Microsoft CRM Solution Import Fields that are not valid were specified for the entity

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

Ugly XML Dump file from CRM.png

To

CRM xml dump file in DreamWeaver.png

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:

Screenshot 2015 04 29 21 52 24

<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 Extend Auto Logout Time in IFD

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.

CRM 2015 Auto Logout

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

ADFS Management

2. in AD FS management, open Relying Party Trusts and find the Display name for the CRM IFD Relying Party Trust

Screenshot 2015 04 03 17 30 58

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

Screenshot 2015 04 03 17 35 57

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.

Screenshot 2015 04 03 17 40 02

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

Set-ADFSRelyingPartyTrust -Targetname “CRM IFD Relying Party“ -TokenLifetime 720

(Again replacing the “CRM IFD Relying Party” with the name used on your system.)

Note: The 720 is time in minutes. 12 Hours in this case. You can change the value up and down as liked.

Set-ADFSRelyingPartyTrust -Targetname “CRM IFD Relying Party“ -TokenLifetime 720

Screenshot 2015 04 03 17 43 47

6. Close out the PowerShell and you are done.

CRM 2013 Improve Outlook Client Performance Issue WFC Compression

CRM 2013 Outlook Performance

After installing the Microsoft CRM 2013  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 2013 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.

Screenshot 2015 03 20 23 03 14

Screenshot 2015 03 20 23 03 29

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” /> 

Screenshot 2015 03 20 23 04 15

3.  Below that, add the following line:  
<add mimeType=”application/soap+xml; charset=utf-8″ enabled=”true” /> 

Screenshot 2015 03 20 23 04 40

4. Save the file and reset IIS for the setting to take effect.

Screenshot 2015 03 20 23 04 53