Hello Joe and Lee, I just took a look at your tutorial in reguards to parent and child portals and was wondering is it necessary to point the host headers in your hosting provider before creating the actual portal? I tried to create a portal and actually created the portal first before attempting to go to my hosting provider to assure that the domain was pointing the same ip address as that which is on the domain in which DNN is installed on? Also am I right that when dealing with portals it is essential that your host allows for at least one dedicated ip address since this ip address has to be referred to by other domain parent portals. This is not a concern in my case but just wanted to verify this? My hosting provider when I talked with them told me host headers could not be changed or rearranged howbeit you can create unlimited subdomains and import unlimited domains into my shared hosting provider. I noticed my portal that I created does not work right at this time. It is either because the rep that talked with me tonight was clueless (which could well be since these guys seem to know more about linux than windows servers) or perhaps I should have been trying to figure out the details in the web server host first and than created the parent portal. Anyway I will try again because I know it can be done at ixwebhosting just not quite as intuitive as your host is as there is no such thing as iis tools or host headers, etc... What I do have is a section called web services that allow minimal front end manipulation of IIS tools such as created a couple dedicated pools, turning folders into web application, creating mime's setting asp.net version that is desired and such but you don't have extensive control in an intuitive fashion maybe I need to dig around in my host a bit more and talk to a knowledgable windows server guy for the company to find out where all their iis configurable items are that the customer can tweak. Thanks, Bo

I think I have figured out the answer myself. In my host is something called A Records. This is equivalent to host headers in other hosting companies. Bottom line is like in Lee's tutorial to discover the way in which you Host allows you to point a domain or a DNS to an IP address associated with the domain in which you installed your dotnetnuke application. So some hosting companies call this host headers while others call it A Records and still others something else. What ever it may be referred to the priniciple is still the same.

I have just done this on my host and while it is right now pointing back to the initial doamin DNN was installed on I am assuming the reason is that the DNS hasn't fully resolved yet and by this evening or so I would expect it to point to the correct domain.

Perhaps though by doing things a little backwords I would need to delete the portal and recreate it what are your thoughts on this Lee and Joe could DNN not be routing it correctly because I created the portal before pointing the DNS to the correct IP address or should I just wait until I know the DNS has resolved an than make my conclusion.

If I do need to recreate the portal I know that by default DNN will increment it to the next number (i.e. though by deleting the portal portal 2 folder was deleted when recreating instead of portal 2 folder being generated it would end up being folder 3 folder by default).

Should I in this case should I have to delete the portal and recreate play with the customize link next to the greyed out box with the PortalID token or could that mess up the automatic numbering scheme of future portals being created?

For example rather than allowing DNN to dynamically created a folder with the next number up I click customize and name the folder the same number as the one that was deleted. Than if I were to create portals in the future would DNN increment correctly or not?

I know when you did the tutorial you hadn't played with the customize option to much in this regards but didn't know if you had since that tutorial was created.

Thanks,

Bo

You shouldn't have to delete and recreate. The internal (to DotNetNuke) addressing is handled by the portalalias table.

Thanks for the reply Joe,

The way my hosting company does things they don't have per say host headers that the customer can work with or that they really understand so I am assuming they accomplish this through what is called A records. By default each domain as a unique IP address and an A record is automatically created to point to this unique IP address. Since there is no way of editing you have to delete and add an A record with the proper domain and the ip address you want it to point to (i.e. the ip address associated with the domain that DNN application is actually installed on).

I have waited about 30 hours or so and I am seeing no difference in the results. What I am finding is that instead of me going to the url specified in the A record I am actually being routed to the main URL my DNN application is installed on.

This really is quite logical since I pointed this A record to the IP address associated with the URL that the web application is installed on rather than the URL that just has an index.html file in it but I am not sure if DNN is not handling this new parent portal domain because I have only checked it since about 30 hours since changing an internal A record or if it is something else going on.

I do have a portal alias that goes to the desired domain name within my dotnetnuke application and I verified that I was indeed checking the portal alias for the appropriate portal.

I also notice that if I go to my main DNN installation click on host and go to portals and than actually click on the portal link that is suppose to take me to the proper URL listed in the portals under host I again just get redirected to the main domain that the installation is located on.

Don't know if this is a host issue or a DNN issue. Tomorrow morning will be 48 hours so maybe I should just wait till than and see if DNN can handle this domain. Perhaps if for some reason my domain is still trying to get resolved DNN can't see it so just lets it redirect to the main domain DNN is installed on as the A record in my host account under this domain told the domain to do.

Thanks again,

Bo

What are the results? Any success?

Hello Lee,

