MSCRMKeyGenerator - Expired key

Yesterday I mentioned that I received a working backup of customer's CRM 4.0 system in a VPC. This morning, when attempting to load the CRM Web UI I was confronted with an error, which led to this information in the Application Event Log:

Source: MSCRMKeyGenerator
Event ID: 18949
Error (partial): Current active key (KeyType : CrmWRPCTokenKey) is expired. This can indicate that a key is not being regenerated properly.

The most common fix for this problem is to restart the Microsoft CRM Asynchronous Processing Service but the service wouldn't start for me. Phil Edry, my esteemed colleague here at Altriva, said "try Rollup 2... that might fix it".

I owe him a beer... it worked.

Exactly why the "active key" expired and what Rollup 2 did to fix it still remains a mystery to me, but I have too much work to do to investigate it now. If you have some more details on this, though, please let us all know. Thanks, -TD

Plugin Registration Tool FileNotFoundException

If you run into this error when attempting to register a plug-in...

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'PluginRegistration, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

... you might read elsewhere that you need to copy microsoft.crm.sdk.dll and microsoft.crm.sdktypeproxy.dll to the same folder as the Plugin Registration Tool's executable. Although that might work for you, it didn't work for me today. I'm working on a VPC with a customer's instance of CRM 4.0 restored onto it and attempting to register a plug-in led to the unhandled exception. (I tried version 2.1 and 2.2 of the registration tool.)

The "fix" was to load the PluginRegistrationTool.sln solution (Visual Studio 2005) and recompile. The application then allowed me to register the plug-in. It apparently found itself!? :-)

-Tim

Infragistics WebGrid and CRM 4.0

A common request I hear from our clients is for inline editing of data within grid views in CRM. Many of them would love to see this functionality in Dynamics CRM 5.0. Occasionally, though, one of our clients has a strong enough need for this capability (e.g., for rapid data entry, Excel-like functionality, etc.) and asks us to provide it.

On a recent project, I worked with a company to replace an Excel-based data collection process (where Excel files are distributed, collected, and consolidated) with a web-based application. The goal was to provide the same general capabilities provided by Excel (ease of data entry, grid-based interface, calculated fields, drop-down picklists, data validation, etc.) but provide it over the web and connect the application with the company's Dynamics CRM 4.0 system. And, of course, the page couldn't post back to the server after entering data in a cell so the use of Ajax was mandatory.



Our client had already invested in ASP.NET components from Infragistics for other projects so I downloaded the components and took a close look at the capabilities, particularly the Ajax, grid, and inline editing features. Fortunately, I became convinced that the components would meet the needs of the project very well so I proceeded with the application's design, estimates, and prototypes.

(Infragistics offers a 30-day trial of their components, so you can give them a test drive before forking over the thousand bucks.)

Downloading and installing the ASP.NET controls was simple. Being new to Infragistics components, though, I was initially tripped-up by their use of three names for their two grid products. Here's the deal: the "UltraWebGrid" and the "WebGrid" are the same product. This isn't at all obvious when first looking at the documentation. The "DataGrid" is the latest grid component, but we didn't use it due to its lack of support for hierarchical data (e.g., ADO.NET DataSet with multiple related DataTables).

To get started with the WebGrid, simple drag it onto the web form from the NetAdvantage 8.3 Web toolbox section in Visual Studio (we used Visual Studio 2005).

The easy way to get data to appear in the grid is to bind the grid to a data source. For example, you can use Visual Studio to create a DataSet that uses the ADO.NET SqlDataAdapter to query one or more CRM Filtered Views. The WebGrid provides a style editor that you can use to set inline editing rules, column widths, fonts, alternating row coloring, etc.

Connecting the WebGrid to a SQL query is fine for display purposes, but you can't (or shouldn't) write data back to CRM directly to the CRM database tables. So you won't get the "quick-and-dirty" benefit of binding the WebGrid to CRM because the grid won't be able to dynamically update the database when inline changes are made.

Although I had to write a lot of code to get data into the grid and write updates back to CRM, it was surprising easy to get all the parts working. The WebGrid provides a rich object model that allows you to configure and access all parts of the grid object, from the height, width, and overall style of the grid down to what should happen after someone types data into a cell.

