Forum Discussion

MinaAdelKondos's avatar
MinaAdelKondos
Copper Contributor
Jan 15, 2026

Error on deployment on a CHE

I'm experiencing an error during the deployment of any package to a cloud-hosted environment. The error occurs specifically at step 11, 'Global Update script for service model: AOS Service,' and results in a failure to resume the deployment process.

The issue happens on the DB sync, however if I tried to sync the DB from the visual studio it succeeded without any errors. And If I tried to restore another empty DB for example, the deployment will succeed.

And if I tried to restore the DB on another CHE, the same issue happens.

The issue is that we need this DB, because it is the Master configuration DB, so we cannot delete it.

 

So my question is what is the best way to solve this issue and how can we know what is the issue with this DB?

 

Thanks in advance.

2 Replies

  • hi MinaAdelKondos​ 

    This kind of issue usually points to something specific inside that database, rather than the CHE or the deployment pipeline itself , especially since:

    • DB sync works fine from Visual Studio
    • Deployment succeeds with a fresh/empty DB
    • Restoring the same DB to another CHE reproduces the problem

    That combination strongly suggests data or metadata inconsistencies that only surface during the AOS Global Update script phase (step 11), which runs a broader set of checks and upgrade logic than a standard VS DB sync.

    A few practical things that have helped in similar cases:

    1.Check deployment logs in detail

    The failure at step 11 should produce SQL or X++ errors in the LCS deployment logs (and sometimes in the SQL error log). Look for:

    Failing upgrade scripts

    Missing objects, invalid metadata references

    Duplicate keys or orphaned records in system tables

    VS DB sync is more forgiving; the deployment upgrade is not.

     

    2.Validate system tables and metadata

    Issues often come from corrupted or inconsistent data in tables like:

    SQLDictionary, SQLMetadata, UtilElements, SysModel*

    Custom extension metadata referencing objects that no longer exist

    If possible, compare these tables against a known-good environment.

     

    3.Run DB validation / consistency checks

    If this is a D365FO-style environment, run:

    Full DB sync + compile with “report errors”

    Metadata validation (best practice checks)

    Any available DB consistency or validation jobs

    Even if they don’t fail hard, warnings can point you to the root cause.

     

    4.Look at recent changes to the master DB

    If this DB has gone through multiple restores, upgrades, or partial deployments, it may contain:

    Incomplete upgrade history

    Leftover artifacts from removed models or extensions

    Sometimes exporting/importing configuration data into a clean DB is safer than continuing to reuse a problematic master DB.

     

    5.Escalate with logs if needed

    Since this blocks CHE deployments and the DB is business-critical, opening a Microsoft support ticket with:

    The failing deployment ID

    Full step 11 logs

    Confirmation that the issue reproduces across CHEs

    is usually the fastest way to get a definitive answer.

    Hope that helps , curious if anyone else has hit a similar “DB works in VS but fails in CHE deployment” scenario and what finally fixed it.

  • This error generally indicates that the database schema or metadata within the Master configuration database is not aligned with the requirements of the AOS Service update script during deployment. Although database synchronization from Visual Studio may complete successfully, the Cloud-Hosted Environment (CHE) deployment pipeline applies stricter validation rules. As a result, misaligned objects such as views, fields, or obsolete schema elements can cause the process to fail.
    To resolve this issue, it is recommended to thoroughly review the deployment logs for the failing step, perform consistency checks on the database schema, and compare the configuration against a clean environment. Microsoft further advises leveraging SQL trace logs, Lifecycle Services (LCS) environment monitoring, and database comparison tools to identify and remediate problematic objects prior to reattempting deployment.

Resources