Hi all,
We had a requirement to automatically create a backup of the database of a Tier 2 environment. Luckily there is the Database Movement API that allows you to do just that.
In his excellent blog post Automated backups of D365FO databases, Dick explains how to set this up using Release pipelines. We have done the same, but using (build) pipelines, so that’s what is documented below.
There are only minor differences. For example we use an output variable for pass the token between tasks, but for the rest everything is pretty much the same. So thank you Dick.
A new pipeline is created:
Before you start, you need to create an application registration and have an account. See Step 1 to Step 3 on this page: Database movement API – Authentication.
After this is done, on your pipeline, click on the Variables tab. Add the following variables:
CLIENTID, CLIENTSECRET, GOLDEN (or ACCEPT, MIGRATION, etc., depending on your environment), LCSPROJID, PASSWORD, USERNAME.
CLIENTID | This is the client ID from your application registration |
CLIENTSECRET | This is the client secret from your application registration |
GOLDEN | This is the Environment Id of the environment you want to create a backup for. You can find this on the Environment details page in LCS. |
LCSPROJID | You can find the project id in the URL when you are on the project in LCS. It’s an integer like 1234567. |
USERNAME | The email address of the service account you will use for this operation |
PASSWORD | The password of the service account |
It should look something like this:
Don’t worry, all data is fake in the screenshot :).
Next on the Output Variables fast tab, set the reference name to task1.
It should look like this:
Next well add the task that will perform a backup of our environment. Repeat the same steps as before to add the PowerShell task but name it Backup database Golden.
Set the inline script to:
Our pipeline will look like this:
On the Triggers tab, click on Add in the Scheduled section. Choose you schedule and unmark the checkbox Only schedule builds if the source or pipeline has changed.
Click on Save & Queue, the click on Save.
That’s it, your pipeline will create a backup for this environment based on your schedule. You should see your backup in the Asset library on LCS when the pipeline has run.
On the Configure entity export to database page in Data management, you can create new source data formats of the type Azure SQL DB.
When you have correctly configured the connection string and click the Validate button, you can get the following error:
Incorrect connection string. The connection string should be of format Data Source=serverName;Initial Catalog=databaseName;Integrated Security=False;User ID=PlaceholderUserId;Password=PlaceholderPassword
You can get this error even when the format is incorrect. The issue is that Dynamics cannot connect to your database server.
In my case the firewall rules were not setup correctly. To fix this:
When importing Excel templates with the Data Management module in Dynamics 365 F&O, you can get the following error:
The data value violates integrity constraints
The issue may be an error in your data, for example mandatory fields are not set, or there are duplicate values, but in our case the cause was different.
Although the Excel file only contained 68 lines, somehow there were empty lines after the data that Dynamics still tried to import.
We selected these lines and removed them, as you can see in the screenshot below. After this step the error was solved.
Hi everyone,
I was setting up a build for Dynamics 365 F&O using the following guide: Azure hosted build for Dynamics 365 Finance & SCM and ran into the following error on the build solution step:
Error MSB4019: The imported project Microsoft.Dynamics.Framework.Tools.BuildTasks.targets was not found. Confirm that the path in the
declaration is correct, and that the file exists on disk.
Digging a bit deeper, it was already going wrong in the NuGet install Packages step with errors like the following:
Feeds used:
D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.jsonRestoring NuGet package Microsoft.Dynamics.AX.Platform.DevALM.BuildXpp.7.0.5816.35654.
Restoring NuGet package Microsoft.Dynamics.AX.Application.DevALM.BuildXpp.10.0.644.10018.
WARNING: Unable to find version ‘10.0.644.10018’ of package ‘Microsoft.Dynamics.AX.Application.DevALM.BuildXpp’.
D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json: Package ‘Microsoft.Dynamics.AX.Application.DevALM.BuildXpp.10.0.644.10018’ is not found on source ‘D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json’.Restoring NuGet package Microsoft.Dynamics.AX.Platform.CompilerPackage.7.0.5816.35654.
WARNING: Unable to find version ‘7.0.5816.35654’ of package ‘Microsoft.Dynamics.AX.Platform.DevALM.BuildXpp’.
D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json: Package ‘Microsoft.Dynamics.AX.Platform.DevALM.BuildXpp.7.0.5816.35654’ is not found on source ‘D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json’.WARNING: Unable to find version ‘7.0.5816.35654’ of package ‘Microsoft.Dynamics.AX.Platform.CompilerPackage’.
D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json: Package ‘Microsoft.Dynamics.AX.Platform.CompilerPackage.7.0.5816.35654’ is not found on source ‘D:\a\11\s\Build\6ba2d33f-0920-4785-8d8e-1234567890/_packaging/FeedD365/nuget/v3/index.json’.
The error was in the nuget.config file, that should point to the correct feed. For some reason the path was missing, causing the error.
The incorrect file was:
The corrected file:
The correct contents of this file for your project and feed can be retrieved when you go to you DevOps project > Artifacts > [Select your feed] > Connect to Feed > NuGet.exe.
Recently a customer logged a bug after moving there environment to new servers.
The batchjob “Notification clean up” went in error with the message
Invalid value (“07-07-2017”..”03-03-2020″) specified in the query predicate
The date range came from the DayRange functionality
It seems to be a Region setting on the server
The shortdate notification was dd-MM-yy
After changing the year yy to yyyy it all went well.
Keep in mind also to change the setting for the AOS service account
You can get this error in the Workflow message processing batch job. You will find that the workflow batch throws this error every 10 minutes or so. The reason you get it every 10 minutes is because of the code in the SysWorkflowMessageQueueManager.expireLeasedMessages() method. In this method, the workflow updates the batch affinity value every 10 minutes.
To debug this issue, you might be tempted to process the workflow messages using the the Tutorial_BatchProcessing form. However, you will not be able to debug this using the Dynamics AX debugger because this form executes the function that fails in CIL. You will have to use Visual studio to debug it.
To debug using the Dynamics AX debugger, use the following job:
Set your breakpoints in the table method workflowtrackingtable.savetracking() on line 161 and/or 154. These are the lines that throw an error message with label @SYS112531.
Wait for about 9 minutes after the workflow batch has the status error, then run the job every 2 seconds manually. After about 1 minute of this you will enter the breakpoint. Then use the debugger to figure out what record in the table SYSWORKFLOWMESSAGETABLE is causing the error.
You could also find it using the following query:
This query returned more records than were causing the issue in my case, so it’s best to make sure using the debugger. I then “fixed” the issue by deleting the identified record from the SYSWORKFLOWMESSAGETABLE table.
If you run the Tutorial_WorkflowProcessinng class and you get the error every time, there might be something wrong with records in the table WORKFLOWWORKITEMTABLE instead. You can figure out what record this is using the debugger as well.
Most likely the work item is linked to a tracking status record that does no longer exist. Verify this using this query:
You can try to get it working by recalling the worklow and resubmitting it. If that doesn’t work you can delete the record in the WorkflowWorkitemTable table.
Unfortunately, I do not know the root cause of this issue but the actions above fixed it for me. Hope this helps. Thanks to the community for inspiration on how to fix this issue.
Just wanted to share this overview of the time zones used in Dynamics AX 2012 and the TZId value that is used to store UTCDateTime values in SQL.
Timezone description | TimeZone | TZId field |
---|---|---|
(GMT-12:00) International Date Line West | 24 | 24001 |
(GMT-11:00) Midway Island, Samoa | 65 | 65001 |
(GMT-10:00) Hawaii | 39 | 39001 |
(GMT-09:00) Alaska | 2 | 2001 |
(GMT-08:00) Pacific Time (US & Canada) | 58 | 58001 |
(GMT-08:00) Tijuana, Baja California | 59 | 59001 |
(GMT-07:00) Arizona | 75 | 75001 |
(GMT-07:00) Mountain Time (US & Canada) | 47 | 47001 |
(GMT-07:00) Chihuahua, La Paz, Mazatlan | 48 | 48001 |
(GMT-06:00) Central America | 15 | 15001 |
(GMT-06:00) Central Time (US & Canada) | 21 | 21001 |
(GMT-06:00) Guadalajara, Mexico City, Monterrey | 22 | 22001 |
(GMT-06:00) Saskatchewan | 11 | 11001 |
(GMT-05:00) Bogota, Lima, Quito, Rio Branco | 63 | 63001 |
(GMT-05:00) Eastern Time (US & Canada) | 29 | 29001 |
(GMT-05:00) Indiana (East) | 74 | 74001 |
(GMT-04:00) Atlantic Time (Canada) | 6 | 6001 |
(GMT-04:00) La Paz | 64 | 64001 |
(GMT-04:00) Manaus | 17 | 17001 |
(GMT-04:00) Santiago | 57 | 57001 |
(GMT-04:30) Caracas | 85 | 85001 |
(GMT-03:30) Newfoundland | 54 | 54001 |
(GMT-03:00) Brasilia | 28 | 28001 |
(GMT-03:00) Buenos Aires, Georgetown | 62 | 62001 |
(GMT-03:00) Greenland | 36 | 36001 |
(GMT-03:00) Montevideo | 83 | 83001 |
(GMT-02:00) Mid-Atlantic | 45 | 45001 |
(GMT-01:00) Azores | 10 | 10001 |
(GMT-01:00) Cape Verde Is. | 12 | 12001 |
(GMT) Casablanca, Monrovia, Reykjavik | 37 | 37001 |
(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, Londo | 35 | 35001 |
(GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna | 79 | 79001 |
(GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Pragu | 18 | 18001 |
(GMT+01:00) Brussels, Copenhagen, Madrid, Paris | 60 | 60001 |
(GMT+01:00) Sarajevo, Skopje, Warsaw, Zagreb | 19 | 19001 |
(GMT+01:00) West Central Africa | 78 | 78001 |
(GMT+02:00) Amman | 43 | 43001 |
(GMT+02:00) Athens, Bucharest, Istanbul | 38 | 38001 |
(GMT+02:00) Beirut | 46 | 46001 |
(GMT+02:00) Minsk | 27 | 27001 |
(GMT+02:00) Cairo | 30 | 30001 |
(GMT+02:00) Harare, Pretoria | 68 | 68001 |
(GMT+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius | 33 | 33001 |
(GMT+02:00) Jerusalem | 42 | 42001 |
(GMT+02:00) Windhoek | 51 | 51001 |
(GMT+03:00) Baghdad | 5 | 5001 |
(GMT+03:00) Kuwait, Riyadh | 3 | 3001 |
(GMT+03:00) Moscow, St. Petersburg, Volgograd | 61 | 61001 |
(GMT+03:00) Nairobi | 25 | 25001 |
(GMT+03:00) Tbilisi | 34 | 34001 |
(GMT+03:30) Tehran | 41 | 41001 |
(GMT+04:00) Abu Dhabi, Muscat | 4 | 4001 |
(GMT+04:00) Baku | 9 | 9001 |
(GMT+04:00) Caucasus Standard Time | 84 | 84001 |
(GMT+04:00) Yerevan | 13 | 13001 |
(GMT+04:30) Kabul | 1 | 1001 |
(GMT+05:00) Ekaterinburg | 31 | 31001 |
(GMT+05:00) Islamabad, Karachi, Tashkent | 80 | 80001 |
(GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi | 40 | 40001 |
(GMT+05:30) Sri Jayawardenepura | 69 | 69001 |
(GMT+05:45) Kathmandu | 52 | 52001 |
(GMT+06:00) Almaty, Novosibirsk | 50 | 50001 |
(GMT+06:00) Astana, Dhaka | 16 | 16001 |
(GMT+06:30) Yangon (Rangoon) | 49 | 49001 |
(GMT+07:00) Bangkok, Hanoi, Jakarta | 66 | 66001 |
(GMT+07:00) Krasnoyarsk | 56 | 56001 |
(GMT+08:00) Beijing, Chongqing, Hong Kong, Urumqi | 23 | 23001 |
(GMT+08:00) Irkutsk, Ulaan Bataar | 55 | 55001 |
(GMT+08:00) Kuala Lumpur, Singapore | 67 | 67001 |
(GMT+08:00) Perth | 77 | 77001 |
(GMT+08:00) Taipei | 70 | 70001 |
(GMT+09:00) Osaka, Sapporo, Tokyo | 72 | 72001 |
(GMT+09:00) Seoul | 44 | 44001 |
(GMT+09:00) Yakutsk | 82 | 82001 |
(GMT+09:30) Adelaide | 14 | 14001 |
(GMT+09:30) Darwin | 7 | 7001 |
(GMT+10:00) Brisbane | 26 | 26001 |
(GMT+10:00) Canberra, Melbourne, Sydney | 8 | 8001 |
(GMT+10:00) Guam, Port Moresby | 81 | 81001 |
(GMT+10:00) Hobart | 71 | 71001 |
(GMT+10:00) Vladivostok | 76 | 76001 |
(GMT+11:00) Magadan, Solomon Is., New Caledonia | 20 | 20001 |
(GMT+12:00) Auckland, Wellington | 53 | 53001 |
(GMT+12:00) Fiji, Kamchatka, Marshall Is. | 32 | 32001 |
(GMT+13:00) Nuku’alofa | 73 | 73001 |
Hi all!
Some time ago I talked about a problem with SSRS reports that were showing empty fields where data was expected. More recently I talked about how display scaling for high DPI displays can cause fonts in the Dynamics AX client to be all messed up. Today, these two issues kind of had a baby of some kind :).
Apparently, the display sizing setting can cause reports to show empty field when printing to client. When you print to PDF, all data is there. When on your host machine, display sizing is set to 125%, some reports can show empty fields. If you set it to 100%, the problem seems to be solved and the report prints correctly to the screen.
If you are working on multiple monitors, it is possible that it works when your remote desktop sessions is opened on one monitor, but the report shows empty fields when you open your remote on another monitor. As mentioned in the previous post, you also get different results when you change the Disable display scaling on high DPI settings property on the Dynamics AX 2012 shortcut.
In any case, it is best to set the display scaling on the client to 100% if possible to avoid these issues.
Today Management Reporter did not want to synchronize the users from Microsoft Dynamics AX 2012 to Management Reporter.
TLDR: make sure that you do not have unknown users with access to Management Reporter in your database. For example users from a different domain or users that have been deleted on active directory.
As you probably know, the users in Management Reporter are actually managed in Dynamics AX by using the role based security of Dynamics AX. The following table shows which roles in AX correspond to which roles in Management report (Source). So for example if you want to be administrator in MR, you need to be Security administrator in AX.
AOT name | Permission | Microsoft Dynamics AX 2012 role | Management Reporter role |
---|---|---|---|
LedgerBalanceSheetDimMaintain | Maintain financial statement setup | Accounting manager Accounting supervisor |
Designer |
LedgerFinancialJournalBGenerate | Generate financial journal report | Accountant Accounting manager Accounting supervisor Chief executive officer Chief financial officer Compliance manager Financial controller |
Generator |
LedgerBalanceSheetDimPrintGenerate | Generate financial statement report | Accountant Accounting manager Accounting supervisor Chief executive officer Chief financial officer Compliance manager Financial controller |
Generator |
SysSecSecurityMaintain | Maintain security settings | Security administrator | Administrator |
LedgerViewFinancialStatement (privilege) | Viewing financial statements | Not applicable | Viewer |
Once you have setup the security in AX, it can take up to 5 minutes for the users to show up in Management Reporter. The synchronization of the users is part of the AX 2012 Companies to company task that is executed by Management Reporter every 5 minutes. You can check if this task has run in the Management Reporter 2012 Configuration Console. Go To Logs > Data mart integration and search the log for AX 2012 Companies to company. If it has executed successfully, the users should show up in Management Reporter.
If on the other hand there are errors in the AX 2012 Companies to company task, users will not be synchronized correctly. In my case, I had restored a database from another domain and there were users in the AX database with roles that gave them access to Management Reporter. Disabling these users in AX does not help, so you have to either remove them from AX or remove the role assignment that give the user access to Management Reporter.
Hi all!
When you open a Dynamics AX 2012 client (RTM/FP/R2/R3) on a remote session it sometimes looks pretty weird. Font sizes are all over the place and overall it doesn’t look that great. See for example in the following screenshot:
You can get better results by changing the properties of the shortcut if you check the checkbox Disable display scaling on high DPI settings on the Compatibility tab.
The result is better but still not entirely accurate:
You can get the best results by changing the display settings on you host system (so the PC or laptop you are working on). I have Windows 8.1 but you should find a similar setting on other versions of Windows in the Display section of the Control panel.
Microsoft recommends 125% scaling by default, but I prefer to set it at 100%. Setting it to 100% will also give you the best results for Dynamics AX 2012 in remote sessions. So, on your system, change the setting to 100% as seen in the following screenshot.
This property will only be active after you sing off and sign in again, so do that also.
If you connect to a remote session now, you will see that the scaling of the text in Dynamics AX 2012 is now accurate. This will improve your experience and your screenshots.
We are moving from AX 2012 FP to AX 2012 R3 and our daily build was failing with the following error:
Length cannot be less than zero
We have traced the problem to the xpo files in version control that contain the (shared) projects. When these are added to the XPO, you get the error above.
There is a blogpost here that explains the problem.
So apparently, when moving from AX 2012 FP to AX 2012 R2 or R3, Microsoft has changed the file encoding of the xpo files for projects from UCS-2 Little Endian to UTF-8. CombineXPO has problems with this so it throws an error.
I did not make changes to CombineXPO, instead to solve this problem, I have converted all projects in my local repository to UTF-8 using a tool called UTFCast . Just make sure you have the Write BOM parameter checked. Then it’s just a matter of checking them in using Visual Studio. After that the build was succesful.
One of our customer had an issue with MRP; it failed with the following error:
Parameters for master plan do not exist.
In our case, the problem was that records in ReqPo and ReqTrans were referencing a plan version (ReqPlanVersion) that did no longer exist. How this situation came to be is unknown to us.
What we did to resolve this:
Don’t forget to change the REQPLANDATAAREAID and RECID values to the values for your environment. The value for REQPLANID can be any value, we chose ‘PlanToDel‘.
4. Delete the new plan called PlanToDel in the form Master Planning > Setup > Plans > Master plan
So in summary, we just created the missing record and then used standard AX functionality to clean the data.
At one of our customers, the Open transactions report for customers was not showing data in some of the fields. There should have been amounts on the report but there was just empty space. The weird thing was that this was only happening on PROD and not on ACC or TST.
After some digging, we noticed that the fields that were empty had the Visible property set to No on the temporary table that was used by the data provider. Thanks to Bill Thompson for pointing us in the right direction: Microsoft Dynamics AX 2012 Report Development Tip – Data Not Showing in Report.
No changes to the report were required, simply set the fields on the temporary table to Visible = Yes and restart the report service. Then the data should show up.
However, although this was a solution, the real problem was that the kernel versions of the AOS and the AX components that were installed on the report server didn’t match. After updating the components to the matching kernel (in our case 6.0.1108.7889-KB3053474-Binary) and restarting the report service, the report worked fine even with the visible property set to No.
So in conclusion, Always check if the kernel versions of all components match when facing weird problems like this.
Update: also check Part 2 when this does not solve the problem.
So I had installed AX 2012 R3 CU11 on an environment. I used the Dynamics AX 2012 R3 updater because AX 2012 R3 RTM was already installed. Everything was working fine, until the server was restarted. The following error was added the the event viewer when opening the Enterprise Portal:
The description for Event ID 110 from source Dynamics .NET Business Connector 6.0 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
6.0:
: The Microsoft Dynamics record being referenced is not valid.
Wrong type of element at call of ConPoke.
ctively.
(C)\Classes\WebSession\webApplication
(C)\Classes\WebSession\init
This was solved by removing the AUC and KTI files for the user that is on the application pool of the enterprise portal, in my case, the business connector user. These files are located at C:\Users\[User]\AppData\Local. While you are at it, remove the AUC and KTI files for all users. After a kernel upgrade, these file can get corrupt/incompatible.
Legend says these files are “self repairing” but don’t believe the lies people!
I came across the following error when trying to print a report in Dynamics AX 2012:
Error while setting server report parameters. Error message: An error occurred while executing OnInit: The report execution failed to start. Verify that Report Extensions have been installed or are configured correctly.
Please consult your administrator or the documentation. (rsErrorInOnInit)
An error occurred while executing OnInit: The report execution failed to start. Verify that Report Extensions have been installed or are configured correctly.
Please consult your administrator or the documentation. (rsErrorInOnInit)
I was installing multiple SSRS instances on one server, other instances were working but this particular instance was not.
If you have multiple SSRS instances installed on one server, you have to make sure that the configuration files for all instances are modified correctly.
To solve the above errors, I performed the steps as describe here for the instance that wasn’t working: Modify Reporting Services configuration files [AX 2012]