In this post I would like to share my experience of setting up a shared Solr 7.2.1 environment on a Windows Server 2016 using IIS Reverse Proxy. This setup is perfect if you want to have, for example, a shared Solr instance next to your Sitecore test environment. Other clients / developers can also utilize the same Solr instance, because it has an actual domain mapping.
In the last few months I was involved in NodeJS web app development using nginx web server as a reverse proxy, which is a standard way of developing production-ready web apps. I thought there should be simillar technique to do the same with IIS – there is and it’s really simple.
I will not go through the steps of setting up Solr 7.2.1 on a Windows Server. One important note though is that localhost shoult NOT have SSL enabled. Mine can be accessed at http://localhost:8721/solr. You can find on how to install Solr 7.2.1 in this post by Robert Hock: Installing SOLR 7.2.1 (on prem) for Sitecore 9.1 – just skip the SSL part.
Now create an IIS site, that will later point to your Solr server. For “Physical path” choose whatever you like that makes sense. It will only contain a web.config file. You can also set “.NET CLR Version” to “No managed code” in the App Pool’s site Advanced Settings.
Select the site and go to URL Rewrite > Add Rule(s)… > Reverse Proxy. At this point it will probably ask you to install ARR (Application Request Routing). Just go through install steps and switch back to Add Reverse Proxy Rule window when done. You can read more about URL Rewrite as a Reverse Proxy Setup IIS with URL Rewrite as a reverse proxy for real world apps.
I have added a solr721.shared binding to my IIS Solr Site and my Reverse Proxy rule looks like this:
After adding this rule I can now browse to http://solr721.shared/ as shown below (you might also need to add your custom domain to hosts file).
Next we need to add SSL to it, since it’s the best practice by Sitecore and is by default. At this point we could easily generate an auto-renewable certificate using win-acme if we had the domain publicly available. However let’s assume, that this Solr instance is in a private network. Therefore we will generate and install a self-signed certificate with 10 years expiration.
Here is a small PowerShell script, that generates a certificate and adds it to Personal Store. You should, of course, modify it to suit your needs.
All available New-SelfSignedCertificate parameters can be found here.
$dns_name = "solr721.shared" $friendly_name = "Pintle " + $dns_name $password = "secret" $num_years = 10 $out_path = "F:\Certificates\solr721.shared.pfx" $date_now = Get-Date $extended_date = $date_now.AddYears($num_years) $cert = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname $dns_name -FriendlyName $friendly_name -notafter $extended_date -KeyLength 4096 $pwd = ConvertTo-SecureString -String $password -Force -AsPlainText $path = "cert:\localMachine\my\" + $cert.thumbprint Export-PfxCertificate -cert $path -FilePath $out_path -Password $pwd
After executing, I can see the certificate successfully generated and installed.
Now in order for this certificate to be valid we also need to install it in the Trusted Root Certification Authorities Store. To do so, just double-click on the generated .pfx file and go through the steps. Couple of things to note: make sure to choose Store Location “Local Machine” and instead of automatically selecting certificate store, choose “Trusted Root Certification Authorities”.
If all went well you should now be able to add HTTPS binding on your custom Solr domain in IIS. I have done so and can now see my Solr with https enabled with my custom domain as seen below:
Now the last part is to make this work in a shared environment. Whether it’s another developer or my client’s Sitecore test CD instance, the only thing I need to do is to provide the .pfx file and install it in the remote machine’s both Personal and trusted Root certificate stores.
After doing so, I can now access Solr through HTTPS from my dev machine (also remember to add it to hosts file):
I hope someone found it useful 🙂