Import Organization Failed: Subquery returned more than 1 value

While trying to import a CRM 2011 organization to CRM 2013 I encountered the following error:

Viewing the log detail unfortunately file did not shed much more light on this.

The only thing I had to go on was the SQL error itself. This indicated that somewhere the system was trying to execute a nested SQL statement that looked something like the following:

select field1 from table1 where field2 = (select field3 from table2)

And that the results from table2 returned more than a single row which is not allowed as the nested relationship is using the "=" rather than "in" operator.

Armed with this information, I decided to run a SQL trace while recreating the import error. And then performed a bit of a needle-in-haystack search for something that might fit the above - using correlating times from the SQL Trace and CRM trace file (although in retrospect I think I could have searched the SQL trace for a statement like 'update organization set set state=...' as this is what happens directly after the failed error).

Lo and behold, I came across the query below which matched the kind of query pattern I was looking for. The suspect had been identified...

Running the essence of the above query in SQL it came back with the following - looks like a smoking gun to me!

In the interest of moving forward as quickly as possible, I decided to run a query that eliminate this particular error by ensuring a singleton output.

update Role set RoleTemplateId = null

where RoleId != 'BDD45E0B-7482-DC11-AB36-005056BC02DA'

and RoleTemplateId='A4BE89FF-7C35-4D69-9900-999C3F603E6F'

Re-running the import again subsequently succeeded... and yet another successful CRM 2013 upgrade under the belt.

Run Report button missing on Forms

We noticed that certain forms in a CRM 2013 upgraded installation were missing the embedded "Run Report" option in the command bar. It appears in some forms but not in others... with no apparent rhyme or reason. For example, below is a screenshot of the upgraded opportunity form:

Anyone see the Run Report option? Neither do I... and the reason cannot be attributed to there not being any context sensitive reports for opportunities. There indeed are!

Yet... it does appear in the command menu for the grid view. Go figure.

I found this post which pointed me in the direction of the resolution. It references two options for resolution. One by directly modifying the export XML for the entity. And the second by using the Ribbon Workbench tool.

The first solution is the way to go. Quicker and easier and does the job. That is, you just need to add the following command definition to the RibbonDiffXml of the entity.

<CommandDefinition Id="Mscrm.ReportMenu.Form">
    <EnableRules>
      <EnableRule Id="Mscrm.FormStateNotNew" />
    </EnableRules>
    <DisplayRules>
      <DisplayRule Id="Mscrm.ReadReport" />
    </DisplayRules>
    <Actions />
</CommandDefinition>

After importing and publishing, the reports have returned to their rightful place (ok I know the report icon is still missing but that is a battle for another day).

Debugging Workflow Plugins in CRM Online

The Plugin Registration Tool has some important features to enable the effective troubleshooting of workflow plugins (and plugins in general). The following posts contain useful walkthroughs of these debugging features:

Debugging standard plugins:

http://guruprasadcrm.blogspot.in/2011/11/how-to-debug-crm-2011-online-plugin.html

Debugging workflow plugins:

http://blogs.microsoft.co.il/rdt/2013/03/08/debugging-workflow-custom-activities-with-plugin-registration-tool/

But sometimes I find that adding good old-fashioned trace statements to the plugin code can also come in very handy.

The following illustrates this form of debugging for workflow plugins:

1. Add the ITracingService reference
2. Output trace information at various points
3. Throw an exception to force the trace information to be output

The plugin will fail as you have forced an error by throwing an exception. And you can now go into the failed workflow and view the trace information that was outputted. 

Error running a report via Outlook Client

Update from Microsoft (3/25/14):

          The issue appears to be fixed:

I received confirmation that the team has processed a change with the NLB system used by CRM Online. As a result, this incident with receiving script errors when running reports from your CRM Online organization should now be resolved.

Update from Microsoft (2/20/14):

After working with my team further, we were able to reproduce this problem internally (not using CRM Online). The problem is specific to a setting on the load balancers used by CRM Online. As such, it appears that this will affect Office365 based organizations (which to be honest makes more sense now). The setting on the load balancers was something recently applied in the move to CRM 2013, however our internal teams are getting approval to undo that change which should resolve this problem. They gave me an approximate 2 week timeframe to get proper approval and undo that change. We’re currently about 1 week through that, so we should be close to having this problem fully resolved.

