Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Note
Community interest groups have now moved from Yammer to Microsoft Viva Engage. To join a Viva Engage community and take part in the latest discussions, fill out the Request access to Finance and Operations Viva Engage Community form and choose the community you want to join.
Important
Starting February 2026, new customers can't create projects in Microsoft Dynamics Lifecycle Services for Microsoft Dynamics 365 Finance, Microsoft Dynamics 365 Supply Chain Management, and Microsoft Dynamics 365 Project Operations. New customers should use the Power Platform admin center instead. For more information, see Lifecycle Services project creation freeze.
Local agent 2.3.0 supports the execution of predeployment and postdeployment scripts. Therefore, you can now set up Microsoft Windows PowerShell scripts that run before and after the environment is deployed. This feature applies to deployments and redeployments, and also to servicing operations.
To make this feature available, create a Scripts folder in the agent file share. To run a predeployment script, create a PreDeployment.ps1 file in the Scripts folder. To run a postdeployment script, create a PostDeployment.ps1 file. The following examples show the folder structure:
- \\\fileserver\agent\scripts\PreDeployment.ps1
- \\\fileserver\agent\scripts\PostDeployment.ps1
If these files don't exist, the deployment continues as usual. The following examples show the new deployment flow.
Deployment or redeployment:
- Get unhealthy modules. In this step, the local agent gets the health of existing services to find which ones are unhealthy. This step applies only to redeployment scenarios.
- Clean up modules. In this step, the local agent removes the services and deletes the contents of the wp folder. This step applies only to redeployment scenarios.
- Link download artifacts. In this step, the local agent downloads, extracts, and processes artifacts from Microsoft Dynamics Lifecycle Services (LCS).
- Predeployment script. In this step, the local agent runs the PreDeployment.ps1 script (if it exists).
- Set up modules. In this step, the local agent deploys the new services.
- Postdeployment script. In this step, the local agent runs the PostDeployment.ps1 script (if it exists).
Servicing:
- Prepare for servicing. In this step, the local agent prepares the package in LCS and downloads it to the environment.
- Clean up modules. In this step, the local agent removes the services and deletes the contents of the wp folder.
- Link download artifacts. In this step, the local agent extracts and processes previously downloaded artifacts from LCS.
- Predeployment script. In this step, the local agent runs the PreDeployment.ps1 script (if it exists).
- Set up modules. In this step, the local agent deploys the new services.
- Postdeployment script. In this step, the local agent runs the PostDeployment.ps1 script (if it exists).
Note
The predeployment and postdeployment scripts can contain any code. You're solely responsible for the code that the scripts run. The local agent just invokes the scripts.
Customizations
The default timeout for script execution is 30 minutes. To change this value, modify the localagent-config.json file, and then reinstall the local agent by using the modified file. The following attribute defines the timeout value and must be set as shown. (The code that is shown here is part of the LocalAgent component in the file.)
"powershellScriptRunner": {
"timeoutMinutes": {
"value": "30"
}
}
Logging
The scripts write their outputs and error messages as .log and .err files into the Logs folder in the Scripts folder. If a script times out, only an error message is logged. This error message has a timeout message. No other outputs are logged in this situation.
The local agent also logs the execution of the scripts as Event Tracing for Windows (ETW) events. You can view these events in Event Viewer. If a script produces any errors, the local agent logs an error event but continues the deployment as usual.