Showing posts with label ScriptHalted. Show all posts
Showing posts with label ScriptHalted. Show all posts

LCS Package Deployment failed D365FO




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:
  1. Go to the Environment Details page that shows the servicing status of Failed
  2. Click on the Manage Environment header if you need to expand it to see the RDP and password information
  3. 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
    1. Go to the Start menu and open Add or Remove programs
    2. In the Add or Remove Programs window, type ODBC in the Search box which should let you see the following results:
                                 

    1. Then highlight the ODBC Driver 17 and press Modify, then click Next on the opening window of the wizard
    2. Then choose Repair and press Next and then press Install on the next dialog
             


    1. Wait for the install to finish and press the Finish button
    2. Repeat these steps for every AOS machine in your environment (including any Private AOS) if you are using a multi-box Sandbox environment.
  1. After these steps have been performed on every AOS, go back to LCS and press Resume to continue with the servicing operation.
  2. If the you already aborted the operation, you can perform these actions BEFORE starting the servicing operation






Support Faryal's Cusine


Virtual Fields Vs Computed Fields

  Virtual Field: A virtual field in D365FO is a field that doesn't have a direct representation in the database. It's a field that y...