Moving data between different instances of Dynamics 365 should be relatively easy with the Data Management framework. Microsoft offers a long list of entities and default templates nicely grouped into relevant packages.
In 7.2 we did experience some issues with loading the default templates, but that seemed fixed in 7.3.2. The real problems showed up when trying to import the packages in projects created based on the export file.
It seemed like after importing file number one or two the Data Management forms got corrupted with an error stating: “Method not found: ‘Dynamics.AX.Application.FormBuildControl Dynamics.AX.Application.FormBuildControl.parentControl()’.”
All other forms checked worked. After a full compile we were back on track, but that really wasn’t a working solution with multiple packages to import.
Debugging the forms didn’t add anything valuable to the troubleshooting. Going back to start and breaking it up into smaller chunks it appeared too random to be data driven as first suspected.
The solution – don’t ask how I ended there – is like this:
After each package I cleared the browser cache and refreshed the tab running my Dynamics 365….
And here a little pitch of Google Chrome that allows you to only clear the most recent part of the data:
It adds a bit of overhead to the data import having to do this step between each package; but nothing compared to the alternatives.
When looking at the hosted environments in LCS sometimes the tiles showing updates doesn’t seem to update probably. The symptoms could be that the numbers indicate that you’re missing some updates after updating it all or that the Last run date isn’t updating.
The status is updated through a scheduled task on the server.
It runs a powershell script in C:\LCSDiagnostics\ called CollectData.ps1
You can run it manually (through an elevated powershell) and that should hopefully update the figures.
It would have been nice to be able to see the run history on the task in the scheduler but for some reason that has been disabled:
That is easily fixed. Open the Task scheduler as Administrator and that gives you the option in the right most part of the form:
Going into License configuration to enable or disable a configuration key you’ll probably see the warning:
This form is read-only unless the system is in the maintenance mode. Maintenance mode can be enabled in this environment by running maintenance job from LCS, or using Deployment.Setup tool locally
Here’s how to work around that in all but production environments:
- Tell the other users working on that environment, since you’ll be restarting the IIS during the process.
- Log on to the server running the AOS service and start up a command prompt in Administrator mode
- Run the following statement where you change K to the correct drive for your AOS service:
K:\AosService\PackagesLocalDirectory\Bin\Microsoft.Dynamics.AX.Deployment.Setup.exe –metadatadir K:\AosService\PackagesLocalDirectory –bindir K:\AosService\PackagesLocalDirectory\Bin –sqlserver . –sqldatabase axdb –sqluser <SQL admin user id> –sqlpwd <SQL users password> –setupmode maintenancemode –isinmaintenancemode true
- Restart the IIS with the iisreset command
This leaves the environment in maintenance mode. This doesn’t mean non-functional; but you probably would like to leave the maintenance mode as soon as possible.
When you are done you run this script from a command prompt in Administration mode (again replace K with the appropriate drive letter):
K:\AosService\PackagesLocalDirectory\Bin\Microsoft.Dynamics.AX.Deployment.Setup.exe –metadatadir K:\AosService\PackagesLocalDirectory –bindir K:\AosService\PackagesLocalDirectory\Bin –sqlserver . –sqldatabase axdb –sqluser <SQL admin user id> –sqlpwd <SQL users password> –setupmode maintenancemode –isinmaintenancemode false
Restart you IIS once more and you’re back on track.
In older versions of Dynamics AX we had a report showing us the size of a company. It wasn’t pretty and it wasn’t fast. But it was nice to have though.
In Dynamics 365 for Operations it’s no longer in the menus; but don’t worry, it’s still there. All you need to do is to utilize how you can access menu items by building your own URLs:
That should give you the report:
When editing screen layouts you drag and drop controls in the (soon to be overhauled by Microsoft) editor. If you end up dragging a bit too aggressively you can actually throw the control off the grid and the visible area.
The funny part is that it’s not easily pulled back in since the editor doesn’t allow you to traverse through the active controls.
Here’s a quick description and fix. First I’ve created a simple layout with a single control:
Then I drag it outside the black area. Notice, that it is no longer visible but not available on the list to the left:
To get it back export the layout to an XML file:
Edit the file in notepad. In this case the file is pretty simple. In real life you’ll be pretty pleased with the search function in Notepad.
The thing to notice here is that the left value has gone negative, since I dragged my control too much to the left:
Change the value to a positive figure and save the document:
Import the layout in the designer
And now the control is visible again:
If you end up with controls out of boundaries, you could close the editor without saving to prevent getting in the above situation.
While testing MPOS changes I had to do an uninstall on my laptop. But every time I tried to uninstall it told me that there was an error and it couldn’t complete the uninstall and that I should contact the administrator.
And then it reappeared in the list of installed apps.
Trying to run the Uninstall-RetailModernPOS.ps1 gave a hint of what’s wrong:
You’ll usually find the script around here:
C:\Program Files (x86)\Microsoft Dynamics 365\70\Retail Modern POS\Tools\
There might be some clever way of fixing this, but in order to move forward I did a quick’n’dirty and not recommended way of fixing it:
Remove the check …
Edit the script by commenting out this line:
This is not recommended and definitely not in a production environment and I do not take any responsibility for any undesired outcome of this. But it did the trick for getting me forward.
Please note, that this doesn’t take away the error. So when you uninstall the next time it’ll still throw the error at you until you once again remove the check.
Normally when I need the table browser in Dynamics 365 I use a Chrome extension called “Table Browser Caller for D365FO“. Often you end up working in Incognito mode when having to access environments with a different AAD account. That requires you to make it available in Incognito mode:
BUT … what the extension does isn’t magic. What it does however is offering a very easy approach to building an URL that I never can remember. And when working in a browser without that extension you can write the URL change yourselve. So I figured that if I wrote it here I might remember it better or at least help somebody else remember it.
Add this to the URL to get the table browser: &mi=SysTableBrowser&TableName=. This will give you something like this:
Notice, that the table browser is being changed in a couple of areas compared to AX 2012. This means that changing data through the table browser is not allowed in production environments for example. Nice in regards to data consistency, but missed when having to dirty-fix data. 🙂