What

A PowerShell Script that configures your Windows IIS (Rock) webserver to "preload" Rock by automatically starting the application after a server restart, significantly shortening the time it takes to get a "first page" from Rock.


Why

After a server restart or OS reboot, by default IIS will just sit there waiting for some web request to come along and then IIS actually starts Rock's application pool, intitializes stuff, etc... which can take a lot of time... and while there are bits and pieces of knowledge floating around on various blogs as to how to fix this, almost none of them get all of the details correct, resulting in a system that doesn't start any faster than it did before, and you're left scratching your head.

While searching around yet again for the correct steps to take to make IIS "warm up" as expected, my Google-fu led me to this article, which is a PowerShell script that automagically configures everything for you. No more editing obscure config files, IIS settings, and installing IIS optional features... this script does it all for you.


How

There are three things that must be in place in order for preloading to work (none of which are enabled by default):

  1. The Application Initialization IIS module must be installed
  2. The Application Pool must be set to Always Running
  3. The start mode of the application must be set to preloadEnabled=True

While it's certainly possible to configure all of these manually (after googling around and finding partial/incomplete information), this PS script does all the heavy lifting. All you have to do is run it on your Rock webserver.

NOTE: This script installs an optional IIS feature and makes changes to the IIS configuration. Please do not proceed without a good backup of your Rock webserver! While it has worked fine on all my systems, I cannot take responsibility for anything unexpected it might do on YOUR system, especially as I did not write this script.
NOTE: This recipe assumes you're running a "real" IIS server instance on a Windows host/VM. If you happen to be running Rock on Azure WebApp (Azure VM is fine), this won't work and isn't necessary in a Azure WebApp instance, anyway.
  1. Download the IISPreloadSetup.ps1 script from this page (scroll down to the DOWNLOAD FILE button near the end) and copy it to the desktop of your Rock webserver. (I'll assume you're logging in as Administrator.)

  2. Edit the script and verify/change the $siteName to match your Rock site name (as it's defined in IIS)
  3. Here you can see mine is named RockRMS but yours may be Default Web Site or something else.
    #Set the site name
    $siteName = "RockRMS"
  4. Run the PowerShell Prompt, which is often an icon pinned to the taskbar (looks like >_) or by clicking the Win key and entering Powershell to get a hit to that app.

  5. Once you have a PS command prompt open, you're likely at PS: C:\Users\Administrator. If so, just type cd Desktop and Enter to get to the desktop directory.

  6. WARNING: This will restart your Rock application, so only perform Step 5 when you're prepared for Rock to restart.
  7. Now type ./IISPreloadSetup.ps1 and then Enter.
  8. If you get an error about the PS1 script not being "digitally signed", enter Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass into the Powershell Window, hit enter, then run the IISPreloadSetup.ps1 script again. That command will set the Execution Policy for the current PowerShell session so that the script can run.

If all goes well you should see the script perform the three necessary steps, like this:
IISPreloadSetup.png
Note that if any step is already installed/configured, the script is smart enough to let you know that and skip it, as you can see on the Application Initialization module step in my screen shot.


What Now?

Now you should see that after a server restart, rather than wait around for a new request to come by before jumping into action, Rock automatically starts initializing its app pool and getting ready to take requests, which will improve that "first page from Rock after reboot" experience we all know so well. This can be observed by running Task Manager and seeing IIS use lots of CPU immediately after a server reboot, because it's gone ahead and started itself up without waiting for an actual request.