Uninstalling Employee Self Service Portal – step by step

Uninstalling Employee Self Service Portal – step by step

A customer of involontarily gotten a Dynamics 365 Employee portal installed. I had to remove it. It has 21 (!?) solutions which are interdependent. This is how I fixed it.

As always, I start off by trying to find if anyone else has run into the same issue, almost. This guy had with another portal type:
https://community.dynamics.com/crm/b/dynamicscrmbestpractices/archive/2017/10/14/dynamics-365-uninstalling-microsoft-portals-steps 

And then my Portal buddy Nick Doelman did some heavy lifting (he actually does!) and sent me this link. It did turn out to be a bit old though. Still useful, but the solutions described in it are not entirely accurate.

https://community.dynamics.com/365/b/dynamics365portalssupport/archive/2017/02/27/portal-troubleshooting-part-three-uninstalling-portal-solutions 

Sitemap

First of all, before you do anything else, start by removing the following things from the sitemap (unless you havn’t added more things pointing to Portal components)

1. The entire Portal “Area”
2. The SubArea and Group under Settings for Portal Settings.

Solution removal

So which solutions are we to uninstall? I will take it from the top, in the order I uninstalled them.

1 ESSPortal
2 BaseHtmlEditor_portal
3 MicrosoftForumsWorkflows
4 MicrosoftForums
5 Feedback
6 KnowledgeManagement

When removing KnowledgeManagement I got this error:
The entity with ObjectTypeCode = 10460 was not found in the MetadataCache
Tried different way, after some time, just refreshed and it was gone. Maybe this should be removed earlier. Not entirely sure which entity this was, as it was removed and I didn’t save a metadata reference before starting.

7 MicrosoftAzureStorage
8 MicrosoftBingMapsHelper
9 CustomerService
10 WebNotification
11 MicrosoftGetRecordIDWokrflowHelper
12 MicrosoftIdentity
There are two dialogs that 
Process/Dialog – Change Password, Removed all Steps. Save & Close
Reset Security Stamp – Removed all steps. Save & Close

13 MicrosoftIdentityWorkflows
14 MicrosoftIdentitySystemWorkflows
15 MicrosoftCrmPortalBaseWorkflows
16 MicrosoftCrmPortalBaseSystemWorkflows
17 Portal Timeline
18 MicrosoftWebForms

When removing this solution I also got the same weird error: The entity with ObjectTypeCode = 10439 was not found in the MetadataCache. 

What I found was that it was actually the sitemap that I hadn’t cleaned up from Portal things. This is why I recommend removing all portal related entries from all Sitemaps before starting to remove any solutions.

19 MicrosoftCrmPortalBase
20 MicrosoftCrmPortalDependencies
21 Portal Privacy Extensions

Unable to open Case entity forms – any of them…

Unable to open Case entity forms – any of them…

I just ran into one of the weirdest errors I have seen in my Dynamics CRM/365 carreer, and I have seen a few.

The problem we had was that the case entity had stopped working more or less totally. When trying to open any type of case form either as a normal user or in the form editor, I got a more or less anonymous error message. After a lot of banging my head against the wall and loosing some of my few strands of hair, I finally with the help of Deepesh excellent blog article:
https://dynamicsofdynamicscrm.com/2015/09/22/error-resolutionthe-case-of-the-form-which-stopped-loading-in-dynamics-crm/
it got me on the right track. I did some URL-hacking to try to access the form editor directly and accidentaly got to a mixed form editor. Very weird, but it showed that the form itself wasn’t broken, hence there was something wrong further down… probably the fields, just as Deepesh’s error. And after removing all custom fields, I got it working. Then tediously going back and removing them one by one, I found the culprit, a custom Lookup to the Product.

To give you some more background:

When trying to edit any case form, I got the following error:

When trying to create a new case, I got the following error:

