Instrumenting a Web Site or Web Application on IIS using URL Rewrite

IIS URL Rewrite 2.0 enables Web administrators to create powerful rules to implement URLs that are easier for users to remember and easier for search engines to find. By using rule templates, rewrite maps, .NET providers, and other functionality integrated into IIS Manager, Web administrators can easily set up rules to define URL rewriting behavior based on HTTP headers, HTTP response or request headers, IIS server variables, and even complex programmatic rules. In addition, Web administrators can perform redirects, send custom responses, or stop HTTP requests based on the logic expressed in the rewrite rules.

To enable the auto-injection of the JavaScript code snippet into IIS 7-based web sites/web applications, you need to use the URL Rewrite module.

Before attempting to use this module, ensure that the following pre-requisites are fulfilled:

  • Make sure that you have access to the IIS Manager console.
  • Download and install the URL Rewrite module on the IIS 7 server. To download this module, go to the URL: http://www.iis.net/downloads/microsoft/url-rewrite
  • Ensure that a web site/ web application on IIS 7 has already been added as a Real User Monitor using the eG administrative interface. The JavaScript code snippet that eG provides when adding the component should be copied to a text file.
  • Check whether compression (static and/or dynamic) is enabled for the web site/web application that is to be RUM-enabled. To perform this check, navigate to the ‘Compression’ extension menu on the IIS manager. For instance, if you want to know whether/not compression is enabled for the Default Web Site on IIS 7, click on the Default Web Site node in the tree structure in the left panel of the IIS manager (see Figure 1), and then select the Compression option from the right panel.

    Figure 1 : Accessing the Compression menu

  • Then, when Figure 2 appears, check whether the Enable static content compression check box and/or the Enable dynamic content compression check box is selected; if so, it means that Compression has been enabled.

    Figure 2 : Checking whether static compression is enabled

    If either or both the check boxes in the Compression section is selected in Figure 2, then additionally, perform the following steps:

    • Open the command prompt and execute the following command:

      reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0

      If the target web application is a 32-bit application that is running on a 64-bit machine, then execute the following command instead:

      reg add HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Microsoft\Inetstp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0

      Click here to know how to verify whether a target web application is a 32-bit application or a 64-bit application.

    • Next, make sure that the dynamicCompressionBeforeCache property is set to false for the /system.webServer/urlCompression configuration element. For this, add the following entry in the web.config file as depicted by .

      <urlCompression doStaticCompression=”false” doDynamicCompression=”true” dynamicCompressionBeforeCache=”false” />

      Figure 3 : Setting the dynamicCompressionBeforeCache property to false

      Alternatively, you can run the following command from the command prompt:

      appcmd.exe set config "WEBSITENAME" -section:system.webServer/urlCompression /dynamicCompressionBeforeCache:"False"

    • Re-order the IIS modules to have URL Rewrite module (RewriteModule) run before Dynamic Compression module (DynamicCompressionModule). In other words, in the modules ordered view of the IIS Manager console, the Dynamic Compression module should be above the URL Rewrite module.
    • Restart IIS.

