-
Microsoft Dynamics CRM 4.0 Edition Differences
I’ve had discussions recently with both customers and partners regarding the differences in the three editions of Microsoft Dynamics CRM 4.0 so I thought I’d quickly cover these today.
Note: For this discussion, I am purposefully not covering CRM Online since the end-customer has no control of that environment.
Editions
We have three editions available to us:
Microsoft Dynamics CRM 4.0 Workgroup.
This edition is limited to five, or fewer, users. It can be installed on Microsoft Windows Small Business Server 2003 R2 Premium Edition, any of the supported Windows Server 2003 editions, or Windows Server 2008. This version is limited to a single organization and a single computer that is running Microsoft Dynamics CRM Server.
Pretty self explanatory: 5 users, one CRM Organization.
Microsoft Dynamics CRM 4.0 Professional.
This edition has no user limit and is limited to a single organization. However, Microsoft Dynamics CRM 4.0 Professional can be installed on more than one computer in the same deployment.
Microsoft Dynamics CRM 4.0 Enterprise.
There is no user limit for this edition. Additional features include support for multiple organizations, multiple server instances, and role-based service installation. Role-based services let you increase performance by installing component services on different computers.
Why is this important?
Most companies run into issues because they purchase the Professional Edition knowing that they will always have a single organization or tenant. Most people know that the Enterprise edition allows you to specify multiple organizations, but what is not really clear, if you don’t know the terminology, is something called role-based services.
CRM 4.0 is divided into a series of server roles that perform various tasks related to the operation of the system as a whole. Unless instructed otherwise, when you install CRM all roles are placed on a single server, which is usually not a problem. But, there may come a time when you need to move one of the roles to a separate server to help ease the processing burden.
And in many cases, this has nothing to do with the number of users but is totally related to what those users are doing. Some operations, such as the application of complex business logic, batch updates, etc., may require a tremendous amount of processing power for a short period of time. Since all of the server roles are on a single server, that one server must perform all of the processing directly.
If the server roles are split, say by moving the Asynchronous Processing service to another server, the load is shared between multiple physical machines so that one set of processes doesn’t affect others.
So, keep that in mind when you start planning your own CRM installation.
Licensing
A Microsoft Dynamics CRM 4.0 deployment operates by using a single license key. Unlike earlier versions, Microsoft Dynamics CRM 4.0 no longer requires additional license keys to be added when changes are made, such as adding a client access license (CAL). The single license key contains the Microsoft Dynamics CRM version, server license, and the CALs.
You can view and upgrade a license in Deployment Manager.
You can view and modify client access license types for each user in the Users area of the Settings area in the Microsoft Dynamics CRM Web client.
Note: There is no difference in the licensing for the CRM Clients, no matter which edition of Dynamics CRM 4.0 you have installed.
References
- Microsoft Dynamics CRM editions and licensing
- Dynamics CRM 4.0 Server Roles
- Use the Command Prompt to Install Microsoft Dynamics CRM
Dynamics CRM, Installation
(No Ratings Yet)598 views
Loading ... -
Migrating CRM from SBS 2003 to SBS 2008
I ran into a fascinatingly irritating issue last weekend while moving a CRM 4.0 installation from Small Business Server 2003 to 2008.
It seems that the Exchange Migration Tool did not properly assign permissions to the Program Files folder where Exchange was installed. It did properly assign the permissions to the Exchange folder set, but not to the root Program Files folder.
Ordinarily this would not have been an issue if not for the fact that I was actually installing CRM into the same folder structure. Here is what happened:
The Problem
The problem surfaced in two separate ways:
- I was installing CRM using the default user of Network Service. This is also the user who would run the CRM Async Service. The installation failed with an access denied error message. It took me a while to figure out it was a permissions issue within the file system which I fixed by giving Network Service permissions to the Microsoft Dynamics CRM folder structure.
This was an incorrect solution.
- The second issue surfaced when I loaded the CRM web page and found none of the icons were visible and I was getting JavaScript errors.
After working with Microsoft and running a Fiddler trace, I finally tracked down the issue.
The Resolution
It turns out that the domain group Users had no access to the E:\Program Files folder structure which is where CRM was installed.
This surfaced initially because of the issue with Network Service not having access but it never occurred to me that an issue could be caused by a permission which is usually there.
I compared the permissions on the original SBS 2003 server against those of the SBS 2008 server to locate and correct the problem which was to give [domain]\Users read, execute, and list permissions on the folder structure.
Dynamics CRM, Installation (No Ratings Yet)418 views Loading ... -
Testing Customizations as a Normal User
This will probably be old news to most of you, but for those who are just starting with CRM, you should have a methodology in place to test your customizations as a normal user.
The Basics
You should have at least one test user for each role in which normal users exist. Normal being not-CRM Administrators. This will allow you to test the functionality of your customizations and custom solutions as each type of user.
While this may not seem like a huge issue, you need to keep in mind that CRM alters the environment and the user interface based on the user’s security. This means that sometimes they will not see things you expect them to or they will have permissions issues where you least expect them.
How to Test
Prior to Windows Vista and Server 2008, you could simply right-click on the Internet Explorer icon, select Run As, then supply the credentials of whatever test user you wished.
Unfortunately, Microsoft changed that behavior and according to this article, it no longer works. Thanks guys.
A possible work-around is using the ShellRunAs commandlet found here.
It is supposed to provide this functionality but I’ve had mixed results ( probably didn’t follow the directions properly ).
So if you’re using Vista or Server 2008, should nothing else work, you can always just Switch Users and log into the machine as the test user.
What to Test
Here are the usual suspects for testing customizations within CRM:
- The Site Map ( left-hand navigation )
- ISV.Config ( buttons and menus )
- JavaScript ( does your custom JavaScript work with all users )
- Custom Solutions ( any custom ASP.NET code you have written and added to CRM )
- Processes. If you have a process that moves data through the system, test it from start to finish as the particular user or users who actually perform the work to make sure you’re covering the whole process as a “normal” user and experiencing what they experience.
Conclusion
This is, at the very least, the minimal amount of testing you need to perform on a customized system. You can get as comprehensive and complex as you desire.
If you will document your testing procedures and steps and repeat those each time a change is made, you should be able to more quickly identify problems and create solutions before your changes reach the hands of the users.
Administration, Customization, Dynamics CRM, Installation
(1 votes, average: 5.00 out of 5)608 views Loading ... -
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)1,247 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)1,053 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)2,608 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)1,249 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,742 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,945 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)4,883 views Loading ...
Loading ...