Customer Effective Blog

Installing the CRM SRS Data Connector With a Named SQL instance

When you deploy Microsoft CRM 4.0 internet facing, you also need to install the SRS Data Connector on your SQL Reporting Services server to enable reports to be generated from CRM while in IFD mode.

If your database is installed in a named SQL instance, the Environmental Diagnostic at the beginning of the installation process will error out with the error ""Unable to validate SQL Server Reporting Services Report Server installation."

The problem is that the installation looks for the SRS database in the default instance of SQL.  If it cannot find it, it doesn't think that SRS is installed.

There is a knowledge base article with a solution to this problem.  It is a pretty simple solution, which involves adding a line to the install configuration XML file and launching the install from a command prompt.

It solved the problem for me recently.

4.0 upgrade incompatibility with the CRM 3.0 VPC

We use the Microsoft CRM VPC images extensively for demo’s, and have configured them for a variety of different business scenarios. Recently I needed to upgrade the August 07 CRM 3.0 VPC image and ran into a lot of errors attempting to do so.  When I opened a ticket with Microsoft, they indicated that the VPC databases were modified in such a way that they are not compatible with the 4.0 upgrade, so if you have VPC images that you’ve done a lot of configuration with, according to Microsoft these images cannot be upgraded.  The solution in my case was to export the customizations from the 3.0 VPC environment, import the customizations into a non-VPC 3.0 image, then upgrade this 3.0 image to 4.0.  Of course in this scenario all user data from the VPC will be lost, but in most instances where a VPC is being used, the customizations are of more importance than the user data itself since these are obviously not production systems.

Error Message When Opening Reporting Services URL

Scenario: To prepare for Microsoft Dynamics 4.0 installation, we configured SQL Server Reporting Services; however, when we go to the report server URL, we see a bright red error message:

The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files'.

Problem: SRS uses ASP.net framework 2.0.50727. Sometimes when IIS is configured prior to installation of .Net 2.0 framework, some of the appropriate permissions do not get set.

Solution: To fix this issue, run aspnet_regiis with the –ga option from a command prompt. In this case, since the NT AUTHORITY\NETWORK SERVICE identity does not have access, it would look like aspnet_regiis –ga "NT Authority\Network Service"

If you are running 32-bit SQL, you would run this from C:\Windows\Microsoft.NET\Framework\v2.0.50727

If you are running 64-bit SQL, you would use C:\Windows\Microsoft.NET\Framework64\v2.0.50727

Cannot Open or Delete Records from Associated View

Scenario: A CRM administrator has added a custom child entity called Company Aliases related to Accounts in Microsoft Dynamics CRM. When a user selects the navbar icon for Company Aliases from an Account record, they see the associated view, and they can click to select one of the associated company alias records; however, they cannot open or delete any of the records. When they try, they get a message saying "You must select one or more records before you can perform this action."

 

Resolution: This error can happen when an entity and an attribute both have the same schema name. In this scenario, the person who created the entity modified the primary attribute schema name from the default new_name to new_companyalias. This can cause a problem when the entity is viewed from the associated view.

Recommendation: When you create an entity, stick with the default name schema name, or, if you want to modify it, do not name it the same thing as the entity schema name.

Thanks to Alex Farquharson for helping me find the resolution to this issue.

 

Workflows, Workflow Assemblies and Callouts

It's pretty much a given that no two organizations have the same business processes. One of the great things about Microsoft CRM is the ability to extend its functionality in a supported way with the use of workflows, assemblies and callouts. With this post, I hope to give a brief overview of each type of extension and give some basic guidance as to when each is an appropriate method for your solution.

 

Workflows

CRM Workflow offers a pretty basic set off tools to put together some automation with little technical knowledge required. Some of this basic functionality includes creating activities, such as tasks, when certain entity conditions are met, or automating some sales processes. One good example of workflow functionality is a rule that sends a welcome email to a contact when that contact's record is first entered into CRM.

