-
DST Update strikes again
I thought we were all through with the Daylight Savings Time (DST) issues, but I was wrong.
One of my customers purchased a newer, more powerful, SBS 2003 box and we had to migrate CRM 3.0 from the old server to the new server.
Overall, everything went fine. Redeployment manager did it's job, CRM installed to the existing database ok, but I ran into an issue when I attempted to install Hotfix Rollup 2.
It wouldn't install and kept crashing at the Checking necessary disk space step ( or something close ).
After digging around a bit, I found the following article:
The article's possible issues and resolutions are some of the strangest I've ever seen:
1) Well, it could be crashing because it can't find a Time Zone registry entry.
2) Well, it could also crash if it found a Time Zone registry key that it didn't expect?
From the KB article: Use the same command on another Microsoft Dynamics CRM server on which update 925874 was successfully installed.
Huh? What if I don't have another CRM Dynamics server? Luckily, I did.
Anyway, it turns out that on the new server, it was issue #1, which I found to be with the Central Brazilian Standard Time time zone which was missing data.
Ah, those crazy Brazilians. :)>
Anyway, I hope to never see this issue again because I hope to be installing CRM 4.0 from here on out.
Dynamics CRM, Installation
(No Ratings Yet)929 views
Loading ... -
Issues related to Installing CRM 4.0 in a co-located environment
Kevin Collins, a friend at one of my partner companies, Integrated Data Architects, ran into an issue getting the Outlook client connected to their CRM server which is co-located at a site in Dallas.
CRM 4.0 now has something called an Internet Facing Deployment which is a new way of configuring CRM which came into play in this case. Read Kevin's article on what he found and how he resolved it.
Dynamics CRM, Installation (No Ratings Yet)763 views Loading ... -
Processing CRM Queue Email
One of the steps that people sometimes forget when creating an email enabled queue it to apply to CRM Forwarding Rule to the Queue mailbox. If you do this, and your queue is in use, you will find unprocessed email in the Queue's mailbox.
The CRM Forwarding Rule rule only works on new, inbound, email and will not process existing mail items.
To process the email in the Queue's mailbox, perform these steps:
1) Create an Outlook profile that allows you to log into Exchange as the CRM Queue user.
Note: if you have disabled the Queue account within Active Directory, you'll probably need to temporarily enable it for this process to work.
2) Start Outlook.
3) Select Tools, Rules and Alerts to open the Rules and Alerts dialog.
4) Click the Rule Rules Now button.
5) Select the CRM Forwarding Rule.
6) Select the Inbox folder on which to run the rule.
7) Click the Run Now button.
That's pretty much it.
Dynamics CRM, Installation (No Ratings Yet)1,811 views Loading ... -
Retrieving CRM Registration Information
I ran into an interesting issue a couple of weeks ago where a prospective customer was attempting to renew their Software Assurance (SA) plan and could not find the original subscription information.
On a hunch, I had him re-run the CRM Registration wizard. Much to our relief, the information originally recorded during the registration process was available – including the SA agreement number.
Something to keep in mind should something similar happen to you.
Dynamics CRM, Installation (No Ratings Yet)875 views Loading ... -
CRM Rule Deployment with Outlook 2007
In the past couple of months, I have run into issues deploying the CRM Forward Rule to Outlook 2007 clients.
If you are facing this issue, you may wish to try installing the CRM 3.0-Exchange E-Mail Router Update.
While the documentation doesn't actually state that issues related to Outlook 2007 can be solved by installing this update, it has corrected the problem on at least three separate CRM installations that I am aware of.
Dynamics CRM, Installation (No Ratings Yet)1,334 views Loading ... -
Publishing CRM SBE via ISA 2004
Andy Goodman has published the final version of a how-to guide that will allow you to publish your CRM web site running on Small Business Server to the Internet.
Great work Andy.
Dynamics CRM, Installation (No Ratings Yet)1,528 views Loading ... -
Discussion Regarding CRM Data Import Strategies
I sometimes spend way more time than I should working on projects that allow me to increase my understanding and knowledge. My current CRM installation is no different. I have invested a great deal of non-billable time on the data import process so that I can better gauge the requirements for future projects of a similar nature. I thought I'd post some of my insights should they prove useful to others in the CRM Community.
Background
This customer has a Business Operations System (BOS) written in Microsoft Access that runs their entire company. We are moving their customer data out of this system into Microsoft Dynamics CRM in order to make better use of the functionality that CRM provides. The main operational features will remain inside of the Access application which has been modified to utilize CRM as the data provider for the customer and contact information.
Note: My customer uses the term Customer for Account and I will that term for this article.
Requirements
The main task was to move the customer and contact information into CRM. A secondary task was to provide the data back to the BOS in a manner that would not require retooling of that application or if modification was necessary, make it a minimal-cost change
Relationships, Relationships, Relationships
The main challenge I faced was moving from a fairly flat database schema into the highly relational CRM schema. The BOS has two tables that store both Customer and Contact information. The two tables are linked to provide a parent-child relationship between Customers.
Strategy
I had to develop a plan for moving this data into CRM, creating the relationships between Customers and Contacts and Parent and Child Customers. After much thought and more than a little trial and error, I finally arrived at a multi-step operation that allowed me to import the data then later establish the necessary relationships.
Tools
Instead of using the native CRM import utility or going with a commercial product like Scribe Insight, I decided to use the Bulk Import sample application that Microsoft released a few weeks ago. I chose this route because I wanted to gain experience with the tool and to better understand its capabilities. I have a couple of upcoming projects that will probably utilize customized versions of Bulk Import so I wanted to know what I was getting myself into.
The tool itself if very well written and contains a variety of interesting programming techniques. I had to introduce modifications that would allow me to move additional data types not supported in the base product, but that was a fairly minor detail.
Bulk Import supports threading so the operations it performs are actually fairly quick. On one import, for the Contacts I think, I was using four threads and was obtaining 22+ creates per second. This allowed me to move roughly 8,000 Customers and 8,000 Contacts into CRM in much less than an hour.
Data Preparation
As I mentioned in a previous article, when you import data into CRM using the CRM Web Services, you can either allow CRM to assign an ID ( GUID ) or programmatically assign it yourself as data provided during the import process. I chose the latter approach and the following techniques:
1) I created duplicate work tables containing data from the two BOS tables.
2) Microsoft SQL Server provides a function called NewID() to generate a GUID.
3) I created columns to record the following IDs:
a) Customer ID
b) Parent Customer ID
c) Primary Contact ID
d) Secondary Contact ID
4) I utilized the NewID() function to assign IDs to each customer and contact, as required, in both work tables, for each record.
5) I also had to perform additional preparation operations such as splitting the Contact name into First and Last names, since that is how CRM requires the data to be imported.
These steps allowed me to have a base set of data that contained everything I needed in order to successfully import our Customer and Contact data.
If I had chosen to allow CRM to create the ID, I would have had to update the Import Database to reflect that value. Since there were so many relationships involved, I found it much easier to provide the ID myself.
Sequencing
Since everything in CRM is related to just about everything else, proper sequencing of import tasks is critical to the success of the operation. When attempting to establish a relationship from one CRM record to another, that record being referenced must already exist within the system. If it doesn't, the operation will fail.
For example: When setting the parentcustomerid for a Contact, you must have already imported the Customer in question before the relationship can be established.
This caused me more than a little mental anguish as I worked through what I thought the "right" or "correct" method was.
Note: I'm not sure there is a "right" or a "wrong" method.
So here was the sequence at which I finally arrived:
1) Import Customers who have Child Customers.
2) Import Customers without Child Customers.
The parentaccountid attribute was supplied from the database to establish the Parent/Child relationship with the Parent Customer.
3) Import Primary Contacts associated with Customers from operation #2.
The parentcustomerid attribute was supplied from the import database to establish the Parent/Child relationship with the Parent Customer.
4) Import Secondary Contacts associated with Customers from operation #2.
The parentcustomerid attribute was supplied from the import database to establish the Parent/Child relationship with the Parent Customer.
5) Import Primary Contacts associated with Customers from operation #1.
The parentcustomerid attribute was supplied from the import database to establish the Parent/Child relationship with the Parent Customer.
6) For those Customers who had valid Primary Contacts, an update operation was performed against all Customer records that would create a link from the Customer to its Primary Contact by updating the value of the primarycontactid attribute to Primary Contact ID found in the import database.
Integration with the Business Operations System
One of the more interesting things we did was to create two SQL Views that would simulate the table and column names that the BOS utilized so that no re-programming was required on the BOS side. These views query the CRM SQL Filtered Views in order to return the requested data. We just modified the location of the linked tables within Microsoft Access and where pretty much done.
The BOS application developer also added a CRM button to the main form that will take the Customer's ID and display the CRM record using the URL Addressable Forms technique outlined in the CRM SDK. This allowed the BOS user to immediate jump to the Customer's CRM record should they need to review additional Customer detail.
In the end, the user now has full access to the features and functionality provided by a true Customer Relationship Management application while still being able to utilize a highly specialized application to run their business operations. The two are linked together so that a minimum of user retraining will be required ( over and above the normal CRM introduction classes ).
Conclusion
What this process allowed me to accomplish was getting all of the data into CRM without worrying about everything absolutely matching up during the first pass – which is how I started off the process and where I wasted much of my time. It also provided a method to verify each step of the operation so that, in some cases, if the import was unsuccessful, I had a checkpoint that I could revert back to without having to delete everything and start over again.
I also fixed a few issues with my Bulk Delete utility that allowed me to delete the CRM records without resorting to using the CRM UI ( and deleting 250 at a time ).
Hopefully, I've provided enough insight into the process to get you to thinking about how you might conduct a similar operation of your own. If not, just ask for clarification.
Have a great weekend.
Development, Dynamics CRM, Installation (No Ratings Yet)3,684 views Loading ... -
Importing Records and the CRMDeletionService
As you may know, each record within the CRM system has a unique identifier that identifies it within the system. This identifier is know as a GUID, or a Globally Unique ID.
When you programmatically import records into CRM, you can either supply the GUID yourself, as a item within the import dataset, or you may allow CRM to generate the GUID.
I was using a modified version of the Bulk Import Utility that I mentioned a while back and for this particular implementation, it made the import much more efficient if I supplied the GUID during the import process.
NOTE: In such a case all you do is assign the value of the GUID to the Entity's ID column, such as:
Lookup keyTestValue = new Lookup();keyTestValue.Value = new Guid(myGUID);keyTestValue.type = EntityName.contact.ToString();
This worked great for a while. I would test a section of the import process, delete the imported records, and reimport them later.
Then I started running to very strange errors:
Server was unable to process request.
Not exactly though provoking or even any help at all in leading me to the root cause of the problem.
The Problem
It turns out, that even though I had deleted my test import records from CRM, they were still in the database.
This is a common practice, and in case you didn't know, the CRM Client does not physically delete CRM records – it merely marks them for Deletion. The CRMDeletionService is the process that runs periodically and makes everything in the CRM world right again.
Except my CRM world wasn't right at all. I couldn't continue my development efforts since I couldn't reliably test my import process, I had no idea why it was suddenly broken, and I had people at the customer site waiting on me to finish.
I finally traced the issue to the fact that I was importing the GUID IDs along with the other Entity data. I am making an educated guess that CRM was getting upset that it was finding those IDs existing within the database during the Create process and the import for that record was failing.
I didn't want to result to manually deleting records from the CRM Base tables because that's against the rules, and I had no idea what magic was required to manually fire off the CRMDeletionService to have it do it's job.
So I did what I usually do in cases like this: I sent a panicked email to a couple of my fellow CRM MVPs for thoughts and ideas.
The Solution
Michael Höhne came to my rescue with a bit of CRM knowledge that I am sharing now. It turns out that you can instruct the CRMDeletionService to run manually, using the following instructions:
1) Open a command prompt.
2) Change your directory to: [CRM installation directory]\server\bin
3) Run crmdeletionservice –runonce
That will run the CRMDeletionService which will remove the deleted records from the database.
CRM Deleted Records Backgrounder
As mentioned above, the CRM client is not actually the process that deletes CRM records, it is the CRMDeletionService that does the actual work. This is probably due to the fact that Delete operations are fairly intensive processes and due to the Entity Relationships you find within CRM, it can be extremely complex and time consuming.
Rather than burden the user with this effort, the CRM Client merely updates the individual records and changes the DeletionStateCode to a value of 2. The CRMDeletionService wakes up on a periodic basis ( unknown and not documented, BTW ), and deletes any record with the DeletionStateCode of 2.
This makes for a fairly efficient system and an overall better user experience.
Should you be accessing CRM data via the SQL Filtered Views, the DeletionStateCode value is taken into account and records marked for deletion are not returned.
Likewise, the CRM Clients both mirror this functionality and totally ignore records marked for deletion.
Future Development Efforts
One of the first CRM add-ons I ever wrote was a utility that performed a bulk delete of CRM data, using the CRM WebService APIs. Unfortunately, it doesn't always function as expected and I haven't had the time to invest into tracking down the issues relating to the failure of the CrmService.Delete call. I think most of these issues are related to relationships and cascading issues.
I will also be adding an option to physically delete the records marked for deletion by running the CRMDeletionService -runonce. That will be a valuable edition.
It may also be possible to create an Undelete utility for CRM but I have no idea if you can "legally" set the DeletionStateCode back to 0 through the CRM Web Services. There will also be tons of issues related to relationships and cascading behaviors that need to be taken into account. All of which means it may not possible, or practical to create such a utility.
Development, Dynamics CRM, Installation (No Ratings Yet)2,537 views Loading ... -
Introduction to the CRM SBE Configuration Wizard
Dynamics CRM 3.0 ships with a Configuration Wizard that allows you to configure most of the common customization points automatically. It builds a configuration file that can either be saved for later Import or Imported live.
Where to find it:
Look in the following folder on your CRM Server:
[installation drive]\Program Files\Microsoft CRM\Tools\
The application file name is:
Microsoft.Crm.Sbe.Configuration.Wizard.exe
Launching the wizard will step you through a process that begins with the following dialog:
You can select the Primary Industry of your company, which will provide answers to later questions.
The following Industries are currently provided:
Financial Services
Banking
Insurance
Government
Healthcare
Health Plan Payer
Healthcare Provider
Life Sciences
Pharmaceuticals
Manufacturing
Discrete Manufacturing
Process Manufacturing
Media and Entertainment
Advertising
Entertainment
Nonprofit
Professional Services
Real Estate
Management Services
Engineering and Architecture
Legal
Retail
Telecom
Communication Service Providers
Equipment Providers
Network, Internet or Applications Service Providers
Transportation and Logistics
UtilitiesThe subjects provided will be automatically populated based on your Industry choice. As you can see, you can Add, Remove, and Edit existing items.
When you define your Sales Operations information, you will allowed to set the display name format for the contact names within CRM as well as change the names of the Account and Contact Entities.
If you utilize territories in your business, you will be allowed to enter those as well.
You can also define your Top Competitors.
Should you use the CRM Services module, you can change specific settings for that as well.
And define your Service Sites.
And Service Queues.
Finally, you may either apply your changes immediately, or wait until a later time. Should you choose Later, you will be allowed to specify a file name that will be used to store the settings ( in XML format ) that will be used by the Configuration Wizard to apply your changes.
In order to start the Configuration Wizard and instruct it to use the XML configuration file you created earlier, you must execute the Configuration Wizard from the command line and specify the name of the configuration file, as is shown below:
The config file will be read and a summary of your specific group of settings will be displayed.
You will then be asked to enter the location for your CRM server.
When you click next on the above dialog, the Configuration will begin the Import process, as shown below:
As you can see, any configuration sections that didn't contain data were skipped. The other messages indicate if that part of the process Succeeded or Failed.
Clicking Finish will close the Wizard.
Related Items of Interest:
The SBE Configuration Wizard is launched at the end of the CRM SBE installation, but you can cancel it and run it later.
Even though the Wizard is titled "SBE", you may also run the Wizard on a CRM Professional installation ( all of the above screen shots are from my development system, which is CRM Professional ).
The configuration file created by the Wizard is to only be used by the Wizard to implement your changes. It is not in a format that is compatible with the CRM Customizations Import process.
I know of no method of adding information to the Wizard to add additional Industries, etc., so we're pretty much stuck with what Microsoft delivers.
Customization, Dynamics CRM, Installation (No Ratings Yet)2,102 views Loading ... -
Driving Dynamics CRM 3.0 User Adoption
Gaining user acceptance and adoption of Dynamics CRM can, of course, be greatly increased with proper instruction and training.
I have begun to notice a pattern in acceptance should you be installing CRM into an organization that does not currently utilize Outlook, or uses it minimally.
If the user isn't familiar and comfortable with Outlook, installing the CRM Outlook client can confuse the heck out of them. This is caused by the fact that once the Outlook client is installed, the user now has at least two different methods to do many things. And, if they don't know where Outlook ends, and where the CRM client begins, it can lead to more than a little bit of frustration as they attempt to determine the correct way to do something.
But doesn't everyone use Outlook?
Not as much as you think, especially in smaller organizations, and especially if they don't have Exchange installed. Either they use Outlook Express for email or use Outlook and then, only for email. That means that things many of us take for granted, like: Contacts, Scheduling, and Shared or Group Calendars are totally new and different. New and different many times is translated into "scary" and scary is bad.
Working through the issues
Here is one approach that I think will work in many organizations who make little or no use of Outlook.
1) Take time to know and understand the product knowledge-level of user community.
2) Perform a phased implementation and get the user working and productive with Outlook before CRM is implemented.
3) Have you or your staff be physically present during this initial phase so that people can ask stupid and embarrassing questions.
Note: There are no such things as stupid and embarrassing questions, but people still think they exist.
4) Perform a simple, quarter or half-day group training session so people can get an exposure to the product.
5) Engage with the users one-on-one, to provide personalized responses to questions and issues.
People will generally react much better to personal coaching than group training and will tend to ask better and more questions when outside of the group setting.
6) By this point you have probably finished your CRM installation, configuration, and customization activities and it is now time to roll-out the CRM Outlook client.
7) Repeat steps 3 through 5 and outline the differences between Outlook and CRM and discuss in detail how the two products work together.
8) Have users keep a notepad to document questions and concerns as they use the system.
9) Perform frequent visits to each user's office to review and address any questions and concerns they may have document in their notepad.
While these steps may not handle everything you encounter, I think it covers most of the issues that I've seen in the past couple CRM implementations.
If you have experiences of your own that you would like to share, please leave a comment.
Dynamics CRM, Installation, Outlook Client
(1 votes, average: 5.00 out of 5)2,146 views Loading ...
Polls
Loading ...