What this means is that the script will be downloading a file to be run (often an .exe or other installer) and the script includes a check of the file signature of the download to make sure the correct file is being run. It's a defense against "man-in-the-middle" attacks. If the file that is about to be run has a different hash signature than the one we know is correct, the script will stop to avoid running an unknown exe or file. Here are our troubleshooting steps:
- Check and make sure the component is updated
- Clear the packages folder on affected devices (C:\ProgramData\CentraStage\Packages) and run the job again.
- Review the script to identify what specific file is being checked for hash and it's location (AI can help us determine this by copy-pasting the script into the Kaseya agent if it is unclear which file is being checked
- If the file exists, see if you or the partner can rename it and try running the script again to ensure the script tries to download a new file (and an old file isn't what is being found with the wrong hash)
- Determine if there are two actual hash values that don't match, or they don't match because one of them is blank (no hash found at all). If the hash couldn't be found, it could be a problem with the way powershell downloads the file
- Review the actual file that is downloaded for any clues. Is the date modified older than when the component is run (could be an old file with the same name, preventing download)? Is it a zip with missing contents (we've had rare instances where AV or network security strips contents of zip files from the download, but this is very uncommon)