Workflow rules in CRM 3.0 are somewhat limited in their functionality, however, they are still quite useful. Workflow functionality in CRM 4.0 is vastly superior to 3.0, mostly due to the ability to create workflow rule directly from the CRM environment and more data creation/update options are available.

 

Workflow Assemblies

Workflow assemblies are a great way to extend the functionality of CRM workflow rules. These accept values from the workflow rule and then return a value as output. Workflow assemblies are often used to implement some custom business arithmetic on values in a workflow, or to act as a string builder for constructing URLs to use in an email sent by the workflow.

 

Callouts

Callouts are the mother of all supported CRM customizations as you can have virtually unlimited functionality. Callouts offer a way to plug in your own code into CRM and have it be executed when certain events happen in CRM. Your The learning curve on developing callouts is a bit more than writing a workflow or even developing a quick assembly, as there is a decent amount of housekeeping that has to be done in order to subscribe to the CRM events. Callouts are also where you'll most likely end up if you've got some sort of system integration going on (absent of something that we would normally use Scribe Insight for) or if you want to do something like automatic Invoice generation.

If you've never set up a CRM callout before, it can be confusing if you're not used to how they operate. I've found a couple of blogs that give some guidance:

• Setting up Callouts
• Writing a CRM Callout Assembly: A How To

Also, the Working with Microsoft Dynamics CRM 3.0 book from Microsoft Press is an excellent resource for getting a good understanding of the CRM framework and how to incorporate server-side programming (aka callouts).

 

The general process I use to determine which method to use to implement some custom functionality is to first decide whether a simple workflow, even if it requires a bit of entity customization, can do the trick. Believe it or not, I often have to just open the Workflow Manager and try to set something up to see if a workflow can do something. When possible, it's nice to use workflow rules because they are much easier to develop and maintain, so I try to solve the problem there first. If a workflow can't do it (even with the help of a small assembly), the callout is usually the way to go.

Microsoft CRM on Virtual Server Now Supported for Production Environments

Thanks to David Yack for answering a persistent question with CRM 4.0:  Will virtualization be supported?  As Virtual Server becomes more common, and with the upcoming release of Windows Server 2008 with Hyper-V, this seems to be a question that many clients are asking.

With 3.0, the answer to the virtualization question was virtual servers are supported for test environments, but not for production environments.

With 4.0, Microsoft has changed the support policy to fully support CRM running on Microsoft virtualization platforms for production environments, and partially support it for non-Microsoft virtualization platforms (like VMware).

You can read the KB article here.

Restricting Microsoft CRM Wunderbar icons based on user security role

Jim Daly from Microsoft commented on my post Microsoft CRM Sitemap Surgery Tips. He had a great additional tip—you can restrict sitemap sub-areas based on the security role of the CRM user. Using the "Privilege" Element in the sitemap string allows you to only display the icon on the Wunderbar if a user has a specific security level for the entity.

You can use any of the following permissions:

• All
• AllowQuickCampaign
• Append
• AppendTo
• Assign
• Create
• Delete
• Read
• Share
• Write

 

For a more detailed example, see the following section of the Microsoft CRM 4.0 SDK.

 

Have you ever used the Privilege element in CRM customizations? Please post your feedback in the comments.

Open new window from wunderbar using Sitemap – an alternative approach to a CRM FAQ

We (Customer Effective) often deploy a FAQ page in our clients' CRM environments as a form of User Documentation. The goal is to be able to sit a new hire down at a computer with a CRM session and tell them to hit the FAQ for a course on creating Accounts, making Advanced Finds, and closing Activities (for example). But with CRM 4.0 our normal approach was leaving something to be desired.

Deploying the FAQ

After creating our FAQ document (complete with images and hyperlinks) and saving it as an htm file we place it on the CRM server and set up a virtual directory pointing to it. We then modify the sitemap (xml file) to add the pointer to the CRM wunderbar.

