Microsoft.Crm.Config.Client.InstallPstAction failed

I often come across admins reporting a specific error when installing Outlook CRM client on some computers.

Action Microsoft.Crm.Config.Client.InstallPstAction failed.
LaunchOutlookInstallerProcess failed.

The fix based on Microsoft KB http://support.microsoft.com/kb/2496442  not always works. To resolve the issue give the user write permissions on the following file:

C:\Program Files\Common Files\System\MSMAPI\1033\mapisvc.inf

This will resolve the problem. If you deploy CRM client via GPO or other similar deployment methods, make sure you configure a script to amend permissions on this specific file otherwise you will end up getting random users reporting the problem.

CRM 4.0 IFD DMZ Secure Deployment

CRM 4.0 and Internet facing deployment is a very easy tool to configure, however I don't think you can find enough information about IFD configuration on a DMZ deployment and the technical details for a secure DMZ implementation. I want to focus on the design solution and not too much on the configuration, althought I still cover some of the configuration.

To implement a secure IFD on the DMZ all you need is a RO DC (Read-only Domain Controller) and a RO DNS (Read only DNS server) and SQL port open to the CRM SQL server. Normally you find in many companies the RO DNS server running with the RO DC.

Using internal DNS servers as the main DNS servers for DMZ servers, it's a common design mistake that puts the internal infrastructure in danger of DNS poisoning, we know we don't have any major exploits in the wild that could take advantage of this design problem, but this could happen at any moment if it does, can cause major issues to the internal network.

The below diagram illustrates how CRM would work with an internal DNS server, and what happens during CRM authentication.

If you monitor the communication process capturing packets between the CRM server and DNS, you will notice the same communication as the above diagram. CRM initiates a conversation with the DNS server, which in this case is internal. The CRM queries for the SITE-DMZ DC GC Global Catalogue where the CRM server is located, DNS replies with a SRV record indicating the GC responsible for that SITE is RODC01, so CRM now communicates entirely within the DMZ zone, while this information is cached, this example shows that internal DNS servers are not required for CRM to successfully authenticate.

The following is the minimum configuration required:

1. CRM IFD server running as Application Server role, deployed on the DMZ. The server needs to be configured first on the internal network, because it needs to join the CRM farm and for this a writable DC is needed.
2. You can keep the Platform Server role on the DMZ or internally if you keep it internally you will need to open a firewall rule. The Platform role is needed to generate the CRM tokens otherwise users won't be able to authenticate.
3. SQL port 1433 open to the internal network.

 Note: the minimum configuration is based on an enterprise license, if you want to deploy IFD on a different server you need an enterprise license otherwise you may not be complying with the license agreement.

With the server now placed on the DMZ and the SQL port open on the firewall, the next step is to configure IFD. Download the IFD configuration tool from the following microsoft page: http://support.microsoft.com/kb/948779 on here you will find the necessary information on how to configure IFD, you place the tool on the dynamics CRM program files folder tools\bin and run it from inside the folder, configure the fields and publish.

When you publish the configuration, your CRM environment will be IFD enabled. It now contains information how to distinguish your internal network from the external. It also now deploys 3 new registry keys to your Outlook CRM clients:

Key: ExtranetServerUrl
Key: ExtranetWebAppUrl
Key: ExtranetDiscoveryUrl

I'm not covering these registry keys on this blog post, if you would like me in future please let me know and will be happy to write a post about this. I mention these keys because they can significantly affect Outlook client users. If you have laptop users with the CRM online version, users may get the following pop-up window constantly prompting for authentication:

If you will not use external access for CRM Outlook client, you can safely delete those keys and the pop-up will not appear. If you prefer to keep the keys but stop the constant pop-up from appearing, you can configure the following registry key:

type: DWORD 32bits
key: ClientAuthAllowRetries
value: 1

 I hope this post helped with the design of your IFD solution on the DMZ. The main areas to be aware is to keep the ports opened to the internal LAN to a minimum and to keep in mind if external access is needed for Outlook clients.

Dynamics CRM 4.0 Extreme Performance with Kerberos Configuration