Here's a screenshot of the application. I had to keep it small to protect the data (I'll try to upload a bigger data-wiped version later) but I mainly wanted to show the overall appearance of the grid and provide an example of the inline popup WebCombo control.




Here's a quick rundown of the architecture for this application:

• Upon application startup, I gather the default filter criteria from the filter options (e.g., date range, owner, etc.). The Infragistics date picker control came in handy for date filtering.


• I then pass the filter conditions to a method that dynamically builds the SQL WHERE clause for the main grid data. The data is stored in related DataTable objects. The WebGrid supports hierarchical datasets, so once you've populated the DataSet you can bind it to the grid and it takes care of rending parent/child rows.


• Once I have the data, I call a custom method to configure the grid columns. This involves setting the type of control for each column. Essentially, you can tell the grid whether a cell should provide a text field (with optional masking/formatting), a dropdown box, a WebCombo control, date picker, image, calculated value, etc.


• With the data in the DataSet and all columns configured, I then bind the data to the WebGrid. That gets the data on the screen, but that's only the beginning. The next part of the project involved writing a lot of JavaScript to handle the various actions that can happen in the grid. For example, when the user clicks into a cell, I sometimes want an Infragistics WebCombo to appear to allow the user to select from a popup grid.


• Saving data from the WebGrid back to CRM involves 1) Creating a Save button (turn-off the auto-postback functionality), 2) When Save is clicked, construct a DynamicEntity (it helps to have some wrapper/helper code for this part to build the SOAP) and set the name of the target attribute and its value, and 3) Use XmlHttpRequest to call the CRM Web Service with either a Create, Update, or Delete command in the SOAP XML.

One of the biggest challenges I faced on the project was using Ajax to dynamically filter the contents that appear in the Infragistics WebCombo objects used in the grid. For example, when the user selects an option on a parent row, I needed to filter the available options in the WebCombo for a cell that resides on a child row. The way I did this was 1) Create a JavaScript event handler for when the user clicks into a cell that needs a filtered combobox, 2) Formulate a CRM SDK query and use Ajax to get back a collection of CRM entitiese, 3) Clear the contents of the WebCombo that's linked to the clicked cell, and 4) Use the Infragistics WebCombo API to dynamically create option rows.

Infragistics provides an abundance of online samples, knowledge base articles, and sample applications to help you ramp-up on their controls.

All in all, the Infragistics ASP.NET controls provided us with a great collection of tools to provide an Excel-like interface for our client. They can now update CRM data from a web grid, which provides them with the rapid data-entry interface that they needed.

CRM 4.0 Development Tools

Here's a list of freeware development tools for Dynamics CRM 4.0 that you might find useful. Thanks to all of the authors and publishers of these apps!

• CRM 4.0 Diagnostics Tool - Exports server and CRM details to file. It's a good idea to run this periodically and keep backups to help with system troubleshooting.
  
• CRM 4.0 FetchXmlWizard (stunnware) - Helps build source code to call the CRM SDK. This was written for 3.0 but it still (mostly) works for 4.0.
  
• CRM 4.0 Form (Entity & Attribute) Reporter - Builds a Word document from exported CRM customizations.
  
• CRM 4.0 JavaScript Export Tool - Exports JavaScript (JScript) from forms. This is especially helpful for keeping track of code changes in a source control system.
  
• CRM 4.0 Metadata Viewer (stunnware) - Browse CRM metadata including entities, attributes, data types, relationships, etc.
  
• CRM 4.0 Trace Log Viewer (stunnware) - Helps with viewing CRM trace log files.

Please let me know if there's a tool you've found useful that's not on this list. Thanks!

Success with Microsoft Dynamics CRM 4.0

Altriva has kept me very busy since joining them in October '08. My first project for them was a CRM 4.0 new deployment for a large manufacturer in the Seattle area. There are 12 users up and running on the system now and they're enjoying the increased information and productivity the application provides.

