LCS Package Deployment failed D365FO
Yesterday, I faced the error during Package deployment through LCS on newly provision Environment.
Deployment were crash on Step-24 and on Runbook the only thing is mentioned that script halted..
Runbook Step
<Log>
<Time>2018-08-28T07:02:12.4782433+00:00</Time>
<MachineName>KHA-DEV-1</MachineName>
<StepID>24</StepID>
<Message>The step started</Message>
</Log>
<Log>
<Time>2018-08-28T07:03:46.6864227+00:00</Time>
<MachineName>KHA-DEV-1</MachineName>
<StepID>24</StepID>
<Message>ScriptHalted</Message>
</Log>
<Log>
<Time>2018-08-28T07:03:46.6864227+00:00</Time>
<MachineName>KHA-DEV-1</MachineName>
<StepID>24</StepID>
<Message>The step failed</Message>
</Log>
When I download the detail logs of the deployment nothing was mentioned their related to Failure of the step..
When I check event viewer logs of the Instance found below error
Faulting application name: Microsoft.Dynamics.AX.Deployment.Setup.exe, version: 7.0.4841.41289, time stamp: 0x1d43b12822ca100
Faulting module name: , version: , time stamp: 0x Please see crash analysis results at https://azurewatson.cloudapp.net
Exception code: 0x Please see crash analysis results at https://azurewatson.cloudapp.net
Fault offset: 0x Please see crash analysis results at https://azurewatson.cloudapp.net
Faulting process id: 0x1980
Faulting application start time: 0x1d43ea61e64c62f, kernel time: 0x02a05724, user time: 0x07f8dcf0
Faulting application path: K:\AosService\WebRoot\bin\Microsoft.Dynamics.AX.Deployment.Setup.exe
Faulting module path: Please see crash analysis results at https://azurewatson.cloudapp.net
Report Id: 7862bf9a-e223-4488-aa6d-a3b5fe340b37
Faulting package full name:
Faulting package-relative application ID:
After spending hours of hours we decide to log the issue to Microsoft about this strange behavior..
After investigation Microsoft found that this is product issue which they are facing on newly create VM and provide solution with us..
Following is the solution provided by Microsft
The
workaround for the issue is the following, and from my testing, these steps can
be performed on a machine that is a non-admin developer box in Microsoft’s
subscription:
- Go to the Environment
Details page that shows the servicing status of Failed
- Click on the Manage Environment
header if you need to expand it to see the RDP and password information
- RDP into your
Developer/Demo or AOS machine within the environment and perform the
following steps to Repair the ODBC Driver 17 installation on the machines
- Go to the Start menu
and open Add or Remove programs
- In the Add or Remove
Programs window, type ODBC in the Search box which should let you see the
following results:
- Then highlight the ODBC
Driver 17 and press Modify, then click Next on the opening window of the
wizard
- Then choose Repair and
press Next and then press Install on the next dialog
- Wait for the install to
finish and press the Finish button
- Repeat these steps for
every AOS machine in your environment (including any Private AOS) if you
are using a multi-box Sandbox environment.
- After these steps have
been performed on every AOS, go back to LCS and press Resume to continue
with the servicing operation.
- If the you already
aborted the operation, you can perform these actions BEFORE starting the
servicing operation