No Success yet I think I might need to delete my portal and recreate it. I created the portal before changing the A Records (aka host headers) in my host account so I'm thinking that because I created the portal and alias first in DNN instead of first pointing the domain name to the installation ip address it is causing some issues.

As of today everything is fully populated and still I keep getting redirected to the installation domain as if the web application didn't know how to handle it so I'm going to try deleting the portal and recreating it now that everything is good on the host end of things and I'll let you know if that did it.

Thanks,

Bo

Ok Lee, Joe, and others reading this thread,

I just had success. Here is what happened. I thought This portal creation thing was a no brainer so I created the parent portal on my DNN Web application thinking that somehow things should be working great.

After reviewing your tutorials Lee on Portal development as well as others I tried to find host headers but finally came to the conclusion that my host called what your host is calling host headers simply A records.

Basically an A record allows you to type in a url and the ip address it ought to point to so I did this thinking we were good to go since the portal was created and the A records were now established but no luck. Now the A records apprently were doing their job almost immediately as I was being redirected to the domain my web application was installed on upon typing the new portal domain.

My host told me it took between 24-72 hours to propogate and since I began this process Monday March 15, 2010 I realised it may not have fully propogated in a day so wasn't quick to blame the web application for the issue since I had not not let the incubation period (resolve time) of the domain repointing to the domain in which the web application was installed on expire so really thought this was the issue.

Well by Thursday March 18, 2010 I still was having issues with my new portal domain resolving to the domain name my main DNN installation was on so called up my host company to verify everything was propogated correctly and indeed it was so I could only come up with one resolve and that is that somehow the web application was not handling my portal properly after it was being redirected to my applicatoins ip address.

Since in Lee's tutorials the order of protocol was to wire up this redirection with the host first and than wire it up at the applicatoin end via adding a new parent portal I decided since I wired it up in the opposite order (adding the portal before rewiring the domain with the main installations ip) I would have to delete the portal and recreate it.

So it was that thinking perhaps DNN may have cached something in the portal in terms of IP address or something in relation to the ip address this domain was pointing to when I created the DNN Portal I decided the best way to test this would be to delete and recreate which is exactly what I did.

Just as soon as I recreated the portal giving it the same alias and everything as I did initially and went to that domain the domain stuck and DNN was properly taking care of the domain name once it pointed to the main ip address that DNN was installed on.

So I guess the moral of this experience is to read and watch the tutorials and follow them in the exact order that Lee Sykes presents them since doing the steps out of order can and possibly will end you up in the same circumstances I found myself in which was everything working properly on the level of my hosting company but than failing at the level of the web application because for what ever reason the web application could not refresh to see the changes that was made with my isp host and so couldn't handle the parent portal correctly.

Thanks Lee for following up with the inquiry.

Bo

By the way Lee or Joe didn't try this yet but do you think it would be wise (should someone else run into this kind of scenario) to delete the portal and than recreate it using the method use sort of just barely hit which was the customize approach to portal numbering.

I guess what I want to know is if someone created a second parent portal that was labeled 1 and for what ever reason it was necessary to delete it would it make sense to recreate it by using the manually way of typing in the portal number so the number 1 could be used again instead of DNN incrementing the number up to 2 so you ended up with a portal 0 and a portal 2 rather than a portal 0 and a portal 1.

I am curious because I am interested to know if using the customization approach in this situation would in someway through off either DNN automated incrementation system so if you were to make a third portal it wouldn't increment to 2 but to 3 or some other number or also wondering if manually renaming a portal to the next number would be ok for all modules.

I know you mentioned in your tutorial that renaming portals to some alphanumeric name could trip up some third party modules that depend on DNN' portal numbers for installing or perhaps instantiating a module properally so this is why I am wondering if clicking on customize for the new portal directory and manually giving it a number would cause modules to be thrown off just as much as if you gave it a alphanumerica number since in both cases you were overwriting DNN' automatic incrementation for that given portal.

Thanks again,

Bo

NO! Don't delete and start over.

"A Records" are part of DNS.

Host Headers are part of IIS Configuration.

PortalAlias entries are part of DotNetNuke.


They are all independent, but they must all be set correctly.

Whoops! Didn't quite finish. DNS, through A Records and other records is used to convert a domain name like mydomain.com to an IP address so that requests can be sent to your web server. When a request comes in at your server, it comes to an IP address, but it still had the domain name in the request. IIS gets the request. The host headers are used by IIS to route the request to the correct website. You can have multiple websites inside a single DotNetNuke installation. So, DotNetNuke can handle requests for multiple websites. It uses the portalalias table to do that. So ... DNS gets the requests to your server (and IIS). IIS uses host headers to figure out which website should handle a request. DotNetNuke uses portalalias entries to figure out which DotNetNuke website gets a request. Does that help? Deleting and recreating your portal won't make a difference. So ... don't do it!