Update from Microsoft (1/31/14):

The core problem is still being investigated, however a “workaround” was discovered that ties in with the new ‘Process Isolation’ feature of the CRM Client for Outlook. There is a registry key that can be applied on client systems to disable the feature. Testing on our side so far looks promising as the script errors on reports have ceased after disabling the feature. This is by no means a solution to the problem and our teams are still actively investigating. If you wish to test this, I’ve included the registry key below to implement on a client. If you confirm it also works from your side, we can discuss pros/cons of this workaround and if it’s feasible for your organizations.

Key Path: HKEY_CURRENT_USER\Software\Microsoft\MSCRMClientKey (DWORD): UseWebFormProcessIsolationValue: 0

-----------------------------------------------------------------------------------------------------------

In one of our CRM 2013 online instances we are receiving errors whenever trying to run a report from the Outlook client. The error looks something like in the examples below (errors occur one after the other).

This does not happen when running reports via a browser so clearly some kind of platform issue. It is somewhat sporadic too and seems to be related to browser cache. So it might go away and then come back at a later point in time. For example, one solution I tried was to delete/recreate the report as I figured that it was perhaps due to some upgrade issue from 2011. This solved the issue for a while but then it returned.

And this was confirmed by Microsoft who are currently troubleshooting the issue. The following is the current guidance provided by Microsoft:

Per our phone conversation, this issue with running reports in the CRM Client for Outlook against a CRM Online 2013 organization on our CTP authentication platform is currently a known issue that has recently been brought to our attention. We are actively investigating this problem and I’ll keep you posted as I know more. Currently, we believe this may be a server side setting – but the investigation has not yet yielded the exact cause of the problem. Unfortunately there is no workaround for the web client other than using the CRM Web Client (i.e. Internet Explorer).

CRM 2013 Insufficient Form Permissions

We had some users who encountered a strange error in their upgraded CRM 2013 environment. We saw this happen on the account and contact form whereby the users were presented with an "insufficient permissions" error when they attempted to open the form.

The resolution proved elusive because the issue itself was very inconsistent. A little hard to explain or understand but the following example illustrates the type of behavior that was being experienced:

1. User experiences permission issue
2. Assign system administration role to user
3. User able to open forms
4. Remove system administration role from user
5. User still able to open forms
6. Later on user again experiences permission issue

So without changing anything the problem mysteriously goes away. Only to resurface at a later point in time (usually after logging out/in but not even that was consistent). So somehow this issue seemed to "cache".

This was despite the fact the user roles assigned did indeed have the necessary read permissions for these entities. And the users could in fact see the views for these entities but were blocked with the message above when trying to open any record.

The first thing to track down was to ensure that the users had permissions to the forms in question. After all, we had created a custom form to replace the built in version as part of the 2013 upgrade merge effort. But this also passed the test with the form being accessible to everyone (and enabled as fallback even though this was irrelevant since this was the only active Main form for the entity).

So this issue had to somehow be permissions related. After a bit of trial and error the issue seemed to hinge around the following "Process Configuration" read permission. This permission existed in CRM 2011 but for some reason (bug?) CRM 2013 is now requiring it to open these forms.

CRM 2013 Notes Control only showing notes

CRM 2013 has a handy new feature for displaying activities, notes, and posts in a single control. This is very easy to configure by just selecting the "Notes" control in the form designer.

You can subsequently also define the default view for this control in the properties. As an aside, it's also recommended to uncheck the "Display label on the form" check box as it will display better without this.

So far so good. Except for one small wrinkle - the "Activities" and "Posts" tabs for this control do not show...

I found a solution to this issue which is outlined in this blog post. Although it does appear to be an issue even for forms that have already been "upgraded". Case in point - the form that I was working with was a new form created in CRM 2013 for an existing entity and the issue still appeared.

Anyway, as described in that post, the issue is fixed by modifying FormPresentation node for the form in question from 0 to 1.

After importing and publishing, the 3 tabs for this control display as expected.

CRM 2013 Report Error: "An error has occurred. Try this action again..."

We were getting an odd error when running a CRM report in an environment that had been upgraded from CRM 2011 Online to CRM 2013 Online.

In short, we were getting the following rather unhelpful generic error message:

