Hi all,

Welcome to The Hub Trustees forum.

The Hub is broken into two parts: [link:www.hubfs.net] running DotNetNuke and [link:cs.hubFS.net] running Community Server. Moving forward, we will only support the Community Server portion of The Hub.

I'm moving the site to a different hosting provider, i.e. from oochie.com to m6.net. There are some deficiencies over at m6.net that I have taken for granted when working with oochie and Scott Isaacs. However, I needed bandwidth and a few other things which made the move compelling. I miss Scott's service during issues of this nature.

The location issue is simple, but may cause troubles later. Requirements:

• The Hub needs the CS instance somewhere in the hubFS.net domain. Candidate locations are at the root of hubFS.net or at hubFS.net/cs. It currently resides at hubFS.net/cs.
• The address for The CS portion of The Hub must be consistent both for outside linkage to The Hub and for internal integrity for the site.
• We don't know if future plans for The Hub will have requirements that mean that we need other portals or other services on the hubFS.net domain.
• We do know that CS and DNN are both pigs and manage everything below them. So if we choose a top level installation of CS, i.e. CS at www.hubFS.net, we are beholden to restrictions on the site based on what CS allows. This may be a non-issue, but should at least be stated.

The current configuration on oochie.com is set up to allow for a domain "cs.hubFS.net" to point to [link:www.hubFS.net]. This allows CS to see all links of the form [link:cs.hubFS.net]. I'd like that to continue, but the new hosting provider has a few restrictions that make that difficult. Primarily, they do not allow subdomain definitions that point directly to virtual directories (which is the standard form of what we are doing). The alternatives are:

1. Promote the CS instance to the root level of the domain, i.e. www.hubFS.net will now be the location of the CS portion of The Hub. Plusses - simple, effective, everyone gets there easily. Minuses - have to test whether the current CS hubFS installation will work there; some current links will be broken (but can be edited to be fixed); this option is restrictive in that we may "paint ourselves into a corner" and disallow other product installations unless they play nice with CS at the root level of the domain.
2. Leave the CS instance at www.hubFS.net/cs and expose that as it's final address. Plusses - fast, easy, gets this done; we don't restrict future growth in other products in the domain. Minuses - some links will be broken; Testing of CS at it's current location but as exposed with this address (no longer at cs.hubFS.net) will need to be tested and this should have little risk. We'd also place a placeholder page at the top level of the domain with a quick welcome banner and a 15 second redirect to the CS portion of the site.
3. Write httpHandlers to manage this process so that the physical address remains www.hubFS.net/cs and the external address to the world for the CS portion remains cs.hubFS.net. There are difficulties in this. I've never written an httpHandler, they can be fragile. Plusses - everything stays as is, no links are broken. Minuses - extra ASP.NET baggage in the httpHandler on every call to The Hub so that url rewriting can be done; uncertain of all aspects of the httpHandler and deployment of this strategy.

All things being equal, option 2 seems the best. Please respond quickly with thoughts. I believe that this is the last of the technical issues before go-live.

---O