Consider this a 2nd part to IIS URL Rewrite – rewriting non-www to www. Reader Rubens asked about redirecting multiple domain names in a single rule. That’s a good question and worth writing a part II blog post about it.
Here’s his question:
If there any generic way to do that if we have multiple domains with
multiple extensions?example:
mydomain.com to www.mydomain.com (already done)
mydomain.net to www.mydomain.com
www.mydomain.net to www.mydomain.com
etccc...
and maybe also
www.mydomain2.net to www.mydomain.com
etccc...
Thanks.
Regular expressions are great for handling .com / .net / .org in a single condition. You can do this using a “Condition input” check for {HTTP_HOST} with a “Pattern” of:
Note that the ^ marks the beginning of the pattern and the $ marks the end when using regular expressions.
Additionally, to handle the mydomain2.net, be sure to set the “Logical Grouping” to Match Any. This allows any of the rules to cause the rule to match the condition and redirect. After setting to Match Any, you can add as many domains as you want with a single rule with multiple conditions.
Let’s look at mydomain2.com and .net. Here’s a Pattern that will catch all situations:
^(www.)?mydomain2.(com|net)$
This catches www and non-www and .com and .net.
The following screenshot shows conditions that will catch the following:
- domain.com (1st condition)
- domain.net (1st condition)
- www.mydomain2.com (2nd condition)
- www.mydomain2.net (2nd condition)
- mydomain2.com (2nd condition)
- mydomain2.com (2nd condition)
- www.domain.net (3rd condition)
Note that the Action will redirect all of them to the same place (www.domain.com), which was Rubens’ goal. Just be sure that no conditions match www.domain.com or you’ll create a loop.
The config that results should look like this:
<rewrite>
<globalRules>
<rule name="Redirects to www.domain.com" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTP_HOST}" pattern="^domain.*(com|net)$" />
<add input="{HTTP_HOST}" pattern="^(www.)?mydomain2.(com|net)$" />
<add input="{HTTP_HOST}" pattern="^www.domain.net$" />
</conditions>
<action type="Redirect" url="http://www.domain.com/{R:0}" />
</rule>
</globalRules>
</rewrite>
You can do this using wildcards too. It would take more conditions. It’s also possible to do this with rewrite maps, another feature of URL Rewrite.
If you’re using IIS 7.0 (or 7.5), URL Rewrite is a valuable tool, well worth installing and using.
One common use of URL Rewrite is redirecting http://domain.com to http://www.domain.com. Many people are doing this for search engine optimization (SEO) so that search engines only see the one site, rather than two sites. The goal is to set a permanent 301 redirect.
You can download URL Rewrite from http://www.iis.net/expand/URLRewrite. For this walkthrough and screenshots I’ll use URL Rewrite 2.0 RC1, but everything that I’ll cover also works for version 1.0 and 1.1.
URL Rewrite works at the global level, or site level (or application level for that matter). Where you apply it is really up to how you manage your server. Either will work for a domain name redirect like this.
You can choose to create the rules using IIS Manager, or using a text editor and updating web.config directly. I’ll show both, starting with IIS Manager.
Let’s get started. First, open IIS Manager and double-click on the “URL Rewrite” icon.
Next, click on “Add Rules…” from the Actions pane.
Here you’ll have a choice from a few wizard options, and with URL Rewrite 2.0 you can also create outbound rules. Create a Blank rule (inbound rules).
Give your rule a good friendly “Name”. I’ll call mine “Redirect domain.com to www”.
In the “Using” dropdown box you can choose between Regular Expressions and Wildcards. Use wildcards if you aren’t familiar with regular expressions since they are much more intuitive. However, if you later need to create more complex rules, regex may be necessary.
For this demo select Wildcards. However, I’ll include instructions for those wanting to use regular expressions.
Enter * for the “Pattern”. That means anything qualifies. We’ll use a condition later instead of matching to the URL. (for Regular Expressions, use .*).
Now expand the “Conditions” section and click “Add”. In the “Add Condition” dialogue enter the following:
| Condition input: | {HTTP_HOST} |
| Check if input string: | Matches the Pattern |
| Pattern: | domain.com
(for regex, enter ^domain.com$) |
| Ignore case: | checked |
Click OK.
Finally, it’s time to set the Action.
In the Action section make sure that the “Action Type” is set to Redirect.
For the “Action Properties”, enter http://www.domain.com/{R:0}. The {R:0} retains the existing URL so if someone typed something like http://domain.com/aboutus it would retain the aboutus as it adds the www.
Note (added later): If you want this to be more generic to account for multiple domain names and to retain the original domain name in the redirect, check out this blog post.
Be sure that the “Append query string” remains checked so that the querystring part is also retained.
Also, be sure that the “Redirect Type” is set to Permanent (301), which is what the search engines like. This tells the search engines to do a permanent redirect, use the new location and ignore the previous location.
Finally, Apply the rule and test!
Using a Text Editor
You can also create this rule manually by adding the following to your site’s web.config (or applicationHost.config if you set this at the server level).
In the <system.webServer> section of your web.config, add the following:
Wildcards
<rewrite>
<rules>
<rule name="Redirect domain.com to www" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_HOST}" pattern="domain.com" />
</conditions>
<action type="Redirect" url="http://www.domain.com/{R:0}" />
</rule>
</rules>
</rewrite>
Save and you should be set.
Or, if you prefer Regular Expressions, use this instead:
Regular Expressions
<rewrite>
<rules>
<rule name="Redirect domain.com to www" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^domain.com$" />
</conditions>
<action type="Redirect" url="http://www.domain.com/{R:0}" />
</rule>
</rules>
</rewrite>
This is just the start to great SEO, but it’s a common step and one that I hope you find helpful.
See Part II on how to redirect multiple domain names to a single domain name: http://weblogs.asp.net/owscott/archive/2009/11/30/iis-url-rewrite-redirect-multiple-domain-names-to-one.aspx
Also see this blog post on how to do a generic redirect while retaining the original domain name.
Note: Ignore everything below. Others have said and I've confirmed first-hand that unique SIDs are required. You cannot clone machines with the same SID and join them to a domain controller that was also created from the same base clone. They must be re-SIDed. Since the NewSID utility isn't officially available or supported anymore, sysprep is required to give it a new SID.
However, there is some truth to the finding about the SIDs. They aren't as necessary as they were once thought, and for some situations it's ok clone without re-SIDing. However, to be completely safe, it's best to re-SID each of your new images.
Original blog post follows:
Amazing!
Admins, myself included, have worried about the machine SID for years and years. Way back it was ghosting, now it’s with virtualization. We made sure to create a new SID after creating servers from server images.
It turns out that this has been a non-issue all of this time, a non-issue that everyone, Microsoft, Mark Russinovich and administrators all over bought into for over a dozen years.
A few weeks back I heard rumor that Mark Russinovich was going to expire NewSID. I figured it was because there were just too many SID references to keep track of that he wasn’t going to maintain that tool forever. It turns out that it’s for a completely different reason.
The machine SID does not have to be unique for security reasons, and Microsoft applications don’t depend on it in their usage. Mark’s blog post here covers all of the details:
http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx
However, it’s important to note the difference between machine SIDs and domain SIDs. Additionally the machine name must be different, and the domain controllers themselves can’t have the same SID as any member servers.
I am watching this thread with interest because situations do arise where people run into issues with WSUS and other tools where generating a new SID resolves their issues. However Mark’s comments suggest that it’s related to the domain SID or the domain controller having the same SID as the members.
If, after some burn-in time, this is confirmed to be the case, it will save a lot of work that administrators spend considerable time worrying about . . . apparently needlessly.
Read the post, it covers it in great details.