D365 CE on-premises — Email signature image upload fails with 500

We are reporting a reproducible defect in the out-of-the-box rich text editor on Dynamics 365 Customer Engagement on-premises. The issue is isolated to the Email Signature record in the new UI. The same signature created through the legacy Personal Settings path uploads the image without error.

Environment

• Dynamics 365 Customer Engagement, on-premises, Server version: 9.1.0048.0004
• Client web resource version: 1.4.11684-v91onpremise
• Organization: DEV, at http://<crm-server>/DEV/
• Affected scope: Email Signature (emailsignature) record, "Signature editor" rich text control, new UI only
• Out-of-the-box functionality. No customisation, plug-in, or third-party component involved

Issue

On the Email Signature record in the new UI, inserting an image into the Signature editor fails. The editor displays "File upload failed. Please try again."

The underlying call is:

POST http://<crm-server>/api/data/v9.0/msdyn_richtextfiles

→ 500 Internal Server Error

The organization name is missing from the endpoint. The correct organization-scoped endpoint is:

POST http://<crm-server>/DEV/api/data/v9.0/msdyn_richtextfiles

Request body (105 bytes — no file content is sent at this stage):

{"msdyn_parententityname":"emailsignature","msdyn_parententity_fieldname":"safehtml","msdyn_parentid":""}

Response

The response is not a Web API error. It is an ASP.NET error page, Content-Type text/html, titled "Runtime Error", with the heading "Server Error in '/api' Application." This is consistent with the request reaching an application at the server root with no organization context instead of the organization-scoped Web API, which would return a JSON error payload.

The control then retries. A single insert attempt produces 11 identical POST requests within approximately 270 milliseconds, each returning the same 500 response.

Steps to reproduce

1. In the new UI, open an Email Signature record (new or existing).
2. In the Signature editor, insert an image.
3. Upload fails. The POST above appears in the browser console.

This reproduces consistently, on both new and existing Email Signature records.

Scope: Email Signature in the new UI only

We created the same email signature via Personal Settings and the image uploaded successfully there. The failure is therefore specific to the Email Signature record in the new UI, not to the image file, the record data, or the environment generally.

The Personal Settings route is not usable for us, however. When a signature created there is inserted into an email and the email is sent, the signature layout is mixed up in the delivered message. Our users therefore prefer the Insert Signature step in the new UI, which is where they encounter the 500 error above. Neither path currently produces a working signature with an image, so we have no viable workaround.

Additional detail

The failure occurs before any file bytes are transmitted, so attachment size limits and blocked file extensions are not a factor.

The attached is HAR file and screenshot for your reference. The HAR capture was recorded 2026-09-15 04:22 UTC.

Please confirm whether this is a known issue on this build and advise on a fix or update rollup. We can provide server-side stack traces, sample signatures, sent-message samples, and further captures on request.We are reporting a reproducible defect in the out-of-the-box rich text editor on Dynamics 365 Customer Engagement on-premises. The issue is isolated to the Email Signature record in the new UI. The same signature created through the legacy Personal Settings path uploads the image without error.

Environment

• Dynamics 365 Customer Engagement, on-premises, Server version: 9.1.0048.0004
• Client web resource version: 1.4.11684-v91onpremise
• Organization: DEV, at http://<crm-server>/DEV/
• Affected scope: Email Signature (emailsignature) record, "Signature editor" rich text control, new UI only
• Out-of-the-box functionality. No customisation, plug-in, or third-party component involved

Issue

On the Email Signature record in the new UI, inserting an image into the Signature editor fails. The editor displays "File upload failed. Please try again."

The underlying call is:

POST http://<crm-server>/api/data/v9.0/msdyn_richtextfiles

→ 500 Internal Server Error

The organization name is missing from the endpoint. The correct organization-scoped endpoint is:

POST http://<crm-server>/DEV/api/data/v9.0/msdyn_richtextfiles

Request body (105 bytes — no file content is sent at this stage):

{"msdyn_parententityname":"emailsignature","msdyn_parententity_fieldname":"safehtml","msdyn_parentid":""}

Response

The response is not a Web API error. It is an ASP.NET error page, Content-Type text/html, titled "Runtime Error", with the heading "Server Error in '/api' Application." This is consistent with the request reaching an application at the server root with no organization context instead of the organization-scoped Web API, which would return a JSON error payload.

The control then retries. A single insert attempt produces 11 identical POST requests within approximately 270 milliseconds, each returning the same 500 response.

Steps to reproduce

1. In the new UI, open an Email Signature record (new or existing).
2. In the Signature editor, insert an image.
3. Upload fails. The POST above appears in the browser console.

This reproduces consistently, on both new and existing Email Signature records.

Scope: Email Signature in the new UI only

We created the same email signature via Personal Settings and the image uploaded successfully there. The failure is therefore specific to the Email Signature record in the new UI, not to the image file, the record data, or the environment generally.

The Personal Settings route is not usable for us, however. When a signature created there is inserted into an email and the email is sent, the signature layout is mixed up in the delivered message. Our users therefore prefer the Insert Signature step in the new UI, which is where they encounter the 500 error above. Neither path currently produces a working signature with an image, so we have no viable workaround.

Additional detail

The failure occurs before any file bytes are transmitted, so attachment size limits and blocked file extensions are not a factor.

Please confirm whether this is a known issue on this build and advise on a fix or update rollup. We can provide server-side stack traces, sample signatures, sent-message samples, and further captures on request.