Opening Intranet webpage with Host Header

[jmarks]

I wasn't sure whether to post this under the Vista section, in the server
section, or in IE7 because I'm not sure where the problem resides.

We are hosting a sharepoint website on a server 2003 computer running IIS 6.
I set up host headers in IIS and Access Mappings in WSS, and everything works
perfectly for workstations with XP Pro. The workstations that are running
Windows Vista Business cannot connect to the site via the host header name.

All clients are running IE7, and are up to date. I have added
http://intranet.company.net to all intranet zones and trusted zones on the
vista workstations. The IP address of the server is being resolved just fine
when using the host header value.

I'm lost. =P

 

[jmarks]

We modified the hosts file on the vista machine, we just added:

server.ip.address.x intranet.company.net

And the freaking thing worked! It isn't the fix I'm looking for though,
because it is a rigged way to fix that problem. Is there any way I can set
something to make the website work without having to modify the hosts file on
every Vista workstation we have?

 

[Daniel Crichton]

You need to add the server IP and it's host name to your DNS servers.

Dan

jmarks wrote on Tue, 17 Mar 2009 13:27:02 -0700:

We modified the hosts file on the vista machine, we just added:

server.ip.address.x intranet.company.net

 

[jmarks]

I already did that. I told you that the workstation is resolving the hostname
to the IP address just fine. I can open up command prompt, run nslookup, and
type in intranet.company.net and it resolves to the proper ip address just
fine.

If it was a DNS issue, the XP workstations would be having the same issue...

 

[Robert Aldwinckle]

I already did that. I told you that the workstation is resolving the hostname
to the IP address just fine. I can open up command prompt, run nslookup, and
type in intranet.company.net and it resolves to the proper ip address just
fine.

If it was a DNS issue, the XP workstations would be having the same issue...

It can still be a "DNS issue" if the timings are different.
You would use netmon to trace to the two cases and compare
the timings. You could also trace the two cases of with
and without HOSTS entries.

BTW provided the TTL value of the DNS A record is high
enough for you to make use of a cached lookup you could
also do this:
1. ping -n 1 the host server name
2. ping -n 1 any alias name involved
3. use ipconfig /displaydns to confirm that there is
a usable A record for accessing the host server cached
and that you have enough time for IE to use it.
Then there would be no difference between having IE use a
hardcoded entry in the HOSTS file or that one. You could
trace the timings involved for those cases too.


Good luck

Robert Aldwinckle
---

 

[jmarks]

So,

I think I figured out the real question here.
When I set up the DNS entry for my intranet site, it just set it up under my
domain (company.local). This makes the FQDN for the site
(intranet.company.net.company.local).
The XP machines resolve intranet.company.net, and automatically assume it is
..company.local at the end.
The Vista machines will only resolve the name if it is
intranet.company.net.company.local.
How do I get the Vista machines to do that?

 

[Daniel Crichton]

So it is a DNS issue, despite your other reply to me. Why did you put the
hostname intranet.company.net in the company.local domain? Why didn't you
create a new domain called company.net and put a host called intranet in
there? Or why didn't you use intranet for the host name so it's FQDN would
be intranet.company.local? I'd personally never rely on automatic domain
suffix searching, there's always a chance it won't work.

Apparently in Vista you will need to make some registry adjustments to get
it to work like it does on XP. Assuming you have put the domain into your
Vista TCP/IP settings, you will also need to enable the option using one, or
possibly both, of the following:

1. start>run>"gpedit.msc"
2. navigate to "Computer Config>Administrative Templates>Network>DNS Client"
3. enable the following two entries
-allow dns suffix appending to unqualified multi-label name queries
-Primary DNS Suffix Devolution.

and/or

Find HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" and
change/create a dword value called "AppendToMultiLabelName" and set it to 1,
you may need to restart

However, before doing either of these I'd suggest that you check up to make
sure the information I've provided is correct. I do not have a Vista machine
to test either of these on.

Dan

jmarks wrote on Wed, 18 Mar 2009 07:14:16 -0700:

So,

I think I figured out the real question here.
When I set up the DNS entry for my intranet site, it just set it up
under my domain (company.local). This makes the FQDN for the site
(intranet.company.net.company.local).
The XP machines resolve intranet.company.net, and automatically assume
it is .company.local at the end.
The Vista machines will only resolve the name if it is
intranet.company.net.company.local.
How do I get the Vista machines to do that?


:

It can still be a "DNS issue" if the timings are different.
You would use netmon to trace to the two cases and compare the
timings. You could also trace the two cases of with and without
HOSTS entries.
BTW provided the TTL value of the DNS A record is high enough for you
to make use of a cached lookup you could also do this:
1. ping -n 1 the host server name
2. ping -n 1 any alias name involved
3. use ipconfig /displaydns to confirm that there is
a usable A record for accessing the host server cached and
that you have enough time for IE to use it.
Then there would be no difference between having IE use a hardcoded
entry in the HOSTS file or that one. You could trace the timings
involved for those cases too.

Good luck
Robert Aldwinckle ---

 

[jmarks]

You guys were right. It was a DNS issue. I figured it out just before you
responded Daniel. I had to make a new DNS forwarding zone for company.net,
and just add a Host record for Intranet that pointed to the server IP address.

No worries about editing the registry. Thanks for the info though!

Problem solved.