One of my customers have migrated to new servers for their AOSes, these are brand new Windoews Server 2012 R2 servers… nice. We hade one issue though… When trying to send emails using batch from a batch jog we got the following error:
Microsoft.Dynamics.Ax.Xpp.ClrErrorException: Exception of type ‘Microsoft.Dynamics.Ax.Xpp.ClrErrorException’ was thrown.
at Microsoft.Dynamics.Ax.Xpp.CLRInterop.staticInvoke(String typeName, String methodName, Object parameters, Type type)
at Dynamics.Ax.Application.WinAPIServer.cryptUnProtectData(Object _encryptedDataBlob) in WinAPIServer.cryptUnProtectData.xpp:line 39
at Dynamics.Ax.Application.SysEmailParameters.password() in SysEmailParameters.password.xpp:line 18
at Dynamics.Ax.Application.SysEmailDistributor.Processemails(Guid _emailProcessorId) in SysEmailDistributor.processEmails.xpp:line 39
at Dynamics.Ax.Application.SysEmailDistributor.Run() in SysEmailDistributor.run.xpp:line 78
at Dynamics.Ax.Application.BatchRun.runJobStaticCode(Int64 batchId) in BatchRun.runJobStaticCode.xpp:line 54
at Dynamics.Ax.Application.BatchRun.runJobStatic(Int64 batchId) in BatchRun.runJobStatic.xpp:line 13
at BatchRun::runJobStatic(Object )
at Microsoft.Dynamics.Ax.Xpp.ReflectionCallHelper.MakeStaticCall(Type type, String MethodName, Object parameters)
at BatchIL.taskThreadEntry(Object threadArg)
It took me some time to figure it out… Apparently the password for the SMTP account is saved in the AX database, but using an encryption key from the computer which saved it (a.k.a. the server that was retired) so when moving to the new server it was not able to read it. To fix it I simply entered the password again from the new server and Presto!
Today little issue was a bit frustrating…. to say the least
I have set up a new AX 2012 Vm in Azure for my colleagues to do some troubleshooting on. The need to install a Hotfix there and thus needs Internet Access from the VM. Normally this is not a problem… there are normally no issues accessing the internet from a correctly configured VM… the key phrase being correctly configured
I installed the VM from LifeCycle Services which is the normal way for AX machines which means I get a preconfigured VM with AX 2012 and it also has Active Directory installed locally to decrease dependencies. I am able to access the VM but no internet access… so I do some basic testing and I can do nslookup when using an external DNS which tells me 1) the VM has internet Access and 2) there is something wrong with the DNS settings. The local dns setting is pointing to the address is pointing to 10.20.12.4 which has nothing to do with my VM. So I tried to change it to 127.0.0.1 and as soon as I saved the settings the connection to the VM dropped… that is strange. I tried again after restarting but got the same result. So what to do…
I tried changing it using Powershell… Success!! Restarted the VM and it was back to 10.20.12.4… Fail!! Something is rotten in the state of Denmark…
I started by looking through Group policies for something strange but could not find anything. So I fired up Sysinternal Autostart and found a strange script:
Hmmm… Looking at the script:
I found it!! This is not OK!!! Well, well… I changed the script and restarted and it worked… So if your AX 2012 VM is behaving strangely look at the c:\scripts\start.ps1 script. It also fiddles with services autostart settings and some other things
Today one of my colleuges had an issue with applying a hotfix in a customers environment. The environment had three AOS instances installed on the same server which had the correct version and they installed a fourth one which they missed to patch.
When we ran the axupdate install file we got this screen:
It said that there is nothing to patch… which there was… weird. So looking around the internet I found out that there is a command line parameters for axupdate called AOSINSTANCENAME… great… that should work…
Doh… turns out you cannot use comandline parameters unless you run a completely silent install…
axupdate.exe AcceptLicenseTerms=1 AosInstanceName=04-AX183ByggUserTest AosStart=0 HideUI=1 InstallAos=1 LogDir=”c:\Temp”
If you miss the HideUI=1 it will also ignore all of the other parameters
Well… all well that ends well
We have a large deploy with a customer this week which is a very bad time for AXBuild to stop working… really bad time. And ofcourse that is what happened (screw you Murphy). There are of course other ways to to a compile in AX byt doing it from within AX is really slow so AXBuild is much nicer and faster.
The problem was that when I launched AXBuild the process kept crashing with this error:
I also got the following events in Event viewer:
Error 14.11.2016 17:49:05 Dynamics Server 01 110 None
Object Server 01:
Can not create default Keyset. Error code -2146893809.
Error 14.11.2016 17:49:05 Dynamics Server 01 110 None
Object Server 01:
The license information can not be decoded.
Error 14.11.2016 17:49:06 .NET Runtime 1026 None
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception
Exception Info: System.Runtime.InteropServices.SEHException
When doing research we found that this is most likely a permissions issue and I got somen hints on what to check:
- Are you running elevated: Check
- Are you local admin on the AOS computer: Check
- Is the AOS user local admin on the AOS computer: Check
- Check AOS user permissions on the AX database and modelstore: Check
I was not able to find the solution so I resorted to Microsoft Support and they sait the same thing… it is a permission issue. So finally I fired up ProcessMonitor (which I don’t do often enough) and the it was after some looking around and filtering. I filtered out everything except the Ax32Serv.exe process and I also removed the SUCCESS lines.
The issue was that my user (the one doing the the compiling) got access denied on a file in the folder:
I changed the permission on the file and Presto! (or as one of my colleugues said – I am going to get a Cappuchino with cinnamon)
The compile is running and things are good
Today one of my customer had trouble using the Excel Workbook Designer in Dynamics AX (“7”). He got the following error when he tried opening the workbook in Excel:
The Error is No Applet Registration found
Turns out he had not installed Microsoft Dynamics Office Add-in which can be found here: https://store.office.com/microsoft-dynamics-office-add-in-WA104379629.aspx?assetid=WA104379629&sourcecorrid=a8afb77b-cfe0-4b70-baeb-f93fa38ad77b&searchapppos=0
Once this was install it worked great
In AX 2012 and prior it was a little tricky to add external users. You basically could not, so you needed to add an Active Directory Account to your AD and import it as a AX user. You might not want to add external users in your AD.
This is much easier in AX7 (it should be Dynamics AX but it is much harder to search for on the internets)… much, much easier… you see AX 7 does not handle identity at all… it trusts Azure Active Directory for this. A requirement is that the external company uses Azure Active Directory.
Note (Added later): If you have set up the AX install in Azure using LCS the “default” Azure Active Directory is the one connected for your Azure tenant. These users are not treated as external users and do not need the modification below.
So, to add an external user to AX you go to System Administration – Users and click New to add a new user. The user we want to add in our example is Kalle Kula, Kalle has the email address firstname.lastname@example.org
The only thing missing is that we need to specify the Azure AD tenant in the domain field and set it to https://sts.windows.net/innoworks.com (which is not completely visible in the screenshot)
Save the user and add roles and we are all set!
So, last week Microsoft released the RTW version of the new AX version called Microsoft Dynamics AX.
One of my colleagues was playing around with it a bit and bumped into a problem. When he tried to export to Excel he got the following:
The browser tries to connect to this address (and obviously this does not exist)
The reason for this is of course that the web app is trying to access the server on IP 127.0.0.1 port 10000 and since I am not doing this logged into the server console it will not work (it does work if i am logged in to the console)
To get this working you need to do these operations:
- On the server edit the file C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe.config and change the IP to the correct address (or name)
- Edit the file C:\CustomerServiceUnit\DOBind\Packages\Cloud\AosWebApplication\AosWebApplication.csx\roles\AosWeb\approot\web.config and change <add key=”AzureStorage.StorageConnectionString” value=”UseDevelopmentStorage=true” /> to <add key=”AzureStorage.StorageConnectionString” value=”UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://YourLocalIP” />
- Open the tcp ports 10000, 10001 and 10002 to the server
https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Faxforum.info%2Fforums%2Fshowthread.php%3Fp%3D325949 (with a little help from Google Translate)
We have set up the new AX demo environment on our Hyper-V lab environment. Most of the features are running fine but there are some issues which we are trying to fix as they arise. Today my colleague was trying to edit a workflow and got an error. Turns out you need a specific application to edit the workflow and this app is downloaded and installed on the fly when you click the link. The problem here is that the SSL certificate in the AX environment is not trusted, this is not an issue when you use a normal browser since you can ignore the error, but it prohibits my computer from installing the application. Here is how you solve the error:
NOTE: THIS IS A TEMPORARY SOLUTION, IT IS IMPLEMENTED TO ACCESS A TRUSTED LAB ENVIRONMENT. YOU SHOULD NEVER EVER EVER DO THIS WITH A CERTIFICATE YOU COMPLETELY TRUST!!!!! IF YOU DO THIS WITH THE INCORRECT CERTIFICATE IT MEANS THAR BAD GUYS CAN SPY ON YOUR SECURE TRAFFIC!!!!!
- Browse to your AX site, click on the Certificate Error button and select View Certificates
- On the windows that appears click Install Certificate and select to install it into your Trusted Root Certificate
- Restart your browser and log back into your AX environment and verify that there no longer is a certificate warning
Now when you go to edit a Workflow you do not get an error
You just login and the install will start automatically and you can edit the workflow.
NOTE AGAIN: THIS IS A TEMPORARY SOLUTION, IT IS IMPLEMENTED TO ACCESS A TRUSTED LAB ENVIRONMENT. YOU SHOULD NEVER EVER EVER DO THIS WITH A CERTIFICATE YOU COMPLETELY TRUST!!!!! IF YOU DO THIS WITH THE INCORRECT CERTIFICATE IT MEANS THAR BAD GUYS CAN SPY ON YOUR SECURE TRAFFIC!!!!!