- Messages
- 30,364
- Name
- Neil
- Edit My Images
- No
shouldn't is never a good word
id put a small amount of money on not needing anything to access it
shouldn't is never a good word
Stewart,
On the Windows 7 machine go to "c:\windows\system32\drivers\etc" folder, there is a file called hosts (no extension), open in notepad and add a new entry as:
123.x.x.x machine_name
Save the file, make sure win7 doesn't add a .txt extension to the file as it does some times. Win7 hides the "known extension types" by default, you can change that behaviour under folder properties.
If Win7 is not installed on C: just substitute the drive letter as appropriate.
This will allow you to access the machine by name.
That's very true, but is a hack that shouldn't be needed and gets complex when you have multiple computers AND DHCP involved. This is a solveable problem. A couple of hours now will mean things work much more smoothly in the future.This will allow you to access the machine by name.
Yeah. A router config problem is potentially an area where this could be an issue. It's clear (to me) that we need to get all the machiunes in the same actual workgroup first.its certainly worth a shot. if it needs to be on a particular then reserve it on DHCP.
No. The fact it thinks it is in a separate workgroup would explain the ping by add but not by name. The NetBios address resolution is learned - a static IP address (I have several here) resolve perfectly well when the network is configured correctly.If the server is static, that would explain the ping by name, but not the ping by IP addy
Damn you and your quicker than me typing!!as said earlier that skirts around the issue if the ip changes for any reason.
Damn you and your quicker than me typing!!
Windows networking builds a dynamic list of Netbios names to IP addresses. It's not particularly well documented, but if the network is setup correctly it will work.Short of using a DNS server service or the hosts file, I can't understand how you're going to resolve a name to it's IP address. (Genuine question, I'm not being sarcastic).
The router is a Linksys WAG354G. Just a basic wireless modem/router.Stewart: can you post a ipconfig /all from the server?
Also, which router is it?
C:\Documents and Settings\Administrator>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : LFH-SERVER
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes
Ethernet adapter Hamachi:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Hamachi Network Interface
Physical Address. . . . . . . . . : 7A-79-05-4C-E7-61
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : No
IP Address. . . . . . . . . . . . : 5.76.231.97
Subnet Mask . . . . . . . . . . . : 255.0.0.0
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 5.0.0.1
Lease Obtained. . . . . . . . . . : 21 October 2011 15:33:57
Lease Expires . . . . . . . . . . : 20 October 2012 15:33:57
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8168C(P)/8111C(P) PCI-E Gigabi
t Ethernet NIC
Physical Address. . . . . . . . . : 00-1C-C0-C5-A6-CD
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.0.4.210
Subnet Mask . . . . . . . . . . . : 255.0.0.0
Default Gateway . . . . . . . . . : 10.0.4.254
DNS Servers . . . . . . . . . . . : 10.0.4.254
C:\Documents and Settings\Administrator>
No problemsFirst of all, MASSIVE thanks to Andy (arad85) who's devoted a huge amount of time and effort to talking me through this.
That's excellent news! Will be good to check it.I think we have a solution now, though I haven't yet re-run all the diagnostics to prove it.
It's how I understand it too soAs I (vaguely) understand it,
Laptop: I don't think it will matter, but as it's an XP machine, you can probably turn the browser on on that machine with no affect. If you have problems, it may be better to turn the browser on and then control it through the registry settings.I also have a couple of potential problems outstanding.
- Firstly, will the laptop be happy being told that it's not allowed to be a MB, even when it's not on the office network?
- Secondly, what happens if/when the server has to be re-booted? All the other machines in the office will be temporarily left without a MB, and I don't know what effect that will have.
Looking back at the ipconfig /all dumps from Stewart shows that the statically allocated IP for the server has a subnet mask of 255.0.0.0 whilst those for the dynamically allocated have subnet masks of 255.255.255.0.
I've sent you a long email Andy, with details of all the tests I ran, but the short answer is yes, it all seems OK now.He was going to test this in more detail tonight, but I think this is now fixed. Any more news Stewart?
Does Network Discovery work across different subnet networks? If you subnet two networks into non overlapping spaces, you should have two separate networks that can't see each other, even though they are on the same piece of cable. I'd have expected the same for hierarchical subnets in a workgroup only environment (i.e. where you don't have Domain Controllers).Another resolution would have been to ensure the Win 7 computers had Network Discovery turned on and HomeGroups turned off. (I think that was covered early on.)
No it wasn't. It was a NetBios issue. The NetBios cache is different to the DNS cache. DNS is ONLY used when there is a period in the network name. Accessing a computer as \\COMP-A will use NetBios. Accessing it as (say) \\COMP-A.home will use DNS.Open a Command Prompt on each computer and type (without the quotes) "ipconfig /flushdns" as the original issue was essentially a DNS problem and this will get rid of the DNS cache in each computer so it is forced to start again.
G:\Users\Andy>nbtstat -c
Local Area Connection 2:
Node IpAddress: [192.168.1.24] Scope Id: []
No names in cache
G:\Users\Andy>ping mainserver.home
Pinging mainserver.home [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=1ms TTL=64
...
G:\Users\Andy>nbtstat -c
Local Area Connection 2:
Node IpAddress: [192.168.1.24] Scope Id: []
No names in cache
G:\Users\Andy>ping mainserver
Pinging mainserver [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time<1ms TTL=64
...
G:\Users\Andy>nbtstat -c
Local Area Connection 2:
Node IpAddress: [192.168.1.24] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
------------------------------------------------------------
MAINSERVER <00> UNIQUE 192.168.1.10 597
G:\Users\Andy>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
G:\Users\Andy>ping mainserver
Pinging mainserver [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=1ms TTL=64
...
G:\Users\Andy>ipconfig /displaydns
Windows IP Configuration
G:\Users\Andy>ping mainserver.home
Pinging mainserver.home [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=1ms TTL=64
...
G:\Users\Andy>ipconfig /displaydns
....
mainserver.home
----------------------------------------
Record Name . . . . . : mainserver.home
Record Type . . . . . : 1
Time To Live . . . . : 86392
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.1.10
Record Name . . . . . : ns1.home
Record Type . . . . . : 1
Time To Live . . . . : 86392
Data Length . . . . . : 4
Section . . . . . . . : Additional
A (Host) Record . . . : 192.168.1.10
....
If it does reset the static IP, this would have fixed the problem as it would pick up the correct subnet mask. It may have caused a different problem - for example if any ports are forwarded from the router to the server. There's normally a reason for static IPs (I like them here as I run a DNS server on one of my machines and it's just easier to deal with rather than having dynamically allocated ones)...Then rebuild the network on each computer by opening a command prompt and typing (without the quotes) "netsh int ip reset c:\resetlog.txt"
Edit: (If the Server had a static IP Address before then you may wish to add this again. Resetting the IP Protocol would have wiped that out.)
I don't think that is quite right. What the subnet mask also does is define the broadcast address. The broadcast address is different between the two different networks described. TBH, I'm surprised it worked at all as you cannot infer that any address OTHER than 10.255.255.255 is a broadcast request on the 10.x.x.x network (i.e. 10.0.4.255 isn't a broadcast address on that network, so the server shouldn't respond to it).In simple terms, the Subnet 255.255.255.0 essentially tells a computer to ignore the 1st 3 Octets of an IP Address, and to only worry about the 4th Octet. So, a computer with an address of 10.0.4.x with a Subnet Mask of 255.255.255.0 will assume all other computers are on the same Subnet of 10.0.4.
The Server with the address of 10.0.4.210 with a Subnet Mask of 255.0.0.0 will be looking for any computers with an IP Address of 10.x.x.x
The reason for them being treated as different was because they are on different networks. One was on a class A network (the 255.0.0.0 subnet) the other was on a subnet of that network (255.255.255.0).Changing the name of the Workgroup would probably have helped, as there seems to have been two Workgroups with the same name, being treated as different.