Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Solarwinds AppInsight for IIS – doing a manual install – and hopefully fixing invalid signature (error code: 16007)

AppInsight from Solarwinds is pretty cool. At least the one for Exchange is. Trying out the one for IIS now. Got it configured on a few of our servers easily but it failed on one. Got the following error –



Manual install it is then. (Or maybe not! Read on and you’ll see a hopeful fix that worked for me).

First step in that is to install PowerShell (easy) and the IIS PowerShell snap-in. The latter can be downloaded from here. This downloads the Web Platform Installer (a.k.a. “webpi” for short) and that connects to the Internet to download the goods. In theory it should be easy, in practice the server doesn’t have connectivity to the Internet except via a proxy so I have to feed it that information first. Go to C:\Program Files\Microsoft\Web Platform Installer for that, find a file called WebPlatformInstaller.exe.config, open it in Notepad or similar, and add the following lines to it –

This should be within the <configuration> -- </configuration> block. Didn’t help though, same error.


Time to look at the logs. Go to %localappdata%\Microsoft\Web Platform Installer\logs\webpi for those.

From the logs it looked like the connection was going through –

But the problem was this –

If I go to the link – – via IE on that server I get the following –



However, when I visit the same link on a different server there’s no error.

Interesting. I viewed the untrusted certificate from IE on the problem server and compared it with the certificate from the non-problem server.

Certificate on the problem server

Certificate on the problem server

Certificate on a non-problem server

Certificate on a non-problem server

Comparing the two I can see that the non-problem server has a VeriSign certificate in the root of the path, because of which there’s a chain of trust.

verisign - g5

If I open Certificate Manager on both servers (open mmc > Add/ Remove Snap-Ins > Certificates > Add > Computer account) and navigate to the “Trusted Root Certification Authorities” store) on both servers I can see that the problem server doesn’t have the VeriSign certificate in its store while the other server has.

cert manager - g5

So here’s what I did. :) I exported the certificate from the server that had it and imported it into the “Trusted Root Certification Authorities” store of the problem server. Then I closed and opened IE and went to the link again, and bingo! the website opens without any issues. Then I tried the Web Platform Installer again and this time it loads. Bam!

The problem though is that it can’t find the IIS PowerShell snap-in. Grr!

no snap-in

no snap-in 2

That sucks!

However, at this point I had an idea. The SolarWinds error message was about an invalid signature, and what do we know of that can cause an invalid signature? Certificate issues! So now that I have installed the required CA certificate for the Web Platform Installer, maybe it sorts out SolarWinds too? So I went back and clicked “Configure Server” again and bingo! it worked this time. :)

Hope this helps someone.

Redirect HTTP to HTTPS with IIS

While deploying OWA in Exchange 2010, by default the OWA website is set to be accessible only via HTTPS. Connecting to the website via HTTP results in an error page, and while this is fine and dandy it would be convenient if users were silently redirected to the HTTP page.