This error only occurred with a few of the records but ran fine for other records. In order to troubleshoot, I removed all the front end components of the report so that essentially the report would just have a blank rendering. And even after doing this, the report still gave up the error above.

So this seemed to point to the fact that there was some issue with the data set...

As it happened this data set had a link-entity join clause and I discovered that when you added in the linked record such that the join would succeed the report would run fine. And in cases where the join did not bring back results the report error would occur - this being our particular case.

So this explained why it occurred only for certain records whereas not for other records in the system. However it does not explain why this error occurs in the first place. At the most I would expect the report to not render results when a join does not bring back results. After all in many cases it is perfectly valid to have a join that does not succeed. Even if there was an error caused by the lack of the join, I would expect to see this error manifesting itself in the returned report as is the case for example when running a report where the sub-report it is calling does not exist.

All in all, while I'm glad I discovered the issue, this does seem very much like a bug in the platform to me.

CRM 2011 UR12 and SharePoint Integration

After having applied the Polaris upgrade (update roll-up 12) the native CRM/SharePoint document integration stopped working. There were two different ways in which this issue manifested itself:

1. When clicking on the Documents link we just received the "spinning wheel" and the page did not load
2. On the occasion that it did succeed to load, the "New" and "Add" buttons did not work i.e. nothing happened at all when clicking those buttons preventing new documents from being added.

As I discovered, it is apparently necessary to update the List Components of SharePoint following the application of UR12. The updated List Components can be downloaded from the following location: 

http://www.microsoft.com/en-us/download/details.aspx?id=5283

This issue is also described in the following KB article along with the steps required for installing the List Component:

http://support.microsoft.com/kb/2810528

Xrm.Utility.openEntityForm no longer working

*** Update 3/5/2013: This issue has now been fixed via a Cloud update ***

Other known issues with UR12 can be tracked here: 
https://community.dynamics.com/crm/b/dynamicscrmsupportblog/archive/2013/01/28/december-2012-update-has-been-released.aspx

******

If you have a CRM Online installation and the Xrm.Utility.openEntityForm jscript function which you *knew* was previously working but apparently is no longer.... well, the good news is that you're not going mad. The bad news is that it is indeed a bug that has been introduced in the current (as of this writing) version of CRM Online. Or as confirmed from Microsoft:

Issue Definition: Xrm.Utility.openEntityForm does not work anymore since Update 5.0.9690.3339 on the CRM Online organization.

I have confirmed that this is an issue with the latest update that has been done with the CRM Online organizations. We are currently working on the code review and should have the fix in place shortly. 

The Microsoft support guy I spoke to indicated that this would likely be fixed within a week although I do not have a definitive date.

For the sake of reference below is the text of the error received when trying to use this form open utility.

object doesn't support property or method '$2b'

We encountered this strange error in a CRM online environment. The symptoms were as follows:

1. Only occurred on the Outlook client (not in IE)
2. Occurred even when form jscript was disabled indicating issue was not with the script
3. Appeared when closing out the contact form

The error message looked as follows:

After a bit of scratching around the solution presented in the following forum discussion seemed to work. Or in short as follows:

1. Close Outlook and IE
2. Open IE and delete temporary files (Make sure to uncheck “preserve favorites website data”)
3. Now if you open outlook, you might see that On the Grid's Ribbon is loading... WAIT for it to load
4. Open the Account, Lead, Appointment

Cannot add more picklist or bit fields

I came across this issue today in a 4.0 environment that still uses SQL 2005. Time to upgrade, huh? Happily that's soon to be the case - so this hopefully is just for the record books.

Anyway the symptom was that while the user was able to add nvarchar fields to the accounts entity, it would error out each time the user wanted to add a new bit field (or for that matter a picklist) it would fail with an error message.

Using the trace tool it took pretty quick to identify the underlying cause. The following exception appeared in the trace file:

Exception: System.Data.SqlClient.SqlException: Too many table names in the query. The maximum allowable is 256.

So what is causing the "too many table names" in query?

Simple. Every time an attribute is added to an entity, the entity views (regular entity view and filtered view) are updated. The filtered view in particular joins to the StringMap view for picklists and bit fields to obtain the corresponding friendly "name" field. For example, for an account field called "new_flag" it will join to StringMap view to create a new virtual field in the FilteredAccount called "new_flagname".