The group that I worked with are responsible for providing support to their worldwide dealer network. They can now access information that was previously difficult to come by such as each dealer's employee hierarchy, current and past service cases, a record of all correspondence, inventory information, and a knowledge base.

Besides helping to build requirements, installing and configuring CRM, and working with IT on architecture decisions, I also had fun (really!) working with SQL Server Integration Services (SSIS) to feed the company's master dealer information into CRM. This integration (well, ETL process actually) is scheduled to run each night using SQL Agent. The SSIS package queries from a SQL 2000 database and calls the CRM 4.0 Web Service to insert or update dealer information in CRM. The article written by CRM MVP Darren Liu helped a lot to put this integration together.

While I was working on that project, there were three people around the office that were diligently working to finish the book Success with Microsoft Dynamics CRM 4.0.

After working with several others in the past who have written a technical book (or started one) I've come to recognize that it takes an enormous amount of discipline, depth of knowledge, caffeine, understanding family members, and ability to get by with little sleep to plan, write, and finalize the content for a book like this. Watching these otherwise friendly clean-cut guys turn into disheveled and mumbling animals was not pretty to see, but they're back to normal again and we'll all be more successful with our CRM deployments because of their insanity.

Dynamics CRM 4.0 Quick Reference

When I've been in CRM design meetings, writing code, working with a new client, or helping someone ramp-up on CRM 4.0, I always thought it would be helpful to have a "CRM 4.0 Quick Reference" handy. I've had to rely on the reference between my ears, which isn't always reliable.

So I got up early a few days last week and put one together.

Now, I realize the content I find most valuable in a Dynamics CRM 4.0 Quick Reference is not necessarily the content you would've chosen. So, if you send an e-mail to me at tdutch@gmail.com I'll send the Word version of the document to you. You can then start with what I've done and tailor it to meet your needs. Of course, it would be great if you share your version with the CRM community as well!

Here's a list of the major sections I've chosen for version 1.0 of the quick reference:

Page 1

• What's New in 4.0 ("Titan")


• Selling Points


• Major Product Components


• CRM 4.0 Server Editions


• Deployment Scenarios


• On-Premise Requirements


• Importing Data


• Unsupported Customizations


• Integration


• Performance and Scalability


• UI Customization (ISV.Config and SiteMap)


• Miscellaneous


• Reporting Options


• Workflow


• Outlook Client


• E-mail Functionality


• Core System Entities


• Asynchronous Service

Page 2

• Forms and Controls


• SDK


• Accessing CrmService (Sample Code)


• IPluginExecutionContext Interface


• Technologies


• Plug-Ins (Plugins)


• Workflow Assemblies


• Entity Relationships

Enjoy!

High-level tasks for a Dynamics CRM 4.0 project

In a previous post, I listed many of the technical skills that a Dynamics CRM 4.0 implementation team likely needs to possess in order to design, code, deploy, and support a truly useful and rock solid system. In this post, I'm going to share some thoughts on the roles and tasks that go into successfully launching a Dynamics CRM system.

On my CRM projects over the years, I've worn the hat of most of the project role members you'll see below - sometimes many of them at the same time. On a CRM deployment with only 10 users, I was the sole contributor - from business analyst to C# developer and everything in between. But most often I've worked on a 2-5 member team, with the largest deployment coming in at 500+ users.

Let's take a look at the hats that you might have to wear on your next project by stepping through the high-level tasks of a Dynamics CRM 4.0 project.

Needs Assessment

Goals and Tasks:

• Gain a thorough understanding of the needs of the stakeholders and their business and end-users.
• Identify and meet with key business stakeholders and domain experts. Ask lots of questions and write down every answer.
• Create and distribute documentation listing the project vision, scope, risks, and assumptions.
• Understand and communicate the project scope. What's in and what's out?

Team Members:

• Business Analyst
• Project Manager
• Senior Developer

