I've done it!  Upgraded my blog from Blogger to the WordPress site I've had for years, jumping 20 years into the future.  Check out https://calafell.me/ and delete your shortcut to https://dynamicsax365trix.blogspot.com/.

Cheers!

Latency Testing for Dynamics 365 for Finance and Operations

Recently I went on a journey testing the latency of the Azure dark fiber backbone between data centers.  This is crucial for a global Dynamics 365 Finance and Operations ("FinOps") implementation.  In general bandwidth can be purchased but latency is hard to influence.

There are some resources online which provide latency numbers which seem to hold somewhat accurate still, but I wanted the latest latency numbers to use in my analysis.  Each end-user location could determine which Azure data center was closest by using Azurespeed.com.  Next I referenced a Microsoft blog to test latency between Azure data centers, so that I could prove the benefit of Azure Express Routes to the nearest/lowest-latency data center, then routing traffic to the FinOps instance would be the best approach.  Here is what I did-

1. Created a vNet with two subnets in the region to host FinOps
    10.20.1.0/24   vNet
    10.20.1.0/26   Resources subnet
    10.20.1.192/26 Gateway subnet
2. Created a VPN Gateway in the region to host FinOps - this takes a long time to deploy

3. Created vNets with two subnets in every destination region each region with a different number for variable 'n.'

    10.20.n.0/24   vNet
    10.20.n.0/26   Resources subnet
    10.20.n.192/26 Gateway subnet
4. Created VPN Gateways in every destination regions
5. Created VPN connections - connections representing both directions must be created, both origin to destination and destination to origin.
6. Created virtual machines (VM) - Deployed the first one manually then created a template for the other regions to make for a faster deployment which could guarantee consistency.
7. Configured the Network Security Groups on all virtual machines
    Limited RDP traffic to my IP and inter-region IPs   {MyIP},10.200.0.0/16
    Allowed PsPing traffic on port 81
8. Did testing using psping (iperf is an alternative)
    On the origin:  psping -f -s 10.20.1.4:81
    On the destination:  psping -l 8k -n 1000 -f 10.20.1.4:81

Example output from PsPing from Korea Central to East US2:

Latency has always been a critical component of any AX or D365FO implementation.  Now that it is hosted by Microsoft we have several tools to test network performance before we deploy.

Debug AIF Document Service within AX

Sometimes it is a pain to create a .NET application and attach a debugger to the AOS service just to diagnose a problem with an AIF service.  It is possible to do all debugging inside of AX.  This example is for a standard AIF document service, however, you can also do the same for a custom service in a way which is even easier.

As a prerequisite, the inbound port must have document version logging enabled.  If not, deactivate it, enable logging, then activate it.

1. Find the exception and its message ID
/System administration/Periodic/Services and Application Integration Framework/Exceptions

Save the Message ID from this screen.

2. Get XML from AIF history
/System administration/Periodic/Services and Application Integration Framework/History

Filter on the Message ID, click "Document Logs" then save the document.

3. Modify XML to remove the entity key list, and keep the key because it is needed in the job.

4. Create a job for debugging

static void testAifXml(Args _args)
{
    #file
    AifEntityKey                                aifEntityKey;
    AxdSalesOrder                               axdSalesOrder;
    FileName                                    fileName = @"\\a\b\c\4BA32F0A-F7FC-46FD-8DB0-ABB04A6F4ECE.xml";
    Map                                         map;
    XmlDocument                                 xmlDocument;
   
    map = new Map(Types::Integer, Types::Container);
    map.insert(fieldNum(SalesTable, SalesId), ['SO000037']);
    aifEntityKey = new AifEntityKey();
    aifEntityKey.parmTableId(tableNum(SalesTable));
    aifEntityKey.parmKeyDataMap(map);
   
    new FileIoPermission(fileName, #io_read).assert();
    xmlDocument      = XmlDocument::newFile(fileName);
    CodeAccessPermission::revertAssert();
       
    axdSalesOrder    = new AxdSalesOrder();
    axdSalesOrder.update(aifEntityKey, xmlDocument.xml(), new AifEndPointActionPolicyInfo(), new AifConstraintList());

    info("Done");
}

Validate AX DLL Versions on Multiple Machines

List the versions for all DLLs which will load in AX using the Get-AxDllVersions. Download the PowerShell script.  Run this script against all machines running the AX client (RDP/Citrix/end-user) and servers. This is useful to confirm that all DLLs deployed match in file version.

Example 1: Export DLL Versions for Local Machine

.\Get-AxDllVersions.ps1

Example single value:

ComputerName : Server1
FileVersion : 6.3.5000.3084
ProductVersion : 6.3.5000.3084
OriginalName : Microsoft.Dynamics.Retail.TestConnector.dll
FilePath : \DAXDEVMCA1\c$\Program Files\Microsoft Dynamics AX\60\Server\Server1\bin\Connectors
FileDescription :
ProductName : Microsoft Dynamics AX Status : Success

Example 2: Retrieving Multiple Server DLL Versions

.\Get-AxDllVersions.ps1 -ComputerName "Server1","Server2"

Example 3: Export Multiple Server DLL Versions to CSV

.\Get-AxDllVersions.ps1 -ComputerName (Get-Content "ComputerList.txt")  | Export-csv "c:\temp\AX_DLL_Versions.csv" -NotypeInformation

Requirements

The script must be run as an account having Administrator access all computers. The script will skip any offline/inaccessible computers.