Way back when CRM 1.0 came out, we embraced email enabled queues as a key responding to our clients support requests. By replacing an email distribution list with a queue we eliminated the problems we often had where two or more people would start responding to an issue at the same time. Now the first person that can work on the issue takes it off of the queue.
However queues introduced a new problem for us. When we used a distribution group everyone knew about the problem immediately. With queues we had to remember to go check the queue regularly to see if anything was in it. To get around the problem we created a small Windows application that installed on each workstation and then popped up a message indicating how many items there were in each monitored queue. This worked pretty well for us until we started upgrading to Vista. We had purchased a specific VB control to pop up the message and that control would not work with Vista.
We decided to start over and embrace the new world of Vista Gadgets. In keeping with our original design, we opted for a two tiered solution with a dedicated webservice on the CRM server and code in the gadget that consumed data from the webservice. The gadget let someone see how many items are in a particular queue without having to open CRM or jump to the Queue area under workspace.
The VS 2005 solution for the webservice and all of the files to recreate the gadget are attached to this post. We consciously hard coded URLs in the javascript for the gadget because it is easier to edit the file and distribute the gadget with the URL set than it is to have each user set the URL when they install the gadget. Therefore you will have to follow the provided instructions to recreate the gadget file.
Richard Riddle, our lead CRM developer did all of the coding on this one. We hope you find it useful.
One of the reasons I have not been posting in a while is that we have been very busy trying to resolve some lingering issues at one of our CRM installations. We have been working with Microsoft over the past 6 months trying to clear up some Outlook performance issues as well as some related email issues when using the CRM Address Book provider.
It has taken a long time to isolate the issues and frankly my commitment to the Dynamics CRM platform was shaken for quite some time. I think Microsoft if is paying attention and being dillegent is addressing the problems and we are starting to see some hotfixes that address the specific issues we have been trying to resolve.
MS KB 938547 should be public within the next few days at http://support.microsoft.com/kb/93847. This KB provides a hotfix that you will have to call in for. Don't bother calling for the hotfix until the KB link above is working. This hotfix requires that CRM Update Rollup 2 be installed on the system.
I'll let you know how our testing of this hotfix goes.
I hope to have news of other hotfixes soon. One of our major issues is sending email when using the CRM Address Book Provider. We have received some preliminary hotfixes but they have not fixed the underlying problem. As best as we can determine, the problem seems to only occur when using Outlook 2003. We cannot reproduce the problem with Outlook 2007. When the final fix comes out I will let you know.
This just in. Microsoft has released its Daylight Savings Time update strategy for Microsoft CRM. If you thought you were all ready for the DST change that is happening in the US on Sunday March 11, 2007 think again!
Give yourself time to digest the 27 page document explaining how to make the changes to the system and data. You can dowlnoad the necessary files here.
I've been struggling with how to standardize synchronization settings for the CRM Outlook clients at one of my customer sites. After playing around with scripts I decided to take a look at Group Policy. I am not expert on Group Policy but I was able to find some great guidance in Group Policy, Profiles, and Intellimirror for Windows 2003, Windows XP, and Windows 2000 by Jeremy Moskowitz (Sybex Press). After reading up a bit on creating custom Group Policy templates I decided to give it a try.
The result is a basic template that allows an administrator to standardize the registry settings that affect how the CRM client for Outlook behaves on a client computer. If you are interested in using this template, it is attached at to this post. You can also download it at http://www.mscrmfaq.com/files/mscrmclient30.zip. As always this file is released as is.
It turns out the the CRM client for Outlook is not really Group Policy compliant because the registry settings it uses do not exist in the proper area of the registry. The template I created is actually applying "old style" NT preferences as opposed to policy. The major difference is that when a true group policy is removed, the registry settings on the affected machines are also removed. When an "old style" policy like this one is removed the registry settings on the target machines are not changed. So a word of caution here, any changes you make using this template will permanently overwrite registry settings on the target computer. Take a moment to understand what the current settings are on your systems before implementing this template.
To use this template unzip the file and then copy the MSCRMClient30.adm file to the C:\Windows\inf folder on the machine you are using to manage group policy. Open GPMC and create a new policy linked to an OU. Edit the new policy and then add the new template as follows:
- right click the Administrative Templates folder under the User Configuration and select Add/Remove Templates.
- Click the Add button and then locate the MSCRMClient30.adm policy file and click OK to save.
- Click Close on the Add/Remove template to finish adding the template to the policy.
- Make sure the Administrative Template folder is still selected and then select the View -> Filtering option from the MMC menu bar.
- Uncheck the "Only show policy settings that can be fully managed" check box and click OK. (You will need to do this each time you want to edit the policy.)
You will now see a folder under Administrative Templates named Microsoft Dynamics CRM 3.0 Client for Microsoft Outlook with various policies in sub folders.
I've been doing a deep dive into the effects of the security model. I recently noticed that the UI does not support sharing of activities to users or teams. This came as an unfortunate surprise because I was planning on "sharing" to be my way out of a tricky situation concerning visibility of activities between business units.
Imagine a scenario with three business units: Executive, Finance, and Staff where Executive is the parent business unit to both Finance and Staff. The security roles in use all allow organizational read for accounts and contacts but only deep read access for activities. The organization President and VP are members of the Executive BU, the CFO and accounting pros are members of the Finance BU, and the marketing, sales, and service folks belong to the Staff BU.
With this basic setup everyone in the company can see any account or contact due to the organizational read privilege. The President and VP can see any activity because they are at the top and have deep read privilege on all activities. The people in the Finance BU can see each others activities due to the same deep read privilege. The same is true for people in the Staff BU. By design people in the Staff BU cannot see activities owned by members of the Executive and Finance BU and members of the Finance BU cannot see activities owned by members of the Executive or Staff BU.
Now the problem is that sometimes the President is communicating with a CRM contact and may make a deal with the contact that others in the company need to know about. However the security roles don't allow this. My first thought was all you need to do is share the activity out to other users and they could see it, but as I stated earlier that is not an option.
In turns out that CRM is smarter than I thought about activity visibility. When an activity is linked to a record using the Regarding field, the owner of linked record inherits visibility to the activity. Therefore they can see the activity even if their native security role would prevent it. It is important that this only applies to the owner of the linked record not everyone that has visibility of the linked record. It also turns out that you can take this one step further. If you share access to the linked record than anyone that you granted shared read access, will also be able to view any activities linked to the share record.
One other side note - this inherited visibility does not apply unless the activity is linked via the Regarding field. Linking through the activity parties as sender, recipient, organizer, etc does not make the activity visible to the owner of the contact or account record. Therefore if the President emails a contact owned by a Staff member the Staff member cannot see the email unless the President explicitly links the email to the contact in the Regarding field.
We recently updated our CRM solution for automatically creating recurring service cases. We use recurring service cases to automatically schedule items for our customers that have signed up for managed services or that are under some form of retainer.
I originally implemented this in CRM 1.2 using CRM using special products in our CRM product catalog to represent each service offering. For example we had a product item the corresponded to Server Patch Management and another that corresponded to UPS system check, etc. Each product was related to a maintenance item that was defined in an XML configuration file. The maintenance item contained all the information need to create a service case as well as scheduling information (e.g. 1st and 15th of the month, 2nd Tuesday of the month, 90 days since last completion, etc.)
I created an ASP.NET web service that contained the code to make it all work. When the web service was called it would look through all active CRM Contracts and examine each contract line item to see if the contract line item was for one of our recurring maintenance tasks. If so the code determined if it was time to schedule a new service case and created the case if required. A simple VBScript executed by the Windows scheduler (an often overlooked tool) called the web service daily. It wasn’t elegant but it worked for almost a year and ensured we did not drop the ball on our contractual obligations.
Custom entities in CRM 3.0 have really allowed us to refine this solution. Richard Riddle, one of our CRM developers, took what I had started with and helped me make a much richer and more robust product. We made significant changes in the architecture of the solution by removing all of the complexity of the XML configuration files and placing all of the information on scheduling and product catalog relationships in a new custom entity that we call Maintenance Items. We also implemented the concept of a template service case that makes it much easier to control what information goes into the service cases that are scheduled automatically. Lastly we replaced the ASP.NET web service and Windows schedule with a new Windows Service.
The new system is much easier to configure and gives us greater flexibility. For example we can now have several recurring services associated with one product SKU. This makes it much easier to package our services in the product catalog and makes our CRM Contracts much more readable. So with a little code and a custom entity Microsoft CRM is now capable of scheduling an unlimited number of recurring service cases based on the contracts we negotiate with our customers.
We have been working on a project that requires harvesting data from a public facing web form. This is a pretty basic request but in the past we've only been asked to do this for lead capture and we have generally specified using the C360 web capture tool as a very effective tool for capturing lead data and either relating it to an existing contact or lead or creating a new lead.
However with this project we have to capture data that updates an existing contact or creates a new contact (C360 currently doesn't support this). We also have to create a custom entity using some of the captured data.
Our first thought was to build a custom web form using ASP.NET and have it connect to the target CRM system using web services. However, we were concerned about three things. First we could not always guarantee that our CRM server would be on line (even the best systems need patching etc.) , the number of hits/second at the public web form could be very high, perhaps higher than the target CRM system could process synchronously and provide a good user experience, and we had no guarantee that the public web server could support ASP.NET.
We decided to make a generic web capture system based on parsing email sent from a web form. Emailing web form data is a basic capability of most hosting platforms so this seemed to clear up compatibility issues. Email would also allow the process to be asynchronous so the users would not perceive a delay. Additionally, email would allow the process to survive a short CRM server outage.
The process is pretty simple. We created a service that monitors a specified CRM email enabled queue. When an email arrives in the queue, the service reads it, parses it, and used the data to create a web request record in CRM (a new custom entity). For auditing purposes we also attach the inbound email the the newly created web request record.
When the web request record is created a workflow rule executes that calls a custom .NET assembly to search for a matching contact record (we use email address just like C360 does) and then either relates the web request to the contact or creates a new contact and relates the web request to the contact. After relating the contact to the web request it is very easy to use the existing workflow functions for dynamic updating to update the contact fields that we want to update. We create and update the custom entity using a similar process.
There are not many things that I don't like about MS CRM 3.0. But one item has recently jumped to the top of the list: Email support for custom entities. I can understand the difficulty in figuring out how to use an email address field in a custom entity to actually create and send an email. What I can't understand is why I can't create email templates for custom entities.
I can create email templates for other record types in CRM that don't represent people (e.g. orders, quotes, service cases.) I should be able to create email templates for my custom entities too. As long as they are related to one of the primary email record types (account, contact, lead) the system should know how to send the email. Maybe in the next service pack???
By the way coming in at number 2 and 3 on the list are: Can't call a workflow for one record type from another record type; and Can't relate a custom entity to a customer (i.e. an account or contact with one lookup.
We just completed a data migration from Act! 6.0 to Microsoft CRM 3.0. Rather than use a third party migration tool like Scribe we decided to use the recently released Microsoft CRM Data Migration Framework (DMF).
The primary reason we opted to use the DMF was that the data in Act was very “dirty”. Specifically each record in Act might actually represent anywhere from 1 to 5 individuals with the names and contact information for the secondary “individuals” on each record separated by various delimiters. I don’t know that Scribe couldn’t do it but I had a feeling it would be easier to script out the migration in SQL than it would be to figure out how to make a tool deal with these irregularities.
The overall process was exporting all the data out of Act! 6.0 and moving it to a format that was more SQL Server friendly. We decided to use a tool specifically designed for the purpose Import Pro from crmaddons.com http://www.crmaddons.com/pc-15-3-export-pro.aspx. From Access we moved the data to a new SQL Server database (ActData) using DTS.
The DMF consists of several wizards and a common data framework (CDF) database. The wizards assist in mapping data in the CDF to data in CRM to account for various pick list option values, record ownership mapping, etc. Getting clean data into the CDF is the key to a good migration with the DMF.
The majority of our effort was creating and testing scripts that normalized the data, split out the secondary contacts in each contact record and then migrated the data to the CDF database. Once the data was in CDF things went smoothly with a few exceptions.
First, we had problems importing historical data as completed activities. It appears that the DMF doesn’t allow for the creation of a record with a statecode of 1 (completed.) We worked around this issue by importing the activities in an open state (statecode=0) and then ran a script in the MSCRM database to update the statecode and statuscode to mark the activity completed.
Second, Act stores dates and times without time zone correction and CRM stores dates and time in GMT. For our conversion this resulted in some records showing the due date as one day earlier in CRM than it was in Act. We corrected this by modifying the scripts to add 8 hours to all dates as we moved records to the CDF database.
Third, we originally had a lot of activity records that would not import on our first test import. Analysis of the failures indicated that they had only one thing in common; a date field where the time was exactly midnight (00:00:00). This was evident when looking at the DMF logs that contain the XML used to insert the record in CRM. When the time was exactly midnight, the time part of the date information was not in the XML field and CRM is very particular about using proper UTC form on date/time information. The workaround here was to add 8 hours and 1 second to all the dates as we moved records to the CDF database.
Once all of the scripts were done and tested we were able to complete a test migration on our development environment and then run the production data migration. The Data Migration Framework is a great tool but it requires a fair amount of SQL scripting knowledge. Moving data from Act to the CDF database was relatively quick once the scripts were developed but the migration from the CDF database to MSCRM was relatively slow (3 to 4 hours to move 65,000 records.)
Thanks to SBS MVP Andy Goodman (AKA Handy Andy) for superb documentation of his CRM SBE install. If you are even thinking about installing CRM 3.0 SBE you need to review this: http://www.sbs-rocks.com/crm/crmsbeinstall.htm
I came across a company at the Convergence conference that has a great solution for CRM users that deal with a lot of documents. They have a device that connects to the network.and allows users to scan documents into CRM. The company name is Intellagent Solutions www.intellagentsolutions.com. If your processes involve a lot of documents you need to check this solution out.
I’ve been having problems with my CRM 3.0 SBE install on a SBS 2003 Premium install. Based on a lot of different posts in many different newgroups as well as some input form the Microsoft CRM team, I decided to try several installs under better controlled and documented conditions to see if I could understand what was happening. Here is a summary of my experiments
Assumptions: CRM 3.0 SBE is advertised to only work with SBS 2003 Premium and only with SBS SP1 installed. To me this means one of two variations: SBS 2003 with SQL 2000 SP4 and no ISA or SBS SP1 with SQL 2000 SP4 and ISA 2004. I also made a gross assumption that a system patched to SBS 2003 SP1 will act that same as a system installed as SP1 (I know this is probably faulted but I just don’t have time to build out that many different servers.)
As a starting point for both tests I built out an SBS 2003 virtual server image as follows and then enabled UNDO disks so I could go back to this point for the start of each test.
- Build out a virtual server image of SBS 2003 SP1 with SQL 2000 SP4 (using MSDN download ISO images) with the following characteristics:
- 2GB RAM, Single 16GB Hard Drive, Dual NIC
- Internal IP Address: 192.168.24.2
- External IP Address: 192.168.16.205 (connected to the Internet through my internal network)
- Domain: demo.local
- Machine Name: SBS
- External domain name: sbs.crm-demo.com (used for OWA and RWW access) Note that there is no host record for this domain name.
- Run the connection wizard to establish connection to the Internet.
- Install Virtual Machine Additions.
- No additional patching, hot fixes, or updates applied.
- Save image and then enable UNDO disks for remaining changes.
Test 1: Install CRM 3.0 SBS on SBS 2003 SP1 with SQL 2000 SP4 (No ISA)
- Restart virtual server image from rolled back state.
- Load CRM 3.0 SBE form MSDN ISO Images using all default settings.
- ERROR: SQL Reporting Services cannot find IP address corresponding to domain name sbs.crm-demo.com. I would have expected SQL Reporting Services to use the machine name of sbs.demo.local rather than the name assigned to the default web site certificate (sbs.crm-demo.com). In my case there is no way that the sbs.crm-demo.com domain name would resolve because there is no host record matching this value. However even if it did resolve it would not work because it would resolve to a public IP address and it would likely be blocked.
- WORK AROUND: Create a forward lookup zone in the SBS DNS Server for crm-demo.com and then create a host record pointing sbs.crm-demo.com to the IP address assigned to the internal NIC (192.168.24.2). Run a IPCONFIG /flushdns and then retry the failed step.
- Note that additional actions will be required after setup completes to remove dependency on this DNS entry.
- ERROR: SQL Reporting Services cannot access the Report Server at sbs.crm-demo.com/ ReportServer due to a 401 access denied error.
- According to KB 896861 this is an issue resulting for Windows 2003 SP1. The KB offers two options to workaround the error. I chose to add the DisableLoopbackCheck DWORD value to the registry.
- Completed install without additional errors.
- Rebooted after installation completed
- Ran through CRM setup wizard.
- At this point any time I tried to run a report I was getting challenged for credentials from the report server at sbs.crm-demo.com. If I supplied credentials the report would continue.
- In order to remove the reference to sbs.crm-demo.com I edited the registry value for SQLRSServerURL at HKLM\Software\Microsoft\MSCRM from https://sbs.crm-demo.com/ReportServer to https://sbs.demo.local/ReportServer and performed an IISRESET at the command line.
- Removed the forward lookup zone for crm-demo.com from the SBS DNS server and flushed the DNS cache.
- Able to access CRM reports with out additional authentication. All seems to work well
Test 2: Install CRM 3.0 SBS on SBS 2003 SP1 with SQL 2000 SP4 with ISA 2004
- Restart virtual server image from rolled back state.
- Install ISA 2004 from the SBS Premium Technologies with SP1 using the MSDN ISO image.
- Modified the default web site setup as follows per recommendation from Barry Givens (CRM PM)
- Set the port 80 and port 443 IP addresses to use all IP addresses rather than the distinct 192.168.24.2 and the 127.0.0.1.
- Set the DisableLoopbackCheck DWORD value per KB 896861 based on experience in first test.
- Ran CRM 3.0 SBE install using MSDN ISO images
- ERROR: Had an error during the SRS install but error cleared on RETRY.
- Install finished with out further error.
- Had a service start error on server startup. Microsoft Firewall Service did not start properly. The service did start from a manual start command.
- Ran through initial setup wizard
- Tested reports without issue.
- Ran the SBS Internet connection wizard and verified that the default web site IP address properties were returned to their pre-crm values.
- Opened CRM and tested reports. Flawless
It appears that the recommended fixes for installation when ISA 2004 is on the SBS 2003 box work. The issue I had in Test 1 Step 3 is perplexing. Oddly enough when I looked at the HKLM\Software\Microsoft\MSCRM\SQLRSServerURL value from Test 2 (ISA Installed) it was https://publishing.demo.local/ReportServer ( a local domain path) rather then the external domain name that I saw in my install without ISA 2004.
It looks like there may be an issue with the RTM code (at least the download from MSDN) for Microsoft CRM 3.0 when installing on SBS 2003 Premium. If ISA 2004 is installed it does not appear to be possible to get a standard install to work because the SQL Reporting Services (SRS) install cannot find the default web site to install SRS.
We implemented SBS SP1 this week and ran into a few issues with CRM after the install. Our installation has Microsoft CRM installed on the SBS server. We also had a few other modifications that made our system different than a baseline SBS 2K3 Premium install. I believe that the difference that caused our problems was that we had multiple IP addresses on our internal NIC. This modification was primarily in place to support SSL publishing of our CRM and Companyweb out to the Internet.
After the SBS SP1 install we had problems with our Microsoft Exchange Connector. We could not send email out from CRM nor could any inbound email come into CRM. We also had problems with some (but not all) of our C360 add on components for MS CRM. We were also seeing event ids 5895 and 5892 for the CRMExchangeQueueService.
We were not able to find a KB that was a dead fit but we pieced together a solution based on several KB’s that referred to incorrect or missing application extension mapping for two key virtual directories under the MS CRM web site.
The MSCRMServices and MSCRMConnector virtual directories contain web services that are used by code that uses the CRM SDK and by the CRM Exchange Queue Service respectively. These virtual directories need to have application extension mapping setup to process web service calls with a .srf extension. You can verify that mappings are installed correctly on each folder by running a simple test from IE.
1. On the Microsoft CRM server, click Internet Explorer, click Tools, click Options, and then click the Advanced tab.
2. Clear the Show friendly HTTP error messages check box, and then click OK.
3. Open the Microsoft CRM Web site by using the following URL, where MSCRM is the name of the Microsoft CRM server to verify the .srf mappings on the two virtual directories:
http://MSCRM/mscrmservices/bizusersdl.srf
http://MSCRM/mscrmconnector/icrmemaildispatchsdl.srf
4. Going to this address should generate either of the following results:
· An XML message. If you see any XML data, the SOAP configuration is good.
· An IIS specific error that occurs without XML data. If you see an IIS error, there may be problems with the configuration on the Microsoft CRM server. Proceed to step 5.
5. Open Internet Information Manager. To do this, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
6. Expand the Microsoft CRM Web site, and then locate the MSCRMServices virtual directory. Right-click MSCRMServices, and then click Properties.
7. On the Directory tab, click Configuration. The .srf mapping should be listed in the Application extensions section on the Mappings tab.
8. If the .srf mapping is missing, follow these steps:
a. On the Application Configuration window, click Add.
b. Click Browse to locate the Crmisapi.dll file. By default, the Crmisapi.dll file is installed at the following location: <install drive>:\Program Files\Microsoft CRM\Server\bin\Crmisapi.dll. If the path contains spaces, you must manually enclose the path with double quotation marks.
c. In the Extension text box, type .srf.
9. Repeat steps 6 through 9 for the MSCRMConnector virtual directory.
Susan Bradley set up this blog for me last October when I received my first MVP award. I've had several false starts trying to figure out what value I could provide to the community through this blog. Admittedly I also got side tracked on layout, style, trying to figure out which skin to use, etc. Eventually the blog just became stagnant and we all know how hard it is to regain momentum.
I'm finishing up the last day of the 2005 Microsoft World Wide Partner conference in Minneapolis today. I've been doing some show-and-tell here at WWPC and I have received a lot of feedback along the lines of “I didn't know you could do that with CRM!”. I've found my inspiration, something that touches my evangelism for the Microsoft CRM product. I've decided to use this blog to primarily educate any and all who are interested on interesting solutions, products, extensions, and development concepts associated with Microsoft CRM.
It will take me a while to get things going but I hope you will find it useful.
Scott Colson, CRM-MVP
As some of you may know, I was working with Harry Brelsford to add some Microsoft CRM content to the “Extending SBS 2003” book. My hope was that I could help my peers in the SMB consulting space avoid some of the pot holes and dead ends that I encountered with MSCRM on SBS. The planned timing of the book release relative to Microsoft's (now) official announcement of the release of Microsoft CRM 3.0 pretty much made the chapter I penned on installing MSCRM on SBS 2003 obsolete so I've decided (with Harry's concurrence) to release the chapter to the public domain in hopes that it will help. This was my first crack on writing a chapter for a technical book. I'd appreciate any feedback that might help me as I start working on the new chapters for the “Extending SBS 2003” that will focus on CRM 3.0.
Check back here shortly for a link to my recipe for a successful CRM implementation on top of SBS 2003 .....
|
I install the following patches and hot fixes on all the Microsoft CRM implementations we manage. This article also demostrates the functionality of the CRM Knowlege Base and is infact a copy of the KB I maintain for my company. As I update my internal KB I'll post the update here.
Prescribed Patches for a Microsoft CRM Server Installation |
| KBA-02024 |
| Purpose & Scope |
| The following Updates and HotFixes should be applied to all Microsoft CRM V1.2 installations. |
| Prerequisites & Initial Conditions |
|
Microsoft CRM v1.2 is installed. |
| Procedure |
|
Install the following Updates and Hotfixes in the order listed.
- (2005-03-28) KB870635 - Microsoft Business Solutions CRM update for Windows XP Service Pack 2
- (2005-03-28) KB837059 - Update to Microsoft Business Solutions CRM 1.2 to add Coordinated Universal Time +1200 to timezone list
- (2005-03-28) KB840934 - Microsoft Business Solutions CRM version 1.2 update for 839153, 839159, and 839162
- (2005-03-28) KB841562 - Microsoft Business Solutions CRM 1.2 hotfix for 839163 and 835306
- (2005-03-28) KB886355 - Microsoft CRM 1.2 Hotfix Rollup for 840058, 841648, 843172, 870575, 888004, 888005, and 888006
- (2005-04-19) KB892949 - Microsoft CRM Update Rollup 1 for Microsoft CRM Sales for Outlook 1.2 (Note this role up addresses a lot of server side bugs too.)
|
| Additional Comments |
| Last updated 4/22/2005 |