Once all the afresaid pre-requisites are fulfilled, proceed to use the URL Rewrite module. For that:

  1. Create two rewrite rules on IIS 7 – a eG RUM Head Rule and a eG RUM Body Rule. Let’s begin by creating the eG RUM Head Rule.

  2. For this, first select the web site (say, Default Web Site) that is to be RUM-enabled from the tree structure in the left panel of the IIS manager console. Then, from the right panel, select the URL Rewrite option (see Figure 4).

    Figure 4 : Accessing the URL Rewrite option

  3. When Figure 5 appears, select the Add Rule(s) option.

    Figure 5 : Choosing to add a new rule

  4. In Figure 6 that then appears, click the Blank Rule option.

    Figure 6 : Selecting the Blank Rule option

  5. Then, click the OK button in Figure 6.
  6. In the dialog box that appears next, enter eG RUM Head Rule as the name of the new rule. From the Precondition list, pick the <Create New Precondition…> option.
  7. The Add Precondition dialog box then appears (see Figure 7). Here, enter isHtmlContent as the Name of the new precondition. Then, choose Regular Expressions from the Using drop-down, and Match All from the Logical grouping drop-down. Finally, click the Add button.

    Figure 7 : Defining the properties of the new precondition

  8. When Figure 8 appears, type {RESPONSE_CONTENT_TYPE} as the Condition input. Then, select Matches the Pattern from the Check if input string drop-down and type ^text/html as the Pattern. Finally, click the OK button in Figure 8.

    Figure 8 : Providing the condition input, input string, and pattern

  9. You will now return to Figure 9. Now, in the Pattern text box therein, type </head[^>]*>, as indicated by Figure 9.

    Figure 9 : Entering the pattern for the rule

  10. Then, scroll down Figure 10 to view the Action Properties section. Here, enter that portion of the eG-generated JavaScript code snippet that needs to be injected into the head (and not the body) of the web pages to be monitored. Typically, the line of code that captures the date/time at which the JavaScript code snippet began execution should be injected into the head. For instance, consider the sample JavaScript code snippet below:

    <!-- RUM Header -->

    <script charset='UTF-8' type='text/javascript'>

    window['egrum-start_time'] = new Date().getTime();

    window['Site_Name'] = '57bf9bbe-5712-40e9-929b-f75c5ab300e9-1606389009637';

    window['beacon-url'] = 'http://192.168.8.33:7077';

    if(!window['egrum-config']) window['egrum-config'] = {}; (function (config) {config.capture = { jsError:true, resourceDetails:true, ajax:true, ajaxCorrelation:false, overwriteBtmUName:false, excludeURLPattern:'none', ajaxExcludeURLPattern:'none', includeURLPattern:'*'};})(window['egrum-config']);

    </script>

    <script src='http://192.168.8.33:7077/rumcollector/egrum.js' async> </script>

    <!-- RUM Header -->

     

    Here, the line of code highlighted in Bold is the one that needs to be auto-injected into the head of all web pages of the chosen web site.

    To ensure this, type this entire line of code in the Action Properties section of Figure 10. Make sure that you append the line with the entry {R:0}. So, your complete Action Properties specification will be as follows:

    <script charset='UTF-8' type='text/javascript'> window['egrum-start_time'] = new Date().getTime(); </script>{R:0}

    Figure 10 : Specifying the line of code to be auto-injected in the head

  11. Finally, click the Apply button in Figure 11.

    Figure 11 : Applying the changes

  12. With that the eG RUM Head rule has been defined. Now, let us proceed to define the next rule – the eG RUM Body rule. For that, once again select the web site (say, Default Web Site) that is to be RUM-enabled from the tree structure in the left panel of the IIS manager console. Then, from the right panel, select the URL Rewrite option (see Figure 12).

    Figure 12 : Accessing the URL rewrite option

  13. When Figure 13 appears, select the Add Rule(s) option.

    Figure 13 : Choosing to add a new rule

  14. In Figure 14 that then appears, click the Blank Rule option.

    Figure 14 : Selecting the Blank Rule option

  15. Then, click the OK button in Figure 14.
  16. In Figure 15 that appears next, enter eG RUM Body Rule as the name of the new rule. From the Precondition list, pick the isHtmlContent option. Then, against Pattern specify </body[^>]*>.

    Figure 15 : Adding the eG RUM Body Rule

  17. Then, scroll down Figure 15 to view the Action Properties section. Here, enter that portion of the eG-generated JavaScript code snippet that needs to be injected into the body (and not the head) of the web pages to be monitored. Typically, the line of code that connects to the eG RUM Collector and runs the egrum.js script should be injected into the body. For instance, consider the sample JavaScript code snippet below:

    <!-- RUM Header -->

    <script charset='UTF-8' type='text/javascript'>

    window['egrum-start_time'] = new Date().getTime();

    window['Site_Name'] = '57bf9bbe-5712-40e9-929b-f75c5ab300e9-1606389009637';

    window['beacon-url'] = 'http://192.168.8.33:7077';

    if(!window['egrum-config']) window['egrum-config'] = {}; (function (config) {config.capture = { jsError:true, resourceDetails:true, ajax:true, ajaxCorrelation:false, overwriteBtmUName:false, excludeURLPattern:'none', ajaxExcludeURLPattern:'none', includeURLPattern:'*'};})(window['egrum-config']);

    </script>

    <script src='http://192.168.8.33:7077/rumcollector/egrum.js' async> </script>

    <!-- RUM Header -->

     

    Here, the line of code highlighted in Bold is the one that needs to be auto-injected into the body of all web pages of the chosen web site.

    To ensure this, type this entire line of code in the Action Properties section of Figure 16. When doing so, make sure that the following are in place:

    • The curly braces in the code snippet should be encoded. For this, you need to replace the 'opening curly braces' in the code snippet with {UrlDecode:%7B}, and the 'closing curly braces' with {UrlDecode:%7D}
    • Append {R:0}.to the entire code snippet.

    So, your complete Action Properties specification will be as follows:

    <script charset='UTF-8' type='text/javascript'>

    window['egrum-start_time'] = new Date().getTime();

    window['Site_Name'] = '57bf9bbe-5712-40e9-929b-f75c5ab300e9-1606389009637';

    window['beacon-url'] = 'http://192.168.8.33:7077';

    if(!window['egrum-config']) window['egrum-config'] = ={UrlDecode:%7B}{UrlDecode:%7D}; (function (config){UrlDecode:%7B}config.capture = {UrlDecode:%7B}jsError:true, resourceDetails:true, ajax:true, ajaxCorrelation:false, overwriteBtmUName:false, excludeURLPattern:'none', ajaxExcludeURLPattern:'none', includeURLPattern:'*'{UrlDecode:%7D};{UrlDecode:%7D})(window['egrum-config']);

    </script>

    <script src='http://192.168.8.33:7077/rumcollector/egrum.js'async> </script>{R:0}

    Figure 16 : Specifying the line of code to be auto-injected in the body

  18. Finally, click the Apply button in Figure 17.

    Figure 17 : Applying the changes

  19. Once both the rules have been created, click Browse. After the page loads successfully, view the source code of that web page to ensure that the JavaScript code snippet has been injected as expected.

    Alternatively, you can also auto-inject the JavaScript code snippet into only those web pages that match specific URL patterns. To achieve this, in both the rules, add conditions to match the URL patterns, as depicted by Figure 18.

  20. Figure 18 : Auto-injecting the code snippet in web pages that match specific URL patterns

 

Verifying Whether a Web Application is a 32-bit Application or 64-bit Application

To achieve this, do the following:

  1. Open the IIS Manager and expand the node representing the target IIS web server in the tree-structure in the left panel of the manager.
  2. Click on the Application Pools sub-node in the tree-structure. The right panel will then change to display all the application pools. From this list, pick the application pool that contains the web application being monitored, and then select Advanced Settings from the list of options to its right.
  3. In the General section of the Advanced Settings window that pops up, check the status of the Enable 32-Bit Applications flag. If this flag is True, it implies that the target web application is a 32-bit application. If this flag is False, then it means that the target web application is a 64-bit application. Figure 19 below clearly depicts steps 1-3 above.

     

    Figure 19 : Verifying whether a web application is a 32-bit or a 64-bit application