VPN Stopped Resolving hostnames

I did a Server 2003 to Server 2008 transition, For now only one domain
controller is Server 2008, the others are 2003.

Directly after that, VPN clients could no longer resolve %computername%, and
it only works if they use %computername%.domain.com. Everything locally works
the same.

Another problem along the same line is that instead of using \\servername,
they have to use \\servername.domain.com to get to network shares.

Ping comes back with "Ping Request Could not find the host"

The strange thing is that the WINS Server, and DHCP are still on a Server
2003 machine, and the VPN servers is also a Server 2003 machine.

I checked the clients who are connected with VPN, and the DNS and WINS
servers are all correct.

Any help is appreciated.

Thank you!
Mike Scott

Dear Mike,

Thank you for your post.

Based on your description, I understand that the VPN client machines cannot
access the internal workstations with computer NetBIOS name after a DC is
upgraded to Windows Server 2008. However, the internal workstations do not
encounter this issue and DNS resolution works fine.

To better understand the issue, I would like to collect the following
information:

1. Do all VPN clients encounter this issue? Are they running Windows XP or
Windows Vista?

2. Netmon:
====================

1) Download and install the Netmon3.1 on a VPN client machine.
http://www.microsoft.com/downloads/d...59d-f4d8-4213-
8d17-2f6dde7d7aac&DisplayLang=en

2) Dialup the VPN connection.
3) Type nbtstat -R and ipconfig /flushdns to clear the cache.
4) Right-click the Netmon icon and select Run as Administrator to launch
NetMon3.1.
5) In the Microsoft Network Monitor 3.1 window, click Create a new capture
tab.
6) In the new tab, select all the Network Adapters in the Select Networks
window, and then press F10 to start capture.
7) Try to ping the internal workstation with the NetBIOS name to reproduce
the issue.
8) After the issue reoccurs, ping the internal workstation with the DNS
name.
9) Press F11 to stop the capture, and then press Ctrl+S save the records.

3. Windows IP Configuration:
====================

After you dialup the VPN connection, type ipconfig /all > ip.txt on the VPN
client machine to export the Windows IP Configuration.

4. Collect the information above on an internal client workstation, which
can access the internal workstation with computer NetBIOS name.

After that, please upload the information to the following space:

https://sftasia.one.microsoft.com/ch...d1c2-90c7-4219
-b748-d7765e0d5768
Password: #5_wMEDs-MFh+e

In addition, please select Enable NetBIOS over TCP/IP on the VPN client
machine to check if the issue disappears.

Thanks. I look forward to your response.

Sincerely,
Joson Zhou
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for the reply Joson!

Your understanding of the problem is correct.

I have done as you instructed, although I used Netmon 3.2, I was unable to
find 3.1.

All VPN Clients that I have ran across so far experience this problem. So
far about 6 clients have reported the problem, including my 2 systems at
home. The clients are almost all Windows XP, with my Vista computer at home
being the exception.

When you look at the files I uploaded, please ignor the "InternalXP_IP.txt"
file. I uploaded it, and then decided I would be better off including all of
the files in one zip file.

The Windows XP VPN client was being connected to using remote desktop, and
the Vista VPN client was being connected to using Live Mesh, so I apologize
for the extra traffic. I can re-capture the same data, but not until tonight.

The other note is that the VPN Clients receive a reply from
"63.225.162.129", this isn't the correct address, but my internet provider
uses a search page if the host isn't found. The correct addresses for the
hosts should have either 216.253 or 172.16 for the first 2 octets.

Thank you for your help!


""Joson Zhou (MSFT)"" wrote:

