Hi,

For folder based sites you must in Web.config, set UseFoldersInsteadOfHostnamesForMultipleSites="true"

Also if developing on a local machine, your first site must be running at http://localhost, it cannot work if your first site is already a sub folder like http://localhost/mojoportal/

Hope it helps,

Joe

Hi,

You don't need to re-install it, you just need to point your Default Web Site to the folder. Go into IIS, right click Default Web Site, choose Properties. On the Home Directory tab, just browse to your mojoportal folder.

More info about IIS configuration here:

http://www.mojoportal.com/iiswebsetup.aspx

You see for folder based sites it must be a Web Site, not an application (Virtual Directory).

Hope it helps,

Joe

I just added some notes to the bottom of this page telling how to test hostname based sites on your local machine:

http://www.mojoportal.com/multiplesitesbasedonhostnames.aspx

Hope it helps,

Joe

Hi Bill,

For multiple sites using host names you need just 1 web site with a fixed ip address and no virtual directories. Use of virtual directory is why you have http://WEBSERVERNAME/MPSiteX, virtual directory cannot be used as a root web site. In this case http://WEBSERVERNAME/ is root web site and /MPSiteX is a virtual directory beneath that site. Thats just not going to work, you must put the web files at the root of the site, ie the folder that corresponds to http://WEBSERVERNAME/. WEBSERVERNAME is the same thing as host name. it can be a root domain like somedomain.com which just means default host at that domain, or you can fully qualify the host name like www.somedomain.com where www is the host part and the rest is the domain, but still the fully qualified host name is www.somedomain.com so you can and should think of the whole thing as the host name. If using multiple domains then it will be more like domain1.com, domain2.com, www.domain3.com etc but they must all resolve to the same ip address. In any case, from mojoportal's point of view the host name is everything between http:// and the next / and this must be specified correctly in site settings for each site. Any host names that resolve to the ip and are not defined on a site will just result in the display of the root site.

You do not need any host headers if you really have a fixed ip address that only 1 site is running on. Host headers in IIS are used if you have multiple IIS web sites all using the same ip address, and in this case the host header tells IIS which IIS site should handle the request. So if your mojoportal installation is in one IIS site but you are having to share the same ip address with other IIS web sites then you do need host headers in your mojoportal IIS site for each host name you plan to use. If your mojoportal IIS site has the ip address all to itself you should not put any host headers at all.

I think you have created problems for yourself if you populated content on a staging machine using virtual directories like
http://WEBSERVERNAME/MPSiteX and now you want to move this content to a production machine with just a root site like http://WEBSERVERNAME/. The content will have broken links and images when you move it because the url has changed and the old url is in the html content in the db. For some features we use relative urls for images but in this example the relative base url has changed from /MPSiteX/ to just /, so even in these features the links and images will be broken. If you had structured your staging machine to have a root web site then it would work better but still a few features like blog will have broken images because it uses fully qualified image urls and your existing content will have the old urls. Fully qualified urls must be used in the blog and any feasture that exposes rss otherwise images would not display in outbound feeds.

You would be much better off creating production content right on the production machine rather than on staging. You could make the pages only visible to admins or whatever internal roles and then when you are ready to go public you change to allow all.

Hope it helps,

Joe

Hi Bill,

From an SEO point of view it doesn't matter if its a single multi site installation or multiple IIS web sites. I think the only SEO issue is using more than 1 hostname/domain for a single site. It will be weird because whichever site is active while editong content is going to determine how the links for images are created at least in features like the blog that use fully qualified urls. For features like the html content mwhich use relative urls for images it won't matter. If the same blog is visible using either of 2 domains then the image may appear to come from a different domain than the blog post if you view it on a different domain than it was entered on. So I would go with one domain per site. I think if you use more than one domain for the same site like mojoportal.com, mojoportal.net etc it will dilute your SEO across the domains.

I'm not sure if this feature is in the current release or just in svn, but for example this site will work with both host names www.mojoportal.com or just mojoportal.com and this is not great for SEO, its better to use one or the other so I added an option in Site Settings for preferred domain and I set this to www.mojoportal.com, so any requests coming in for mojoportal.com will be redirected to www.mojoportal.com to keep all my google analytics results and search results in a single hostname. Another reason is my ssl certificate is for www.mojoportal.com not mojoportal.com so if a user tries to login on mojoportal.com it would give a warning about the certificate not matching. By forcing www.mojoportal.com I avoid that problem.

SSL is an important consideration for how you configure your sites. If any of your sites are going to need SSL they will be best if they are on separate IIS sites from the others. I mean you could have the root cite use ssl and disable it for child sites, but as soon as you need ssl for a child site you need to move it to its own IIS web site and you need another ip address. This is because only 1 SSL certificate can be installed in a site and only 1 SSL certificate can be bound to port 443 on a given ip address.

If none of the sites will ever need SSL then the single IIS web site is beneficial because you have only one installation to upgrade for all the sites and it uses less server resources than if they were all separate sites. If there is a chance the sites will need ssl at some point it will be easier if they are separate, then you can add another ip address and ssl cert as needed.

Hope it helps,

Joe