Amanda:

This always creates some confusion.  Let's forget about DNN for a minute, think about how regular Web sites work and how you go about registering a domain and pointing it to the Web server, where ever that Web server might be.  When you register a domain, you have the domain you will use in the URL and DNS automagically will route the traffic to the server.  On the typical Web server, if you are hosting multiple Web sites with only one IP address, IIS needs to know how to find the right Web site physical directory where to serve the pages from.  Since all Web sites use the same address, and by the way, the same port, 80, the only other way to differentiate the sites is by the Host Name, or Alias for the site.

So, what you are missing is the definition of the Host Name in IIS, this is in the Web site definition.  The Host Name must match the Alias you entered in DNN.  I am not near a server right now to tell you the steps, sorry.  Then, to run the site from another PC, a way to route those packets is needed.  If it is a public site, a registered domain would accomplish that.  For an intranet site, you can set it up in the internal DNS server.  For testing however, what I do is to add the Alias/Domain/Host Name to the Hosts file on my PC.  In that way I can create or fake any domain I want.  Again, the entries in the Hosts file, the DNN Alias, and the IIS Host Name must match.

Hope this helps, it is not a step by step procedure but you may be able to figure it out.

Carlos

 Actually, you never need to do anything in IIS.  It's just name resolution that's needed to direct the new portal name, whether parent or child, to the IP that IIS answers on for the DNN app.

Jeff

 http://{ServerName}/dotnetnuke/

{ServerName} is the FQDN or the server name itself or just the IP, but that URL has to match the portal alias you used in creating the portal.

Jeff