In 3.0 the sitemap simply points to the faq.htm which displays in the main CRM window. And here's the rub – in 4.0 it is displaying with no scrollbar.

As a workaround, we can use a small bit of javascript in the sitemap to call the faq.htm to open in its own window – complete with scrollbar. Here's the line from the modified sitemap for opening the FAQ in its own window:
<SubArea Id="nav_FAQ" Title="FAQ" Description="FAQ" Url="javascript:window.open('<FAQ URL>',null)" Icon="<faq_icon location>" Client="All" AvailableOffline="false" />

There are some pros and cons of this approach.

The Pros are:

1. The FAQ page opens in its own window and therefore has a scrollbar
2. The stand-alone window could prove useful for the user to be able to launch the FAQ and have it open while working on the form in question within CRM

A potential Con is:

1. The CRM window is left blank when the new window opens with [object] being the only thing displayed in the window

Audit Functionality in Microsoft CRM

Let's say that your company wants to configure Microsoft CRM to process employee expense reports, but your firm has approval levels that need to be captured. Currently, an out of the box installation of Microsoft CRM does not have auditing capabilities. Fortunately if that is a requirement for your business, Customer Effective has developed solution.   

Auditing functionality can be created for expenses, sales cycle audits or sales forecasts. Auditing can be adapted to virtually any CRM entity customer or otherwise. 

The typical audit trail would include a "From" value", a "To" value, a time or date stamp and a record identifier like the name of an expense report or a CRM user. In this case of expenses, when an update is made to an expense report (or a line item on the expense report) a server callout is made to the database and a record is inserted into a custom entity to reflect the changes that were made. And since our solution is built on server callouts it's fully supported for future upgrades.

Expense Reports - Microsoft CRM as an application platform

Many of the companies that I've worked with in the past handle expense reports using Excel spreadsheets. One problem with the Excel method that is you're required to enter that data somewhere else if you want to do any real aggregate reporting or analysis. Also there's the issue of approval and rejection of the expense line items. And then, of course, you need to notify the submitter (usually by email) so they can modify the Excel spreadsheet and resubmit…etc. For a company with a sales team spread out all over the country…that's a lot of back and forth wheel spinning. Leveraging CRM as an application platform, Customer Effective has a unique configuration for handling expenses for our customers. We even use this configuration in our own production CRM environment. 

We've created a solution that captures general expense report data (submitter, dates, approval status) as well as detailed line item information. This design has the flexibility to associate expenses to a particular account, project or even a specific project task. Since the expense piece is integrated with our project entities, we can produce internal and customer facing reports of expenses incurred against projects by running a single report. Also, expenses can be approved or rejected at the line item level or the header level. We've deployed this configuration with real-time integration into Great Plains as well, pushing expense data directly into the back office accounting operations. 

From the expenses approvers' perspective, custom views (as seen below) can be created to organize the data for the way you work. And finally, from the expense submitter's perspective, every status change on the expense report is visible in CRM so there no need to call or email the accounting personnel about the status of a submitted expense. If audit trails on expenses are a requirement, Customer Effective has a solution for that as well. 

Projects and Timesheets - Microsoft CRM as an application platform

The configurability of Microsoft CRM 4.0 really makes it more of an application platform for solving a number of issues. Let's say, for example that you'd like to track your company's ongoing projects as well as the time that your employees spend on each of the individual project tasks. At Customer Effective we've created and deployed custom configurations to accomplish this in Microsoft CRM.

Everyone has different needs when it comes collecting project related data. Since CRM can be configured for virtually anything, it is an ideal application platform for project tracking. In our custom Projects entity, we capture project financials, engagement details, project task information and open issues....as well as project expenses and time entries for tasks. Our timesheets configuration (pictured below) allows Customer Effective consultants and project managers to select specific project tasks to enter time against. This gives us an accurate, up to date status of our ongoing projects at any point in time. With the addition of our Project Status Report, we can then export this global picture of the project's status (in a number of different formats) and send it to our customers. This would be difficult to accomplish with Microsoft Project.

