Hiding Navigational Items based on drop down value

We had a request were based on a drop down value the navigational structure must show certain options based on the drop down value on the record.
Shawn Redmond

hideNavBarItemByName("Details:", "Divisions");

If (crmForm.all.fieldname != 3)
{
hideNavBarByItemName(‘Details’, ‘Value1');
hideNavBarByItemName(‘Details’, ‘Value2');

}

hideNavBarItemByName = function( sectionName, itemName )
{
setNavBarItemVisibilityByName(sectionName, itemName, false);
}

setNavBarItemVisibilityByName = function( sectionName, itemName, visible )
{
var groups = document.getElementById("crmNavBar").childNodes;

if( groups != null )
{
for( var i = 0; i < groupname =" groups[i].childNodes[0];" items =" groups[i].childNodes[1].childNodes;" n =" 0;" item =" items[n];" display =" visible">

Update Rollup 6 for Microsoft Dynamics CRM 4.0

The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup 6 on Thursday, August 27, 2009.
Below are the links to the release and related information about the Rollup. Please see the Knowledge Base (KB) article for more details about the Update Rollup 6 content and instructions.
Microsoft Download Center: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=79f90982-c039-41c2-af8e-3119ecf27790
Microsoft Knowledge Base Article: http://support.microsoft.com/?kbid=970148
Install Details about Update Rollup 6
Update Rollup 6 is cumulative. You do not need to install any previous Update Rollups prior to Update Rollup 6
The Update Rollup 6 client can be deployed before the server is upgraded to Update Rollup 6
Update Rollup 6 can be uninstalled
Steps to make Update Rollup 6 available via AutoUpdate can be found in the Update Rollup 4 blog posting. The Link and Patch IDs can be found in the kb article at http://support.microsoft.com/?kbid=970148.
Information about how to avoid reboots when installing the CRM Outlook Client can also be found in the Update Rollup 4 blog posting.
Update Rollup 6 and all future Update Rollups will contain Mobile Express
The CRM team released the English version of Mobile Express on July 8, 2009 as an update to the CRM Server. Since Mobile Express is now part of the Server product it will be installed and updated as part of all Update Rollups going forward. There is a Getting Started: CRM Mobile Express blog that has some pointers on how to get started. The localized versions of Mobile Express will be delivered in a future update rollup.

CRM integration into Skydrive

Hi

Last week I was asked to assist a user in Russia to integrate Skrydrive into CRM.
Skydrive is a online document mangement system provided by Microsoft using your windows live id.

This is fairly simple to do:
Download the CRM demonstration Toolkit and run it on the CRM server.
Connect to your CRM installation.
Open the SiteMap editor
Select the "Open from CRM" option.

You will notice that your sitemap is loaded in a easy to use UI editor.Having grouped your areas and subareas respectively.

Add a Area called Documents
Add Under (Documents)
On Documents select "Add Under" this will give a window with a drop down to CRM entities and a URL.
Use the URL Option. (You should have created a online skydrive account.Login into skydrive and copy the url for your document library.)
Paste the Url in the URL field
Description"Documents"
Icon URL (Your choice of icon)
Select "Publish to CRM"
Open CRM /Refresh CRM

You should have a Area called "Documents " in the navigational tree.
When opening, this will open your document library on skydrive.

Easy as falling out of a tree,just remember to let go of the branch.....:)

Microsoft CRM Information Documentation

Microsoft CRM Information PDF's
Top 10 Compelling Reasons to Use CRM Download
Customer Case Studies Download
What’s New in MS CRM 4.0 Download
Sales Force Automation Overview Download
Marketing Automation Overview Download
Customer Service Overview Download
MS CRM 4.0 What’s New Top 60 Datasheet Download

Microsoft CRM Additional Information

Implementing MS CRM 4.0 Download
Microsoft Dynamics CRM 4.0 Users Guide Download
Optimizing & Maintaining CRM 4.0 whitepaper Download

Preparing for your CRM Certication made easy with -Richard Knudson’s Dynamics CRM Trick Bag

Demo practice test for Dynamics CRM Applications exam MB 632 (20 questions)
Demo practice test for Dynamics CRM Installation exam MB 633 (15 questions)
Demo practice test for Dynamics CRM Customization exam MB 631 (20 questions)

Microsoft CRM 4.0 Update Rollup Best Practices

Found a great right-up on Rollup's

Updates: Microsoft CRM 4.0 Update Rollup Best Practices

Frank Lee
http://microsoft-crm.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=cat%3dMicrosoft%2520CRM%2520Update

You may have noticed that the Microsoft CRM Update Rollups are being released on a regular basis like every 2 months since Update Rollup 2. This is much more frequent then the previous update release schedule (6 to 9 months). So how do Small Medium Businesses (SMB) manage this given the more frequent updates?
Here are three approaches and my notes on each one:
1. Only apply Update Rollup as needed to solve bugs/issues
- requires the least amount of administration resource, but could result in the highest reactive situation when encountering CRM issues/bugs that are solved by an Update Rollup
2. Apply every Update Rollup upon being released
- requires the most amount of administration effort to update the CRM Server and all of the CRM Outlook Clients upon each release of an Update Rollup. However, this offers the highest avoidance of CRM issues/bugs that are solved by Update Rollups
3. Apply Update Rollup on every 4, 5, or 6 months cycle
- a good balance of administration resource and risk avoidance due to CRM issues/bugs that are solved by an Update Rollup. As for 4, 5, or 6 - it would be your preference.
Guess which approach I'd recommend for most SMBs? Yup, number 3. I'd personally select the every 4 months cycle.
Some good practices on deploying Update Rollups:
1. Always backup your CRM environment per the Update Rollup instructions prior to applying the Update Rollup. If you have a test environment (I highly recommended having one), apply the Update Rollup there first.
2. Wait two weeks after the release of an Update Rollup before applying it - just like any software, Update Rollup may contain some bugs itself. There were some Update Rollups in the past that were "re-released" due to issues/bugs arised from the Update Rollup. If this does happen, contact Microsoft CRM Support immediately for resolution. And if you had waited after two weeks, you would mostly enjoy the benefit that a work-around/resolution is available due to Support already encountered the issue already. No need to be the very first to apply an Update Rollup in production unless it fixes a specific issue/bug
3. It is not necessary to apply both the CRM Server Update and CRM Outlook Client Update at the same time. I do highly recommend they are both applied the same time to get the latest fixes to all your CRM enviornments (Server and Outlook Clients). However, it is OK to apply the CRM Server Update first, and then apply the CRM Outlook Client Update the next few days/weeks. Or the other way around - apply the CRM Outlook Client Update first and then apply the CRM Server Update afterwards
4. Most SMB doesn't have a large CRM Users count, but if yours do, then I would look into auto deployment of the CRM Outlook Client Update to save time. Reference the Microsoft CRM 4.0 Implementation Guide - Microsoft_Dynamics_CRM_IG_Operating.doc, section "Automatically update Microsoft Dynamics CRM for Outlook" for details
5. If you had encountered a bug/issue and have not apply the latest Update Rollup yet. What should you do? I would open a CRM Support Incident via CustomerSource - if the bug is a bug and "not a feature" then there is no cost to the Support Incident and you would get a resolution from the CRM Support engineer to either apply the latest Update Rollup, a Hot Fix, or other work-around.

Configuring Microsoft Dynamics CRM 4.0 for Internet-facing deployment

Configuring Microsoft Dynamics CRM 4.0 for Internet-facing deployment
Published: February 13, 2009 Updated: May 15, 2009

This document describes configuring Microsoft Dynamics CRM (On-Premise Edition) for Internet-facing deployment (IFD), and a few of the common issues and resolutions associated with Microsoft Dynamics CRM IFD.
You can deploy Microsoft Dynamics CRM (On-Premise Edition) using one of the following deployment types:
· Microsoft Dynamics CRM for internal users only
· Microsoft Dynamics CRM for internal users and IFD access
· Microsoft Dynamics CRM for IFD-only access
For more information about configuring Microsoft Dynamics CRM for Internet access only, see Internal Network Address under the "IFD configuration properties details" section in this article.
Microsoft Dynamics CRM uses Integrated Windows authentication to authenticate internal users. Integrated Windows authentication implements pass-through authentication functionality so that Microsoft Dynamics CRM users are not prompted a second time to log in to Microsoft Dynamics CRM after their initial sign on to the Active Directory network.
Configuring IFD for Microsoft Dynamics CRM enables access to Microsoft Dynamics CRM from the Internet, outside of the company firewall, without using a VPN solution. Microsoft Dynamics CRM configured for Internet access uses forms authentication to verify credentials of external users. When configuring Microsoft Dynamics CRM for Internet access, Integrated Windows Authentication must remain for internal users.
Configuring IFD sets the Microsoft Dynamics CRM Web site to use anonymous authentication for external users, and provides a sign on page to capture users' credentials and obtain an authentication ticket cookie. Microsoft Dynamics CRM IFD checks for a valid CRM ticket cookie before processing the page request. When a page request does not contain a valid CRM ticket, the page request is redirected to the sign-on page. A page request with an expired CRM ticket is also redirected to the sign-on page. Users access the Microsoft Dynamics CRM Web site by typing the IFD URL in Internet Explorer. Because this type of authentication sends user credentials and passwords using clear text, you should always configure Microsoft Dynamics CRM using a Secure Sockets Layer (SSL). For more information about SSL, see Make Microsoft Dynamics CRM 4.0 client-to-server network communications more secure. For more information about forms authentication and IFD, see Web Form (IFD) Authentication. For more information about forms authentication with active directory, see Forms Authentication in ASP.NET.
On This Page

Common Issues
Methods available to configure IFD
You can deploy Microsoft Dynamics CRM for IFD by using one of the following methods:
· During Microsoft Dynamics CRM Server installation or upgrade.
o Install a new deployment of Microsoft Dynamics CRM (On-Premise Edition) using command-line options and an XML configuration file that contains IFD configuration information (specified in the following topic).
o Upgrade from Microsoft Dynamics CRM 3.0 to Microsoft Dynamics CRM (On-Premise Edition) using command-line options and an XML configuration file that contains IFD configuration information (described in the following topic).
· Configure an existing deployment using the Microsoft Dynamics CRM Internet Facing Deployment Configuration tool. Configure an existing deployment of Microsoft Dynamics CRM that did not use an XML configuration file that contained IFD configuration information (described in the following topic). To configure the existing deployment, download and run the Microsoft Dynamics CRM Internet Facing Deployment Configuration Tool (described in the topic below).

Configure during Microsoft Dynamics CRM Server installation or upgrade

When using the command-line option to deploy a new installation of Microsoft Dynamics CRM or upgrade from Microsoft Dynamics CRM 3.0, you can enable IFD by adding the element to a Microsoft Dynamics CRM Server Setup XML configuration file. The element must be defined under the elements. When the enabled element is set to true (), Microsoft Dynamics CRM Server Setup configures the deployment for access from the Internet. Additional information is required to make the Web site accessible from the Internet. For more information see, "Use the Command Line to Install Microsoft Dynamics CRM" in the Installing Guide in the Microsoft Dynamics CRM 4.0 Implementation Guide. The Microsoft Dynamics CRM Server Setup XML configuration file makes the same changes as the Microsoft Dynamics CRM Internet Facing Deployment Configuration tool, see the table below for the list of properties that are added or updated. The configuration file should look similar to the following example:


157.55.160.202-255.255.255.255
https
mysubDomain.myDomain.com:443
mysubDomain.myDomain.com:443


For more information about the IFD deployment properties in the element see, the IFD Configuration Properties on this post by clicking on the post link.

Configure an existing deployment using Microsoft Dynamics CRM Internet Facing Deployment Configuration tool
The Microsoft Dynamics CRM Internet Facing Deployment Configuration tool adds a node to the web.config file for IFD settings, creates deployment properties in the MSCRM_config database, and adds a registry key to Microsoft Dynamics CRM Server enabling Internet-facing access. You can use the Internet Facing Deployment Configuration tool after installing or upgrading to Microsoft Dynamics CRM. You can also use this tool any time you want to change the IFD configuration properties.
Read the Microsoft Dynamics CRM 4.0 Internet Facing Deployment Scenarios document for specific configuration scenarios and instructions to help you successfully implement Microsoft Dynamics CRM IFD.
You can also get detailed instructions for using the Microsoft Dynamics CRM Internet Facing Deployment Configuration tool in How to use the Microsoft Dynamics CRM Internet Facing Deployment Configuration tool.
Note
To update other configuration fields, download and run the Microsoft Dynamics CRM Internet Facing Deployment Configuration tool from Microsoft Dynamics CRM 4.0: Planning and Deployment Guidance for Service Providers.

IFD configuration properties details

Internal Network Address

When you configure Microsoft Dynamics CRM for IFD using the Internet Facing Deployment Configuration tool or using an XML configuration file, on initial Microsoft Dynamics CRM installations only, you are adding a new Windows registry key. The IfdInternalNetworkAddress registry key contains the IP addresses and subnet masks for internal computers using Microsoft Dynamics CRM. The registry key location is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM

When a user submits a page request, the Microsoft Dynamics CRM Server compares the user's IP address and subnet mask with the values in the registry key to determine which authentication type to use, anonymous access authentication for Internet access or Integrated Windows authentication for internal users. For example, the IP addresses and subnet masks of your Microsoft Dynamics CRM users are as follows:

10.10.1.1-255.255.255.0,157.55.164.93-255.255.255.0

When the subnet is 255.255.255.0 and the IP address are 10.10.1.1 or 157.55.164.93 then any IP address that starts with 10.10.1 or 157.55.164 is considered internal.
When a user requests a Microsoft Dynamics CRM page and the user's IP address and subnet masks is 157.55.165.22-255.255.254.0 and the IP address and subnet mask is not found, Microsoft Dynamics CRM uses forms authentication to display a sign on page. Any IP addresses and subnet masks not in the Internal Network Address registry key cause the Microsoft Dynamics CRM Server to respond with the IFD sign on page to request the user's credentials.
If users are accessing Microsoft Dynamics CRM from multiple subnets, you must update the IfdInternalNetworkAddress registry value to reflect the different subnets. When you have more than 1 subnet, you can add multiple values to the IfdInternalNetworkAddress registry key. Separate the values using a comma but do not add a space after the comma.
To configure Microsoft Dynamics CRM for IFD only access, enter the IP address to the Microsoft Dynamics CRM Server and a subnet mask of 255.255.255.255. Then only those page requests from the Microsoft Dynamics CRM Server are considered internal, and all other page requests prompt the sign on page.

IFD Root Domain Scheme

In the Root Domain Scheme or IFD Root Domain when using the Internet Facing Deployment Configuration tool, enter https as the value of this MSCRM_config database property when you have SSL set for the Web site.
Important
SSL is strongly recommended fo Internet-facing deployment of Microsoft Dynamics CRM.

SDK Root Domain

In the SDK Root Domain or the IFD SDK Domain when using the Internet Facing Deployment Configuration tool , enter the domain name where the SDK Server role is installed. This is used for applications that use the methods from the Microsoft Dynamics CRM Software Development Kit(SDK) as the value for this MSCRM_config database property. Add the domain name and the root domain (.com), for example mycompany.com rather than mycompany. If using a port that is not the default, then you need to include the port number in the SDK Root Domain, for example, domain.com:5555.

Web Application Root Domain

In the Web Application Root Domain or the IfdWebApplicationRootDomain when using the Internet Facing Deployment Configuration tool , enter the domain name only for the Microsoft Dynamics CRM Web application as the value for this MSCRM_config database property. Add the domain name and the root domain (.com), for example mycompany.com rather than mycompany. If using a port that is not the default, then you need to include the port number in the Web Application Root Domain, for example, domain.com:5555.
Important
When using server roles divided out to different computers, you must use different domain name values for IfdWebApplicationRootDomain and IfdSdkRootDomain. For more information, see the topic below Using Server Roles.
Service Provide License Agreement
ServiceProviderLicenseAgreement replaces OnPremise as the authentication strategy in the node of the Web.config file.

IFD URL
You must define a URL for the Microsoft Dynamics CRM IFD deployment using the following format:
https://.
For information about changing Microsoft Dynamics CRM port assignment, see How to update the Microsoft Dynamics CRM Web site port after you install Microsoft Dynamics CRM 4.0.

Common Issues
Use DNS host or alias record with IFD
Create a host or alias record for each organization that plans to access Microsoft Dynamics CRM externally from the Internet. If you use host headers to uniquely identify the Microsoft Dynamics CRM Web site, you should remove the host headers and set up a Domain Name Service (DNS) alias record. This is particularly important because SSL does not work with host headers. The DNS alias record ensures that the URL address for the external and internal organization resolves correctly. The alias record is a name for your Web application that is composed of a subdomain name to identify the organization, second-level domain name to identify your company, and root domain name such as .gov, .tv. or .com. For Microsoft Dynamics CRM IFD, your DNS alias record should resemble the following:
crm_organization_name.domain.com
The Internet Facing Deployment Configuration tool includes a Check DNS option on the Tools menu to test DNS resolution. If you have not defined domain names in DNS, the Internet Facing Deployment Configuration tool displays a message indicating that the domain name cannot be resolved. For specific instructions, see Setup test DNS record in How to configure an Internet-Facing Deployment for Microsoft Dynamics CRM 4.0.

Firewall exceptions

If one or more firewalls are running between the clients and the Microsoft Dynamics CRM Server, an exception for the port used by the Microsoft Dynamics CRM Web site must be established to allow clients to connect.

Running reports

To enable complete reporting functionality for a Microsoft Dynamics CRM deployment configured for IFD, the deployment must be running the Microsoft Dynamics CRM Connector for SQL Server Reporting Services.
When a Microsoft Dynamics CRM user runs a report from Microsoft Dynamics CRM, Microsoft SQL Server Reporting Services Viewer requests the report and data from the remote Microsoft SQL Server Reporting Services computer. To access the report, the Microsoft Dynamics CRM user enters the Microsoft Dynamics CRM server URL. Microsoft Dynamics CRM Connector for SQL Server Reporting Services runs as a Microsoft SQL Server Reporting Services data processing extension and handles the authentication in the delegated mode used for reports.
However, the Microsoft Dynamics CRM Connector for SQL Server Reporting Services does not work with the Microsoft SQL Server 2005 Workgroup Edition because it does not support custom data extensions used in the Microsoft Dynamics CRM Connector for SQL Server Reporting Services. To resolve this issue, upgrade Microsoft SQL Server 2005 Workgroup Edition to one of the following editions:
· SQL Server 2005 Standard Edition
· SQL Server 2005 Enterprise Edition
· SQL Server 2008 Enterprise Edition
· SQL Server 2008 Standard Edition
For specific SQL Server 2008 upgrade version information, see SQL Server 2008 Books Online Version and Edition Upgrades.

Using Dynamic worksheets or Dynamic PivotTables

To export data to Dynamic worksheets or Dynamic PivotTables for Microsoft Dynamics CRM users connecting to a Microsoft Dynamics CRM IFD deployment, install and configure the Microsoft Dynamics CRM for Microsoft Office Outlook client on the computer of the Microsoft Dynamics CRM user trying to open the Dynamic worksheet. When Microsoft Dynamics CRM is not in the same domain as the client computer, Microsoft Dynamics CRM for Microsoft Office Outlook client handles the Microsoft Dynamics CRM user login credentials for the Microsoft Dynamics CRM database used in the worksheet.
For information about securing data exported to Microsoft Office Excel, see Microsoft Dynamics CRM Team blog article Dynamic Export to Excel feature – How to protect data over the wire.

Using server roles

In a Microsoft Dynamics CRM deployment you can split the configuration into two separate server role groups or separate each individual server role across multiple computers. If you configure IFD for a Microsoft Dynamics CRM deployment using server role groups or separate server roles, you must obtain different SSL certificates if the Application server role and the SDK server role are on different computers. You cannot use the same certificate for both server roles. If you did not obtain different SSL certificates defined with root domain names specific to the Application server role and SDK server role, then the DNS server detects duplicate mappings and cannot resolve the domain names. To resolve this duplicate mapping issue, assign different values in the deployment properties for the IFD App Root Domain and IFD SDK Root Domain. The value that you enter in the Internet Facing Deployment Configuration tool for the App Root Domain is the domain associated with the Application server role. The value that you enter in the Internet Facing Deployment Configuration tool for the SDK Root Domain is the domain associated with the SDK server role.
For more information about server roles, see Making Sense of Server Roles.

Configure IFD with an ISA server

After you configure Microsoft Dynamics CRM for IFD and you are using an Internet Security and Acceleration (ISA) server, any user attempts to login from the Internet are challenged for a Windows login instead of the Microsoft Dynamics CRM sign on page. This causes the user authentication to fail. You can resolve this issue by changing the configuration setting on the ISA server to Request Appear to come from Original Client. This setting causes the ISA server to interpret the request as coming from the original client IP. For this configuration setting to work, the web server must point to ISA Server's internal IP address as the Default Gateway.
Configure IFD for a multi-forest with a perimeter network model
When you use a perimeter network to isolate Internet-facing resources from your internal corporate network, you have to open the ports to the local area network to successfully deploy Internet-facing Microsoft Dynamics CRM. You can see an example of a perimeter network model in the Planning Guide in the Microsoft Dynamics CRM 4.0 Implementation Guide under the heading, "Multi-forest with client Internet access."
The following information on how to configure Microsoft Dynamics CRM for IFD with a perimeter network model is from Joel Lindstrom's CustomerEffective blog. You need to do the following when using a perimeter network model:
1. Install and configure Microsoft Dynamics CRM.
On an initial installation, you can install and configure Microsoft Dynamics CRM for Internet-facing access using the command-line installation options or you can wait until after you have Microsoft Dynamics CRM running and tested before configuring it for IFD.
2. Enable the perimeter network solution.
3. Open the required ports to the local area network:
o Microsoft SQL Server
o Microsoft SQL Server Reporting Services
o Microsoft Exchange Server 2003 or Microsoft Exchange Server 2007
o Domain Controllers
For more information about Microsoft Dynamics CRM ports, see "Network ports used for Microsoft Dynamics CRM 4.0" in the Planning Guide in the Microsoft Dynamics CRM 4.0 Implementation Guide.
4. Test the Microsoft Dynamics CRM server to ensure that it is working as expected.
5. Obtain and install a wildcard SSL certificate for your Microsoft Dynamics CRM deployment.
6. Use the Internet Facing Deployment Configuration tool to set up the IFD deployment. While using the IFD tool, verify that the DNS values resolve.

Hiding Button's on related views in CRM

Onload:
HideAssociatedViewButtons = function(loadAreaId, buttonTitles)
{
var navElement = document.getElementById('nav_' + loadAreaId);
if (navElement != null)
{
navElement.onclick = function LoadAreaOverride()
{
// Call the original CRM method to launch the navigation link and create area iFrame
loadArea(loadAreaId);
HideViewButtons(document.getElementById(loadAreaId + 'Frame'), buttonTitles);
}
}
}


/* Used internally by the 'HideAssociatedViewButtons' method */
HideViewButtons = function(Iframe, buttonTitles)
{
if (Iframe != null)
{
Iframe.onreadystatechange = function HideTitledButtons()
{
if (Iframe.readyState == 'complete')
{
var iFrame = frames[window.event.srcElement.id];
var liElements = iFrame.document.getElementsByTagName('li');
for (var j = 0; j < buttonTitles.length; j++)
{
buttonTitleParts = buttonTitles[j].split('::');
if (buttonTitleParts.length > 0)
{
buttonTitle = buttonTitleParts[0];
for (var i = 0; i < liElements.length; i++)
{
liElement = liElements[i];
if (liElement.getAttribute('title') == buttonTitle)
{
if (buttonTitleParts.length == 1)
{
liElement.style.display = 'none';
break;
}
else
{
/* We want to hide a menu item in a drop-down menu.
Find the descendant text element with the specified text.
Then find its parent list item and hide it:
*/
menuText = buttonTitleParts[1];
var spanElements = liElement.getElementsByTagName('span');

for (var k = 0; k < spanElements.length; k++)
{
spanElement = spanElements[k];
if (spanElement.className == 'ms-crm-MenuItem-Text' )
{
textElement = spanElement.firstChild;
if (textElement != null && textElement.nodeType == 3) /* 3 = Node.TEXT_NODE */
{
if (textElement.data == menuText)
{
liMenuItemElement
= spanElement.parentNode.parentNode.parentNode;
liMenuItemElement.style.display = 'none';
break;
}
}
}
}
}
}
}
}
}
}
}
}
}

HideAssociatedViewButtons("CRMRELATIONSHIP", ["Add existing XXXXto this record", "Add a new XXXX to this record"]);

Troubleshooting CRM, Kerberos, and the Error 401.1 – Unauthorized: Access is denied

Troubleshooting CRM, Kerberos, and the Error 401.1 – Unauthorized: Access is denied
Posted on January 23, 2009 by Dan Blake

You install Microsoft Dynamics CRM 4.0 and follow the instructions to the best of your ability only to find that when you try to access the CRM web site, it prompts you for a password three times then you get the message:

You are not authorized to view this page.
HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials.

This has got to be the #1 most common error people run into when installing Microsoft Dynamics CRM 4.0. In all of the production, testing, and development environments I have set up, the 401.1 error is the one I have spent the most time troubleshooting. It is ALWAYS caused by a problem with Kerberos and double-hop authentication. The trouble is that there are SO MANY ways you can break Kerberos. Over the weekend, I went through another marathon troubleshooting session to resolve yet another Kerberos issue. This time it was in our Sandbox (testing) hosting environment. It came down to an incorrect SPN this time.

Service Principal Names (SPNs) and Delegation
For Kerberos double-hop authentication to work, you must have the proper SPNs configured and you must configure delegation for the computer account or service account that the service runs under. For CRM, this is the identity that your CRM web site’s application pool uses.

The SPNs you need to configure for Kerberos double-hop authentication to work properly are set up as follows:

setspn –A HTTP/servername:5555 domain\serviceusername_or_computername
setspn –A HTTP/servername.company.com domain\serviceusername_or_computername

If you configure the application pool to use an AD user account (service account) as its identity, you should use the name of that account in the above configuration. If you use Network Service, you should use the computer name (and you won’t need to prefix it with domain\). These commands add an SPN in Active Directory. You can also use ADSIEdit to configure this. Note that you need to use the port number for the short (NetBIOS) name version of the SPN but NOT for the FQDN version. This one got me recently.

Next, you need to allow delegation for the computer or service account using ADUC.

Incorrect or Missing SPN
You need to make sure that you have the correct SPN configured. Use setspn -L “computer_or_account_name” to list all SPNs for the service account and computer accounts.

Ex:
setspn -L CRMSERVERNAME
setspn -L Domain\service_account_name

In a recent troubleshooting experience, I had the port number added to the FQDN SPN and I got the following misleading error in the event log:

Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 1/20/2009
Time: 1:55:03 PM
User: N/A
Computer: ONCCRM01

Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/crmdiscoveryserver.domain.net. The target name used was HTTP/crmdiscoveryserver.domain.net. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (MSCRMHOST.NET), and the client realm. Please contact your system administrator.
For more information, see Help and Support Center at

All of the info I found while searching indicated that the problem was due to the next issue, Duplicate SPNs, when in reality, it was because Kerberos was looking for an SPN without the TCP port and I had configured it with the TCP port.

Duplicate SPNs
Duplicate SPNs can be difficult to resolve if you don’t know how.

Knowledgebase Article Windows 2000 Server Prompts Domain User for Credentials describes how to use LDP and Adsiedit.msc to troubleshoot and fix a duplicate SPN problem. When you run LDP, make your search string http/* to return all SPNs configured for web sites. You can narrow that down further to http/computername* if the former string yields too many results. Do the same for host/* and MSSQLServer/* just in case.

Event ID 11 — Service Principal Name Configuration
Note the important comment that the “setspn -X” option is only available in Windows Server 2008, not 2003. If you have Server 2008, this is much simpler than using LDP which can be daunting to those unfamiliar with AD and LDAP.

“Negotiate,NTLM” not configured on the web site and/or virtual directories
Your web site must have Negotiate/NTLM configured or the client and server will not negotiate Kerberos. This is the default setting but any number of things can change this configuration. The following article discusses how to configure this parameter using adsutil. I prefer to use the Metabase Explorer in the IIS Resource kit because it lets me see all of the configuration parameters and edit them directly. Either way will work.

Error message when you try to access the Microsoft Dynamics CRM Web site: “You are not authorized to view this page”


Keepalives not enabled on the CRM web site
Keepalives are turned on by default in IIS. If they are turned off, Kerberos will break. This is the most difficult issue I have ever had to troubleshoot related to the 401.1 error in CRM. I don’t know how it got turned off but the only thing that led me to the fix was to analyze the traffic with Netmon then use IIS Diagnostics to troubleshoot Kerberos. Use Metabase Explorer or adsutil to examine and change the keepalive setting.

Three Top Tips for CRM 4.0 Plugin Development

Guest Post: Three Top Tips for CRM 4.0 Plugin Development
by menno

Tip #1 Sign your assembly!
This is a step that's importance isn't made blatantly clear in the SDK documentation, but is absolutely key to the successful implementation of your plugin (and also makes a huge difference to debugging successfully as well). If you follow the "create a simple plugin" walkthrough in the SDK, it is listed as step 3 here: http://msdn.microsoft.com/en-au/library/bb955365.aspx.

The steps it describes are basically as follows:

Right-click your project in Solution Explorer and click Properties.
Create a new strong key file by clicking the Signing tab, select the Sign the assembly check box and select in the drop down list.
Type a name for your key and decide if you need to password your assembly enter the password here or if not, clear the Protect my key file with a password check box.
Click OK.
Save your changes by clicking the Save All button.
The screenshot below shows the Signing Tab & the Create Strong Name Pop up:


Alternatively you can use the sn.exe command line tool. Once you have signed your assembly, you will see a *.snk file listed in your solution explorer.

Tip #2 Register any Interops in the GAC
In my most recent project, I was working with some COM API's to integrate into the clients Line of Business Accounting System. Visual Studio is smart enough to build a COM Interop around any (registered) dll you wish to import, which is very handy - until you try to deploy your plugin to the CRM Server & it has no knowledge of the Interop you are referring to in your code.

You need to make sure that your interop dll is registered in the Global Assembly Cache (GAC) of the CRM Server. The first step you need to keep in mind is that to register your dll into the GAC, your assembly must be signed - so if you followed Tip #1 above you'll be fine! Once your assembly is signed, you can add it to the GAC in two ways, if your a fan of command line utilities, you can use the gacutil.exe command: gacutil /i MyComInterop.dll

I however tend to prefer the GUI tools provided, such as the .NET Framework 2.0 Configuration tool. To use this:

Select Microsoft .NET Framework 2.0 Configuration (CRM 4.0 uses .Net 2.0 by default) from the administrative tools menu
Select Manage the Assembly Cache
Click Add an Assembly to the Assembly Cache (The second option)

Locate your dll using the dialog window that appears and Click Open.
Tip #3 Use the Plugin Registration tool (in the SDK)
The registration of plugins in CRM 4.0 is made so much easier than it used to be in CRM 3.0 - mainly due to the Plugin Registration Tool that ships with the SDK & can be found in the SDK\tools\pluginregistration directory. Some good instructions on how to set it up & use it are listed here, so I wont waste time in repeating them.

What it doesn't mention is what you need to do if you update your Dll's. Initially I wasn’t sure if I had to delete & re-register them, or how to get CRM to recognize that I had updated my dll. If you spent any time at all writing callouts for CRM 3.0 or earlier versions, your first instinct is to stop services, copy over dll's and then restart the services. However you do not need to do this anymore (thank goodness)!

Using the Plugin Registration tool, you can simply:

Copy over your dll's in the server\bin\assembly\ directory
Select the Update option for the selected plugin:

Browse to the new dll file by clicking on the elipse on the update assembly window, and selecting your dll from the dialog window
Select Load assembly

Once the assembly has loaded, select Update Selected Plugins
You will receive a confirmation popup once the system is finished that confirms what has actually been changed
Click OK.
All this occurs without having to restart services - so is seamless to end users and a lot less painful than it was with callouts in CRM 3.0! I really love this change for developing plugins in Microsoft Dynamics CRM 4.0.

So thats it...
So there you have it, my three top tips for CRM 4.0 plugin development. These are the 3 things that I find when working with plugins are not highly documented, but can either save you a lot of time if you know about them - or give you a lot of grief if you forget them! I hope they help you.