And if I downloaded the file, the contents was: (I have hightlighted the part which has some, but only slight relevance)

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #D856E3CEDetail: 
<OrganizationServiceFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>
  <ActivityId>a3831d4c-6557-4f8a-b558-ba8c01b97e21</ActivityId>
  <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: #D856E3CE</Message>
  <Timestamp>2017-06-29T13:12:03.5384906Z</Timestamp>
  <ExceptionRetriable>false</ExceptionRetriable>
  <ExceptionSource i:nil=”true” />
  <InnerFault>
    <ActivityId>a3831d4c-6557-4f8a-b558-ba8c01b97e21</ActivityId>
    <ErrorCode>-2147220970</ErrorCode>
    <ErrorDetails xmlns:d3p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic” />
    <Message>System.NullReferenceException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #5CCC57F6</Message>
    <Timestamp>2017-06-29T13:12:03.5384906Z</Timestamp>
    <ExceptionRetriable>false</ExceptionRetriable>
    <ExceptionSource i:nil=”true” />
    <InnerFault i:nil=”true” />
    <OriginalException i:nil=”true” />
    <TraceText i:nil=”true” />
  </InnerFault>
  <OriginalException i:nil=”true” />
  <TraceText i:nil=”true” />
</OrganizationServiceFault>

Here are some facts:

  • We had installed a solution that is an upgraded solution, originally from CRM 4 via CRM 2011 and 2013. Not sure if the field definition from the earlier versions are causing this. Probably not.
  • I tried switching off all plugin steps. But it didn’t help at all. This is usually what Microsoft support will ask you to do when you have issues why I tried it myself. Always good to try and send this to Microsoft support when registering a support ticket.
  • I have tried spinning up a clean 8.2 Dyn 365 with no customizations, creating a solution with just the case entity and importing that. It did not work. Not very strange, as the problem was a field that is causing the problem. Adding solutions does not remove anything unless you are using managed solutions with patches etc.
  • I tried exporting a small solution with just the case forms and removed all custom fields from the customization file manually and reimported it. It did not work, which is not strange either, as the error was not on the form.
  • I tried creating cases via the API. That did work. I did not use the lookup field that I later found out was the culprit. Perhaps writing something to all fields in the case entity would have generated an error. The reason for doing this was that I wanted to see if I could get an exception in my code that contained more information than what I was getting in the UI. Hence I wasn’t at all happy that it did work.
  • I tried retrieving cases via the API. That did work. Again, not happy at all.
  • I tried to manufacture the URL to the form ( https://contoso.crm4.dynamics.com/main.aspx?appSolutionId=%7b<solutionguid>%7d&etc=<entityobjectid, 112 for case>&extraqs=formtype%3dmain%26formId%3d<Guid for the ofrm>%26action%3d-1&pagetype=formeditor) That did not work. No form URL with etc=112 works.
  • I tried to retrieve the form via the API, that works. Again, not happy, but at least it showed that there probably wasn’t any problem with the form.
  • I tried to manufacture a weird URL, with the correct form id with the incorrect EntityObjectID. That showed the form, but with the information that the form is for the “other” entity. Weird, but showed that there is actually nothing wrong with the form itself. I could even edit the caseform this way, move fields, remove fields, but not add new stuff. Totally unsupported way of editing a form, but when in love, war and when Dyn365 buggs out, anything is allowed.See below. This proved to be a very useful, as the form seemed for some very strange reason to be involved in this. The way I proved this was that I had an “original”, instance where the error showed and one where I had got it to work, after removing some fields, and removing all unnecessary fields from the main form. After this I created a solution which only imported the form from the non-functioning instance for the case entity and imported it into the working instance. I had not expected the result, but it actually stopped working. With the error described above. So for some reason the form was part of the problem.
    A weird Form Editor – the Case form loaded with the Account Entity (EntityTypeCode=1). Be careful when using this, and use at your own risk!
  • I got the same error as above when I try to open the case form in the normal UI.
  • When I try to create a new case, I get the error shown in the file “AnErrorHasOccuredWithTimeStampAndLog.png”
  • As for what happened with the system just before/during/when this error occurred, we were doing customizations on the case form from a spotty internet Connection, and the case for did work before.
  • In the field-section of the Case entity, I selected “Custom” fields, and I have a notion that most of these errors are probably caused by code which mix up custom lookup fields with built in ones. So I would start by looking at lookup fields based on system entities with custom relationships to case like:
    • case 1:N case
    • product 1:N case
    • account 1:N case
    • contact 1:N case
    • pricelevel 1:N case
  • However you might have several fields that are causing errors (I did), and that might make it very tricky to find what is wrong. Cause once you managed to remove the last field causing the error, and then restore the solution and then remove it again, you will find that you are back to a non-functioning entity, and you will have to work your way through each of the fields, with all their dependencies again, until you find the next one. Hence the methodology becomes
    1. Export solution
    2. Remove fields until you get the entity to work. Document exactly which fields you try and in which order. Always work in the same order. Remove a field, try to open the case, remove the next field, try to open case form, and so on. All the time documenting, which fields and in which order.
    3. When you get the case form to work, import the solution again.
    4. Remove the the field(s) that you know are causing the problems.
    5. If, after this, it still does not work, go to 2.
  • After I removed the fields, and cleaned the form, I recreated the fields with the exact same schema-names and that worked perfectly. Not sure though how it will work when I export it, I am still not sure what is causing this. Probably some erroneous code in the case logic.
  • I was able to replicate this error on other instances. So the problem is certainly connected to the solution itself. 


So to sum it up. This is most obviously a bug in the Dynamics 365 platform as it should never be able to go into this state. In my case entity the problem was two lookups AND the main “Case” form. After removing the fields and removing all non-necessary stuff from the form by using a URL hack described above, I managed to get it working.
If you run into this, I hope you manage to fix it. It isn’t easy and it will take some time. Hopefully I have given you some pointers.

    Gustaf Westerlund
    MVP, Founder and CTO at CRM-konsulterna AB
    www.crmkonsulterna.se

    Could not find GUID for server…

    Interesting error today.

    All of a sudden our development server stopped working. We got the following error in CRM:
    Microsoft CRM Error Report:

    Error Details:


    Could not find GUID for server: CRMSERVER$


    Full Stack:


    [ActiveDirectoryObjectNotFoundException: The local computer is not joined to a domain or the domain cannot be contacted.]


    at System.DirectoryServices.ActiveDirectory.Domain.GetComputerDomain()


    at Microsoft.Crm.BusinessEntities.SecurityUtils.GetGuidFromServerName(String serverName)…
     
    It seems that it was caused by the fact the the domain servers DNS was down. I have read of other causes for the same error, but make sure that the DNS service of the domain server is up and running.
     
    Gustaf Westerlund
    Microsoft Dynamics CRM Chief Architect

    Logica
    www.logica.com

    Strange problem with Country and Country Code

    A couple of days ago I had the wierdest error. We have added some fields on Acccount and a new entity called Billing Account so that there is Contry and Country Code in both. The wierd thing was that when I opened the tab with the field, after about 1 second, the country changed to “United States” and the country code to “1”. This even happened to the custom entity.

    I was confused. The country code was supposed to be according to the so and so ISO standard, where Sweden is SE. Hence 1 was very incorrect. I started looking if some tired programmer might have added some javascript or similar but found nothing out of the ordinary. Then I though I’d just like to see what happens when I run IE directly from the CRM server, and praise and behold, it didn’t change the field! That narrowed it down. First I thought it was google Toolbar, so I uninstalled it, but the error was still there. Then I tried running IE in InPrivate surfing and then it didn’t change it! So, there must be some plugin in IE that causes it. After some uninstalling and testing I found it, Swedbank has this “e-kort” or e-card program that let’s you generate a one-time VISA number, this was the program that caused this error. It is probably some program this Swedish bank has bought from some american company and it has this weird feature.

    Well, that just teaches you, don’t install a lot of crap into IE. 🙂

    Gustaf Westerlund
    Microsoft Dynamics CRM Chief Architect

    Logica
    www.logica.com