by gustaf | Nov 29, 2017
If you are using Dynamics 365 Online, Dynamics 365 Support is your IT-department for your Dynamics system and you need to know or start learning how to working with them in a good way. There are several things you should consider.
Registering a support ticket
First of all, registering a support ticket is of course important. This might not be as trivial as it seems, as it depends on which type of license you have. If you have bought your licenses using CSP (Cloud Service Provider) or Select/Volume Licensing then you will most probably be directed to your CSP/Select partner for any support issues. You can of course buy premier support from Microsoft but that might not always be an option for smaller companies. There are some tricks as well if you are stuck with CSP/Select or similar, and will be happy to tell you about these in person if I meet you, but I won’t write about them, as I am afraid it will be “fixed” which would be sad.
If you have bought your licenses directly through the O365 portal, you can also create a ticket using the portal. You need to be a Global Admin or a Dynamics 365 Service Admin to place a ticket. Currently you cannot indicate that the ticket is for Dynamics so you simply write so in the text and the O365 support team will create a new Dynamics 365 ticket for you. I was amazed at how fast the Office 365 support called me after registering a ticket, I think it took less than 1 minute. So I would suggest you choose the option “call me”.
If you have a partner, I strongly suggest that you register them in the Office 365 portal for the Dynamics 365 subscription as Partner of Record (PoR). This will make your company show up in their Microsoft partner portal where they can register a support ticket for you.
Checklist
When registering the ticket with Microsoft, there are some things you have to note:
- Be polite. Even if your system is slower than sirup in January (a Swedish saying) or nobody can log in, you will not be getting any help faster by screaming or being rude. I like to quote my grandfather who had a good saying: “Better to be strong in argument and withheld in words, than the other way round.” I have actually gotten written compliments for being nice by the support people, do you think they will go the extra mile for me?
- Be very exact with what is you think is wrong. The best way is to formulate it like this: “I did X and expected Y but I got Z”. Also be clear on when you define the case as closed. This is particularly important, and hard when you have performance issues or intermittent errors. But try to be as exact as you can. For example: “When users run Chrome open a Contact (after the contact form already has been loaded for another record) it takes 10 seconds. We expect it to take no more than 2 seconds.”
- Only have one issue per ticket. Better to have many tickets open. I have had 4 tickets open for one single customer at the same point in time.
- If you think the issue is important, describe it in business impact terms. For example “The bug X affects all sales people in the organization effectivly stopping them from using Dynamics 365. It severly risks our entire Dynamics 365 investment as users look at other solutions and the user adoption drops dramatically and the trust in the system is drastically lowered for every hour this bug is not fixed. We have 4354 sales people in our global sales organization spread out over 34 countries. It also affects managements abilities to manage the company as no pipleline and forecast numbers are produced which could potentially cause sever business damages that cannot easily be fixed within the coming 4-5 years.” – This was just made up 🙂 but it is important to not hold back when doing this, especially if you are Swedish or from other cultures which value humbleness.
- Be clear on limits of the error.
- Which Operating system?
- Which browsers?
- What times? Can you see any clear patterns on when it happens?
- Geos?
- Security roles?
- Types of users affected, AD users federated to O365 or Cloud users?
- How long?
- Which versions of Dynamics 365 are you running?
- Which instances have the issue (the url:s)?
Types of tickets
What types of tickets can be registered? Should you only register a ticket when you want help with something?
Well, no, you can and should register a ticket for many different reasons. As I mentioned at the top of the article it is important to think about Microsoft Support as your Dynamics 365 IT-department. They will help you with a lot of things that your IT-department would have helped you with had they hosted your Dynamics system. The main difference is probably that they do nothing else than host Dynamics 365, every day, year after year… not many IT-departments that can compare with that.
Typical issues they can help out with are:
- Something seems to have stopped working that used to work, and you didn’t change anything. Like you cannot create an Application User anymore.
- Something clearly is a bug in Dynamics 365 and you want Microsoft to know about it (they might not know) and you want to let them know how important it is for you (they will surely not know this).
- You need some information from the Server, like the “Top 10 table Usage” report from the SQL database.
- You have performance issues.
- You need to change the planned upgrades because your team won’t make the set time.
- You want to set some non-clustered indexes on the database.
- You are doing a migration of large amounts of data and you will be a bad neighbour for a few days and if possible you would like a little more than the 2 allocated threads in the API.
- You want a database copy prepared for installation into an on-prem equivalent.
- You need some detailed information on how the service is managed, like
- How backups are stored
- How to restore backups from the 90 day tape backup
- Where an instance is hosted
- You would like to move an instance to another datacenter
- You need to remove a managed solution but it has dependencies that shouldn’t be there…
- You need to do some task with an instance that you cannot do yourself with the instance manager.
In other words, they will be your superfriend when working with Dynamics 365 and you want to be really nice to your super friend!
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB
www.crmkonsulterna.se
by gustaf | Oct 5, 2017
As many of you probably have noticed version 9.0 has just been released. If you havn’t, spin up a trial by clicking here: New Trial
It has a very nice and shiny UI which I really think you should try and some very other very nice new features. However, you should be a bit wary of using it in production environments just yet as there seems to be a bit too many serious bugs as described in this document:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/admin/readme-9
I am working with a customer and we have a specific non-production instance we call “sandbox” which we use to test apps and features outside of the ALM (application lifecycle management) process, so we installed v9 or July Update as it is called and tried it out.
What I found when trying to deploy our unmanaged customization with all the entities which we have changed in the project, was that I got the weirdest error, it complained that it was missing an internal Microsoft Web Resource with the name of:
“CampaignActivity_main_system_library.js”
So, I opened up the customization.xml (yes, all you oldtimers from CRM 3.0 time remember it as the true export file) and searched for the guid and the web resource name in the file. I found that it was actually used on the main form of Compaign Activitiy, and if you look at the read-me document I have linked above, it mentions that the Campaign Activity is one of the entities which does not work. Hence, there is probably some old code in there that Microsoft have decided to remove, and havn’t had time to replace.
So, the temporary fix to get our solution to work in Dynamics 365 v9.0 (July Release), go into the customization.xml and then manually remove all <Event> tags which include that webresource, and if the <Events> tag was empty, remove that too. Then put the customization.xml file back into the solution file and reimport it.
The campaign activity still won’t work but at least our solution imported. Perhaps there are similar issues with other entities.
I will expect this issue to go away very soon.
And on the issue of if it is ok and supported to manually edit (hack) the customization.xml file I am under the impression that it is as long as it actually import into a system without any forceful shoehorning as it is up to Dyn365 to validate it.
On monday, I will be heading to CRM UG Summit in Nashville which is sure to be a great trip. I am planning to try to make some video there which I will post here and on my Youtube, and don’t miss my session on if it is really is a fair fight to compare Online with Onprem? Guess what I will say?
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB
www.crmkonsulterna.se
by gustaf | Sep 15, 2017
When authenticating to Dyn 365 with S2S the following is a simple program using the S2S authentication which core I think I got originally got from my pal George Doubinski. I like to use it to test S2S. Very clean and easy to build on.
string organizationUrl = “<org url>”;string clientId = “<client id in Azure>”;string appKey = “<secret for the clientid>”;string aadInstance = “https://login.microsoftonline.com/”;string tenantID = “<contoso or whateveryouhave>.onmicrosoft.com”;
ClientCredential clientcred = new ClientCredential(clientId, appKey);AuthenticationContext authenticationContext = new AuthenticationContext(aadInstance + tenantID);AuthenticationResult authenticationResult = authenticationContext.AcquireToken(organizationUrl, clientcred);var requestedToken = authenticationResult.AccessToken;
using (OrganizationWebProxyClient sdkService = new OrganizationWebProxyClient(GetServiceUrl(organizationUrl), false)){sdkService.HeaderToken = requestedToken;OrganizationRequest request = new OrganizationRequest();
WhoAmIResponse response = sdkService.Execute(new WhoAmIRequest()) as WhoAmIResponse;
Console.WriteLine($”UserID:{response.UserId}”);Console.WriteLine(“Press any key to continue…”);Console.ReadKey();
}
However, the line:
AuthenticationResult authenticationResult = authenticationContext.AcquireToken(organizationUrl, clientcred);
 |
