Did 25R2 deployment overwrite MAIL_SENDER1 configuration parameters?

Hi ​@maheshmuz,

From my understanding, MAIL_SENDER1 is an IFS Connect configuration object rather than application metadata that is normally recreated during every release deployment. Therefore, under normal circumstances, I would not expect a 25R2 upgrade to intentionally reset a customer-configured MAIL_SENDER1 instance back to the original core values. However, the actual outcome can depend on how the environment was upgraded, whether configuration data was restored from backups, whether environment recreation was involved, and whether any post-upgrade activities were performed on the IFS Connect configuration. I have not found any release documentation stating that 25R2 explicitly resets MAIL_SENDER1 to its default configuration during deployment.

If the sender configuration changed after the upgrade, I would suggest investigating whether the MAIL_SENDER1 parameters were maintained as environment-specific configuration or if they were overwritten during a configuration import, environment refresh, delivery deployment, or other post-upgrade activities. In several IFS Connect implementations, customer-specific sender definitions and authentication settings are considered operational configuration and should ideally remain unchanged unless a deployment activity explicitly updates them. The fact that the change was observed immediately after the upgrade does not necessarily prove that the 25R2 installer itself performed the reset.

Hi ​@ashen_malaka_ranasinghe ,

Thank you for your response.

Sorry, I should have mentioned that this was not an upgrade but an update that we applied to the environment. Previously, the environment was running 25R1, and we applied the 25R2 update.

The issue occurred after applying the 25R2 update. We did not experience this problem with the previous updates that were installed in the environment. This appears to have started only after the 25R2 update installation.

Hi ​@InfFilipV , Thank you for the response. What would be the recommended method to follow for mitigating this issue? Is creating a new ifs connect without using the default ifs connect the only available way to mitigate this issue?

Hi,
yes, not using auto created instances is only future proof option.

This file was untouched for 3 years… 
If it was split in multiple files, it would not happen… (but now it is hard to solve - if IFS splitted it now, it would trigger another reimport….)

When you recognise in logs (during delivery build) that this file "fndbas\server\connect_config\0_ConnectConfigurations.xml" is present in delivery, you can backup current configuration - but you must notice it first…
Backuping these before every delivery installation is also just complicated easy to forgot workaround...

I too encountered this issue where the MAIL_SENDER1 values were reset to their default. To resolve it across Service Update installations, I created a new Mail Sender record with the values I needed to be preserved, and made it our default sender. It’s not ideal, but it worked.