Fields that are not valid were specified for the entity
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.
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.
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.
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.
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.
When running a workflow / process in Microsoft CRM, you receive a message that looks like this:
The e-mail address for one or more recipients is either blank or not a valid e-mail address
This error message is a little misleading as it points to an email address problem. As the title of the error suggests, the problem could be from:
1. A blank email address.
2. An email address with an error, such as a “.” at the end of it: email@example.com.
3. The more likely one is that the contact or account record associated with the flow has a setting to
E-mail Do Not Allow.
This setting will prevent any workflows in CRM from running and sending email messages.
The fix is easy… just change the setting back to allow. Then save the associated record.
You then need to restart the stalled process or workflow.
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
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:
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
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.
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 that your CRM setup is working. Go to the local computer name (ours is vserver06) on the correct port: http://vserver06:5555
We called our Deployment of CRM – “CRM2015″ So the URL redirects to: http://vserver06:5555/CRM2015/main.aspx
Because we were were logged in as the server administrator, we were able to load
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 IIS Server
In our case we registered a test domain: iwebscrm15.com and set the SSL wildcard to: *.iwebscrm15.com and applied that cert to the server.
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 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 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.
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.
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.
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.
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: 220.127.116.11
That is Your IP Address of the Server.
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:
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).
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 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.
Configure the internal access Claim-based authentication requires the following steps:
CRM 2015 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 2015 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!
If you have it all correct at this point. Probably a good time to take a SnapShot (backup of the virtually system) and label it something you remember.
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.
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 (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
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.
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
7 Click OK.
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.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.
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 ).
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 DirectoryLDAP Attribute: User Principal NameOutgoing 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 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.
Create the following Rule #1Claim rule name: Pass Through UPN (or something descriptive)Incoming claim type: UPNPass 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 SIDPass 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 nameOutgoing claim type: * NamePass through all claim values
Click Finish, and when you have created all three rules, click OK to close the Rules Editor.
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, *.iwebscrm15.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. 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.
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.iwebscrm15.com fserver4\VSERVER06
fserver4\VSERVER08 = the domain / machine name of the server.
c: \> iisreset
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:
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
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.
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
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
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.
We found after following these instructions, that we could not write services that connected via the endpoint https://your.crm.dom:444/adfs/services/trust/mex. This is due to the CRM Sandbox service using port 808. The solution we applied what one that we wrote for CRM 2013, but is applicable here for CRM 2015: https://www.interactivewebs.com/blog/index.php/crm-2013/adfsservicestrustmex-returns-503-on-crm-2013-windows-2012-ifd-mex-endpoint-fix/
This should be done routinely as it will only pop it’s head up at a later date.
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!
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
Microsoft Dynamics CRM 2013 uses standard SQL Server cell level encryption for a set of default entity attributes that contain sensitive information, such as user names and email passwords for Server-Side Sync and authentication tokens for Yammer integration capabilities. This feature can help organizations meet FIPS 140-2 compliance by ensuring that the data is encrypted “at rest” so that local database admins cannot read the data in the database tables directly. For Microsoft Dynamics CRM Online, all new and upgraded organizations use data encryption. For on-premise versions of Microsoft Dynamics CRM 2013, users who have the system administrator security role (and in the PrivUserGroup) can activate data encryption or change the encryption key after data encryption is enabled in the Settings > Data Management > Data Encryption area. After you activate data encryption, you cannot turn it off. NB: For on-premises versions of Microsoft Dynamics CRM:
Copy your organization data encryption key. It is strongly recommend that you make a copy of your data encryption key. This is particularly important for on-premise deployments that may need to reactivate data encryption after a redeployment or failure recovery.
However, if the Microsoft Dynamics CRM website is not configured for HTTPS/SSL, the Data Encryption dialog box will not be displayed. Instead, you’ll get the error noted at the right. For a more secure deployment, we recommend that you configure the website for HTTPS/SSL. As a work-around, it is possible to get at the CRM 2013 Data Encryption settings even if the website is not configured for HTTP/SSL. To do so, use a tool that can be used to modify CRM database tables, such as Microsoft SQL Server Management Studio and open the configuration database (MSCRM_CONFIG); in the DeploymentProperties table, set DisableSSLCheckForEncryption to 1. In order to set the property use the following SELECT and UPDATE statements:
<span style="color: #000000;">SELECT [ColumnName],[BitColumn]
After performing an IISReset on the CRM Server, you’ll be able to see the encryption screen. Paste the encryption key in to a text editor, such as Notepad. As a best practice, save the text file that contains the encryption key on a computer in a secure location on an encrypted hard drive. Also note that if you keep the default encryption key with all the special hieroglyphic characters, you’ll need to save the file with Unicode encoding — see screenshot below. Also, note, there is one data encryption key per organization.
Testing our system, I backed-up our test Adventure Works CRM organization database, and restored it as AdvWrks2. I imported (re-deployed) the AdvWrks2 database to create a new CRM org. I browsed to Settings => Admin => Users, and selected my User. I changed the Primary E-mail address and hit save. Here’s where I got a “Data Encryption error — There are encrypted fields in the organization database, but the data encryption feature isn’t activated.” What this means is that the org that I originally backed-up had encryption enabled, and we copied and re-deployed that org to the new org — which is now requiring data encryption be activated with the Encryption Key from the original org. I went ahead and activated using the Encryption Key that I had previously saved, and got the good news that the Encryption Key was activated successfully.
So we’ve seen CRM 2013 Data Encryption be activated automatically, by simply installing CRM, as noted in the highlighted paragraph at the top of this post. We also know that Data Encryption will be enabled on all CRM Online deployments.
We’ve further seen that when an encrypted CRM database is restored and redeployed it requires that data encryption be activated with the appropriate encryption key. If you ever think you may want to restore your CRM organization database for disaster recovery or redeploy your CRM system for testing or operational reasons, you simply must save off the encryption key of your existing CRM system.
“Database cannot be started in this edition of SQL Server” error when restoring a Microsoft Dynamics CRM database.
This error only happens when the original SQL instance was running an enterprise version and the destination server is not.
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.
Use 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. 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')
CASE WHEN ind.type != 1
'DROP INDEX [dbo].[AuditBase].' + QUOTENAME(ind.name) + ' '
ELSE ' '
'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)) + ' (' +
SELECT name + CASE WHEN sc.is_descending_key = 1 THEN ' DESC' ELSE ' ASC' END + ','
JOIN sys.columns c ON sc.object_id = c.object_id AND sc.column_id = c.column_id
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
' WITH (DROP_EXISTING = ON) ON [PRIMARY]'
END as Script
FROM sys.indexes ind
JOIN sys.partition_schemes ps on ind.data_space_id=ps.data_space_id
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
FETCH NEXT FROM indScript INTO @recreateScript
WHILE @@FETCH_STATUS = 0
BEGIN TRANSACTION t1
Execute sp_executesql @recreateScript
IF @@ERROR > 0
ROLLBACK TRAN t1
declare @message varchar(max)
set @message = 'Audit history recreate index failed. SQL: ' + @recreateScript
RAISERROR (@message, 10,1)
FETCH NEXT FROM indScript INTO @recreateScript
DROP PARTITION SCHEME AuditPScheme
DROP PARTITION FUNCTION AuditPFN
DROP TABLE #indexesScript
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.