Hello Joe thanks for the quick reply,

If you read down my thread fully you will see I had already done this before your reply. Actually today I saw Lee Sykes comment asking me if I had any results or success which I didn't up till today since I was waiting for the DNS to propogate. But at least in my case when I went ahead and deleted the portal and recreated it again using the same portal alias as was on the one I had first made that wasn't being directed to by DNN I than found that when I typed in that new website that this portal was to point to it resolved to it properly even though the A records in my isp host was pointing to the ip of my main DNN installation.

However as I mentioned earlier before I deleted the portal but after I had pointed the A records to the IP address of my web application installation I was only getting redirected to that domain that contained the web application installation and not to this second parent portal. Howbeit of course when I deleted and recreated the portal DNN automatically incremented the portal number to the next number as if the former still existed. For example I deleted the portal that DNN had dynamically named 3 and when I recreated it DNN named it 4 even though I deleted 3 somehow DNN did not realize it could utilize the number 3 again and so went to 4.

This is why I wrote another reply of inquiry concerning the possibility of clicking on customize portal folder so that if I had to delete a dynamically numbered portal and recreate a new one I could tell DNN to create a folder with the same number as the one that had been deleted but I just wasn't sure if this was ideal as I was afraid it might mess with DNN automatic numbering scheme of portals so from then on out I would have to create these portals manually if I wanted more instead of relying on DNN automatic portal incrementing engine when creating a portal.

Thank you Joe in giving me the break down of the difference between A records, VS host headers VS portal alias. I know DNN portal alias is driven by the DNN web application and that A records and Host headers are dealt with by the company hosting the site and yet I wonder if somehow their isn't somehow some cross communication from DNN. I mean why would it be that when I mistakingly created the new parent portal in my DNN application first than pointed the new domain that I wanted to be another DNN website to the ip address of the DNN application that even after it all propogated it was still being redirected to the IP address of the main DNN web application in which the A record was told to be pointing this domain to but when I deleted the portal in DNN and than recreated it exactly the same way as I first created it DNN seemingly was handling this new domain properly allowing me to go to this new web site address even though in my isp host the A record for this domain was physically pointing to the IP address of the main DNN installation which was not the domain name of this new parent portal?

Actually if went ahead and typed in the dedicated ip address associated with this domain name that I was setting up to work as a new web site via DNN parent portal I would actually end up on a under construction page that shows up on every new domain that is mounted on this host out of the box without any tweaking but if I type in the domain name that this dedicated ip was given to and not the ip address I now go to my new parent portal of my DNN installation and not the under construction page and I can only guess this is do to my changing this A record to point to the main DNN installation.

Changing A record pointers I believe is the only way this host allows customers to take a domain name and point it to a different ip address. I am certain this method has worked in my case because was I signed into my new portal as admin I added a new html module and typed in some stuff just to differentiate it from my main portal of my DNN installation and when I type in this new parent portal domain name I see this new addition where as it will not appear when I type in the domain name in which I installed the web application itself at.

Having said all that however I will communicate with my isp provider again just to see if indeed they have something called host headers that a customer can tweak or that they could tweak opposed to just plain A records out there. If they do than I will certainly remember this for future portal creations on my DNN installation or others that I do for clients but as I was trying to troubleshoot this issue I couldn't come up with anything else tweakable that seemed to do with allowing the customer to take a domain name and point it to a different IP address accept through A records at least with ixwebhosting which is my host but I will ask them and do a small reply to this in order to help us all understand exactly what is right in the case where host headers aren't readily made available to the customer for tweaking.

Thanks,

Bo

Hello Joe,

Just got done speaking with my hosting company in reguards to A records and host headers and apparently host headers as you said do have to do with IIS but they were sure that what they were calling A records was basically just a front end method to tweaking the host header to route to the ip address you wished it to route to so in my case this was the issue but I'm sure it could slightly differ from host to host.

I am still not sure why deleting the portal and recreating it would allow DNN to handle the domain name or the new web site for the parent portal appropriately unless somehow there was some caching that was going on or something else like this. Maybe if I had actually deleted the portal alias and readded the alias instead of deleting the whole parent portal and recreated it I would have gotten the same results.

As I am writing this reply I am thinking that perhaps the issue really was in the portal alias but didn't think to delete it and recreate it first before recreating the whole parent portal but the good news was I had not really set up this portal in terms of populating it with anything other than what DNN populates it with out of the box since this was to be a brand new site that hadn't really been worked up in terms of content so that was a plus in my case.

If you guys have any more suggestions that would help me or perhaps others who might have run into this kink please let me know.

Bo