SSL Certificate Error on .NET

If you see the following message when trying to call a secure web service from .NET applications, it normally is associated with the SSL certificate being expired or not valid for the URL you ‘re calling:

[System.Net.WebException]: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid according to the validation procedure.

Make sure you really investigate if the certificate is valid.

In a recent case we had to deal with the reason the certificate was throwing this error was the root certificate authority has been changed when the third party service renewed their SSL certificate. The new certificate authority Go Daddy was not recognized by the web server (old Windows 2003 server) and then the server considered the certificate invalid.

It took us awhile to figure it out, but after registering the certificate authority on the server it worked fine.

 

See you,

Amadeu.

Advertisements

How to Recycle an IIS Application Pool Using a Command Line

Use the following command line in order to recycle an application pool on IIS 7:

[system drive]:\windows\system32\inetsrv\appcmd recycle apppools /apppool.name:”Your Application Pool Name”

 

Works like a charm.

 

See you,

Amadeu.

URL Rewriting – Part 3: Integrating with SharePoint 2010

In this series of posts I’m going through the URL Rewriting process using the IIS URL Rewrite feature.

Check the previous posts out:
URL Rewriting – Part 1: The Basics
URL Rewriting – Part 2: Outbound Rule

On the previous posts we installed the feature and configured inbound and outbound rules using the IIS Rewriter. In this article we go further and show how to integrate the IIS URL Rewriter with a SharePoint site.

SharePoint 2010 Support for IIS URL Rewriter

If you search for IIS URL Rewriter on SharePoint you might see some articles about it not being supported on SharePoint 2010. It is kind of true but not completely. It will depend on the type of authentication your site is using. If you want to build a public internet site (anonymous authentication), you can use IIS URL Rewriter on your site with a few tweaks. If you’re building an intranet site (Windows or Claims authentication) you’re not going to be able to use IIS URL Rewriter.

When I first started trying to integrate IIS URL Rewriter and SharePoint 2010 I was building a public internet on my DEV environment and it was configured for both Windows and anonymous authentication. I noticed the anonymous part (mainly content and web part pages) worked fine but the administrative part (list management, user management and settings pages) didn’t. It would always ask me for authentication and it never had a consistent behavior. Every time I tried one of the administrative pages asked for authentication.

Installation

You should install the IIS Rewrite feature on all SharePoint WFE servers. The installation on SharePoint uses the very same process described on the first part of the series.

Tweaks for SharePoint 2010

Disable the LogRewrittenUrlEnabled property

On the WFE servers execute the following command:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0


Edit the web.config file

Add the following node under configuration/system.webServer in order to change compression settings:

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

Restart IIS

Execute an IISRESET command on all WFE servers.

Testing Inbound and Outbound Rules

Edit the web.config file for your site on all WFE servers.

Add a new inbound and outbound rules to test on your site. Here is a simple example you can add to your web.config under the configuration/system.webServer node:

<rewrite>
  <rules>
    <rule name="Home Page Rewrite" stopProcessing="true">
      <match url="^(/$|$)" />
      <action type="Rewrite" url="/pages/default.aspx" />
    </rule>
  </rules>
  <outboundRules>
    <rule name="Home Page Outbound Rewrite" stopProcessing="true">
      <match filterByTags="A, Link" pattern="(/?)pages/default\.aspx$" />
      <conditions>
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
      </conditions>
      <action type="Rewrite" value="{R:1}" />
    </rule>
  </outboundRules>
</rewrite>

These rules will remove the home page redirect from the browser’s address bar and rebuild all the links to the home page to point to /.

References

http://codeblog.shawson.co.uk/iis7-urlrewrite-outbound-links-with-compression-enabled/

http://blogs.msdn.com/b/danielvl/archive/2010/01/07/registry-values-for-iis-url-rewrite.aspx

On the next articles of this series we will talk about custom IIS Rewriter providers and how to implement them.

See you,

Amadeu.

Turn Static and Dynamic Compression Off on IIS 6.0