> Dear Mike,
>
> Thank you for your post.
>
> Based on your description, I understand that the VPN client machines cannot
> access the internal workstations with computer NetBIOS name after a DC is
> upgraded to Windows Server 2008. However, the internal workstations do not
> encounter this issue and DNS resolution works fine.
>
> To better understand the issue, I would like to collect the following
> information:
>
> 1. Do all VPN clients encounter this issue? Are they running Windows XP or
> Windows Vista?
>
> 2. Netmon:
> ====================
>
> 1) Download and install the Netmon3.1 on a VPN client machine.
> http://www.microsoft.com/downloads/d...59d-f4d8-4213-
> 8d17-2f6dde7d7aac&DisplayLang=en
>
> 2) Dialup the VPN connection.
> 3) Type nbtstat -R and ipconfig /flushdns to clear the cache.
> 4) Right-click the Netmon icon and select Run as Administrator to launch
> NetMon3.1.
> 5) In the Microsoft Network Monitor 3.1 window, click Create a new capture
> tab.
> 6) In the new tab, select all the Network Adapters in the Select Networks
> window, and then press F10 to start capture.
> 7) Try to ping the internal workstation with the NetBIOS name to reproduce
> the issue.
> 8) After the issue reoccurs, ping the internal workstation with the DNS
> name.
> 9) Press F11 to stop the capture, and then press Ctrl+S save the records.
>
> 3. Windows IP Configuration:
> ====================
>
> After you dialup the VPN connection, type ipconfig /all > ip.txt on the VPN
> client machine to export the Windows IP Configuration.
>
> 4. Collect the information above on an internal client workstation, which
> can access the internal workstation with computer NetBIOS name.
>
> After that, please upload the information to the following space:
>
> https://sftasia.one.microsoft.com/ch...d1c2-90c7-4219
> -b748-d7765e0d5768
> Password: #5_wMEDs-MFh+e
>
> In addition, please select Enable NetBIOS over TCP/IP on the VPN client
> machine to check if the issue disappears.
>
> Thanks. I look forward to your response.
>
> Sincerely,
> Joson Zhou
> Microsoft Online Support
> Microsoft Global Technical Support Center
>
> Get Secure! - www.microsoft.com/security
> ================================================== ===
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Hi Mike,

Thank you for the information.

I've checked the information and would like to share my findings with you:

Analysis:
==============

1. From the IP configuration files of the VPN clients, I notice that there
is no suffix configured on the workstations. Therefore, they will not query
the DNS server for name resolution when you access the internal
workstations with the NetBIOS name.
2. The Netmon files show that the VPN clients have sent NbtNS packets to
the WINS server but do not get any response, so the name resolution fails.

Suggestions:
==============

In this case, I suggest that you manually configure the DNS suffix for the
TCP/IPv4 address in the VPN connection. To do this, please follow these
steps:

1. Click Start , click Run , type ncpa.cpl and then press Enter.
2. In the Network Connections window, right-click the VPN connection that
you want to configure, and then click Properties.
3. Click Internet Protocol Version 4 (TCP/IPv4) , and then click
Properties .
4. Click Advanced , and then click the DNS tab.
5. Type the DNS domain name in the DNS suffix for this connection box, and
then click OK.

After that, please type to ping the internal workstation again and check
the result. If the issue is resolved, you may refer to the following KB to
add domain suffix to VPN clients via DHCP.

232703 How to Use DHCP to Provide Routing and Remote Access Clients with
Additional DHCP Options
http://support.microsoft.com/default...b;EN-US;232703

If the issue persists, please capture the information (Netmon and Windows
IP Configuration) for further research.

Sincerely,
Joson Zhou
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks Joson!

To be honest, although I can change the configuration of the clients, I
would rather change it at the server. Of course, seeing how this change in
behaviour happened at the same time as the server migration, it would make
sense that it's related.

One other piece of information that may be helpful, the domain controller
that has Wins and DHCP on it was renamed to oldServerName, and I named the
new server the same as what the old one was. For example, if the server was
Server1, it is now oldServer1, and the new server is Server1.

Do you think that could cause the issue?
Did all of the VPN clients not get responses from the WINS server?

The link to that article about assigning DHCP options to RAS clients looks
really interesting, I may have to verify my options.

Thanks for your help!

""Joson Zhou (MSFT)"" wrote:

>
> Hi Mike,
>
> Thank you for the information.
>
> I've checked the information and would like to share my findings with you:
>
> Analysis:
> ==============
>
> 1. From the IP configuration files of the VPN clients, I notice that there
> is no suffix configured on the workstations. Therefore, they will not query
> the DNS server for name resolution when you access the internal
> workstations with the NetBIOS name.
> 2. The Netmon files show that the VPN clients have sent NbtNS packets to
> the WINS server but do not get any response, so the name resolution fails.
>
> Suggestions:
> ==============
>
> In this case, I suggest that you manually configure the DNS suffix for the
> TCP/IPv4 address in the VPN connection. To do this, please follow these
> steps:
>
> 1. Click Start , click Run , type ncpa.cpl and then press Enter.
> 2. In the Network Connections window, right-click the VPN connection that
> you want to configure, and then click Properties.
> 3. Click Internet Protocol Version 4 (TCP/IPv4) , and then click
> Properties .
> 4. Click Advanced , and then click the DNS tab.
> 5. Type the DNS domain name in the DNS suffix for this connection box, and
> then click OK.
>
> After that, please type to ping the internal workstation again and check
> the result. If the issue is resolved, you may refer to the following KB to
> add domain suffix to VPN clients via DHCP.
>
> 232703 How to Use DHCP to Provide Routing and Remote Access Clients with
> Additional DHCP Options
> http://support.microsoft.com/default...b;EN-US;232703
>
> If the issue persists, please capture the information (Netmon and Windows
> IP Configuration) for further research.
>
> Sincerely,
> Joson Zhou
> Microsoft Online Support
> Microsoft Global Technical Support Center
>
> Get Secure! - www.microsoft.com/security
> ================================================== ===
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Hi Mike,