The flexibility of Microsoft CRM 4.0 allows us to leverage this configuration in a number of ways. For example, we do our billing, timesheets and resource planning using this configuration. Not to mention many of our dashboard reports (utilization, backlogged hours, weekly work plan, project summaries) are driven from the data captured here. And of course this configuration is fully integrated with standard CRM 4.0 functionality like activity tracking (email, tasks, appointments, etc).

Tip on publishing lookup data from CRM for integration purposes

I recently ran into a situation where I needed to push data from a lookup field in CRM (many to one relationship to the form) into an xml document using the Scribe MSCRM publisher.  In this case I had an entity (GL code) that I created as a many to one relationship to another entity (expense entry) so that users could select the gl code from a lookup on the expense entry form - this expense entry form contains the data that needs to be published to XML.  The catch here is that, when you create your publisher object for the expense entry in the Scribe console, you cannot choose to include the data in the related entity (GL code) so that it will be captured in the xml.  If you use the  "include parent/child object" functionality of the CRM publisher, it will not include this related entity so the xml will be missing the all important GL codes when the user saves the expense entry record in CRM. 

There are several approaches to working around this limitation, but the simplest solution I've found is to create an ntext field that resides on the (in this example) expense entry form, then use onchange javascript (listed below) to copy the value that the user selects from the gl code lookup into the ntext field that resides on the expense entry form.  This way the gl code data that is copied to the ntext field on the expense entry form will be exposed by the CRM publisher and available in the resulting xml.  Obviously you will want to hide the ntext field that you create on the expense entry entity as its only purpose is to act as a placeholder for the gl code data so that it can be published with the rest of the expensee entry data.

var lookupItems = crmForm.all.new_glcodeid.DataValue;
var name;

if (lookupItems != null) {
    // There is a lookup value
    var lookupItem = lookupItems[0];
    name = lookupItem.name;
    }
else {
    // There is no lookup value.
    name = "";
    }

// Update the GL Code text field.
crmForm.all.new_glcode.DataValue = name;

Run Microsoft CRM Reports Off-Line

One of the best new capabilities in the Microsoft CRM 4.0 offline client is the ability to run CRM reports off-line. When you install Microsoft CRM for Outlook with Offline Access, it will install the Microsoft Report Viewer Redistributable 2005. When you are on-line, reports will run as normal in Microsoft CRM. When you "go off-line," the reports will still run; however, they will only reflect the data synched to your off-line SQL Express database.

This is a fantastic new capability, as it allows users to view reports on their local data, even when they are not connected to CRM.