We found an issue when downloading dynamic PDFs files on IIS 6.0. Since it uses a regular PDF as a template and binds the data dynamically on the client, IIS compression was modifying the file and it cause the bind to fail. In this case you need to disable IIS’ file compression (both static and dynamic) and the only way to do it on IIS 6.0 is through the IIS Metabase.
You can use metabase editor or edit it manually by the metabase’s XML file. The steps to edit the metabase file manually are the following:

 

Enable IIS Metabase direct edition

Go to IIS Manager.
Right click on the computer name an select Properties.
Check the Enable Direct Metabase Edit option and click OK.

 

Backup the metabase file

The metabase file is located at C:\windows\system32\inetsrv\metabase.xml

 

Edit the metabase file
Add the following attributes to the virtual directory (IIsWebVirtualDir node) or web site (IIsWebServer node):

DoStaticCompression=”FALSE”

DoDynamicCompression=”FALSE”

 

Save the metabase file

 

Reset IIS

Run the iisreset.exe command

 

Disable the IIS Metabase direct edition

Go to IIS Manager.
Right click on the computer name an select Properties.
Uncheck the Enable Direct Metabase Edit option and click OK.

 

See you,

Amadeu.

URL Rewriting – Part 2: Outbound Rule

In this series of posts I’m going through the URL Rewriting process using the IIS URL Rewrite feature.

Check the other posts:
URL Rewriting – Part 1: The Basics

 

On the previous post we installed the feature and configured an inbound rule, which basically is a friendly URL when requests come from the browser to IIS. In this post we are going to talk about other rule templates available on the IIS URL Rewrite. One of the rules we are going to see is the outbound rule which is when we process elements on the returning HTML to be set to the browser and transform URLs into friendly URLs.

 

Outbound Rules

Outbound rules control the way links should be rendered when IIS sends HTML back to the browsers after processing the requested page. It can be used to enforce SEO links on your site (friendly URLs) and handle business rules.

 

Outbound Blank Rule

Go to IIS Manager. Select your site.

In the URL Rewrite screen, click on “Add Rule(s)…” link on the Actions panel.

 

Select the Outbound Blank rule template.

When creating a rule you need to define:

  • Name: rule name.
  • Pre-Condition: the pre-condition defines if the outbound rule should be applied to the response IIS is sending to the browser. You can use different fields of the response to check on your pre-condition.

The pre-conditions can be reused between different rules.

  • Name: pre-condition name.
  • Using:
    • Regular expression: defines Regex as the parser for the expression defined on the pattern field.
    • Wildcards: defines the wildcards parser as the parser for the expression defined on the pattern field.
    • Logical grouping:
      • Match all: all conditions need to apply for the outbound rule to be applied.
      • Match any: if one condition applies the outbound rule is applied.
    • Conditions:

  • Condition input: HTTP header field to be checked. Examples: it can be the content type ({RESPONSE_CONTENT_TYPE}) or the response status ({RESPONSE_STATUS}).
  • Check if input string:
    • Matches the pattern.
    • Does not match the pattern.
    • Pattern: the pattern to be tested.
    • Ignore case: ignores cases when applying the pattern. It is a good setting to be left checked if you do lots of regular expression.
  • Match
    • Matching scope: defines if the outbound rule should be applied to the response header (server variables) or to the response body (response).
      • Response
      • Server variable
    • Match the content within: tags and attributes to apply the rewrite when processing the return HTML content.
    • Custom tags: specify your custom tags contained on the return HTML.
    • Content:
      • Matches the pattern.
      • Does Not Match the Pattern.
    • Using:
      • Regular Expressions: looks for a regular expression on the selected tags properties.
      • Wildcards: looks for a wildcard expression on the selected tags properties.
      • Exact Match: looks for a exact match on the selected tags properties.
    • Pattern: expression to be matched based on the type of expression selected on the Using field.
    • Ignore Case: ignores cases when applying the pattern. It is a good setting to be left checked if you do lots of regular expression.
  • Conditions
    • They are the same as pre-conditions but cannot be reused between outbound rules.
  • Action
  • Action Type:
    • Rewrite: applies the regular expression to the links found on the return HTML.
    • None: doesn’t execute any operation on the request, just closes it.
  • Stop processing of subsequent rules: stops the processing if the rule is applied.

 

