Ehsan Mahpour’s Weblog

I posted an article from Steven Hargrove’s weblog  about how to redirect a web page in correct way last week and he asked me to remove it from here since he would like to keep the credit of that.
In respect to his request I removed the article from my blog. just wanted to say that  I never steal content from other people without mentioning about the source of that in my blog.

Anyways, whoever is interested to read it can go to his weblog and read it. Click here

I was looking for a simple solution to synchronize the IIS settings across a webfarm that I found an interesting post on Scott’s webblog.

Included Files

With the theory behind us, let’s take a look at the files included in the download file. Note that I did not try to pretty it up or put a lot of error checking in it. It’s simple and easy to understand, but that also means that you may need to do some digging into the files to make any changes or to troubleshoot any issues that I didn’t handle in a friendly way.

[The first two files are the ones that you will use to do a Metabase Merge or Push.]

MetabasePush.bat

Usage: MetabasePush {ServerIP} [SMTP FQDN]

You can call this from a batch file that can live somewhere else, like on the desktop of your primary web server. It will do a metabase push from the current server (localhost) to the target server specified by the ServerIP.

You can optionally add the SMTP FQDN and it will update that on the target server. We use that at ORCS Web because each server node has a different SMTP FQDN.

MetabaseMerge.bat

Usage: MetabaseMerge {ServerIP} [SMTP FQDN]

This operates the same as MetabasePush except that it does a Merge instead. The ServerIP is required and the SMTP FQDN is optional. Don’t forget the differences mentioned above between a Push and Merge. This file calls RemoveAdminACLLine.vbs so that the target server retains its own security settings.

[The following files are helper files and don’t need to be run directly.]

IIsCnfg2.vbs

This is a copy (confirmed up to date May 2006) of IIsCnfg.vbs but with two minor modifications to make the target username and password optional.

Metaacl.vbs

This is an untouched Microsoft script to view and update the metabase ACLs permissions.

RemoveAdminACLline.vbs

This is used by MetabaseMerge.bat to remove the ACL lines so that the permissions on the target server are left untouched during a Merge.

ChangeSMTP-FQDN.vbs

This will change the fully qualified domain name of the SMTP server on the target server that you specify. It is used when there are different SMTP DNS names on each server.

Scott Forsyth’s IIS Clustering Utilities

Here are a few of the most popular ways to do cross domain calls via JavaScript: proxies, JSON, and Flash.

Cross domain proxy

This is one of the most common approaches. Your script calls your server, your server makes the call to the remote server and then returns the result back to the client. There are some definite advantages to this approach: you have more control over the entire lifecycle. You can parse the data from the remote server, do with it what you will before sending it back to the client. If anything fails along the way, you can handle it in your own way. And lastly, you can log all remote calls. WIth that you can track success, failure and popularity.

Cross domain JSON

For this to work, the remote server needs to be set up to handle this. It needs to accept an additional parameter: a callback function. Then, to make the remote request, you insert a new script tag into your page with which will allow you to specify a remote URL. The reponse back will load a JSON object as a parameter of the callback function you specified in the request. Yahoo, for example, has implemented this feature in their web services API’s. This is great because you can implement web service calls without ever needing a scripting language on your server. Check out Jason Levitt’s article, JSON and the Dynamic Script Tag, on XML.com for more information.

Cross domain using Flash

Flash, by default, is much like Ajax in that you cannot request data from a remote server. However, you can enable this capability by placing a special XML file on the remote server to accept requests from other domains. With JavaScript’s capability to interact with Flash, we can use Flash as a bridge for sending cross-domain requests. (XML.com has a nice write-up of this technique.) There are still some limitations to this technique, most of which seems to be limited to older versions of Flash. There’s also the issue with users having Flash installed and enabled.

Sub-domains are still cross domains

One point to note and it’s fairly subtle. Plenty of us have our sites running at www.example.com and at example.com. They both point to the very same place. To us, we see them as the same thing. But to an Ajax call, it’s considered cross domain. Therefore, if you have to make an Ajax call to the same server, don’t code the domain as part of the request; just use the path.

The Future

Some have already begun looking into establishing standards that could be implemented into future browsers, such as JSONRequest and ContextAgnosticXMLHttpRequest. JSONRequest seems the most promising but that could be because I prefer JSON over XML and see it as really gaining traction over the next couple years.