I need to confess something… Sometime I do not read all of the release notes as thoroughly as I maybe should. This was made clear to me the other day when I tried to set up a batch job and make sure it was executing in a new Dynamics 365 for Finance and Operations Production environment. Or maybe I read it, but did not really understand it…
Before, you were able to create a batch group and add servers to it. This was used in for instance AX 2012 or D365FO to control execution and divide resources in an optimal way between batch jobs. Especially when you were dealing with large, time consuming, batches that you needed to ensure ran correctly while not starving smaller (time critical) jobs of resources
Starting with version 10.0.29 the default behaviour is that all Batch Servers are assigned to all Batch Groups. Each Batch Group has a scheduling priority set to either Low, Normal, High, Critical or Reserved Capacity and the batch jobs are then assigned to the Batch Group meaning that you will (almost) always have load balancing over all servers. The exception to the rule is if you choose Reserved Capacity.
Reserved Capacity means that you on an environment level can exclude a percentage of the total batch capacity (aka Batch Threads). The setup is done in System Parameters – Batch global settings. The default setting is “No reserved capacity”, meaning that all batch servers threads are available to the load-balancing. You are able to change this to Low, Medium or High (10, 15 or 25 percent) which will then exclude batch capacity from the pool. Worth knowing is that when no batch jobs with Reserve Capacity are executing the reserved batch threads will be sitting idle.
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!