Hi,

It has been a while since my last post. I want to talk about how you can improve massively CRM performance with Kerberos implementation. Kerberos is an authentication process that can save lots of processing time on the authentication side, rendering CRM much faster, I don't think is difficult to implement and it gives your CRM a major boost in performance.

Before I go through the steps, I will not explain the technical side of Kerberos because that is long subject, and you can find many whitepapers online covering kerberos authentication in detail, so I will focus only in the configuration requirements and how to troubleshoot.

Lets assume the below enterprise role-based configuration:
Domain: crm.domain.com



AD Configuration / SPNs
The first thing to do is to configure SPNs, we need to make sure we don't duplicate SPNs for the alias crm.domain.com, if we do kerberos will not work. The following command will show us if any duplicate SPN exists:

ldifde -f c:\spn_out.txt -d "DC=domain,DC=com" -l serviceprincipalname -r "(serviceprincipalname=*/*)" -p subtree

Analyse the spn_out.txt for any duplicate/existing SPNs with the name crm.domain.com

The following SPNs are required for Kerberos to work on our above environment, and these need to be configured under the service account domain\crm.service you add SPNs using setspn command or with ADSI EDIT

HTTP/crm.domain.com
HTTP/application
HTTP/application.domain.com
HTTP/platform
HTTP/platform.domain.com
HTTP/reporting
HTTP/reporting.domain.com

We are creating SPNs for the DNS name, and all servers in the CRM farm apart from:
SQL and reporting, because the SQL account will automatically create it's own SPNs and reporing runs under the Network Service account which happens in most deployments and by default does not require SPNs, if you run under a different service account, then you need to also add corresponding HTTP/ SPN to that service account.

with the SPN in place, we can jump to the next step IIS.IIS CRMAppPool is running under domain\crm.service account, the first setting to make sure is enabled is the windows authentication Kernel-mode authentication, to get there, highlight the website > click authentication > highlight Windows authentication > on the right menu click advanced settings. Note: this is normally enabled by default.

DNS Configuration
Make sure the domain you use for CRM is an A record this case crm.domain.com and not a CNAME record.

IIS Configuration
The second configuration is to enable the useAppPoolCredentials to true, which by default is set to false. Highlight the website and double click configuration Editor located at the Management section, below is a screenshot of the location of the windowsAuthentication key we need to configure to enable the use of the AppPool Credentials.


double click and change UseAppPoolCredentials to True

IE Configuration

At this point if you access crm.domain.com you will be prompted for credentials. We need to add crm.domain.com to the Trusted Sites and make sure this zone is configured to to Auto Logon and Windows Authentication is enabled.

Delegation of Authentication
Another crucial step is to delegate authentication in AD, we need to delegate authentication to the service account domain\crm.service and the CRM servers: application and platform

With an account with permissions to delegate authentication you right-click the user account domain\crm.service in AD and click properties, click on the delegation tab, and enable:

• Trust this user for delegation to any service (Kerberos only)

• User Kerberos only

Testing / Troubleshooting
We have now all in place to test Kerberos authentication, opening crm.domain.com and not getting prompted for username/password is a good sign authentication is working, if we do get prompted, review the following configuration:
- SPNs
- Trusted Sites zone configuration and check if the domain is listed on the trusted sites list.
- Double check IIS
-Review duplicate SPNs, you just need one duplicate and it will not let you authentication, so make sure there are no duplicates.

If all is correctly configured, and we still getting prompted, I suggest you monitor the traffic between IE and the server with wireshark, capturing all communication packages and on the filter type kerberos to view packages only related with Kerberos.

If authentication works, it doesn't mean that we are necessarily using kerberos, so I suggest you confirm this with wireshark or with Fiddler. When you run Fiddler, you can capture authentication headers, below is a screenshot illustrating a kerberos tickets on the headers, a kerberos ticket always start with Y or oY



Hope this post was useful for you, and if you have any questions please feel free to leave any comments.

References:
 SPN Configuration - http://rc.crm.dynamics.com/rc/regcont/en_us/op/articles/configurespn.aspx#o45872