Dynamics - Learn by coding..!!!

Hello there,

Upgrading a Cloud-Hosted Environment (CHE) in Dynamics 365 Finance and Operations is usually a "set it and forget it" task. But occasionally, the LCS deployment hits a wall at the DevToolsService step, leaving you with a failed update and a Visual Studio instance that feels a bit broken.

If you’ve seen the error Update script for service model: DevToolsService on machine..., you aren’t alone. Here is the simple, direct way to fix it and why it happens.

The Issue: Why Automation Fails

The LCS deployment uses a PowerShell script called AutoUpdateDevToolsService.ps1 to automatically find your Visual Studio installation and update the D365 extension.

Why it misses:

Version Mismatch: If you’ve upgraded to Visual Studio 2022 on an older VM, the script sometimes looks for the VS2019 path and panics when it can't find it.
Folder Permissions/Missing Links: Sometimes the automation simply fails to resolve the path to the existing extension, causing the whole deployment to "fail" even if the AOS and Database steps are fine.

The Solution: The "Manual Touch"

When automation fails, the most reliable fix is to handle the extension installation yourself. This approach ensures the tools are registered correctly in your specific version of Visual Studio.

1. Locate the Package

Navigate to the Service Volume (usually the K: drive on cloud VMs).

Path: K:\DeployablePackages\

Sort the folders by Date Modified and open the most recent folder—this is the update package currently being applied.

2. Find the Scripts

Inside that package folder, go to:

DevToolsService\Scripts

3. Install the Extensions Manually

In this folder, you will find one or more .vsix files. These are the Visual Studio extension installers. You should see:

The Main Installer: Usually named Microsoft.Dynamics.Framework.Tools.Installer.vsix (look for the version that matches your VS, e.g., .17.0 for VS2022).
The Internal Tools: Microsoft.Dynamics.Framework.Tools.InternalDevTools.vsix.

Action: Close all Visual Studio instances and double-click these files to run them. If prompted, select the version of Visual Studio you are currently using.

Final Step: Resume the Upgrade

Once you’ve manually installed the tools, the "heavy lifting" for that step is done.

Go back to Lifecycle Services (LCS).
Click Resume on the failed deployment.
The system will re-check the environment, see that the tools are present, and move on to the next steps (like Database Synchronization).

Summary

Don't let a "DevToolsService" error ruin your day. If the automation can't find Visual Studio, just walk into the K: drive, find the latest deployable package, and run the installers manually. It’s a 5-minute fix for a frustrating problem.

Cheers!

Have you ever updated a Legal Entity name in Dynamics 365 Finance and Operations, hit save, refreshed your browser, and… nothing? The old name is still staring back at you from the dashboard or that little "pill" in the top-right corner.

It feels like the system is gaslighting you! In this blog, we’ll explore why a simple name change can turn into a deep-dive into the D365FO architecture, and we'll share the definitive steps to fix it.

The Problem: "I changed it, but I don't see it!"

The goal seems simple: Navigate to Legal Entities, change the "Name" field, and expect the UI to reflect that change globally. However, due to how D365FO handles caching and data relationships, the "Display Name" often gets stuck in the Application Object Server (AOS) memory or the Global Address Book (GAB).

Observations from the Field (The "Trial and Error" Phase)

Before we found the "Golden Fix," we observed several interesting behaviors while trying to force the system to update:

The Browser Isn't the Boss: A "Hard Refresh" (Ctrl + F5) or clearing browser cache rarely works for this. This isn't a website styling issue; it's a server-side data synchronization issue.
The "Pill" Control is Persistent: When using the modern Unified Header (the "bubble" that shows ID | Name), the name seems more stubborn than when using the Legacy Navigation bar. This is because that specific control is heavily dependent on the Metadata Cache.
Default Company Swapping: Even changing your user's default company, logging out, and logging back in doesn't always "nudge" the session to re-read the new name.
The GAB Duplicate Mystery: Searching the Global Address Book (GAB) often reveals multiple records for the same name. If the Legal Entity is linked to the "wrong" Party ID, or if the Party Record didn't update along with the Legal Entity form, the UI stays stuck in the past.

The Master Checklist: How to Actually Fix It

If you are facing this, follow these steps in order.

1. The Global Address Book (GAB) Audit

D365FO pulls names from the Party Record, not just the Legal Entity table.

Identify the Source of Truth: Go to the Legal Entity form, right-click the name, and select Form Information > Administration. Note the Party ID.
Update the GAB: Search for that specific Party ID in the Global Address Book. If the name there is the old one, edit it manually.
The Merge: If you find duplicate Party IDs for your company, use the GAB Merge tool to consolidate them into the "Master" ID linked to your Legal Entity.

Learn more: Microsoft Learn: Global Address Book Scopes

2. The Server-Side Flush (The "Magic" URL)

If the data is correct in the GAB but the UI is still wrong, you need to flush the AOS cache. Append this to your environment URL:

https://[yoururl].com/?mi=SysClassRunner&cls=SysFlushData

6. The Final Option: Service Restart (Tier-2)

In Tier-2 Sandbox environments, the Azure Redis Cache might be holding onto the old name. If all else fails, go to Lifecycle Services (LCS) and perform an AOS Service Restart. This clears the memory entirely and forces a fresh pull from the database.

Reference: LCS Environment Management

Conclusion: Data Integrity is Key

The takeaway? A Legal Entity in D365FO isn't just a row in a table; it’s a Party in a global ecosystem. When names get "stuck," it's almost always a sign that the link between the CompanyInfo table and the DirPartyTable needs a little manual love (or a big server-side reset).

We hope this guide helps you keep your environments clean and your Legal Entities accurately named!

Happy New Year everyone and Happy D365'ing!!