Search This Blog

Thursday, August 13, 2015

CRM integration: Change Folder Name in Sharepoint and CRM integration

If you have any doubt in the post please post comments. I will try to solve your problem.

When you add a document in sharepoint usually it pop up do you want to create a folder and save the file inside.
 If you click ok then folder will be create by the name of guid of the current record entity.
It is not user-friendly how to change the folder name?

By default there is no out of box feature to configure the folder. 

Solution:
When we open the document in the quote we are going to create folder name with quote id.

In the CRM website go to Tools\DocumentManagement. Open the areas.aspx file. In this file only folder will be create in the sharepoint.

 Mscrm.DocumentLocationHelper.autoCreateLocation(siteCollectionUrl, defaultLocationUrl, defaultLocationId, defaultLocationType, entityLogicalName, entityDisplayName, folderName, entityCentricPrimaryName, entityCentricEntityName, entityCentricPrimaryId, entityCentricEntityType);

The above mentioned method will going to create folder in sharepoint by default. In that method we are going to change the value of folderName parameter.

The red color code is the extra lines of code added in the existing method.

  <script type="text/javascript">
        function getParameterByName(name) {

            name = name.replace(/[\[]/, "\\[").replace(/[\]]/, "\\]");
            var regex = new RegExp("[\\?&]" + name + "=([^as&#]*)"),
                results = regex.exec(location.search);
            return results === null ? "" : decodeURIComponent(results[1].replace(/\+/g, " "));
        }

        function CreateOrSelectDocumentLocation() {
            debugger;

            if(typeof(autocreatelocation) != "undefined" && autocreatelocation)
            {
                document.getElementById("showProgress").style.display = "inline";

                if (typeof(defaultLocationUrl) != "string" || isNullOrEmptyString(defaultLocationUrl))
                {
                    Mscrm.DocumentLocationHelper.showNotification("LOCID_DOCM_SPLOC_INVALIDPARENT", "");
                }
                else
                {
                    //oId=Current record GUID
                    var strId=getParameterByName("oId");
                    strId=strId.slice(1,-1);
                    var strEntity="";

                    var strFilter="";
                    if(entityLogicalName=="quote")
                    {
                        strEntity="QuoteSet";
                        strFilter="$filter=QuoteId eq (guid'" + strId + "')";
                    }
                  //Get the quote number and assign in the folder name variable
                    XrmServiceToolkit.Rest.RetrieveMultiple(
                             strEntity,
                             strFilter,
                             function(result) {
                                 if (result != null && result.length > 0) {
                                     if(entityLogicalName=="quote")
                                         folderName = result[0].QuoteNumber;
                                 }
                             },
                             function() {},
                             function onReturn() {

                             },
                             false
                         );
                    Mscrm.DocumentLocationHelper.autoCreateLocation(siteCollectionUrl, defaultLocationUrl, defaultLocationId, defaultLocationType, entityLogicalName, entityDisplayName, folderName, entityCentricPrimaryName, entityCentricEntityName, entityCentricPrimaryId, entityCentricEntityType);
                }
            }
            else
            {
                var _locationId = <%= Microsoft.Crm.CrmEncodeDecode.CrmJavaScriptEncode(_locationId) %>;
                if (!IsNull(_locationId) && _locationId != "") {
                    var locationSelectorControl = $find("documentsGrid_DocumentLocationSelector");
                    locationSelectorControl.setSelectedLocationItemInMenu(_locationId);
                }
                else if(typeof(errorMessage) != "undefined")
                {
                    Mscrm.DocumentLocationHelper.showNotification(errorMessage, "");
                }
                else
                {
                    document.getElementById("errorMessageArea").style.display = "inline";
                }
            }
            
            if(document.getElementById("showProgress").style.display != "none")
            {
                var gridProgress=parent.document.getElementById("progress");
                if(!IsNull(gridProgress))
                {
                    gridProgress.style.display="none";
                }
            }
        }
</script>

Security Rights for Import Data Tool visible in ribbon

If you have any doubt in the post please post comments. I will try to solve your problem.

To enable the Import data tool button we have to first check the whether rights are property given. In
core records check rights that are given in the image below.



Monday, August 10, 2015

Default file size limit for the CRM Data Import Wizard (and how to modify it)

If you have any doubt in the post please post comments. I will try to solve your problem.

Step 1 Make sure that you modify the different timeout settings. The below KB includes additional information.
A time-out occurs when you import large customization files into Microsoft Dynamics CRM
http://support.microsoft.com/kb/918609

Step 2 Verify the current value for the "Max" file size for data upload. By default the value is set to "8".

Use MSCRM_CONFIG
select ColumnName, IntColumn from ServerSettingsProperties
where ColumnName = 'ImportMaxAllowedFileSizeInMB'
Go
To change the value you would need to apply the below statement. It will change the default value from 8 to 10. As a result the max file size for data import will now be 10 MB.