One only needed to look up a little higher in the trace file to see the view being constructed with many joins for the bit and picklist fields. Such that if the number of these two types of field combined exceeds 256 (or thereabouts given other joins that may already exist) it will cause this join limitation to occur. Which is only a limitation on SQL 2005. This is no longer a limitation from SQL 2008 and up.

The options for resolving this issue are therefore:

1. Upgrade. Really. The technology you are using is around 7 years old (at least) and there does come a point where the compelling reason to upgrade is just the combined benefits of all the various enhancements that have been introduced over time (that is, if you cannot find a single compelling reason).
2. Clean up your system and review whether you actually do need all those fields in your environment. This actually is relevant whether you upgrade or not. I'm a big proponent of keeping the environment as clean as possible as my first post on this blog will attest to (disclosure: the above environment is extended directly by the client as we like to encourage our clients to do so they are not reliant on us for every little change required).

CRM Outlook Form and Display Rules

There seems to be an issue with the Outlook CRM create form as it relates to the Display Rule for ribbon buttons. More specifically - and by way of example - you can add a custom button to the ribbon and set it up with a Display Rule to control when the button should show. For instance, you can set up a FormStateRule where State = Existing and this will tell the application that the custom button should only show on the edit (update) form and not the new (create) form.

So where's the issue?

Well in addition to the Display Rule, you can also define an Enable Rule which controls whether the button should appear in an enabled or disabled (i.e. greyed out) state. The Display Rule trumps the Enable Rule i.e. if the Display Rule returns a "Do not display" result, then there's no point in executing the Enable Rule to determine how to display it. Which of course makes sense and is how it should work.

The good news is that this is precisely the behavior if you open up the create form using Internet Explorer navigation. Yay!

The bad news is that it seems that the same behavior is not exhibited if you open up the create form using Outlook navigation. And just to make sure you know what I mean by "Outlook navigation" below is a screenshot to help clarify this:

Outlook Create Form - note the icon at top left

Versus the same form opened using Internet Explorer:

IE Create Form - note IE container

The issue of course is that in the case of the Outlook Create Form it will execute the Enable Rule function whereas in the IE Create Form it will not. And the result might be an error in the Outlook Create Form as the function may not be relevant to such a form state.

