I have seen more than one person on the DotNetNuke forums faced with a problem when trying to access their portal. Only to find out that they had moved the portal or changed the hostheader, DNS etc. for the url associated with the portal. As it turns out, the root of the problem is that the Portal Alias is now “out of sync” with the url they are using to access the portal. There are two ways to fix this, that I know of. Updating the records in the PortalAlias table in the DotNetNuke database or pointing the original url back to the portal to align with the portal alias records.
Updating the PortalAlias table should be pretty self explainatory for the most part. Simple open the table in SQL Management Studio and edit the value in the HTTPAlias column to the url you are needing to use for the portal.
The other option of pointing the original url back at the portal may not always be possible. However, there is some trickery that can be used to emulate the original url. This is a well documented and widely used practice across platforms… yes even the Mac uses it. But it’s still cool I SWEAR! You have probably guessed it by now. Yes I am referring to the
hosts file.
On windows it is located in %windir%\system32\drivers\etc and is simply called hosts. It is a standard text file with a description at the top and a list of tab separated key \ value pairs. In this case, its more like a value\key pair. The value, that is the IP address, is actually listed first and then the hostname is entered after a tab character. Here is an example:
127.0.0.1 localhost
127.0.0.1 dnn.dev
So, for the sake of discussion, say you had a portal that was configured with a portal alias of sampledomain.dev and for one reason or another you can no longer access that domain or do not have control to point it to a new server. You can temporarily point sampledomain.dev to your own pc or development server etc. Of course this only applies to your computer and does not have any really effect on the actual domain information. Which is a good thing. Once you have entered 127.0.0.1[Tab]sampledomain.dev into the hosts file and saved your changes. Get the man’s best friend, no put the dog down, I am talking about the command line! Launch PowerShell and run the following command: nbtstat –R You should see this message: Successful purge and preload of the NBT Remote Cache Name Table.
At this point, you can launch a new instance of IE or your browser of choice and navigate to sampledomain.dev. It should now skip DNS resolution and go directly to the IP address you specified in the hosts file.
I am sure many of you already know all about the host file and how it works. However, it appears that it is still drastically underutilized or understood. Personally, if I am doing any kind of serious web development, I want to use IIS to host my development site. This is especially true when developing DotNetNuke. Cassini just doesn’t cut it for me when doing large scale web apps. So I frequently add and remove entries from my host file to emulate portals or recover them from other computers. I will probably end up writing a PowerShell script to handle all of this in one easy command at some point. When I do I will be sure and post it in an updated article.
I truly hope that this little trick adds a useful tool to your toolbox, and if it was already there, hopefully I have encouraged you to make the best use of it!
Update: I have uploaded the Add-Host PowerShell script to the downloads page that will automate most of this process.
You can get it here.