If you decide to deploy off-line reporting in CRM, you will need to consider the ramifications that it has on hyperlinks. If you include any drill-through hyperlinks to CRM in your reports, you will not want to "hard code" your CRM URL (for example http://crm/etc).

Instead, use CRM's CRM_URL hidden parameter to build your CRM hyperlinks. You can see full details here. In a nutshell, here are the high-level steps:

1. Create a parameter in your report called CRM_URL. Check the checkboxes to allow null values and internal.
2. When you build your hyperlink, use the following format (in this example, for accounts):

   =Parameters!CRM_URL.Value & "?OTC=1&ID={"& Fields!accountid.Value.ToString() &"}"

3. Update the "OTC=" with the object type code of the entity that you are linking. If you don't know the OTC of the entity, consult the Microsoft CRM Metadata Browser.
4. Remember that the OTC for custom entities can be different in different environments. If you decide to publish your report to another environment, and it includes a hyperlink to a custom entity, you will need to update the hyperlinks. The good news is that if you are linking to a system entity, you will not have to change anything—your dynamic hyperlink will work fine.

The result will be a dynamic hyperlink that will point to the CRM server when viewed on-line, and link to the local machine CRM environment when off-line.

This approach will also ensure that your links work properly when viewed via Internet Facing Deployment.

One caveat—the CRM_URL hidden parameter only works when reports are viewed via the CRM report viewer. If your reports are viewed external to CRM, like on a SharePoint dashboard, you will still need to hard code the CRM URL. Not too big of an issue, because if you were able to view your SharePoint dashboard, you would have to be on-line.

Helpful info if your integrating sales orders in CRM using the Scribe MSCRM 4.0 adapter

If you ever need to write a dts that will insert/update any of the total fields (totalamount, totalamountlessfreight, totaldiscountamount, totallineitemamount, or totallineitemdiscount amount) on the sales order header in CRM and you are using the Scribe MSCRM 4.0 adapter, you MUST run the dts as the INTEGRATION user.  If you try to run it as an AD user (even if it has privusergroup access), you will receive errors.  This is new to 4.0 as with previous version of the Scribe MSCRM adapter this was possible.  The catch-22 here is that I've never been able to successfully process sales orders through scribe using the "integration" user setting.  More detail on this below . . . .

I ran across this recently when I upgraded all of the scribe componenets (Insight 6.2.2, GP Adapter 3.8, and MSCRM adapter 4.0) for a customer that was running a GP-CRM integration that I had previously implemented, and after upgrading the MSCRM adapter from version 3.5 to 4.0, the integration of sales orders between CRM and GP ceased to function.  When I looked in the execution log, I found the following error:

Repeating the step failure due to an error on previous row
(salesorder.totalamount cannot be updated unless running as INTEGRATION
user.)

This error relates to the 'run as user' setting that scribe uses to process the dts through the MSCRM adapter.  By default, the integration dts's run as user "integration", which is not an active directory user but a user internal to scribe that can be used process dts's without having to burn up an AD license on a dedicated user.

I've never had any luck with using the INTEGRATION user so one of the first things I always do when configuring an integration with sales orders is to change this to an AD account that has privusergroup access.  Whenever I've tried using the INTEGRATION user, the following error always results so if you see this error this is more than likely the culprit:

ExecuteRequest failed: Not enough privilege to
access the Microsoft CRM object or perform the requested.
operation.

I've asked Scribe about this but there is no known solution to date that I know of (and no, running unlockso.sql does not help). 

If your doing a GP-CRM integration using scribe, the use of an AD account for the sales order dts's (ordertocrm.dts, ordertocrm_transferred.dts, invoicetocrm.dts, invoicetocrm_posted.dts) works great for MSCRM adapter version 3.5 and lower, but with the Scribe MSCRM 4.0, some code has been added so that you are REQUIRED to use the integration user for these dts's since this is the only user that has the ability to update the total fields on the sales order header.  I inquired into this with Scribe, and they are looking at possibly changing this functionality so that this requirement is no longer an issue with the 4.0 adapter.

So how did I resolve the issue?  I downgraded to the 3.5 adapter and all is well again.  Obviously this is really just a work-around for the present time as support for this version will be phased out, and if your on CRM 4.0, as I recall th 3.5 adapter is not compatible with that version of CRM.  I'll put out another post as I get updates from Scribe regarding this issue. 

Managing the Windows Indexing Service for Microsoft CRM

Applies to 3.0 and 4.0

What is the Indexing Service?

The Indexing Service is a Windows service that indexes files to improve search performance (see Wikipedia for detailed description).

Why does Microsoft CRM require Indexing Service?

Microsoft Dynamics CRM uses the indexing service to index the CRM help files. It is required to be installed and running on the CRM server, or on any clients running the Outlook client with offline access (formerly called "laptop client").

What's the problem?

In some cases, especially on the client, the indexing service can be a resource hog. I recently installed and configured the offline client on a brand new Windows XP laptop. Everything went ok; however, afterwards I noticed that system performance was extremely slow. After checking the task manager, I found that cisvc.exe (indexing service) was eating up 97% of CPU resources.

So what can be done about it?

There are several things that you can try if you experience this problem:

• Wait and see—wait a while to let the indexing service finish indexing the CRM help files. Reboot, and see if the problem persists. After the initial indexing of the CRM help files, the indexing service should use a very small amount of resources (unless another application is using the service and causing the problem).
• Uninstall the indexing service (under add/remove windows components) and reinstall it—in case the service is corrupted.
• Customize how often the Indexing Service is used on the workstation. Within Administrator Tools/ Computer Management, right-click the Indexing Service, navigate to All Tasks | Tune Performance, click the Customize radio button, click the Customize button, and adjust the slider(s) to the lowest setting. Then, reboot the workstation and monitor the performance of the Indexing Service.
• Since the indexing service is only used to index the CRM help files, you probably could disable the Indexing Service and your CRM client would probably work ok. However, this is not supported by Microsoft, so I would not recommend it.

In my case, the wait and see method worked for me. After the initial indexing was complete, the indexing service is now using <1% of cpu resources.

Microsoft CRM Customizations Zip File

If you have spent any time exporting customizations from Microsoft CRM 4.0, you have probably noticed that the customizations xml file is now exported in a zip format. This presents several advantages:

1. It speeds up the time of the customization export.
2. It simplifies emailing a customization file to somebody else, as Outlook does not support emailing of XML files.

But, did you know that you can also import customizations in zip format? I was under the impression that you had to extract the customization file before you imported it, but by accident I discovered that you can actually import a zipped customization file.

I've found that it seems to take a little bit longer to import a zipped customization file than an unzipped xml, but it is nice to save a step.

Lessons learned from using the CRM IFD tool

With Microsoft Dynamics CRM 4.0, you can configure your CRM implementation to work internet facing. In other words, users can access CRM without having to be logged in to your network or using VPN, and they can access all functionality, including reports.

From implementing a couple of IFD environments, I have found a few things that may not be clear from the documentation for the IFD tool.

1. When you unzip the ifd tool, you have to save it to the c:\program files\microsoft crm (or whatever your crm program file name is)\tools folder, otherwise it will not run.
2. When you run the IFD tool, you will need to specify only the domain name in the SDK and root domain fields—do not enter anything like crm.domain.com—just domain.com
3. Your external URL for your crm needs to be in the form of crmorgname.domain.com. You will know your CRM org name because when you run the IFD tool, it will display it in the gray box in the lower left corner of the form. You will need to set up a CNAME in DNS with the name of the CRM org name pointing to the CRM URL. If you want to have your external url be something other than your crm org name, you will need to set up a CNAME pointing to the org name URL.
4. If you use an ISA or other firewall, you will need to enable forms authentication for the CRM server.
5. After running the IFD tool, when you go to the external url, you should see a blue login form, not the windows login box, if your IFD deployment has been successful. If you see the Windows login dialog box, CRM is trying to authenticate via Windows Authentication, not IFD mode. This login form will be located at http://crmurl.domain.com/signin.aspx

Also, be sure that if you want IFD users to be able to run reports, that you install the SRS connector. The SRS connector is located in the CRM installation.

CRM 4.0 License Keys

Microsoft Dynamics CRM 4.0 license keys for products obtained in Volume Licensing are embedded in media -- the keys do not appear on MVLS; as they do for some products; nor are they printed on the media itself (DVD) or on the media sleeve; The physical media and the downloads from MVLS/VLSC both will contain the license key in a text file, so Customers may either download the product or order the physical media and simply install it – the install will look for the license key file in either case!

If the Customer started with a TRIAL version, and is using a TRIAL key, the only reason they would need to look for a license key is if they do not want to reinstall the product over the TRIAL, in which case they find the license key file in the download files or on the media and enter the key into the license manager.   The key will be located in a file called ‘license.txt’ in the download or on the media.

For Microsoft Dynamics CRM 4.0 media obtained through the Dynamics ERP product price list/Business Ready Licensing, keys ARE NOT embedded in the media, and must be obtained from the Dynamics CRM Partner, who can obtain them in PartnerSource.