Can the issue be resolved if we manually configure the DNS suffix for the
VPN connection? If the setting solves the issue, you can add the suffix via
DHCP by referring to KB232703, which I mention in my previous reply. This
way, you do not need to change the configuration on the client side.

In addition, I suggest enabling the "Enable broadcast name resolution"
option in RRAS.

As I know, renaming the server should not cause this issue if the records
are updated correctly in DNS and WINS.

In regards to your question, yes, from the Netmon file, both Windows Vista
and Windows XP machine did not get response from the WINS server.

Thanks.

Sincerely,
Joson Zhou
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

My apologies, I didn't quite read the last post right.

I made the changes you asked, and I still am unable to resolve the names
correctly. I did a capture, and uploaded the file. It is 2008-11-24.zip

One thing changed though, now when I type ping hostname, it changes it to
hostname.domain.com.

Thanks!

""Joson Zhou (MSFT)"" wrote:

> Hi Mike,
>
> Can the issue be resolved if we manually configure the DNS suffix for the
> VPN connection? If the setting solves the issue, you can add the suffix via
> DHCP by referring to KB232703, which I mention in my previous reply. This
> way, you do not need to change the configuration on the client side.
>
> In addition, I suggest enabling the "Enable broadcast name resolution"
> option in RRAS.
>
> As I know, renaming the server should not cause this issue if the records
> are updated correctly in DNS and WINS.
>
> In regards to your question, yes, from the Netmon file, both Windows Vista
> and Windows XP machine did not get response from the WINS server.
>
> Thanks.
>
> Sincerely,
> Joson Zhou
> Microsoft Online Support
> Microsoft Global Technical Support Center
>
> Get Secure! - www.microsoft.com/security
> ================================================== ===
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Hi Mike,

In this Netmon file, I notice that the client machine accessed the DNS
server 192.168.x.x instead of the DNS server associated to the VPN
connection (172.16.x.x) to resolve the name. As a result, it pinged the IP
address "63.225.162.129" but not the correct one of the destination machine
(172.16.x.x).

I suggest that you follow the steps in the following KB article to resolve
the issue:

Cannot Change the Binding Order for Remote Access Connections
http://support.microsoft.com/?id=311218

Thanks

Sincerely,
Joson Zhou
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Joson!

Thanks for your help! I was finally able to find out what the problem was.
It turns out that WINS wasn't binding to the correct address. The WINS server
had 3 different IP addresses, and it was listing an address that wasn't the
one specied in DHCP on the main TCP/IP Properties Page.

After removing them all, and adding them back so that the WINS server
address specificed was on the "Use the Following IP Address" in TCP/IP
properties, and the other two addresses were listed in the "advanced TCP/IP"
section, everything is working fine.

Once again, thanks for all of your help. I really appreciate it!

Mike Scott

""Joson Zhou (MSFT)"" wrote:

> Hi Mike,
>
> In this Netmon file, I notice that the client machine accessed the DNS
> server 192.168.x.x instead of the DNS server associated to the VPN
> connection (172.16.x.x) to resolve the name. As a result, it pinged the IP
> address "63.225.162.129" but not the correct one of the destination machine
> (172.16.x.x).
>
> I suggest that you follow the steps in the following KB article to resolve
> the issue:
>
> Cannot Change the Binding Order for Remote Access Connections
> http://support.microsoft.com/?id=311218
>
> Thanks
>
> Sincerely,
> Joson Zhou
> Microsoft Online Support
> Microsoft Global Technical Support Center
>
> Get Secure! - www.microsoft.com/security
> ================================================== ===
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Hi Mike,

Great! I am glad to hear that.

Have a great day.

Sincerely,
Joson Zhou
Microsoft Online Support
Microsoft Global Technical Support Center