The Microsoft Dynamics CRM community is constantly growing, and it does so in many directions.

Now we are all (who desire to sign up for it) ranked by our individual CRM Rock Star shine!

Just enter your certs, projects and inspirations and – voila! – you get your ranking in your own country and globally.

Check my stats here http://crmrockstar.com/rappen and sign up to find out how much of a Rock Star you are!

In Microsoft Dynamics CRM 2011 there is a known performance issue when the POA table grow large.
Just the other day I was working with a customer to help them pin down why the POA table was so large in their organization database. We were also investigating if they could benefit from the use of Teams in CRM 2011 instead of using “share with users” as their POA table was growing a lot.
If users frequently share records with other users you could benefit from setting teams as owners of those records instead. Or to have the users share with Teams instead of specific set of users.
As we started our investigation we had a look at the POA table to see which objects they were sharing.
The POA table stores information about records in CRM that is shared with other users or teams. The share can be made either by a user, custom code that shares a record, or by the system due to relationship behaviors or system settings.
You can configure system settings to “Share record with the previous owner”. This might not be needed in your system. When this setting is activated, all records that are assigned to another user will be automatically shared with the original user. And an entry in the POA table will also be created for that share.

.
The relationship behavior cause share records to be created in POA.
Let say User Adam owns an Account named Company A and the relationship between Account and Contact is set to the default. “Parental”, then the following will occur.

If another user creates a contact under Account Company a record in the POA table will be created. This record makes sure that user Adam will have access to the new contact under “his” Account. This might be as you want it to be and this might not be an issue at all.
But if we instead have a custom entity that is a parent of another custom entity that is used for logging or to keep track of something that will generate a lot of records. If the parent record is owned by user Adam and a plugin or some import job creates the child records under a system account (integration / admin account) CRM will create a record for each child record in the POA table. This might result in a POA table growing out of control.
You will not be able to see this under the “share” properties in CRM. It´s only added to the POA table in this case. This is probably not something you need. If you instead set the relationship configuration to “Referential” you will not generate any extra record in the POA table.

Here is a SQL Query you can start with to see what is taking up the space in your POA table.
(Only possible in On-Premise installations)
SELECT ObjectTypeCode, COUNT(ObjectTypeCode) AS Total
FROM PrincipalObjectAccess
GROUP BY ObjectTypeCode
ORDER BY Total DESC
To find the name of the entity (ObjectTypeCode) you can use the following select statement in SQL Server.
Change the name of the database “CRMORGDB_MSCRM” to your organization database name.
SELECT DISTINCT name, objecttypecode
FROM [CRMORGDB_MSCRM].[MetadataSchema].[Entity]
ORDER BY name ASC
I hope this will help you to prevent some unnecessary records in the POA Table
Happy POA record hunting
//Hans

The long long wait is over...

Have you ever had a CRM installation that can be accessed using different URLs, e.g. one to be used inside a corporate network, and one to be used for external access?
Have you also written some javascript to make calls to the OData endpoint or to open a new entity form?

Then you have realized that the context.getServerUrl method returns the URL that was assigned the server during the installation of CRM, and not the URL currently used to access CRM.

Why is that a problem?

Well, authenticating the user to one URL, and then having javascript making calls to the OData endpoint on another URL, will just give the user a "too bad, you are not authorized to do anything on this URL".

Now, at last, in Microsoft Dynamics CRM Software Development Kit version 5.0.13 the context.getClientUrl method is introduced, which returns the base URL currently used by the user to access the CRM application.
The getServerUrl method is still there, but deprecated and should not be used in the future.

Documentation can be found here.

Happy javascripting!

 

Hi.
I would like to share some information with you regarding a little error message that you might stumble on if you have CRM 2011 and enable document management.

If you get an error message from the webpage during form load in CRM 2011 then you might be having the same problem as I just had.

The error message is
Error during FormLoad Access is denied

This error was generated because the CRM Server was configured with document management and the URL for the SharePoint server was not configured with FQDN (http://SharePointServer) and the users access CRM with the server name in FQDN format (http://crmserver.domain.com)

To resolve this you should use the same format for your SharePoint URL and your CRM URL.

Like http://SharePointServer and http://crmserver
This will place the URLs in the same security zone in Internet Explorer (if your admin has not configured any special IE Policy restrictions)
All URLs that you access without FQDN format will be placed in the Local intranet Zone in Internet Explorer by default

If you click to open the document location in your CRM form within the left navigation area you might also see a warning message from Internet Explorer like the following

 

I hope this is helpful for some one else as well

Happy troubleshooting!

//Hans

In this post I will provide you with a little example on how to protect your Microsoft Dynamics CRM Organization database with SQL Server Transparent Data Encryption (TDE).

If you want to protect your database even the backup files so that no one will be able to take one of your backup files or disks and just move it to another SQL server and be able to get the information from your system you should use TDE to encrypt your database.
TDE will not encrypt data sent over the network!
Do not use this in production without reading more about it first!
Make sure you know enough to maintain it and know all about TDE before you use it in production.

In SQL Server 2012 Enterprise Edition you can try this out.

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'SuperPassword';
GO
CREATE CERTIFICATE ServerCertificate WITH SUBJECT = 'Server Certificate DEK';
GO
USE CRMORG_MSCRM;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE ServerCertificate;
GO
ALTER DATABASE CRMORG_MSCRM
SET ENCRYPTION ON;
GO

Encryptions you may choose from are
DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, and 256-bit AES

It’s very IMPORTANT to backup you certificate ServerCertificate.
Without the Certificate backup you will not be able to use your database files / backup files if the server crash and burns, or if you need to recover your data.

After you run the following SQL commands the backup files will be placed in your MSSQL\Data folder. Make sure to back these up to a secure location.

USE master
GO
BACKUP CERTIFICATE ServerCertificate
TO FILE = 'ServerCertExport'
WITH PRIVATE KEY
(
FILE ='PrivateKeyFile',
ENCRYPTION BY PASSWORD ='YourOtherStrongPassword'
);
GO

Note* if you use TDE on any database in you SQL instance the TempDB will also be encrypted. This might have an impact on performance.

If you lite to read more about TDE you can start with these pages on MSDN.
About TDE.
http://msdn.microsoft.com/en-us/library/bb934049.aspx
About Encryption keys.
http://msdn.microsoft.com/en-us/library/ms345262.aspx

Be safe!

//Hans