Due the overwhelming success of the first Dynamics CRM Incubation Week, Sanjay Jain and Microsoft will be holding the event again. This time, it will be at the Microsoft Technology Center in Boston, MA during the week of April 20th. I will again have the opportunity to participate as an advisor helping start-up companies build out their visions using the Microsoft Dynamics Platform.
If you are interested in the event, please visit Sanjay's blog and nominate your team and ideas!
One of my colleagues, Kris, came across an odd occurrence with a client. Apparently, all of our custom ISV.Config settings were not displaying in the Web interface for some users. We checked the settings (we had selected that they display in the Web) and the user's computer and couldn't deduce initially what the problem was. After some iterations with CRM support, we determined the source of the problem...our old friend, the CRM cookie and its interaction with the Outlook CRM client. Apparently, the ISV.Config configuration of Outlook overrides the Web's configuration. In our specific example, we configured the ISV buttons to display only for the Web client. Since our user had the Offline Outlook client installed, the buttons didn't show even when she accessed from the Web.
After we corrected the situation with our user (see below for some possible fixes), we did some more testing internally. Thanks to Neil, another fantastic Sonoma colleague, we came up with the following matrix of test cases and whether the buttons displayed or not:
Note: The display is referencing the grid and record-level buttons and settings. The application level menu always seemed to correctly display in each test case.
The cells highlighted in yellow are ones that the behavior of the application doesn't match the configured settings, thanks to the sharing of the cookie. As you will see, when Outlook is open, the Outlook setting drives the display.
So what are your workarounds? Here are a couple...
- Use a different URL (such as an alias or fully qualified domain name) for the configuration of Outlook than what you use when accessing from the Web. Then, Outlook and IE won't share the same cookie and all is well.
- Add all of options (the settings Web Application, Outlook, Outlook Offline) and then it will display no matter what. This might be less desirable as you would have possible buttons/links displaying in Outlook (or the Web) when you don't want them to, but this is better than not showing at all!
What confused us with the original case was my incorrect assumption that the Offline Client setting pertained to the state of the Outlook client (ie whether the user was online or offline). Apparently, this setting applies to the Offline Client itself. Since it seems to be more useful for this setting to be targeted for the state of the offline client, I am hoping this might be changed (or added) in the next release of CRM.
We recently received an e-mail from a gentleman who was having trouble publishing a workflow rule from our Advanced Workflow Programming chapter from our recent Programming Microsoft Dynamics CRM 4.0 book. This chapter showed how to create custom declarative WF XAML workflow rules and install them within Dynamics CRM 4.0.
While this technique was never officially supported, early SDK documentation existed that demonstrated how to create custom WF XAML workflow rules and install them to Dynamics CRM 4.0. Further, multiple books (including ours) helped to further demonstrate the power of WF within CRM.
However, sure enough, we tried out our example this week and discovered the same "Workflows created outside of CRM are not supported" error. The only change that we noticed was that our system was now on Update Rollup 2 (as was the system of the individual who originally e-mailed me). I checked with the product team and apparently this ability was disabled with Update Rollup 1 due to some stability issues. We generally used the more customary workflow activity assembly approach in most of our implementations, so we hadn't yet noticed this change with the rollup installation.
So, I am sorry to say that at this time you will be unable to create custom declarative WF rules, even in an unsupported state, if you install any of the CRM rollups. For on-premise and partner hosted deployments, you will need to continue to use custom workflow activities approach. For Dynamics CRM Online, your workflow rules will be limited to what the workflow editor from CRM user-interface allows.
(Note: this post also appears on the Microsoft Dynamics CRM Team blog)
One of the GREAT new features in Microsoft Dynamics CRM 4.0 is the ability to get pop-up reminders in Microsoft Outlook for activities created in CRM. Our company Sonoma Partners uses Microsoft CRM on a day-to-day basis for our own sales, marketing and service and we have a lot of workflow automation setup on our customer records to automatically create follow-ups activities such as tasks and phone calls. By default, Microsoft CRM will create reminders for every record it syncs into Outlook that has a due date. Consequently, a large number of customer records and a large number of automated activities means a large number of pop-up reminders!
Personally, I have found that sometimes these reminders were a bit too much for me and I found myself wishing I had less pop-ups. This is especially true if you don’t include the customer’s name in the activity subject because otherwise you will see a reminder dialog that looks like this (not terribly useful because all the records look identical).
Fortunately, I picked up a neat little registry setting trick from former CRM Product Manager Michael Lu. By adding the registry setting OutlookSyncDisableTaskReminders to your client computer (not the server) at HKEY_CURRENT_USER/Software/Microsoft/MSCRMClient and setting its value to 1, the Outlook client will not create reminders on activities it syncs into Outlook.
This solution won’t work for everyone, but I find that it works pretty well for me.
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-install Windows to correct them. Only administrators will have the necessary permissions to perform this modification. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use the Registry Editor at your own risk.
A nice article exists to help you make the client-to-server communication with Dynamics CRM 4.0 more secure. A section configuring IFD and SSL can also be found in this article.
We followed the Configure Microsoft Dynamics CRM client-to-server communication for Internet-facing deployments section in this document with one of our hosted clients. We setup IFD, SSL, and enabled the Require SSL check box in IIS. Once we enabled that checkbox, we discovered we had authentication issues with plug-ins. Upon debugging further, we found the plug-ins were receiving the following service Url from the plug-in context:
Since the https port was really 443 in this case, we were getting an error. We played around with the settings and once we updated the LocalSDKPort value to 443 and the plug-ins started working again.
So, if you find yourself with this problem, ignore the bolded part in step 5 and continue to update the LocalSDKPort with your SSL port as the rest of the step describes.
5. If the Microsoft Dynamics CRM Web site is configured to use the default http (80) and https (443) TCP ports, you do not have to modify the LocalSDKPort registry subkey value, and you can skip this step.
As most of you know by now, Microsoft CRM Support has released Update Rollup 2 for Dynamics CRM 4.0. Here are some quick findings that we have discovered that I hope can be useful for some of you.
Exporting and importing customizations
Update Rollup 2 made some schema changes to the customizations and the rollup documentation provides a general warning about only export/importing customizations from system with the same rollup installed. This approach is painful for our development environment and for ISVs, as it is not easy to guarantee that all customers will be on the same rollup. What I learned from the product and support teams (and confirmed with some quick testing) is the schema changes to the customization file in UR2 is confined to just Templates and Outlook Synchronization areas.
Therefore, if you need to import/export between different rollup deployments, you should be ok provided you excluded those two customizations from your file.
I am hoping that CRM Support will be more specific with the customization schema changes on future rollup releases, or better yet, allow them to be backwards compatible between rollups.
Manually configured steps
There are a number of hotfixes that require manual configuration. I didn't see these documented too well (although I could have missed it). Anyway, here is a list that we have discovered. Note that this could just be a partial list.
- 955452 (http://support.microsoft.com/kb/955452/ ) Line feeds are not used when you send an e-mail message that uses an e-mail template to render data that has line feeds in Microsoft Dynamics CRM 4.0
- 955745 (http://support.microsoft.com/kb/955745/ ) Error message when you try to configure the Microsoft Dynamics CRM 4.0 client for Outlook: "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms"
- 956527 (http://support.microsoft.com/kb/956527/ ) The Microsoft Dynamics CRM client for Outlook consumes three times as much memory in version 4.0 as in version 3.0
- 959248 (http://support.microsoft.com/kb/959248/ ) Microsoft Dynamics CRM 4.0 slows to unacceptable levels when you process e-mail messages by using the Microsoft Dynamics CRM E-mail Router
- 957871 (http://support.microsoft.com/kb/957871/ ) The Workflow Expansion Task records cause the AsyncOperationBase table in the MSCRM database to grow too large in Microsoft Dynamics CRM 4.0
- When you install any rollup, it will affect the entire deployment. For those of you that leverage multi-tenancy (as we do in our client development environment), you need to be aware of this and plan the release accordingly. Pay special care to the customizations changes and quickly review each hotfix within the rollup to ensure there won't be compatibility issues with your custom code. Naturally if your custom code follows the supported SDK, you should be ok from rollup to rollup.
- Update Rollup 2 may screw up your existing CRM web.config. I recommend you make a backup of the CRM web.config file prior to running the rollup. Here are two errors we have seen:
- Publishing workflow rules fails. This error is now documented in the release notes. You need to update the CRM web.config files and add the following line to the <authorizedTypes> section:
<authorizedType Assembly="mscorlib, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.Globalization" TypeName="CultureInfo" Authorized="True"/>
- We had our IFD settings wiped out from the CRM web.config. To correct, we used the IFD tool to reset the values.
- Microsoft recommends that you keep the update rollups between the Outlook client and the CRM server in sync. I am not sure this is always a hard requirement, as we have some internal Outlook clients on the latest rollup, prior to updating our server. This is something you can test, if rolling out to your Outlook clients users is not always easy to do.
- Each rollup *should* be cumulative. This means that you can install UR2 on a system that hasn't been patched with UR1.
It looks like Microsoft re-released the Update Rollup 2 hotfix and it *should* address some of the web.config issues noted above. Check out the MSFT blog post for more information.
We recently had the opportunity to collaborate with the Microsoft Product Team with two fantastic utilities, and I am happy to say they are now finally available! The two tools are:
- Customization Comparison Utility
- Configuration Data Utility
Customization Comparison Utility
The Customization Comparison Utility allows you to take two exported customization files (either xml or zip) and display all the differences between the files. You can review any two valid customization files and also export the results to Excel for additional analysis or documentation needs. Similar to many source control systems, the tool displays to you the following:
- What is identical between the systems
- What has changed between the systems
- Exists in the source system, but not the target
- Exists in the target system, but not the source
This tool can be extremely handy when reviewing or validating a system for changes or alterations from a base or development system prior to importing a new set of customizations. Independent Software Vendors (ISV) can use this tool to help manage their version releases to existing clients' systems. However, anyone using Dynamics CRM 4.0 with multiple environments (such as development, staging, and production) can quickly and easily log the differences between those environments for planning, troubleshooting, and documentation purposes. And since the tool merely looks at the customization files, it works for all deployment models, including CRM Online!
Configuration Data Utility
In most of our implementations, we use the power of Dynamics CRM entity extension capabilities to create configuration-based entities. This allows our clients to configure their system with data instead of requiring expensive and time-consuming code changes. One of the current dilemmas of this approach is when you need to apply your configuration data from one environment (such as development) to another environment (such as testing or production).
The Configuration Data Utility allows you to quickly and easily transfer configuration-based data in one Microsoft CRM organization into another organization with a few simple steps. The utility steps you through a set of wizard steps that has you select the custom entities that contains the configuration data you wish to export. Once complete, the utility will create a single data file with the exported data, ready to imported into the destination environment.
When importing the data, if the application finds records that already exist in the destination system, it will simply update all of the information in the existing record. If data is in the destination system but does not appear in the Export Data File, the record will not be changed in the destination system. Lastly, if relationships to other records exist in the imported data, the application will first resolve by GUID and if no matching GUID is found, it will resolve by the primary attribute of the related entity record.
Also note the following:
- The entities in the destination system must have the same schema as the source data system.
- You also have the opportunity to save this configuration file to be reused, saving you additional time for repetitive exports/imports.
- The tool preserves the source system's record id (GUID), which comes in convenient when referencing entities in Workflows rules.
- This utility IS NOT a replacement data migration tools and options out there. It is meant to migrate basic data setup between environments.
- The import tool can be run in command-line mode, making it usable for installers as well.
- At this time, the export/import tool is available for on-premise deployments only. However, since you have the source for this tool, you can quickly convert it for CRM Online.
These tools can be run on any machine (i.e. doesn't have to be the CRM server) that has .NET 3.5 installed and access to the CRM environment. Each tool contains a full users guide (currently located within the main project folder). And as mentioned briefly above, Microsoft also provides the source code for each of these utilities, allowing you to further extend them to fit your own needs!
While these tools were developed with ISV's in mind, they are extremely valuable for anyone implementing Microsoft Dynamics CRM 4.0. We have been using both internally for a few months now have been extremely handy numerous times.
Feel free to download these tools at: