The installation of Dynamics CRM 2011 in tightly controlled multi-domain Active Directory environments can be a real challenge. Dynamics CRM’s tight integration with Active Directory (AD) is a double-edge sword: having built-in Kerberos single-sign on (SSO) for end-users is a big win for organizations using the Microsoft AD for desktop authentication, but the extraordinary permissions required by the CRM Installation Wizard to setup the directory groups and create SQL databases can be difficult to collect in an enterprise-class environment. The easiest way to install CRM is for the installer to have Domain Admin in the AD and SysAdmin in the SQL Server, unfortunately in a large organization, it can be impossible to find a single person (or account) invested with such omnipotence. Fortunately you can specify groups that already exist using the command-line installation option and a configuration file. The Dynamics CRM Installation Guide has a description of the services, components and the four AD groups: ...

I’ve been watching the CRM Developer Toolkit since it was in CodePlex for CRM 4.0 and, while it had some nice features, it came at the price of requiring too many changes to my team’s methodology. With the most recent release in SDK 5.0.7 however, the toolkit has become a productivity enhancing add-on that I can’t live without. The CRM Solution template does a fantastic job of managing and deploying the Web Resources, Plug-ins, Workflows and Silverlight in my solutions. As great as it is, there are still a few pitfalls to watch out for so here is a list of do’s and don’ts when it comes to using the toolkit.   1. Only create Web Resources in CRM The developer toolkit makes it very easy to add new Jscript files to your solution, so you may be tempted to do so, but there’s a problem here. Visual Studio doesn’t know about your solution’s provider prefix, so that gets added to the Web Resource when you deploy. This makes your solution appear out-of-sync with CRM since the file name in Visual Studio remains ...