I am a software trainer. Training facilities clone a master image onto multiple machines for the students. Previously, we used to name these student machines S1, S2, S3, etc.

The downfall to this, was that the hostname change meant we had to tweak every machine manually to fix things in IIS and some Server software we are running.

So, to avoid this, we have been doing some testing with cloning the images to S, S, S, S, etc

This means we have duplicate hostnames in the same workgroup. I don't care, as long as each machine still behaves itself. I think they need to be on the same workgroup in order to get internet and also for a license which they can all share.

However, I was thinking there would be problems with a local machine trying to hit an address and being confused with there being duplicate addresses to hit.
So far tests indicate that everything is working ok:
If I dump a helloWorld.txt under the root of IIS on one machine (http://S/helloworld.txt) I can hit it fine from that machine, but if I jump on another machine, I cannot hit it (which is good).

I heard there was some way to completely rule out the machines from getting confused with each other, you could tweak the hosts file with some sort of loopback command to to ensure that the duplicate hostname machines would not conflict with each other?

Can anyone point out how to ensure the machines with duplicate names take their local address to be the one to use over other machines (both in IIS and any other protocols)

Hope I have clarified that OK - let me know via comments if not.

  • FYI: Being in the same workgroup is necessary for exactly one purpose: computer browsing using NetBIOS (the computer list under Network Places). It is not necessary for accessing a shared Internet connection. – grawity Jun 3 '11 at 17:25
  • good point. Ill question the training facilities on the need to be in the same workgroup. – Simon Jun 9 '11 at 19:52

In Windows, look at the path 'C:\Windows\system32\drivers\etc'. There will be a file called hosts (with no extension). Start Notepad as administrator (so that it will have write permissions to the Windows folder) and then open the hosts file. You'll see something like this:

# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#     rhino.acme.com          # source server
#     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       localhost
#   ::1             localhost

You can go ahead and add a line like this to the file:       s

s will now resolve to, without DNS/WINS ever being checked. The hosts file allows you to manually specify the addresses of hostnames, overriding other methods of name resolution.

Fun fact: the C:\Windows\system32\drivers\etc folder appears to be an intentional duplication of the unix /etc, with multiple files of the same name and format as in Unix systems.

  • Did the "handled within DNS itself" comment come with Windows, or was it added by you? (Just curious because DNS does not handle "localhost".) – grawity Jun 3 '11 at 17:21
  • 1
    That comes from Windows itself. In NT6 (Vista/7) the DNS subsystem will resolve localhost to internally, so this entry is no longer in the hosts file. Microsoft leaves that comment in the hosts file to clarify why the typical localhost entry is not there. Microsoft implemented that change as part of the IPv6 implementation. Resolving localhost in the DNS subsystem means that an entry doesn't need to be added in the hosts file for every addressing standard, so it's a little more logical for localhost when you potentially have many addressing standards in use. – jcrawfordor Jun 3 '11 at 21:11
  • 1
    The term "DNS" normally means the protocol running over port 53 (UDP/TCP). It wouldn't be correct for you or Microsoft to call the Windows name resolution subsystem "the DNS subsystem" when it handles much more (/etc/hosts, NetBIOS, WINS, LLMNR, even plugins such as mDNS), just like one wouldn't call Unix gethostbyname() "DNS". – grawity Jun 4 '11 at 8:37
  • 1
    Also, regarding the "fun fact": the initial versions of Winsock were indeed created to be as close as possible to Berkley sockets, to simplify porting. hosts, services and protocols were part of it (although before WinNT they were in %WINDIR%). – grawity Jun 4 '11 at 8:42
  • Good point, @grawity, although in this case it is Microsoft's own phrasing. – jcrawfordor Jun 4 '11 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.