D365 – Dev Enviornment – Missing event logs

We see that newer CHE are missing event viewer logs for the D365FO development machines. To Enable those logs run following commands in Power shell as Admin. (While wait for Microsoft to fix the machines)

AOS Event Logs

$AOSSetupETWManifestDir = "K:\AosService\WebRoot\Monitoring"
foreach ($manifestFile in Get-ChildItem -Path $AOSSetupETWManifestDir*.man | select-object -Property BaseName,Name)
{

$dllFile=""

if ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName).Instrumentation.dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName).Instrumentation.dll"

}

elseif ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName)Resource.dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName)Resource.dll"

}

elseif ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName).dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName).dll"

}

else 

{

    Write-Host "Warn : Skipping $AOSSetupETWManifestDir\$($manifestFile.Name) as DLL not found"

    Continue    

}



Write-Host "Installing $AOSSetupETWManifestDir\$($manifestFile.Name) using $dllFile"

wevtutil.exe im "$AOSSetupETWManifestDir\$($manifestFile.Name)" /rf:"$dllFile" /mf:"$dllFile"

Write-Host "Finished installing $AOSSetupETWManifestDir\$($manifestFile.Name) `n`n"

}

Commerce Logs

$AOSSetupETWManifestDir = "K:\RetailServer\webroot\bin"
foreach ($manifestFile in Get-ChildItem -Path $AOSSetupETWManifestDir*.man | select-object -Property BaseName,Name)
{
$dllFile=""

if ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName).Instrumentation.dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName).Instrumentation.dll"

}

elseif ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName)Resource.dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName)Resource.dll"

}

elseif ((Test-Path "$AOSSetupETWManifestDir\$($manifestFile.BaseName).dll"))

{

    $dllFile = "$AOSSetupETWManifestDir\$($manifestFile.BaseName).dll"

}

else 

{

    Write-Host "Warn : Skipping $AOSSetupETWManifestDir\$($manifestFile.Name) as DLL not found"

    Continue    

}



Write-Host "Installing $AOSSetupETWManifestDir\$($manifestFile.Name) using $dllFile"

wevtutil.exe im "$AOSSetupETWManifestDir\$($manifestFile.Name)" /rf:"$dllFile" /mf:"$dllFile"

Write-Host "Finished installing $AOSSetupETWManifestDir\$($manifestFile.Name) `n`n"
}
After running scripts

D365 Database sync – command

Command to do a manual database sync on Development environment

K:\AosService\WebRoot\bin\Microsoft.Dynamics.AX.Deployment.Setup.exe -bindir “K:\AosService\PackagesLocalDirectory” -metadatadir “K:\AosService\PackagesLocalDirectory” -sqluser “axdbadmin” -sqlserver “localhost” -sqlpwd “xxxx” -sqldatabase “AxDB” -setupmode “sync” -syncmode “fullall” -isazuresql “false”

IDX10205: Issuer validation failed for D365 Operations

While setting up a new VM for cutomer project, we came across an issue where we were not able to do the API calls and were receiving following message in the window event logs.

2017-08-09_21-44-48

Clicking “Details” will give you something like below (Trimmed details – showing the relative error message)

IDX10205: Issuer validation failed. Issuer: ‘https://sts.windows.net/GUID-AAD#1/’. Did not match: validationParameters.ValidIssuer: ‘null’ or validationParameters.ValidIssuers: ‘https://XXXXXXXXXX.sandbox.ax.dynamics.com, 00000000-0000-0000-c0000-000000000000, microsoft.erp, https://sts.windows.net/GUID-AAD#2

The first thing to notice that GUIDs are different – these ids should be similar when request is being posted with bearer token. This lead us to check the “UserInfo” table in the onebox machine. However, that didn’t help – so we looked further.

Upon further investigation we found out that web.config file in J:\AosService\WebRoot that had the original domain name related to person who deployed the VM for D365 Operations.

The domain name was different than actual tenant, after making the both same we were able to post the requests through Postman and received successful response. 

The lesson learnt was that we should be deploying the VMs from their tenant’s account instead of partner’s account.

Thanks,