New post series 'WorthKnowing'

Hello Everyone,

I'm excited to kick off a brand-new blog series where I’ll be sharing bite-sized insights and interesting facts about Dynamics 365 Finance and Operations (D365FO).

This series will highlight:

• Hidden gems that have been around for a while but often go unnoticed
• New features and their best use cases
• Common functionalities you might be using differently than intended
• Similar looking things with their core differences

Each post will be short, sharp, and packed with useful takeaways to help you get the most out of D365FO.

Stay tuned — and let’s explore these insights together!

-Harry Follow us on Facebook to keep in rhythm with us. https:fb.com/theaxapta

How to Remove a Model or ISV Solution from Dynamics 365 Finance and Operations (D365FO)

Hi Folks, 

Removing a model or ISV solution from a Dynamics 365 Finance and Operations (D365FO) environment can be a necessary step during system cleanup, decommissioning unused features, or resolving conflicts. However, it must be done carefully to avoid breaking dependencies or corrupting the application metadata.

In this post I’ll Walk through the safe and structured process of removing a model or ISV solution from D365FO.

Before you begin, ensure:

• You have access to a development environment (Tier 1).
• You have admin rights in Visual Studio and Lifecycle Services (LCS).
• You’ve taken a full backup of model you want to delete/remove.
• You’ve identified dependencies and verified that no other models rely on the one you’re removing.

1. Identify the Model

Open Visual Studio in your D365FO development environment:

·       Go to Dynamics 365 > Model Management > Model Management.

·       Use the Model Util tool or PowerShell to list installed models:

Get-AXModel -Details

Identify the model name, publisher, and layer (e.g., ISV, VAR, CUS).

2. Check for Dependencies

Use the Model Dependencies Report in Visual Studio:

·       Go to Dynamics 365 > Model Management > Model Dependencies.

·       Select the model and generate the report.

·       Ensure no other models depend on the one you want to remove.

3. Uninstall the Model

If the model was installed via a deployable package (e.g., from an ISV), you’ll need to:

·       Remove the package from the AOSService\PackagesLocalDirectory.

·       Delete the model folder manually.

·       Optionally, use PowerShell: (This command only works for models installed via XPO or model store, not for package-based deployments.)

Uninstall-AXModel -Model <ModelName

4. Rebuild and Synchronize

After removal:

• Open Visual Studio.
• Rebuild the solution to ensure no broken references.
• Run Database Synchronization to update the schema.

5. Check in the changes

Do the code check in for deleted objects, make sure you select all deleted objects from your ‘pending changes’ tab.

6. Prepare package for Sandbox

·       Create DefaultModelDelete.txt This file tells the system which models to remove. It must contain the exact model name as registered in the model manifest. Just add exact model name in this file, if there are multiple models pl add into next line for example,

§  Model1

§  MyISVModel

• Create a new deployable package using your build pipeline or manually.
• Place the DefaultModelDelete.txt file in the root of the deployable package folder (same level as AXDeployablePackage).
• Ensure the model binaries and metadata are not included in the package.

7. Package deployment

·       Upload the package to LCS Asset Library.

·       Apply it to your sandbox or production environment.

·       Monitor the deployment logs for confirmation that the model was removed.

Removing a model—especially in production—requires precision and planning. Using the DefaultModelDelete.txt method ensures a clean and supported way to decommission ISV or custom solutions without manual intervention in higher-tier environments.

Custom web service in D365FO - Part-II

Hi Folks,

In Part 1, we covered the foundational elements of creating custom services in Dynamics 365 Finance and Operations (D365FO), including the architecture, request/response contracts, and service class. In this second part, we’ll explore how to implement business logic, test your service, and handle errors effectively to ensure your service is robust and production ready. Its important you take a look to my previous post as I will carry on example from that post.

 Custom web service in D365FO - Part-I

Implementing Business Logic

Once your service class is set up, the next step is to implement meaningful business logic. This could involve querying tables, performing validations, or updating records. Here's an enhanced version of the processMsg() method with actual logic:

Testing the Service

Once deployed, you can test your service using tools like Postman or SoapUI. Here's how to do it with Postman:

1. Set the URL:

https://<your-environment>.cloudax.dynamics.com/api/services/TheAxaptaInterface/TheAxaptaService/processMsg

1. Set Headers:
• Content-Type: application/json
• Authorization: Bearer token (use OAuth 2.0)
2. Request Body (JSON):
3. Send Request and inspect the response.

Error Handling and Logging

Robust error handling is essential for production-grade services. Here are some best practices:

• Use try-catch blocks to handle both X++ and CLR exceptions.
• Log errors using the EventLog or custom logging frameworks.
• Return meaningful messages in the response contract to help consumers understand what went wrong.
• Avoid exposing sensitive data in debug messages.

Example of logging:

EventLog::add(EventLogCategory::Application, EventLogLevel::Error, "CustomServiceError", response.parmDebugMessage());

-Harry Follow us on Facebook to keep in rhythm with us. https:fb.com/theaxapta

[Solved] Unable to connect with Dev box Error code: 0xd07

Hi folks,

Recently, I ran into a frustrating issue while trying to connect to my development box. Out of the blue, the system refused to let me in and threw an error that blocked my access. If you've ever been in the middle of a project and suddenly lost access to your VM, you know how disruptive this can be.

After some trial and error, I found a solution that worked—and I’m sharing it here in case it helps someone else facing the same problem.

Error message: 

Remote Desktop Connection

As a security precaution, the user account has been locked because there were too many logon attempts or password change attempts. Wait a while before trying again, or contact your system administrator or technical support.

Error code: 0xd07

Extended error code: 0x0

Timestamp (UTC): 06/11/25 09:48:38 AM

Solution: 

Step 1: Try a Full Stop and Start (Not a Restart)

First, I tried restarting the VM from the Azure portal, but that didn’t help. What worked was stopping the VM completely and then starting it again. This seems to reset some internal state that a simple restart doesn’t touch.

Step 2: Use an Alternate User to Regain Access

If the stop/start method doesn’t work, the issue might be with the admin account being locked. In that case, you can log in using an alternate user account. You can find this user’s credentials on the LCS (Lifecycle Services) page under Environment Details.

Here’s how to proceed:

• Log in to the VM using the alternate user.
• Open the Run dialog (press Win + R) and type: lusrmgr.msc
• This opens the Local Users and Groups management console.
• Find the admin user, right-click on it, and select Properties.
• Uncheck the option that says “Account is locked out” (or similar).
• Apply the changes and try logging in again with the admin account.

Other Recommendations: 

1. Add the other user in Admin group once your admin account is enabled, this will give you more control on this when needed. 

2. You can also install Account Lockout Status for further troubleshooting on why account is getting locked

3. While you are unlocking Admin account, also set 'Password never expire' option this will disable the option itself of account getting locked. 

-Harry Follow us on Facebook to keep in rhythm with us. https:fb.com/theaxapta