Troubleshooting Issues in Sitecore (IIS) - Razl, SPE Content Migrator

This blog post is simply about some basic troublshooting steps whenever we have integration with 3rd party modules which relies on custom APIs in Sitecore. 

First one in this discussion is Sitecore Razl. Sitecore Razl is a database comparison tool for the Sitecore CMS. It allows a developer to compare two different Sitecore databases and see the differences in each. A developer can then migrate changes from one database to the other. (ref)

Once the connection specific package is installed in a server, when trying to load the connection in the Razl tool, it would say it cannot connect. Same accessGuid is present in configuration and Razl Connection window. 

Second one is related to SPE Content Migrator. Script used to migrate content between Sitecore instances using Sitecore PowerShell Extensions.(ref).

In this case, even after enabling SPE Remoting and allowed role "sitecore\PowerShell Extensions Remoting" for authorization, migrator script always responded with the below error. 

Test Script:

Error:

Troubleshooting Steps: 

Both these errors have similar troubleshooting steps. Both these tools interact with Sitecore CM using custom APIs or Handlers. With the current client, there are many IIS rewrite rules added to support their business requirement or for security reasons in Content Management Server. 

• LowerCaseRule
• RemoveTrailingSlashRule
• Root Hit Force HTTPS Redirection
• Sitecore Login or Admin Force HTTPS Redirection
• Forbidden
• Redirect Error Page for a Business Requirement

First step - We enabled IIS logs for the CM site and also enabled all the available fields to log. Refer here to find the list of available fields in IIS Logs - https://www.finalanalytics.com/help/httplogbrowser/field-list.html. We tried multiple times from the tool (Razl or SPE Content Migrator) and we found the POST requests and it was redirected with 301 and a GET request was sent finally to Sitecore. Sitecore was not able to respond to the GET request as it was expecting a POST request from these tools. We tried to check the IIS rewrites one by one and found one of these rewrite rules are redirecting these requests. 

Razl: It was LowerCaseRule which redirected the Razl request. We added the negate rule to avoid Razl URLs. 

SPE Content Migrator: It was RemoveTrailingSlashRule rule which redirected all SPE migrator requests. We added the exception to prevent it. 

It is best to start with IIS first to understand the source of the problem. Happy Troubleshooting!.

IIS 301 Redirects with Cache Control

With IIS rewrite module, we can create 301 redirects. Once the 301 redirect response is sent to the browser, client browser caches it indefinitely until browser cache is cleared or hard reload happens. This can tweaked by setting proper cache control header. 

Sometimes 301 redirects need to be changed (yes, it happens!). Even though we change it in rewrite rule in web.config, browser does not send the request to the server to know whether there is an update in the destination url. We can avoid it by setting cache-control response header. 

The problem with the IIS Rewrite Module is that once the "redirect" rule is hit, it does not process further rule. StopProcessing flag is respected only for Rewrites and not for Redirects. If it is respected, we can add outbound rules to modify the response header whenever the response status code is 301. 

A probable solution is to create an intermediate page "redirect.aspx". This page will redirect the request to target URL with proper cache control. Please make sure that instead of Action type as Redirect, we need to change it to Rewrite in IIS Rewrite rule. 

In the aspx page, we can set cache control so that the 301 redirects can be cached in proxy (CDN) for a specific days or hours. In the IIS rewrite rule, we need to change from Redirect to Rewrite. 

Below aspx page will not allow any layer to cache the 301 redirects. Please note that this may increase the traffic to our web server since all the 301 redirects will hit the web server to get the target URL all the time. It is important to set the proper cache control to avoid heavy load on the web server. Based on current infrastructure, we can set cache control header to cache it in CDN or the web server itself.