Chapter 2 briefly discusses setting up and testing your application across different environments. The same testing strategy holds true for your deployment scenarios. You should always test and validate your solutions against the supported configurations that Microsoft CRM customers might be running. If you don’t test your solution against one of these configurations, you need to communicate that caveat to your customers.
Never assume that Microsoft Dynamics CRM and its dependent services will be set up on a single computer. Always assume scale-out and multirole deployments. Use the following checklist for testing the topological compatibility of your application:
Single-box deployment. Microsoft Dynamics CRM and SQL Server are on the same computer.
Two-box deployment. Microsoft Dynamics CRM and SQL Server are on separate computers.
Three (or more) box deployment. Microsoft Dynamics CRM servers are network load balanced (NLB) and SQL Server is on a separate computer.
Multi-role. Load-balance the Microsoft Dynamics CRM Web servers on multiple computers. Further separate the API server, the Microsoft Dynamics CRM asynchronous processing server, and SQL Server onto different computers.
Reporting server. Test reports with a Reporting Services computer separate from the SQL Server computer and the Microsoft Dynamics CRM server.
Microsoft Dynamics CRM supports four different operating systems (two for the Outlook client and two for the server). All operating systems also come in 32-bit and 64-bit versions. Use the following checklist to ensure that your solution works with the correct operating systems:
Client. Windows XP-SP2 32-bit
Client. Windows XP-SP2 64-bit
Client. Windows Vista 32-bit
Client. Windows Vista 64-bit
Server. Windows Server 2003 32-bit
Server. Windows Server 2003 64-bit
Server. Windows Server 2008 32-bit
Server. Windows Server 2008 64-bit
Microsoft Dynamics CRM supports two Web browsers: Internet Explorer 6.0 and Internet Explorer 7.0. You may want to have your custom code detect the HTTP_USER_AGENT of a user’s browser and redirect to an error page if an unsupported browser is used.
Microsoft Dynamics CRM 4.0 supports both Microsoft SQL Server 2005 and SQL Server 2008 as its database and reporting catalog (SQL Server Reporting Services). You need to test against specific database servers only if you implement your own database or queries. If you build custom reports, you may want to test compatibility with SQL Server 2008 Reporting Services in addition to SQL Server 2005 Reporting Services.
It’s easy to cut corners and write your custom code so that it only supports Integrated Windows Authentication. However, many customers deploy Microsoft Dynamics CRM in an IFD environment, and your code should accommodate both authentication scenarios, especially if you are developing a third-party solution or add-on. Also, if your organization isn’t using IFD today, don’t assume that it won’t want to deploy it in the future.
For plug-ins, you should be using the ICrmService interface for all calls back to CRM. This interface is already authenticated and shouldn’t present any issues with Windows or IFD.
If you’re using the Enterprise edition of Microsoft Dynamics CRM, you can configure multiple organizations for a single deployment (multi-tenant). When you create your custom code and deploy it, you must carefully consider the security between organizations in a single deployment. As a general rule one tenant should never have access to the data managed by another. This is to protect the data of customers in shared hosting situations (Microsoft Dynamics CRM Online, Hosting Providers, or IT departments). Be sure that you test the following two situations with your solution:
Solution is configured for the Default Organization only. Other tenants are present on the system.
Solution is configured for the non-Default Organization. Other tenants are present on the system.
You may choose to mandate one or more languages for your solution. If this is the case, your configuration code should check for these with the RetrieveAvailableLanguages message.
The following suggested test scenarios will help ensure that your solution is functional in multilingual configurations:
Solution Base Language = Organization Base Language.
Solution Base Language <> Organization Base Language. However, the Solution Base Language is provisioned and active on the organization.
Solution Base Language is not installed on the organization.
If appropriate, you should also test your solution for accessibility. Just as you test for environmental compatibilities, you should examine the strengths of your application with respect to accessibility. Many companies and government agencies mandate certain accessibility features in the software products they buy. Work with your customers to understand these requirements in detail.
Windows High-Contrast mode is a special mode used by visually impaired users. It can be activated using the accessibility features in Windows. Windows users operating in this mode will also modify their Microsoft Dynamics CRM user profiles to optimize Microsoft Dynamics CRM’s Web pages for high contrast. It’s easy to overlook the high-contrast performance of your application because—many developers don’t even know the setting exists!
High-contrast mode for Microsoft Dynamics CRM is turned on on the User Settings page, as shown in Figure 9-8.
In Windows Vista, turn on High-Contrast mode in Control Panel and then activate it using left Alt+left Shift+Print Screen, as shown in Figure 9-9.
Figure 9-10 shows Microsoft Dynamics CRM on High-Contrast Windows without optimizations. As you can see, not all of the icons appear on the screen.
Figure 9-11 shows Microsoft Dynamics CRM on High-Contrast Windows with optimizations.
As you can see, all the elements appear in the Web user interface when it is aware of high contrast. Be sure to test your custom solution in these modes and fix any portions of your user interface that aren’t displaying correctly.