Pre-Compiled Secret Server On-Premises Releases

This topic only applies to Secret Server On-Premises.

Overview

Before Secret Server 11.8, Secret Server On-Premises was delivered in a dynamically compiled state. IIS compiled parts of the website, particularly the .aspx pages, when it received the first request for them after the application started.

Starting with 11.8, every on-premises release is pre-compiled. The pages are compiled when Delinea builds the release, so IIS no longer compiles anything at run time. This applies to upgrades and to fresh installations of 11.8 or later.

Pre-compilation has three practical consequences:

  • Faster startup. Application startup is noticeably quicker because the time previously spent on dynamic compilation is eliminated.

  • The App_Code folder is no longer used. IIS cannot run a pre-compiled application that contains an App_Code folder, so Secret Server handles that folder for you at startup. See The App_Code Folder.

  • Edited .aspx files are no longer honored. Because the pages are already compiled, any manual change you made to an .aspx file in the application folder has no effect after the upgrade. See Manually Modified .aspx Files.

Code Integrity and Catalog Signing

Because a pre-compiled release no longer generates code at run time, the set of application files on disk is fixed from the moment the release is deployed. That makes the installed files suitable for catalog signing, which is the mechanism Windows code-integrity controls such as Windows Defender Application Control and AppLocker use to verify that files on disk have not been altered. A dynamically compiled application cannot be covered this way, because IIS creates new assemblies after deployment.

Catalog signing of the installed application files is separate from the integrity check that protects the upgrade package while it is delivered to you. For the package check, which validates the hashes.crt security catalog and the ss_update.zip file before an upgrade is applied, see Ensuring Upgrade Security.

The App_Code Folder

Versions earlier than 11.8 shipped with an App_Code folder inside the Secret Server application folder, usually C:\inetpub\wwwroot\SecretServer. IIS compiled the contents of that folder automatically. A pre-compiled application cannot start while that folder is present.

When a pre-compiled release starts for the first time, Secret Server renames the App_Code folder so that IIS ignores it. No action is required from you as long as the account running the application pool is allowed to rename folders in the application folder.

If the Web Page Does Not Load After the Upgrade

If the application pool account does not have permission to rename the folder, Secret Server cannot start and the Web page does not load. The browser typically keeps loading indefinitely. Fix this in either of the following ways, then run iisreset on the node:

  • Rename the folder yourself. On the upgraded server node, open the application folder, find the App_Code folder, and rename it, for example to App_Code_Bak.

  • Grant the application pool account Modify permission on the application folder, so that Secret Server can rename the folder itself the next time it starts. See Running the IIS Application Pool As a Service Account.

Repeat on every server node in a clustered environment.

A renamed copy of the folder left over from an earlier upgrade, such as App_Code_Bak, does not interfere with startup. Only a folder named exactly App_Code does.

Manually Modified .aspx Files

If you edited any .aspx file in the application folder to change how Secret Server looks or behaves, those edits stop working when you upgrade to 11.8 or later, because the compiled page no longer reads the .aspx file. There is no way to re-enable them. Before you upgrade, confirm that you do not depend on any such modification.

Before You Upgrade

  • Confirm that the account running the Secret Server application pool has Modify permission on the application folder on every server node.

  • Check whether anyone has modified .aspx files in the application folder, and plan for those changes to stop working.

  • Back up the application folder before upgrading. See Secret Server On-Prem Upgrade Checklist.

Related Topics