Microsoft Dynamics AX (Archived)

LCS Diagnostics failed after test deployment

(0) Share

Report

Posted on by Dynamixa

Does anyone know why this would occur after a deployment. It happens every time. Any help much appreciated.

WARNING DETAILS

Warning code

95017

Warning message

Script [InstallLCSDiagnostics_Unified] failed execution against VM [%AOSSERVERNAME%]. Last Result: 0xFFFFFFFF ()

Inside the LCS deployment script install log the following is shown:

System.IO.FileLoadException: Could not load file or assembly 'LCSDiagFXService, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

If the LCS diagnostic exe is run manually it crashes with the strong name validation error also.

*This post is locked for comments

All responses (2)

Answers (1)

Dynamixa on at

Like (0)

Report

RE: LCS Diagnostics failed after test deployment

Followed the instructions above and it works now!

After logging this with support it appears there are multiple customers effected with this particular issue.
Verified answer

AXGuy on at

Like (1)

Report

RE: LCS Diagnostics failed after test deployment

We have the same issue. After deploying multiple machines from various different regions & subscriptions to ensure that the issue wasn't isolated to us we decided to debug the script and have identified a workaround. The script is "C:\DynamicsAX\InstallLCSDiagnostics_Unified_I0_R0\Input\InstallLCSDiagnostics_Unified_I0_R0.ps1"

There are the following issues:

Firstly, service installation fails with "Strong name validation error". If you remove strong name validation (as per stackoverflow.com/.../strong-name-validation-failed) then you will encounter the following error: "System.ComponentModel.Win32Exception: The name is already in use as either a service name or a service display name". If you delete the conflicting service with "sc delete LCSDiagnosticClientService" and the service successfully installs then the "Discover" operation fails with a parameter mismatch. Once this has been corrected the pipe (net.pipe://localhost/LcsDiagnosticsPipe) fails from the IJobDispatcher in the “GetAXEnvironments” method. Even running the -debug flag against the LCSDiagFXCollector shows a blank were the connection should be.

This process has been established from breaking down the scripts and application using the trace log (See: docs.microsoft.com/.../configuring-tracing) and ILSpy (github.com/.../ILSpy).

To work around this we have done the following:

1) Install the "On-Premise" LCS Diagnostics tool

2) Discover & Upload your environment using this (creates "On-Premise" instance tile for given ENVIRONMENT_NAME)

3) Remove the diagnostics from LCS (Environments -> Admin)

4) Run the "DiscoveryStatus" from the command prompt (C:\LCSDiagnostics\LCSDiagFXCollector.exe -DiscoveryStatus "ENVIRONMENT_NAME") to ensure

5) Run "Discover" from the command prompt providing the Environment ID from LCS for the relevant environment (C:\LCSDiagnostics\LCSDiagFXCollector.exe -Discover "DATABASE_SERVER" "AX_DATABASE" "ENVIRONMENT_NAME" "AZURE_HOSTED_ENVIRONMENT_ID") - this will also run job to run the "Collect" script

6) Remove the "On-Premise" tile created in step 2

Once the environment is refreshed the diagnostic tiles will appear in LCS. After about 30 minutes the tiles will have had time to update and show meaningful numbers against the data from the collector.