Just a thought... Isn't it awesome at this stage of the project to know that, with Dynamics CRM 4.0, you can deliver an extremely robust CRM or line-of-business application for dozens or hundreds of users in less time than it takes an average IT shop to decide between .NET vs. Java or thick-client vs. browser-based? Think about it... you're out of the gate with a solid and proven enterprise software architectural design including role-based security, web services API, metadata-driven UI and business object engine, customization tools and much more without writing a single line of code. Now, designing business objects, writing plugins, creating SRS reports, and integrating the system with other systems takes time and skill, but the point is that you can focus much more on the needs of the business and less on how you're going to provide e-mail templates, workflow, or hundreds of other features -- because many of them are already ready to go! Anyway, just a thought...

Project Plans

Goals and Tasks:

• Define the work that will be done on the project and who will do it. This typically involves creating a statement of work (SOW), requirements specification, use cases, test and defect tracking plans, a list of resources and their availability, a work breakdown structure (tasks and time estimates), and a project schedule.
• Requirements Elicitation: Gather, understand, review, and articulate the needs of the system's stakeholders and users. Observe current business processes, interview users and stakeholders, and distribute summaries for verification.

Team Members:

• Project Manager
• Test Lead

Dynamics CRM 4.0 Implementation Plan

At this point, you should carefully read the Dynamics CRM 4.0 Implementation Guide to gain an understanding of Microsoft's recommended approach to planning, designing, configuring, customizing, and deploying a CRM 4.0 system. However, as lengthy and detailed as the Planning and Installation Guides are, they don't cover many of the real-world project topics such as setting up and using a defect tracking system, utilizing a source code repository, or conducting system testing. I'll cover these topics below.

Team Members:

• Project Manager
• Development Lead
• Test Lead

Project and File Management Tools

Below are some of the tools I put in place before starting in on a Dynamics CRM 4.0 deployment.

• Requirements Management: Ideally, system requirements should be maintained in a system that's accessible to all project team members and stakeholders. In the past, I've used the customer's Dynamics CRM system (in a stable environment) for this purpose. I created a custom "System Requirements" entity and added attributes such as requirement name, id, description, priority, time estimate, key stakeholder(s), questions/answers, requirement elicitation status, implementation status, etc. If it's not possible for you to utilize the CRM system for this purpose then Excel (maintained in SharePoint, of course) works well, too.
• Version Control: It's essential to set up a version control system (such as Microsoft Visual SourceSafe) to safely store and track documentation, source code, exported CRM XML-based customization files, and other system artifacts. Also, assign someone the task of making backups of the file repository and keeping a copy off-site (if allowed by the company).
• Defect Tracking: Given the ease of customization in Dynamics CRM 4.0, you could utilize the "test" system for tracking defects. However, if this is not practical or possible then you'll find several excellent choices for logging and tracking the status of system defects. Systems that I've used in the past (that I've liked) include FogBugz and Jira.
• Automated Builds: If your CRM 4.0 deployment includes plugins, custom ASP.NET applications, Windows services, or other compiled code, consider taking the extra time to automate the compilation and deployment of all software components. Tools such as MSBuild and NAnt help make full automation of builds and deployment a reality. The benefits of this type of automation are that you don't have to build and deploy manually hundreds of times (thus saving you lots of time in the long run) and you'll end-up with fast and consistent deployments.
• SQL Server Backups, scheduled at least daily. Backing up the CRM databases will not only preserve your hard work designing entities and attributes but will also store the hundreds of lines of JScript you've no doubt written for your project. Needless to say, this is a critical task that should be scheduled and verified at least once per day.

Team Members:

• Project Manager
• All Developers
• All Testers
• System Stakeholders

System Configuration and Customization

Note: This section is incomplete. I'll fill-in the details here soon.

• Entities and attributes
• Forms: layout, data validation, JScript code, dynamic picklists, tabs, views
• Navigation: SiteMap, isv.config
• Security Roles
• E-mail: inbound, outbound, tracking, templates
• Reports
• Workflow
• Plugins and workflow assemblies
• Custom applications: ASP.NET, IFRAME, ISV folder
• Systems Integration
• Outlook considerations: customizations, offline/online

Testing

Goals and Tasks:

• Make sure that the system does what the users and stakeholders want it to do and as agreed upon in the SOW and requirements documentation.
• Execute the test plan. Log all defects.

Many more project details coming soon... please check back for an update to this posting.