I recently had a requirement to perform some Data Migration, but I needed a test system while I built up my SSIS process as I didn’t want to use the real online environments. Luckily, I have my own on-premise Dynamics 365 Version 9 Server which I have always used for testing and messing around with solutions and compatibility.
The main issue I have always had with using on-premise servers however is that these days, we are all developing with online environments, and solutions and what not from online cannot be imported into an on-premise environment. In the past, I have often just resorted to hand modifying solutions to get them in to the system. This would often involve editing the solution.xml file within the solution zip file, to alter the version tags at the top, and to remove the crmonline tag. Quite often, this would also require a few modifications to the customizations.xml file to remove any tags that do not exist in version 9 of Dynamics.
Its a hack, but for testing purposes, this was always something that worked.
These days though, you more often than not will face all manor of other issues, such as dependencies on other solutions, and its become a lot harder to achieve this.
Had a curious issue recently where I had set up a new Dynamics 365 Version 9 on premise server for testing. Everything was working as expected until I upgraded to the latest September 2019 release of CRM (update 0.8).
Upon further examination though, it had nothing to do with the update, it was the new Organisation I had created called “Portal”. For some reason, this organisation simply would not work, giving an error when trying to access it. I could see some nasty error messages in the Event Log which made me think it was something to do with the Upgrade (Assembly DLL load issues).
However, I created a new Organisation which actually worked fine.
I think I have come to the conclusion that the name of the org, Portal was producing some internal error with CRM and preventing it from loading. Maybe /Portal in the URL is reserved for something else, who knows.
Its not something that would probably affect many people, but I felt compelled to write a post about it in case anyone else was stuck with this.
This was an interesting find by one of my colleagues, and verified by myself to be a real issue.
All of a sudden, one of our custom entities within our development environment started to throw errors when trying to edit business rules.
We got to the point where we were seriously considering resetting the environment using a backup, when it was discovered that the only thing we could think that had changed was that the entity had been enabled for Entity Images as a test. Sure enough, deleting the field that was created for the entity image was enough to bring the business rules back.
So, let that be a lesson, if you enable entity images on a custom entity, you may just lose access to your business rules.
I am not sure if Microsoft is aware of the issue, or are planning on fixing it, but its something to watch out for.
The other day, I was investigating some solution import issues, and I need to see who was guilty of importing a solution into an environment that it should never have been imported into.
I fired up the old XrmToolbox, to use the Plugin called Solution History which I always found a nice handy little tool for getting at the history of when and who imported solutions.
It was at that point that I realised that CRM now supports a Solution History view within the user interface. I have no idea when this appeared, but it seems to be sometime this year.
Since then, I have found this invaluable for investigation solution issues, and also for updating environments where you need to follow the exact pattern of solution imports that were done within a test environment.
To use it, simply get to your Settings area of Dynamics, and choose Solution History from within the Customization section.
This will then give you a nice list of the solutions that were imported, exported, succeeded and failed.
I setup a trial of a V9 instance of Microsoft Dynamics 365 for some testing, and I found that the Adxstudio 7 solutions would not import. The installer goes in, but installing the base portals solution fails.
To get round this, I converted the instance to a sandbox, reset it to V8.2, installed the solutions, and I intend to upgrade it to V9, although I will have to wait a week for the scheduled update to work.
So there you have it. You cannot set up a new V9 instance to run old portal code on.
Recently I had an issue where all of a sudden, a solution would not export from the development environment, even though it was previously fine, and as far as I knew, it had not changed. Dynamics would throw a very unhelpful error, with no details of what went wrong.
I tried creating a new solution, and adding the exact same components and that one also failed, so I knew it was not the solution itself, but its contents.
After a bit of trial and error, I discovered that it was the SLA’s that were causing the issue. Turns out that it was because one of the SLA’s had not been activated. Never thought it needed to be, but in this case, it was causing an issue.
So, if it ever happens to you, make that one of the first things you check, it might save you some time.
This was a version 8.2 on premise install, but I didn’t have access to the actual server.
I was getting this error when trying to import a solution into an On Premise Dynamics 365 environment.
This was a solution that I knew had previously imported into other environments, so I was very confused why it would not import. Turns out, the Sandbox Processing Service on the server was not actually running.
Restarting the Service allowed the solution import to proceed.
I believe this must have happened as we had experienced a power cut, and I have certainly seen Dynamics services not restart properly when a server is not safely switched off correctly. Also, it may have had something to do with the fact that this one little Virtual Machine server was running about 20 different CRM Organisations at once.
Anyway, never assume that its an issue with your solution. Nine times out of ten, it is, but always remember to check your environment as well.