Example of an Outbound Rule

This example rule is intended to modify links pointing to the product.aspx page rewrote to the /products/[product id]/[product name] format.

Here is the rule configuration:

This is the HTML code for my home page with the links to the products:

This is the returned HTML I can see on my browser:

This is how the page looks like. The rewrite feature has no effects on the page itself.

References about this topic can be found at  IIS.net.

 

Complexity of Regex

If you look at the outbound rule example you might find very complex to write Regex. Normally it is not very easy to write it if you’re not used with its syntax and it can lead you to make several mistakes and have problems debugging it.

 

If there is a tip I can give you it is: test it outside IIS and your web pages before trying to debug it in any other tool or way. A good, simple and free (some of the features are free) way to do it is using the Regex Hero web site. It has a nice UI and several features to allow you understand how the matches happen.

 

Conclusions

At this point we know how to create basic inbound and outbound rules in IIS using the IIS Rewrite module. This way we can make entire sites look friendlier for end users changing its URLs to have a more meaningful appearance. On the next articles we will look on how to create custom providers to have rules created outside of IIS and how to integrate the IIS Rewrite to SharePoint 2010.

 

See you,

Amadeu.

Set IIS Redirect Settings using Powershell

Hi.

Today I had to change the redirect setting on IIS for a site and before it has been a kind of painful process.

I don’t like doing things manually because it is very error prone and mainly when I’m dealing with Production servers errors are not very welcome.

This powershell script can change these settings for you:

import-module webAdministration

$siteName = "Your Site"
$redirectPage = "http://yourredirectpage.com/destination.aspx"

# Set the redirect
Set-WebConfiguration system.webServer/httpRedirect "IIS:\sites\$siteName" -Value @{enabled="true";destination="$redirectPage";exactDestination="true";httpResponseStatus="Found"}

In order to disable redirect you can use this script:

<pre>import-module webAdministration

$siteName = "Your Site"
$redirectPage = "http://yourredirectpage.com/destination.aspx"

# Disable the redirect
Set-WebConfiguration system.webServer/httpRedirect "IIS:\sites\$siteName" -Value @{enabled="false"}

You can get the script file here.

See you.

URL Rewriting – Part 1: The Basics

Sometime ago I’ve been asked to deliver a rewrite/redirect engine solution for a project. I started researching, got some tips from my boss and found a few IIS/.NET solutions to do this kind of operation: IIS URL Rewrite ModuleURLRewriter.Net and URLRewriting.Net.

Doing this task I realized there is not much information about URL rewriting in general and even less articles about using it with SharePoint 2010. I then decided to write a series of articles on how to use it, how to configure it on IIS and apply the URL rewrite concept to SharePoint 2010.

 

What is URL Rewriting?

URL Rewriting is the operation of change the external URLs for a web site in order to allow it to have more meaningful and search friendly URLs. It can make your site easier to use and also make it more appropriate (or friendly) for the search robots crawling it.

As more web sites become dynamic and data driven, some of them expose really confusing URLs for either people to memorize and understand or for search robots to analyze. URL Rewriting can help sole this problem allowing site admins to expose URLs that actually represent the page’s content.

 

Here some examples of hard to remember and understand URLs:

https://myspworld.wordpress.com/post.php?post-424&action=view

http://www.google.com/search?sugexp=chrome,mod=9&sourceid=chrome&ie=UTF-8&q=url+rewriting

http://yourwebsite.com/products.aspx?prodid=62

 

Here are some examples of friendly URL:

https://myspworld.wordpress.com/2012/05/28/url-rewriting-part-1-the-basics

http://en.wikipedia.org/wiki/Rewrite_engine

http://yourwebsite.com/books/sharepoint-2010

 

Which URLs would you prefer to have on your web site?

 

URL Rewriting can be done in two ways: rewrite or redirect.

