Hi Ion,

I'm far from an expert as you can see from my posts, however I believe that the difference between a child and a parent is how you setup the alias...yourdomain.com/child vs. child.yourdomain.com with the latter being a parent portal alias.

Now, I didn't get a chance to check before I had messed around with the DB tables and decided that it would be better to just use a fresh install, but someone was saying that you can change the alias that you use to access the site as a child to a parent. So under portals->yourportal you would add child.yourdomain.com and then remove the yourdomain.com/child aliases that are there. This of course means that you have to have your dns setup to understand where child.yourdomain.com is suppose to be sent too. I use No-IP.com and was able to use the management system they have to direct my main dns name and the child to the same IP. This might prevent you from having to completely rebuild. Now, having said that be sure that you create a site template before you mess around to much so that you can for the most part recreate the site from scratch if you need too. I always copy out the website directory to a archive directory so that I can recover anything that doesn't move, and I completely wipe the website directory for a fresh install. You will have to reinstall all the modules that you used BEFORE you recreate the site using the template or you will have alot of holes ( missing modules are just not installed from the template)

Good luck

Thanks for your reply.

Turns out, my portal is not a child portal, so that's not the problem.

I did a bunch more searching and found this, *which solved my problem*, but I have no idea why.

http://forums.asp.net/1037419/ShowPost.aspx

My (limited) understanding of this fix is:  if you set a session variable, it causes IIS (or whatever framework your hosting provider is using to distribute load or provide failover or proxying or whatever) to behave differently.  It does this by either a) ensuring that the rest of that browser session stays on the same server, or b) activating whatever mechanism your hosting provider has to preserve session state across multiple web servers.

Why does this help what appears to be a cookie problem?

In the case of a), it would (presumably...I'm just guessing here) help because DNN login authetication works by setting a cookie on your browser that is based on the Ethernet MAC address of your server.  If during a session in which you are logged in, you suddenly are connecting to a different server, with a different MAC address, your cookie is no longer any good.  So setting a session var doesn't actually change cookie behavior (on the client or server side), but it has the happy side-effect of forcing a browser's entire visit to the site to take place on the same server.  If you have set a long login expiration period in DNN, it might be limited if your hosting provider sets a lower default value for IIS session lenght.  Check MSDN, there is a way to add a line to default.aspx that would override this hosting provider setting and make it equal to your DNN setting.  It's a workaround.

In the case of b), presumably the hosting provider has configured all the servers in the farm to use the same "virtual" Ethernet MAC address?

Your Mileage May Vary.

The ultimate solution might, in the worst case, require DNN use something besides the server MAC address as the basis for creating the authentication cookie.  Which probably isn't straightforward....