IIS redirect using URL Rewrite

In the following example we will redirect HTTP to HTTPs using URL Rewrite. You will need the following items completed in order for this to work correctly.
– SSL Certificate for site installed in IIS.
– Site properly installed and configured for SSL (site set up and binding in IIS configured).
– URL Rewrite 2.0 is installed on the sever.

GUI Version

– Select the website you wish to configure
– In the “Features View” panel, double click URL Rewrite

You will notice there are currently no rules configured for this site. Click “Add Rules…” in the Actions menu to the right of the “Features View” panel

Use the default “Blank rule” and press “OK”.

When editing a rule there are the “Name” field and 4 configuration pull down boxes.
– Enter “Redirect to HTTPS” in the name field.
– Next we will configure the first configuration pull down box called “Match URL”, on the right side of “Match URL” press the down arrow to expand the box.

Within the “Match URL” configuration box we will set the following settings:
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: (.*)

We can now edit the next configuration pull down box which is “Conditions”, Press “Add…” to add a new condition to the configuration.

We will configure the condition with the following settings:
Condition Input: {HTTPS}
Check if input string: Matches the Pattern
Pattern: ^OFF$
Press “OK”

You should see your condition in the list of conditions.

For this setting we do not need to configure the “Server Variables” pull down box. Continue onto the “Action” configuration box and pull down the box by selecting the arrow on the right. We will configure the following settings for the “Action” configuration:
Action Type: Redirect
Redirect URL: https://{HTTP_HOST}/{R:1}
Redirect Type: See Other (303)

Press “Apply” then press “Back to Rules”

You should now see the rule configured on the main screen of the URL Rewrite module.

Test your site, it should now redirect from HTTP to HTTPS.
If we exam the web.config file we can see where the rule was entered. If we entered the rule directly into the web.config file it would show up in the GUI.

Web.Config Rule
You can also edit the web.config file of the site directly and you will be able to see the rule in the GUI. You will need to enter the following within the <system.webServer> </system.webServer> elements.

?

1 2 3 4 5 6

<rule name="Redirect to HTTPS" stopProcessing="true"> <match url="(.*)" /> <conditions><add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" /> </rule>

When implementing this solution you need to make sure to use relative paths for all references on your page because there is a possibility you will get a warning asking you if you want to display secure and insecure items. For example, if you have a logo on your page and the URL to this logo is http://domain/images/logo.jpg, do not use the whole path because including the http:// will hard code this image to use http and not https. Instead use /images/logo.jpg.


Replace the Redirect URL https://{HTTP_HOST}/{R:1} with https://{HTTP_HOST}{REQUEST_URI}

Best Practice for RPC Timeouts in Exchange

Exchange 2010 and 2007 use RPC (Remote Procedure Calls) for all client and RPC proxy calls. For example, email clients (Outlook, Outlook Anywhere (OA), and ActiveSync) use RPC for MAPI connectivity.

The default keep alive time for RPC connections uses the IIS idle connection timeout, which is 15 minutes. This usually doesn't cause a problem on local LAN or WAN connections, but routers and switches that are used to connect Internet clients to internal Exchange servers often have more aggressive timeouts. Typically these network devices have a 5 minute timeout which causes problems for external clients, particularly Outlook Anywhere, iPhone, and iPad clients. Symptoms include messages stuck in the Outbox and poor email performance on the remote clients, and high CPU utilization on the Exchange Client Access Servers (CAS).

The new best practice is to adjust the RPC keep alive timeout value on the Client Access Server from 15 minutes to 2 minutes. Since RPC is a function of Windows, not Exchange, this value is adjusted under the Windows NT registry key. The value is located here:

HKLM\Software\Policies\Microsoft\Windows NT\RPC\MinimumConnectionTimeout

Normally the MinimumConnectionTimeout DWORD value does not exist, which means RPC uses the default value of 900 seconds (15 minutes). To adjust it, create or modify the MinimumConnectionTimeout value and set the value to decimal 120 (seconds, or 2 minutes). IIS must be restarted on the CAS to affect the change.

The following command will create the appropriate values:

reg add "HKLM\Software\Policies\Microsoft\Windows NT\RPC" -v "MinimumConnectionTimeout" -t REG_DWORD -d 120

The Outlook and ActiveSync clients honor this new timeout during the connection to the CAS, so both client and server now send a Keep-Alive packet after two minutes of inactivity, effectively maintaining both TCP connections needed.

A colleague of mine works for a large global company that was affected by this. They have several thousand iPads connecting to nine load balanced CAS servers and all the CAS were peaking at 100% CPU utilization. Once they implemented this change the average load on the CAS is now 20-30% and the iPad performance is much improved.

This is my new best practice and I make this change on every Exchange CAS deployment. For more information about RPC over HTTP see Configuring Computers for RPC over HTTP on TechNet.

Source

Outlook Anywhere RPC over HTTP

Symptoms:

Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server server.contoso.com.
The attempt to ping the endpoint failed.
Additional Details An RPC error was thrown by the RPC Runtime process.
Error 1818 CallCancelled

Source

On the Mailbox servers: a DWORD entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to "1".
Next, as indicated earlier, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey.
So, set the following on the Client Access Servers:
1.The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
2.The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.
Finally, you need to make sure that the DCs are listening on port 6004:
On the Global Catalog servers: a REG_MULTI_SZ entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004.
There is 1 last thing to deal with in this SSL-ID load balanced configuration.
Outlook profile creation hard codes a call to DSProxy on 6004.
Which means that we can get split connectivity during profile creation.
To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:
On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.
By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity.

Source