On the rewrite operation we have the actual meaning on the URL rewriting. We are hiding our internal complex URL and exposing a friendly URL. When the friendly URL is requested we translate it to our internal URL (full of parameters and numbers nobody but our site would understand) and execute it. The user’s browser will receive the returned HTML with the friendly URL.

On the redirect operation we expose a friendly URL but instead of executing our internal URL and keeping the friendly URL for the user’s browser, the user is redirected to a different URL, a friendly or not so friendly one, depending on how we configure the redirect.

On the browser’s level the difference between rewrites and redirects is how the URL will be displayed. On the rewrite, the browser will keep the friendly URL all the time. On the redirect, IIS will send a HTTP request for a new URL back to the browser, the browser will request the new URL and the browser’s address bar will be updated with the new URL. The user will definitely notice that the URL has changed.

 

As an example of rewrite we could have:

-The user types an url on the browser: http://yoursite.com/oldurl.

-The redirect engine detects that this URL should be changed to newurl.

-The redirect engine makes an IIS call to new url  http://yoursite.com/newurl and send its HTML output back to the browser.

-On the browser’s address bar the user will still see the old url: http://yoursite.com/oldurl.

 

As an example of redirect we could have:

-The user types an url on the browser: http://yoursite.com/oldurl.

-The redirect engine detects that this URL should be changed to newurl.

-IIS will send a HTTP request asking the user’s browser to go to  http://yoursite.com/newurl.

-The browser will request the new url and update its address bar.

 

 

IIS URL Rewrite 2.0

Analyzing a few solutions for this URL Rewriting, the one I liked better was the IIS URL Rewrite 2.0. In my case it made more sense since the run SharePoint 2010 and IIS 7 and it would be easily integrated with these technologies.

The URL Rewrite is an IIS 7 feature which allows you to process inbound and outbound URLs and redirect or rewrite it according to rules. The rules can be hard-coded, use wildcards or can even be regular expressions (I really enjoy using REGEX even though it is not that easy to create or maintain the expressions).

 

For more references on the IIS URL Rewrite check these links out:

URL Rewrite 2.0: http://www.iis.net/download/urlrewrite

URL Rewrite Extensibility Samples: http://download.microsoft.com/download/3/9/E/39E30671-7AD2-4902-B56B-C300D862595E/RewriteExtensibility.msi

Using Custom Rewrite Providers: http://learn.iis.net/page.aspx/803/using-custom-rewrite-providers-with-url-rewrite-module/

Developing a Custom Rewrite Provider: http://learn.iis.net/page.aspx/804/developing-a-custom-rewrite-provider-for-url-rewrite-module/


Installing

The installation is very simple. You just need to download the installer and run it.

Get the 32-bit installer or the 64-bit installer.

After it is installed, open IIS Manager and check a new icon on the web site’s features.

 

Using the URL Rewrite

When you click on the URL Rewrite icon on the web site’s features, it will take you to the URL Rewrite rules screen. It should be an empty screen since we don’t have any rule configured. Rules are the definitions telling IIS how to handle the URLs. Basically, we can have inbound rules and outbound rules. Inbound rules are applied when the requests come to IIS and outbound rules are applied before IIS sends HTML back to users’ browsers.

It is now time to add rules and start with URL rewriting.

 

Inbound Blank Rules

On the URL Rewrite screen, click on “Add Rule(s)…” link on the Actions panel.

Select the Inbound Blank rule template.

