MID Server Script Files get skipped in instance/app upgrades, after Checksum values are automatically addedDescriptionThe fix for a pair of security related product defects added in Utah (PRB1608860/PRB1588253), adds values to the checksum field of all MID Server Script File [ecc_agent_script_file] records where the record has no attachment and the script is in the record field. This causes those records to be skipped in future upgrades as Customizations. The impact of that is customers don't get potentially important fixes and enhancements related to those scripts, which could break features, or leave vulnerable script versions in place.customers may revert these to out-of-box, as is best practice after upgrades, removing the necessary checksumthis may add confusion and delay for customers and servicenow tech support when debugging issues with these applications after upgrade, where checking for skipped upgrades is an important part of that process. Many feature use MID Server Script Files of various types, including but not limited to: Agent Client Collector FrameworkCore AutomationDiscovery - IP BasedEvent ManagementMicrosoft SCCM SpokeMID ServerOrchestration - RuntimePattern DesignerSecurity Support OrchestrationServiceNow IntegrationHub Action Step - PowerShell System Center Configuration Manager (SCCM) Steps to Reproduce Tested in a Vancouver patch 2 instance Install any app or plugin that uses MID Server Script files e.g. Agent Client Collector Framework, which adds:GetAllIpsForWindows.ps1 /ecc_agent_script_file.do?sys_id=f9e62be6ffb11010574f5897d53bf1acGetAllIpsForLinux.sh /ecc_agent_script_file.do?sys_id=0fd36f66ffb11010574f5897d53bf11c already the 2 newly added script files are no longer on the out-of-box version "Store Application: Agent Client Collector Framework", but a custom "Update Set: Default" version, created by systemThe sys_update_xml record to go with this is set replace_on_upgrade=false Upgrade the app, or upgrade the plugin by upgrading the instance. If there is nothing to upgrade, Repair the plugin instead because the same code runs. The files are Skipped as customisations. If the app had a newer version of th record, to add a feature or correct a defect, it would not be applied.Tracing the database update to the transction will take you to a "Events process 0" job, which will have been processing either: A plugin.upgraded event, by script action Generate Checksum on Plugin UpgradeA plugin.activated event by script action Generate Checksum on Plugin Activation These both do a normal GlideRecord .update(). WorkaroundThis problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available. The workaround will ideally need doing before any app or instance upgrade that changes the contents of the script field of any MID Server Script File record: Set any sys_update_xml records for out of boc ecc_agent_script_file records, where they are in the Default update set, updated by system, to Replace on upgrade = true The alternative is to revert to the out-of-box version of the record after the upgrade, but this may leave the record without a checksum. In that case update the record, and a business rule adds it before update. With both methods, you will still end up with a custom version, you will need to deal with in the next upgrade until this problem is fixed.Related Problem: PRB1708634