Visiting the main URL itself of the domain where OWA is hosted (as in visiting http://mail.contoso.local/ instead of the OWA URL http://mail.contoso.local/owa as I was talking about above) too results in an error page. Again, would be convenient if users were redirected to the HTTPS OWA page silently.

There’s two ways of doing this. First approach is to do a plain redirect. Open up IIS Manager, go to the default website, double click “HTTP Redirect”, and fill up similar to the screenshot below:


Here you are telling IIS you would like to redirect incoming requests to the default website to be redirected to the OWA link you specify. Also, only requests to the default website link are to be redirected, not anything to a subdirectory of that website (as in redirect http://mail.contoso.local/ but not http://mail.contoso.local/blah). This is very important (for instance: failing to do so will break EMC and EMS as Exchange uses Remote PowerShell for its management tasks, and these connect to a PowerShell Virtual Directory in IIS).

image.pngYou can set up a similar redirect in the OWA Virtual Directory too so anyone accessing http://mail.contoso.local/owa is redirected to the HTTPS version.

Apart from this, go to the SSL Settings in both places (default website and OWA Virtual Directory) and un-tick the checkbox that says Require SSL. This is important – else the server will not apply the redirect as we are telling it that any access to this website requires SSL.

While this setup is fine, I don’t find it elegant as we are redirecting all links to a specific host. It’s possible the web server is accessible over two addresses – http://mail.contoso.local and http://mail.fabrikam.local – but now we are redirecting even the fabrikam.local addresses to https://mail.contoso.local. Not good.

Hence the second approach. Do URL rewriting. This requires the URL Rewrite module which can be downloaded from A handy reference guide can be found at the same site. Once you install the module and close and open the IIS Manager, you will see an icon for “URL Rewrite”. This gives a GUI to manage rewrite rules.

To create a new rule using the GUI click on “Add Rule(s)” at the top right corner in the actions pane. Select “Blank Rule”, give it a name (I called mine “Redirect HTTP to HTTPS for default site”), and fill thus:

image.pngThe Match URL section looks at the URL and performs matches on it. You can specify matches in terms of regular expressions, wildcards, or an exact string to match. The pattern is matched at the portion after the ‘/’ following the domain name. For instance if a URL is of the form http://mail.contoso.local/owa/blah/blah, then the pattern is matched with ‘owa/blah/blah’. You can setup a rule to perform a certain action if the pattern matches or does not.

In my case, I wanted to target URLs of the form http://mail.contoso.local/ with nothing following the ‘/’ after the domain name. So I set the pattern to be matched as ‘^$’ which in regular expression language stands for an empty pattern (the ‘^’ denotes the start of the pattern and the ‘$’ denotes the end; so essentially we are saying match for a pattern with nothing in it).

Note that since URL matching only look at the bits after the ‘/’ in the URL, we can’t use it to distinguish between HTTP and HTTPS links. This is important because if I don’t do that in this particular case, I could have a link that redirects http://mail.contoso.local/ to https://mail.contoso.local/ and since the redirected to link too matches the pattern I specify, it will be redirected again (and again and again …) to http://mail.contoso.local/ in a perpetual loop. So we want the above pattern to be matched, but only if certain conditions are met. This is what the next section of the UI lets you specify.

From the configuration reference we can note that the HTTPS server variable lets you determine if the link was HTTP or HTTPS. If it was HTTP, then this variable has a value OFF. We can use this to not match the pattern above for HTTPS links.

Click “Add” in the Conditions section, fill it up thus, and click OK:

image.png image.png

So now the rule will match all non-HTTP links with an empty pattern. Good!

Next step is to tell IIS what to do in case of such matching URLs. This is specified at the Action section:


We specify the action to be taken as Redirect. And specify the Redirect URL as https://{HTTP_HOST}/owa. The HTTP_HOST is a server variable that contains the domain name in the URL, so we can use that to redirect the URL to whatever domain it was meant for, but with HTTPS prefixed. (This is why we are doing the rewriting in the first place instead of doing a blanket redirect as in the first approach). In this case, I want the URL to redirect to OWA, so I set the redirect URL as https://{HTTP_HOST}/owa.

Next I create a similar rule for OWA so IIS redirects http://mail.contoso.local/owa to https://mail.contoso.local/owa. The Conditions section for this rule is same as the above so I am skipping that in the screenshot:


I set the match URL to be ^owa/?$ which stands for URLs starting with the word ‘owa’ followed by an optional slash (that’s what the /? stands for) and ending with that. Such URLs – non HTTPS, don’t forget to add the Condition section for that – are redirected to https://{HTTP_HOST}/owa.

It is also possible to create this second rule under the URL Rewrite section in the OWA Virtual Directory. In which case you’d skip the “owa” in the rule as the matching happens only after the “owa” bit of the URL (as we created it within the OWA Virtual Directory).

Also: in this case I was only concerned with redirecting OWA URLs. But if I wanted to do a similar thing for say the ECP URL too, I would tweak the rule above instead of making a fresh one. Set the Match URL to be ^(owa|ecp)/?$ and the Redirect URL to be https://{HTTP_HOST}/{R:0}. Putting the two options – “owa” and “ecp” – in brackets with a pipe between them means we want to match on either of these words. And {R:0} in the Redirect URL is replaced with whichever one matches.

Here are the two rules in the summary window:


For those who prefer non-GUI approaches, you can edit the C:inetpubwwwrootweb.config file directly and manage rules. The GUI is only a fancy way of making changes to this file. For the two rules we made above, here’s what the web.config file contains:

Similar to plain HTTP redirecting, redirecting HTTP to HTTPS via URL Rewrite rules too require the Require SSL checkbox to be un-ticked in both the default website and the OWA Virtual Directory.

That’s all for now. I am no IIS expert so there could be errors/ inefficiencies in what I posted above. Feel free to correct me in the comments!