Meshsettings Folder being deleted

[EMAFan]

I run a Intel EMA cluster with both servers running all roles except the primary server which runs the ManagementServer role too. Running the latest version with Windows 2025, SQL 2022. No problems with any functionality for clients either registering or provisioning, nor managing.

However I have a strange problem affecting the website. On my secondary server if I navigate to the website via the server two hostname (server2.domain.local), the web page loads successfully. If I load it via the share hostname alias (bob.domain.local) it will work randomly depending on which round robbin DNS lookup server you hit.

Digging down this is caused by the fact if you query server1.domain.local directly (the primary server), you receive a web.config file error concerning a shared decryption problem. The root cause of this is that the MeshSettings folder is missing on server1 and it is trying to decrypt the connections.config file which is encrypted by a machine key, on the second server (server2.domain.local)

I fixed this by decrypting the connections.config file on server2 (aspnet_iisreg), copying it over in clear text, re-encrypting it on server1 and copying the app.config file into a newly created MeshSettings folder.

However less than 24h later, the folder is gone again on server1 regardless of what ACLs I set. Presumably a process in IntelEMA is detecting this anomaly and clearing the newly creating files. When the folder is deleted, of course the web server on server1 fails again until the MeshSettings folder is created.

This issue doesn't occur on another cluster instance I have with a similar setup. On that setup, both servers have a MeshSettings folder created by the application and no manual creation of the files or decryption is required. Am I missing a step to configure this and why is the folder deleted regularly by a process? Nothing in any logs I could find made reference to it.

Thank you

[Arun_Intel1]

Hi EMAFan,

Greetings!

Your analysis is correct, the root cause of the web.config decryption error and the "MeshSettings" folder issue on your Intel EMA primary server is related to how Intel EMA handles encryption keys and configuration synchronization across cluster nodes.

Why the MeshSettings Folder Disappears

In a properly configured Intel EMA cluster, the "MeshSettings" folder (and its contents, like connections.config) should be automatically created and maintained by the application on all cluster nodes. If you have to manually create or copy files, this usually indicates a misconfiguration in how the cluster handles encryption keys or shared secrets.

The fact that the folder is deleted regularly suggests that the Intel EMA application is performing a consistency or integrity check and removing what it sees as "foreign" or inconsistent configuration, likely because:

The configuration file was not created by the application itself, or

The machine-level encryption keys (used for encrypting/decrypting connections.config) are not synchronized between nodes, causing decryption failures, which then triggers a cleanup or reset process.

What Should Happen

When setting up an Intel EMA cluster:

Machine Keys Must Match: The IIS machine keys (used for encryption/decryption) must be identical across all cluster servers. This ensures that any encrypted configuration (like connections.config) can be decrypted by any node in the cluster.

MeshSettings Folder: The application should create and maintain the "MeshSettings" folder and its contents automatically on each server, provided the keys and cluster configuration are correct.

What could be the issue:

On your problematic cluster, the machine keys are not synchronized between server1 and server2, so when server1 tries to decrypt a file encrypted by server2, it fails and the application removes the folder as part of its error handling.

Manually copying and re-encrypting the file is a temporary workaround, but the application expects to manage this itself and will clean up what it sees as an anomaly.

How to Fix

Synchronize Machine Keys Across All Cluster Nodes:

In IIS Manager, go to the Machine Key section for your EMA application.

Set the same values for Validation Key and Decryption Key on all cluster servers. Do not allow IIS to auto-generate these keys; they must be identical to ensure cluster-wide decryption works.

Save and apply the changes, then restart IIS/app pool on all nodes.

Remove Manual MeshSettings Folder and Let EMA Recreate It:

After synchronizing keys, delete any manually created MeshSettings folders/files.

Restart the Intel EMA services (and IIS) on all nodes. The application should now automatically create and maintain the MeshSettings folder and its contents, and the decryption errors should cease.

Verify Cluster Health:

Access the EMA web console via both the individual server hostnames and the shared alias.

Confirm that the MeshSettings folder persists and that there are no decryption or configuration errors.

Why Your Other Cluster Works

Your other cluster works because, during its setup, the machine keys were correctly synchronized, allowing the application to handle encryption and configuration replication as designed.

Therefore, we are missing the step of synchronizing the IIS machine keys across all cluster servers. Without this, Intel EMA cannot reliably decrypt shared configuration files, leading to the observed folder deletion and web.config errors. Once the keys are synchronized, the MeshSettings folder will be managed automatically by the application and will persist as expected.

Please refer to the Intel EMA Server Installation and Maintenance Guide given below under the Section 2.2.2.8 : "Set the values for the Validation key and the Decryption key to the values used for the initial distributed server,

https://www.intel.com/content/www/us/en/content-details/841803/intel-endpoint-management-assistant-intel-ema-server-installation-and-maintenance-guide.html?DocID=841803

Thanks & Regards

Arun

Intel Customer Support Technician

intel.com/vPro

[EMAFan]

Thank you for this incredibly detailed reply. I assumed I had missed something and had references the server guide but clearly not well enough. Please give me a few days whilst I look if this solution works. If it does (which I have all the confidence it will), I will accept the solution.

[Arun_Intel1]

Hi EMAFan,

Sure!

Please feel free to revert for any further query!

Thanks & Regards

Arun

Intel Customer Support Technician

intel.com/vPro

[Arun_Intel1]

Hi EMAFan,

Please let us know if the issue has been resolved and are we good to close this thread.

Thanks & Regards

Arun

Intel Customer Support Technician

intel.com/vPro

[EMAFan]

Unfortunately this did not work - the IIS settings were correct.

However I deleted my manually created Mesh Settings and restarted AppPools on both servers. On one server the IntelEMA service restarted correctly after the AppPool was restarted. On the other, after restarting the AppPool, and then restarting the IntelEMA service it entered a service start loop. I diagnosed that IntelEMA had removed the settings.txt file from the Platform Engine folder. After rebooting the machine, the service still failed to start so I ran the installer again. The installer complained that MeshSettings was missing, so I manually recreated it again. With the MeshSettings folder created and settings.txt missing the installer seemed to detect a corrupted install and allowed me to install all the components against whilst retaining my settings from the DB.

It is now working correctly.

[EMAFan · Accepted solution]

Solution:

1. Stopped AppPool

2. Stopped services.

3. Restarted services.

4. Service enters loop...

5. Recreated MeshSettings folder manually using decrypted IIS settings.

6. Ran platform installer.

7. Selected install.

8. Complete install and restart server.

[Arun_Intel1]

Hello EMAFan,

Glad that the issue has been resolved and the set up is working fine now!

Please feel free to contact us for any further query, we are happy to assist you!

Thanks & Regards

Arun

Intel Customer Support Technician

intel.com/vPro