![]() |
|
Welcome to Vista Banter. You are currently viewing our boards as a guest which gives you limited access to view most discussions, articles and access our other FREE features. By joining our free community you will have access to ask questions and reply to others posts, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
|
|||||||
| Networking with Windows Vista Networking issues and questions with Windows Vista. (microsoft.public.windows.vista.networking_sharing) |
|
|
LinkBack | Thread Tools | Display Modes |
|
|||
|
I have fought this one for months. Mapped drives that worked fine in the
office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |
|
|||
|
Thank you for sharing your experience with us. The other two options are setup WINS or DNS suffix in the client site for NetBIOS name resolution.
Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I have fought this one for months. Mapped drives that worked fine in the office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |
|
|||
|
I had tried that, but apparently i didn't go far enough. I had set the com
suffix in the network adapter DNS append suffix box, but not the full contoso.com suffix that would resolve the address to a FQDN. I think that the KB on this solution should be updated with an example. So are you saying that if i set the DNS suffix to eg. 'contoso.com' that I wouldn't have to map the drives via FQDN path? In an aside, this is still very different from the way XP worked. It is an obscure but critical difference that affects the productivity of my users. I held up Vista upgrades because of this issue. -- Russell Reid "Robert L [MVP - Networking]" wrote: Thank you for sharing your experience with us. The other two options are setup WINS or DNS suffix in the client site for NetBIOS name resolution. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I have fought this one for months. Mapped drives that worked fine in the office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |
|
|||
|
It is better to setup WINS instead of using DNS suffix because using WINS is setup in the server side while using DNS suffix is in the client side.
Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I had tried that, but apparently i didn't go far enough. I had set the com suffix in the network adapter DNS append suffix box, but not the full contoso.com suffix that would resolve the address to a FQDN. I think that the KB on this solution should be updated with an example. So are you saying that if i set the DNS suffix to eg. 'contoso.com' that I wouldn't have to map the drives via FQDN path? In an aside, this is still very different from the way XP worked. It is an obscure but critical difference that affects the productivity of my users. I held up Vista upgrades because of this issue. -- Russell Reid "Robert L [MVP - Networking]" wrote: Thank you for sharing your experience with us. The other two options are setup WINS or DNS suffix in the client site for NetBIOS name resolution. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I have fought this one for months. Mapped drives that worked fine in the office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |
|
|||
|
Interesting. We do have WINS setup on our DC. (Server 2003 R2 SP2) Still
had the problem over VPN. Second, I thought that WINS was no longer required for a Server 2003 network if you do not have any legacy operating systems. Are you saying that Vista now requires WINS to function correctly on the network? -- Russell Reid "Robert L [MVP - Networking]" wrote: It is better to setup WINS instead of using DNS suffix because using WINS is setup in the server side while using DNS suffix is in the client side. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I had tried that, but apparently i didn't go far enough. I had set the com suffix in the network adapter DNS append suffix box, but not the full contoso.com suffix that would resolve the address to a FQDN. I think that the KB on this solution should be updated with an example. So are you saying that if i set the DNS suffix to eg. 'contoso.com' that I wouldn't have to map the drives via FQDN path? In an aside, this is still very different from the way XP worked. It is an obscure but critical difference that affects the productivity of my users. I held up Vista upgrades because of this issue. -- Russell Reid "Robert L [MVP - Networking]" wrote: Thank you for sharing your experience with us. The other two options are setup WINS or DNS suffix in the client site for NetBIOS name resolution. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I have fought this one for months. Mapped drives that worked fine in the office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |
|
|||
|
As said, it is better to use WINS for VPN. Otherwise, you may do DNS suffix.
This link may give more information about WINS. Does Windows 2000/2003 domain needs WINSDoes Windows 2000/2003 domain needs WINS. Q1: Is there a definitive list of the services and operations that will no longer work in Windows 2003 Server if ... www.howtonetworking.com/server/wins1.htm -- Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... Interesting. We do have WINS setup on our DC. (Server 2003 R2 SP2) Still had the problem over VPN. Second, I thought that WINS was no longer required for a Server 2003 network if you do not have any legacy operating systems. Are you saying that Vista now requires WINS to function correctly on the network? -- Russell Reid "Robert L [MVP - Networking]" wrote: It is better to setup WINS instead of using DNS suffix because using WINS is setup in the server side while using DNS suffix is in the client side. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I had tried that, but apparently i didn't go far enough. I had set the com suffix in the network adapter DNS append suffix box, but not the full contoso.com suffix that would resolve the address to a FQDN. I think that the KB on this solution should be updated with an example. So are you saying that if i set the DNS suffix to eg. 'contoso.com' that I wouldn't have to map the drives via FQDN path? In an aside, this is still very different from the way XP worked. It is an obscure but critical difference that affects the productivity of my users. I held up Vista upgrades because of this issue. -- Russell Reid "Robert L [MVP - Networking]" wrote: Thank you for sharing your experience with us. The other two options are setup WINS or DNS suffix in the client site for NetBIOS name resolution. Bob Lin, MS-MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com "Russell Reid" wrote in message ... I have fought this one for months. Mapped drives that worked fine in the office were not accessible over a VPN connection. I searched and searched for a solution in vain. I tried all of the solutions and hotfixes that seemed related: The SMB shares hotfix (kb933468), the route metric hotfix (kb930163), deleting cached credentials (cmdkey.exe /delete /ras), remove IPv6 for the VPN connection, set the DNS server address explicitly in the network adapter settings, etc, etc. To no avail. Turns out the solution was simple. Map the drive with the fully qualified domain name of the server. We map drives via script so this is a fairly easy to implement solution. If you map drives via the 'Map Network Drives' command in 'Computer' then you have to add the domain suffixes manually when you map the drive. So the format of the mapped drive path should look like this: '\\server1.contoso.com\fileshares\staff' instead of the default map for the same share that looks like this: '\\server1\fileshares\staff'. You have to adjust this in the path window when you map the drive. I have not found a way yet to alter the map once it is created. Seems stupid that windows vista doesn't use the FQDN for the map, but you need to use it for the map to be available over a VPN connection. We us VPN alot since we travel often. I have held up several Vista upgrades until I could resolve this one. I hope this helps any of you who have also been frustrated by this problem. -- Russell Reid |