| Cloud computing – isn’t it great? |
Requires ADAL version 2.x and the method AquireToken has been removed in the later version of that library.
If you look around the net, many advocate staying on 2.x version of the library but I didn’t have that option as I was integrating with Dyn 365 Operations and that was using the ver 3.x.
So, to make this work in version 3.x you just have to make a simple fix:
AuthenticationResult authenticationResult = authenticationContext.AcquireTokenAsync(ClientConfig.CRMOrgUrl, clientcred).Result;
Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se
by gustaf | Aug 28, 2017
Have been trying to install Voice of the customer for one of my customers. As with larger customers,
and of course, many of the smaller ones too, I am not allowed to (and I don’t really want to) be the global admin in their Office 365. I am however a Dynamics 365 Service Admin, which I think is fair.
So I was trying to provision Voice of the Customer (VoC) but it failed and after many weird loops and dances with support, of which I will not mention here, I finally got hold of Microsoft support and they were able to tell me that not only did I need to get hold of one of the global admins (you know, one of the scary pale guys who they lock in a safe somewhere cause god knows what would happen if they stepped in front of a car…) but the user also needs to have a full plan 1 Dynamics 365 license.
Said and done, we allocated it, and restarted the installation – do remember that you have to install VoC from the “Applications” tab, and not only as a Solution.
So, quick recap:
To install VoC, you need:
– Dynamics 365 online instance
– User with Dynamics 365 Plan 1 license
– Same user with Global Admin rights
Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se
by Gustaf Westerlund | Jul 3, 2017
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
- Export solution
- 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.
- When you get the case form to work, import the solution again.
- Remove the the field(s) that you know are causing the problems.
- 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
Recent Comments