When creating a rule you need to define:

  • Name: rule name.
  • Match URL: defines the rules for matching URLs and applies your rule.
    • Requested URL:
      • Matches the pattern: your rule is applied if the requested URL matches the pattern.
      • Doesn’t match the pattern: your rule is applied if the requested URL doesn’t match the pattern.
    • Using:
      • Regular expressions: defines Regex as the parser for the expression defined on the pattern field.
      •  Wildcards: defines the wildcards parser as the parser for the expression defined on the pattern field.
      • Exact match: defines the URL should match exactly what is on the pattern field.
    • Pattern: defines the pattern to be searched on the URLs.
    • Ignore case: defines if your rule ignores case on the matching test. That is a important field to be selected since you have no idea on how users might type URLs.
    • Conditions:

      • Defines conditions based on the HTTP request for the rule.
      • Logical grouping:
        • Match all: requires all matches to continue processing the rule.
        • Match any: one match is enough to continue processing the rule.
      • New Condition:
        • Condition input: request variable.
        • Check if the input string: has option on how to match the input string.
        • Pattern: can be a regular or wildcard expression.
    • Server Variables

      • Allows the rule to change values of server variables.
      • Set server Variable:
        • Server variable name: variable name.
        • Value: new value.
        • Replace existing value: allows the value to be replaced if it already exists.
    • Action:

    Action types available: rewrite, none, redirect, custom response and abort request.

    Rewrite

    Defines that your rule will rewrite the URL and execute it but the URL on the user’s browser will continue the same. This execution will be transparent for the user.

    • Action Properties:
      • Rewrite URL: URL to execute instead of the original one.
        • Offers tags to be used as dynamic part of the rewrite URL:
          • {R:0}: returns the whole input expression.
          • {R:1}: returns the first part of the input URL contained in parenthesis.
          • {R:N}: returns the N part of the input URL contained in parenthesis.
      • Append query string: appends to original query string to the new URL.
      • Log rewritten URL: logs rewritten URLs to IIS log files instead of logging the URLs request by the browser.
    • Stop processing of subsequent rules: the rules are processed in the order they appear on the Rewrite Rules screen. When selecting this option your rule will abandon the processing of the following rules if this rule is applied. This normally is how you want to configure it.

    None

    No action should be taken. This is an odd option to be seem here since we can disable the rule.

    Redirect

    Defines that your rule will rewrite the URL and send the new URL back to the user’s browser. The user will notice the URL has changed and a new request will be made to IIS to process the new URL.

    • Action Properties:
      • Redirect URL: URL to redirect the browser to.
        • Offers tags to be used as dynamic part of the redirect URL:
          • {R:0}: returns the whole input expression.
          • {R:1}: returns the first part of the input URL contained in parenthesis.
          • {R:N}: returns the N part of the input URL contained in parenthesis.
      • Append query string: appends to original query string to the new URL.
      • Redirect Type:
        • Permanent (301): Redirects the browser to the new URL and tells the browser to cache it.
        • Found (302): Temporary redirect. The browser doesn’t cache it.
        • See other (303): Redirect for application using POST HTTP method.
        • Temporary (307): Also a temporary redirect introduced on HTTP 1.1. Requires the request to be repeated to be executed.

    Custom Response

    Creates a custom HTTP response to the browser with a status code defined by the rule.

    • Action properties:
      • Status code: status code number.
      • Substatus code: substatus code number.
      • Reason: string with the reason.
      • Error description: string with the error description for the response’s body.

    Abort Request

    Aborts the request and drops the HTTP connection.

     

    Example of an Inbound Rule

    In our example we are going to setup a regular expression rule to rewrite the friendly URL /products/45/sharepoint-book to our actual application URL /products.aspx?id=45&name=sharepoint-book.

    Basically we are creating a rule to get any URL composed by products/[a sequence of any characters]/[a second sequence of any  characters] and rewrite it as product.aspx?id=[first sequence of characters]&name=[second sequence of characters].

     

    Testing the example

    The product.aspx page code is very simple and just shows the two query strings ID and Name.

    The test it, first we accessed the regular URL using the parameters in the querystring.

     

    Then we tested our rewrite rule:

     

    It worked just fine. Behind the curtains IIS got the friendly URL /prodcuts/45/sharepoint-books and execute the URL /product.aspx?id=45&name=sharepoint-books.

     

    IIS UI versus Web.config

    All the options you configure on the IIS user interface actually are written on the web.config file.

    If you fill more comfortable going to the web.config file you can configure all of your rule there. It is also a much simpler way to copy the settings to move to a different server.

    All the settings are under configuration/system.webServer/rewrite node.

    Follow the web.config snippet for the inbound rule we created:

     

    On the next article I will write about outbound and user-friendly URL rules.

     

    See you,

    Amadeu.