I'm working with a printer management application called GoPrint (hosted on Windows Server 2003 R2) that uses the HTML rendering engine (i.e, Internet Explorer) on each Windows client to popup messages related to printing. The first time I try to print, I login using the popup UI and everything is fine. On subsequent print commands (never having logged out), I get a dialog box titled "Windows Internet Explorer" with this text: To display the webpage again, Internet Explorer needs to resend the information youve previously submitted. If you were making a purchase, you should click Cancel to avoid a duplicate transaction. Otherwise, click Retry to display the webpage again. I want to suppress this messagefor the GoPrint application, but not for all Web sites visited from this Windows client. If I make an entry in the Windows client's HOSTS file for this server name, then this "resend" message never appears. But why? Did adding the entry to HOSTS effectively change its Internet zone (Restricted/Internet/Trusted/Local intranet)? (Adding this server to the Trusted or Local intranet zones made no difference.) How could the method of name resolution affect subsequent HTML traffic? Why (and how) is HTML communication to servers defined in HOSTS handled differently than servers resolved via DNS? It happens that this particular Windows XP SP3 client is in the same subnet as the server (123.45.67.xxx). Will the workaround fail when the Windows client is not in the same subnet as the server? (No proxy is configured.) I should mention that I'm not a network expert, but I'm comfortable interpreting a packet trace when necessary. I don't need a full technical explanation here if someone can just direct me to a document that explains why this works. BTW, adding this server to HOSTS also suppresses an IE dialog box complaining about the invalid certificate on this server. I don'tunderstand that either: certificate processing is bypassed or surpressed for servers in HOSTS? And I don't think this solution has anything to do with GoPrint itself, but GoPrint tech support has no idea what's happening here on the client end. An explanation, or a pointer to one, would be greatly appreciated. Sande

I should have been a little more specific: This is all native TCP/IP, no Active Directory involved and no Windows domains. (The client's in a workgroup, not the same one as the server.) The entry in the HOSTS file appears in one of two forms: 1) the GoPrint server's fully qualified domain name, like it is in DNS: 123.45.67.89 server.subdomain.domain.com -or- 2) an alias of the server's name: 123.45.67.89 server I think this is TCP/IP name resolution, not NetBIOS or anything else. As far as Windows clients are concerned, we don't have an intranet; that is, no servers are considered local. I'd be happy to answer any other questions I can. Sande

HOSTS is just another name resolution method, it doesn't effect or control communication.It sounds likeyou have the answer,HOSTS is returning a different IP than DNS isand as you suggest one IP is trusted by IE and one is not trusted. I would use NSLOOKUP to test name resolution with DNS and then use "PING ServerName" and "ping ServerName.subdomain.domain.com" to test name resolution w/ HOSTS since HOSTS is checked before DNS in the resolution order.DNS lookup can return different resultsthan from HOSTS, orbe failing completely,for multiple reasons:1. There isn't an internal DNS server and/or the external DNS server isn't configured to resolve internal names or zones. (Secondary DNS pointing to an external server can cause this.)2. TheDNS zone has missing, incorrector duplicate entries for the server.3. The internal DNS zone doesn't match thedomain name and suffix set on the workstations; or the workstation domain name doesn't match the server FQDN. (If the resolution attempt doesn't include the FQDNthen resolving "servername" can fail if the wkstns are configured for domain.com or domain.local and FQDN of the server is servername.subdomain.domain.com.) Check out DNS search suffixes.hth.

These DNS notes are good ideas, but the DNS lookup and HOSTS return the same IP address. In fact, it turns out that's not where the problem lies. To recap, when the GoPrint client is configured with a correct server reference of server.subdomain.domain.com, the unwanted Resend prompt appears. When the server name in the HOSTS file is server (any name with no periods), the Resend popup does not appear. However, when the server name in the HOSTS file is server.subdomain.domain.com, the Resend popup does appear again. I have come to believe my instincts were right on this: it's a matter of IE security zones. (Specifically, of our not having set them correctly.) I added server.subdomain.domain.com to the Trusted sites zone, where we have been adding all our domain.com entries. (Because, when I asked our technical network experts how to set up the security zones, they said to do it that way, since "Trusted sites" were the most trusted of all. Now I understand how that's wrong.) But the name "server" alone resolves to the Local intranet security zone, I think, since it contains no periods. (It is not being dereferenced using the DNS suffix, because the suffix, domain.com, would not yield the correct server name.) And what's the primary visible difference between the two zones? The Trusted sites zone shows prompts that the Local intranet zone suppresses. Like this Resend prompt. This is all hypothesis, since I couldn't find a utility that would tell me, for a given server reference, what zone it resolves to. However, the solution supports my hypothesis: When I move all our domain.com entries from the Trusted sites zone to the Local intranet zone, the Resend prompt disappears. I also have to be careful that a *.subdomain.domain.com entry in the Local intranet sites zone is not overridden by a more specific server.subdomain.domain.com entry in the Trusted sites zone. Why isn't this problem more common? Because most organizations use Windows domains, which resolve to the Local intranet zone, or else a proxy configuration that corrects identifies the Local intranet zone. We have neither, and I had bad advice about how the zones should be used. BTW, for anyone who is still confused, the most trusted zone is "Local intranet", which is where you should put all your domain.com reference. The next most trusted zone is "Trusted sites", which is where you should put Internet sites, outside your organization, that you trust. One person suggested that "server" alone resolves not as a DNS name, but as a NetBIOS name. I can understand why that might be so, but then what security zone are NetBIOS names considered to be in? I didn't find documentation to answer this. So I've solved the problem, I think. I hope this saga can help someone else down the road. And maybe a knowledgeable network programmer will write a utility that, for a given server reference, will display which zone it was determined to be in. (NetBIOS or not.) Sande