Use MSCRM_CONFIG
UPDATE [MSCRM_CONFIG].[dbo].[ServerSettingsProperties]
SET [IntColumn] = '10'
WHERE ColumnName = 'ImportMaxAllowedFileSizeInMB'
Go

The range for the 'ImportMaxAllowedFileSizeInMB' is between
<Min>1</Min>
<Max>32</Max>
<Default>8</Defaul

Wednesday, August 5, 2015

Microsoft Dynamics CRM Authentication (On-premises)

Microsoft Dynamics CRM Authentication (On-premises)

If you have any doubt in the post please post comments. I will try to solve your problem.

Have you ever wondered how you are authenticating to your CRM application? It is useful to think about this because it:

  1. Helps you troubleshoot when there are security-related issues.
  2. Reinforces your understanding of your network infrastructure.
We will be taking a look at Windows authentication, claims-based authentication for internal access, and claims-based authentication for external access.
Windows authentication
Windows authentication is available to clients who want to authenticate using Kerberos or NT LAN Manager (NTLM). It is used in an intranet setting where all users are members of your Active Directory (AD) domain. When a client tries to log into the CRM website anonymously, they receive a 401 error. They get redirected to AD where their Windows (logon) credentials are compared to an existing account. AD then grants them a Kerberos ticket which they use to authenticate into the site. CRM accepts the ticket and pushes content to the client.
crm_windows_authentication
Source: Microsoft
Claims-based authentication: internal access
This authentication method is used in a multiple domain environment where there is no trust between domains, or where users exist in a different attribute store; users are authenticated internally. When an anonymous request is sent to the CRM server, it is rejected with a 302 error and the client is redirected to the Active Directory Federation Services (AD FS) login page. By logging in, they send a request for a security token. If they do not already have a valid Kerberos ticket on the network, they receive a 401 error. Otherwise, the Kerberos ticket is used in this step and the client automatically receives the security token to use on the CRM server. In the event that they do not have a Kerberos ticket, the client sends their logon credentials to Active Directory and supplies that Kerberos ticket to AD FS. The security token is then issued to the client which is then used against the CRM server. The CRM server authenticates the client and receives content.
crm_claims-based_internal_authentication
Source: Microsoft
Claims-based authentication: external access
Accessing the CRM website through the internet using Internet-facing deployment (IFD) is now done with claims-based authentication. Both of the claims-based authentication methods are largely the same. The main difference between internal vs. external access is that Kerberos tickets are not used in external authentication. When a user navigates to the CRM website, they are redirected to AD FS and prompted to login. If there exists more than one trusted claims provider in AD FS (Active Directory is the only claims provider by default), the user will select a claims provider. Users then login and the credentials are validated by AD FS.
crm_claims-based_external_authentication
Source: Microsoft
A multiple server environment is recommended for a CRM server deployment. Although small businesses with a limited number of users can house AD FS and CRM on the same server, it is recommended to have AD FS and CRM on separate servers.

Session Time out in CRM

If you have any doubt in the post please post comments. I will try to solve your problem.

In CRM,after a period of time session would expire and back to sign page.

Once you deploy ADFS in a functional environment, the users will generally receive timeout requests, or requests to log back in, which can quickly become an issue within an 8 hour shift (480 minutes).

ADFS
Active Directory Federation Services (ADFS) is used by Microsoft Dynamics CRM for an Internet Facing Deployment (IFD).  Relying Parties are used to allow users to be authenticated when trying to access Microsoft Dynamics CRM.

The solution is to set the ADFS Timeout. The ADFS timeout determines how long the claims token will live in the system before requiring a re-authentication or signin from the user. This can be set on the internal and external sides of ADFS. You will need to know the names of your ADFS relying party trusts.

Step:1
Open the deployment manager and check type of authentication enabled in CRM.If claim or IFD is an enabled

Step:2
Check which server ADFS is available. It is not sure ADFS lies has in same application server.

Step:3
To begin, open the ADFS Management Console:
  
Open the left hand navigation, expand relying parting trusts to find the display names:
Now, run the Windows Powershell from the machine with ADFS installed.

For Windows 2008 Server, you will need to add the PSSnapin from the ADFS Command Prompt:


(In Windows 2012 and later, the ADFS role is pre-installed and you can move on to the next step.)


Using the Internal Relying Party Trust Display Name from the ADFS wizard above, enter this command where the dev.mydomain.com is the name of your internalcrm ADFS Relying Party Trust Display Name.
 
The last line of the results specific TokenLifetime will say how long the current time out is set.

Set the timeout to 480 for 8 hours ( minute increments). Example below is (240).


Now, set the timeout is set. You can follow the same steps to review or set your external timeout as well. It's not a good security practice to set your external lifetime greater than 1 hour, as somebody who logins in remotely and forgets to logout, the session will be active until that timeout period is reached.