Fortunately there is a work around until Microsoft fixes this issue (which I haven't made them aware of as the workaround is quite effective and not too onerous). Simply add a condition to your custom jscript function to limit it to working with update form as highlighted in the example below.

function CustomButtonEnableRule() {

 if (Xrm.Page.ui.getFormType() == 2) {
     // function logic
 } else {
     return false
 }
}

Cannot delete reports

On occasion I have encountered an error while trying to delete reports from the CRM user interface. The specific error message being: "Error occurred while deleting an item from the report server":

The error details are as follows:

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #9B008CA6Detail:
<OrganizationServiceFault xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/xrm/2011/Contracts">
  <ErrorCode>-2147220970</ErrorCode>
  <ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
  <Message>System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #9B008CA6</Message>
  <Timestamp>2012-07-26T08:26:48.1031182Z</Timestamp>
  <InnerFault>
    <ErrorCode>-2147187945</ErrorCode>
    <ErrorDetails xmlns:d3p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
    <Message>Error occurred while deleting an item from the report server.</Message>
    <Timestamp>2012-07-26T08:26:48.1031182Z</Timestamp>
    <InnerFault i:nil="true" />
    <TraceText i:nil="true" />
  </InnerFault>
  <TraceText i:nil="true" />
</OrganizationServiceFault>

The error seems to be caused by the fact that the report has lost its reference back to the reporting services report repository (i.e. CRM org folder under http://<server>/reports).

The easiest way to deal with this issue is to simply upload a working report definition into the errant report. And subsequently you should be able to perform the delete operation.

Cannot open entity customization form

We were experiencing an issue whereby we could not modify the contact entity web form. Every time we'd try and open up the form editor, the following error message would be issued:

A little bit more information was revealed after turning on DevErrors:

Not sure how this issue came about but I imagine it's likely only to occur in an upgraded environment. Away, after a bit of digging I came across the following article which seemed to describe the same problem (albeit for the lead form):

http://blogs.msdn.com/b/atif/archive/2012/01/22/unable-to-open-lead-entity-form-in-crm-2011.aspx

So I decided to export my contact entity and perform a search on all cases where "rowspan" has a value greater than 1 (e.g. rowspan="4"). I came across 6 cases and in each case I performed a count of the row elements and they matched up with the rowspan count. Until the very last one that is...

In short, the screenshot below is what I found.

The rowspan count equalled to 4 yet there was only one row element (the one containing the rowspan element). So I added in 3 additional row elements as shown in the highlighted text, imported the customization and published.

And just as advertised this resolved the issue.

Contact: Details Updated Change Log

This particular issue has been troubling me for quite some time. Every now and then, in a particular client installation, a bunch of contact records would get updated and the update would be logged in the Notes section showing the previous and current values.

Not only is this issue a little bit annoying, but when you combine this with the fact that this contact will then get updated in CRM and subequently propagated to other users' contacts folder - well then you have data pollution. First of all, the change log is unnecessary and it doesn't take long before people start blaming "CRM" or the "Outlook Client" for making these unsolicited changes. Second of all, it can in fact make changes that you don't want. Like in the screenshot above where "USA" is being replaced by "United States" where you might have certain standards and/or functionality based on the specific values that appear in a particular field. Third of all, it generates unnecessary updates that need to be uploaded and then downloaded to all other clients ("what? I didn't make changes to those contacts..."). And let's not even mention the cryptic audit comment that is written to the notes that now will appear on all contact records that get updated and if the values get reverted back to what they were previously (i.e. the correct values) this audit will appear again and again...

This particular update seemed to occur only for internal company contact records and not for external contact records. And through various tricks of the trade I was able to verify 100% that this update was not coming from CRM - rather CRM was just the conduit for propagating it as described above. But the problem was that I could not attribute this to other 3rd party software... so it was a little hard convincing the client without another prime suspect.

I finally came across the following forum posting which seemed to describe the issue I was facing to a tee: http://social.technet.microsoft.com/Forums/en/outlook/thread/8fa240c6-fb3b-48fc-b7d4-8a82919e3912

In short, from this posting 2 prime suspects emerged. The most likely one being the "Microsoft Exchange global address list (GAL) synchronization with Microsoft Outlook 2010" feature and this feature can be disabled using Group Policy as described in this article: http://technet.microsoft.com/en-us/library/ff871432.aspx. This presumably resolves the problem globally as it uses Group Policy.

The second suspect is the "Social Connector" feature that is built into Outlook 2010 and which apparently also has this change logging feature. This can be disabled on a client by client basis by navigating as shown in the screenshot below.

As can be seen, the default is "update without prompting" - a little hard to understand why it would have been designed this way. For me personally, and it seems for many others, it could have saved a few gray hairs if the design of this feature gave a little bit more consideration to the user experience.

"Error on page" redux

Recently I encountered this troublesome error yet again. And once again it proved to be the type of error that makes one wonder if perhaps the time has come to pursue another career... if you know what I mean.

The symptoms were as follows:

• When navigating to an account, contact, etc. via the standard CRM UI navigation, everything worked fine.
• When navigating via drill down from any CRM report (that adheres to the standard SDK report writing standard), the "Error on page" would show up. Other than the message everything loaded fine but of course, when the form was closed you would receive the standard "Send us the error report and have no fear that someone will indeed be reviewing, analyzing and making sure this gets resolveds asap back at Microsoft HQ"... or something like that.

When clicking on the "View the data that will be sent to Microsoft", the following is what appeared.

Line>352</Line>
<URL>/main.aspx?etn=account&extraqs=etc%3d1%26id%3d4288f08f-31c3-dd11-8d14-00104b325722&id=4288f08f-31c3-dd11-8d14-00104b325722&pagetype=entityrecord</URL>
<PageURL>/main.aspx?etn=account&extraqs=etc%3d1%26id%3d4288f08f-31c3-dd11-8d14-00104b325722&id=4288f08f-31c3-dd11-8d14-00104b325722&pagetype=entityrecord</PageURL>
<Function>anonymous(){try{action();}catch(e){if(e.number!=-2146823277){throwe;}}executeActionQueue();}</Function>
<CallStack>
<Function>anonymous(){try{action();}catch(e){if(e.number!=-2146823277){throwe;}}executeActionQueue();}</Function>
</CallStack>
</ScriptErrorDetails>

I should also mention that this occured on forms without any jscript libraries present (active or non-active). At some point, I even tried creating a completely vanilla CRM installation on the server and the error persisted even in that environment!

I first received this error with rollup 7 installed on the server, so I uninstalled that but the error persisted. Eventually I installed rollup 8 and magically this error went away. I am not sure if update rollup 8 truly resolved this issue, whether it coincided with another server reboot that somehow cleaned up whatever was polluting the environment, or whether the stars were once again aligned for me. But whatever it was I think it salvaged my dwindling supply of hair.

Report not showing under "Run on Current Record"

This has happened to me on a number of occassions. I modify an existing report making sure it adheres to all the CRM SDK reporting standards and in the report definition I make sure to specify that he appropriate entity/entities are entered in the "Related Record Types" and that the "Display In" is set to "Forms for related record types" and/or "Lists for related record types".

Yet when I open up the entity form (in the example above this would be a Marketing List record), the report appears under the "Run on All Records" section rather than under the "Run on Current Record". While this would be ok had the report not been linked using the context-sensitive "CRMAF" nomenclature - in this case, the report has been written such that it should be context-sensitive. So why does it show in the wrong section?

The behavior that I've observed is that if the report is created initially such that it does not adhere to context-sensitivity, it will rightly appear under the "Run on All Records" section. Later on, if you modify the report definition to include context-sensitivity it will still remain in this section.

If that is the case simply deleting and recreating the report will resolve this issue. At least that's been my experience.

The product key is not compatible with the installed version of Microsoft Dynamics CRM

I encountered this error message while recently trying to apply a permanent license key to a CRM installation.

The error message was clearly wrong because the license key was for the same version as the trial license.

The solution was to essentially ignore this error message. And the way to do so was to add a registry setting that instructs the installation wizard to ignore the errors arising out of the pre-installation systems checks and allow you to click "Next" to kick off the installation. This allowed the new license key to be updated without any side effects to the CRM installation.

The steps required to do so can be found here.

IFD Sign In Prompt for Dynamic Excel Exports

If you have set up IFD (internet facing deployment) within your organization and you attempt to export to a dynamic worksheet, you may be presented with the IFD Sign In prompt (see screenshot) presented in the CRM spreadsheet rather than having your data auto export to Excel.

If this happens, first try and navigate to the Data tab in Excel and click the "Refresh from CRM" icon. If that doesn't work, try with the "Refresh All" option.

If this still doesn't work, then do as follows:

• On the Data tab click Connections to open the "Workbook Connections" window
• Click Properties
• Click the Definition tab
• Click "Edit Query"
• Enter your credentials

After authenticating do as follows:

• Click Ok on the Error window (after entering credentials)
• Click Cancel on the Edit Web Query window
• Click Ok on the "Connection Properties" window
• Click Close on the "Workbook Connections" window

After having performed these steps, try to refresh once again first using the "Refresh from CRM" icon and if that doesn't work, click "Refresh All" and your data should appear.

I am not currently aware of a permanent solution for this issue.

Manually uninstalling CRM 2011

I encountered a situation where CRM 2011 did not uninstall cleanly which left the server in a state of limbo i.e. you could not re-install CRM as the setup process detected that CRM was still installed and prevented re-installation, but the CRM program was also absent from the Add/Remove Programs and therefore you could not re-run the uninstaller.

I also encountered this situation with CRM 4.0 but in that case there is a published KB article describing how to go about uninstalling the application manually. I could not find an equivalent CRM 2011 KB article so - given the lack of options - I decided to follow the instructions outlined in the 4.0 KB article.

The end result was that I managed to uninstall the application following these guidelines but I had to substitute some pieces of this process as outlined below. Please note that this is not an official guideline from Microsoft so you will need to assume the risk in following these steps.

In short, you need to walk through the steps in the following KB article:

http://support.microsoft.com/kb/946980/en-us

However in Step #7:

• Replace references of 059DD8CB00184F24E99A62CF4D6109FA with 55D425C090410500DBE735E02565E025 (points 2-11).

• Replace references of {BC8DD950-8100-42F4-9EA9-26FCD41690AF} with {0C524D55-1409-0050-BD7E-530E52560E52} (points 21-22).