Laptop hangs when accessing Domain-dfs on other networks

  • Thread starter Thread starter WUR-DE
  • Start date Start date
Robinson

I built a new computer using a windows retail version CD and the problem
persists
I posted the requested output as GP.zip to
http://cid-a03ee8e9ffc88ef5.skydrive.live.com/browse.aspx/.Public?uc=1

A few remarks
- the /pktinfo, /pktflush, spcinfo and /spcflush commands sho no different
behaviour on this new computer
- the new computer resides in the root-OU "computers" with a minimum set of
grouppolicies
- I performed the requested GP-commands on this newly created computer
- I interpreted your "dir Windows\policydefinitions" as "dir
c:\windows\inf\*.adm" as we are talking XP here
- The problem also persists when making use of "wurnet.nl" instead of "wur"
as servername

It looks as though we'll have to focus on the serverside
I'll start some experiments in that direction

xie xie
Michiel Pieters
 
Robinson
I built a test domain-dfsroot in my test-domain
It has no extra root-targets
Performing the same tests results in acceptable delays

Our production dfs-root has 8 extra root-targets, the majority of which is
typically located at remote sites
Checking out these extra root-targets and the way Explorer deals with that
is causing the abnormal delays and even hangs

Looking forward to your reaction!
Michiel Pieters
Wageningen UR
the Netherlands



WUR-DE said:
Robinson

I built a new computer using a windows retail version CD and the problem
persists
I posted the requested output as GP.zip to
http://cid-a03ee8e9ffc88ef5.skydrive.live.com/browse.aspx/.Public?uc=1

A few remarks
- the /pktinfo, /pktflush, spcinfo and /spcflush commands sho no different
behaviour on this new computer
- the new computer resides in the root-OU "computers" with a minimum set of
grouppolicies
- I performed the requested GP-commands on this newly created computer
- I interpreted your "dir Windows\policydefinitions" as "dir
c:\windows\inf\*.adm" as we are talking XP here
- The problem also persists when making use of "wurnet.nl" instead of "wur"
as servername

It looks as though we'll have to focus on the serverside
I'll start some experiments in that direction

xie xie
Michiel Pieters



"Robinson Zhang [MSFT]" said:
Hi Michiel,

Thank you for clarification.

After discussing with my colleagues again, we suspect there is a specific
component on your Windows installation image or on your computers. I
suggest you build a new computer by using a Windows retail version, then
join domain to test the problem.

At same time, I will help you check the Group Policy on your computer.

1. Click "Start", input "CMD" (without quotation marks) to Start Search bar
and press "Enter".
2. Please run the following commands one by one.

gpresult -v > D:\gpresult.txt
cd\
cd Windows\policydefinitions
dir > D:\gp.txt

Then, please go to D driver, upload gpresult.txt and gp.txt to Windows Live
SkyDrive.

Thank you for your cooperation. I am looking forward to your reply.

Thanks again.

Best regards,

Robinson Zhang
Microsoft Online Support
 
Hi Michiel,

Thank you for your latest information. I have involved my colleagues with
different specialists and we need time to do some research. I will contact
you as soon as possible.

Thank you for your understanding.

Best regards,

Robinson Zhang
Microsoft Online Support
 
Hi Michiel,

Thank you for your patience.

We performed further research and have some new findings.

1. When the computer in domain network (IP address: 10.x.x.x), it has valid
DNS and IP address, and it can locate AD and DFS related servers via DNS
name resolution.

2. We noticed when the issue occurs, the problem computer gets IP address
(192.X.X.1 ) from a DHCP, but no DNS and WINS. Therefore, as what we can
see in the network trace package which you provided previously, the
computer keeps performing NetBIOS name resolution request via broadcasting.
As you know, broadcast traffic will not be routed. As a result, the
computer cannot get a valid response.

Given the situation from these information, I suspect that the issue is
related to name resolution. Here are our suggestions:

1. Please let me know the network topology. For example, is there a router
between your domain network and 192.x.x.x subnet? How are these two
sub-networks connected? Also, is there DC or DFS Root target server in the
192.x.x.x subnet?

2. I also noticed that you mentioned everything starts to work correctly
after restarting the computer. It is a bit abnormal. Could you please run
"ipconfig /all" before and after restarting computer? If the computer is
able to get a valid DNS server from the DHCP server after restart, it would
be able to locate AD and pull necessary information regarding the DFS
namespace.

3. Also, please try to access DFS by using \\w####t.nl\<DFSRootName>
instead of using \\W##\### (domain NetBIOS name). How it works in different
scenarios (before and after restart, in the new network)?

4. Did you enable INSITE option for the DFS namespace? If yes, the DFS
client will not access DFS target servers in other sites, and may cause
similar problems. Please have a look.

5. Meanwhile, I would like to let you know that this is a complicated issue
and is related to server components. (This newsgroup is mainly focus on
Windows client.) I will continue to do my best to help you on checking some
basic settings and mainly focus on the Windows XP side. However, please
know that we may still suggest contacting Microsoft CSS for further
investigation in the future, to ensure your are best served. Thank you
for your understanding.

Again, thank you for your time and efforts on the issue.

Hope it helps.
 
Robinson
thanks for your reply

There is no router between our domain network and the test-network, on
purpose, to emulate a home network.

We do not have a dns in our test-network because of practical problems. It
is completely isolated. The issue remains the same though: on home-networks
with dns, querying the dfs-root results in a system-hang

It does not happen when the move from the domain-network to the home-network
is accompanied by a restart because then the dfs referral cache (dfsutil
/pktInfo) is empty. So in my opinion that is normal behaviour. However after
having had a vpn-connection to the domain network, the dfs referral cache is
again filled and the problem re-occurs. As long as we cannot get rid of this
referral cache (/pktinfo) the problem persists


We didn't touch the INSITE option, so is Disabled by default.. Enabling it
seemed to me a possible solution, but I didn't succeed Enabling it (access
denied) and discarted the project.

Please let me know how to contact Microsoft CSS so we will not bother you
anymore with this issue

Thanks again
Michiel Pieters
Wageningen University and Research
The netherlands





"Robinson Zhang [MSFT]" said:
Hi Michiel,

Thank you for your patience.

We performed further research and have some new findings.

1. When the computer in domain network (IP address: 10.x.x.x), it has valid
DNS and IP address, and it can locate AD and DFS related servers via DNS
name resolution.

2. We noticed when the issue occurs, the problem computer gets IP address
(192.X.X.1 ) from a DHCP, but no DNS and WINS. Therefore, as what we can
see in the network trace package which you provided previously, the
computer keeps performing NetBIOS name resolution request via broadcasting.
As you know, broadcast traffic will not be routed. As a result, the
computer cannot get a valid response.

Given the situation from these information, I suspect that the issue is
related to name resolution. Here are our suggestions:

1. Please let me know the network topology. For example, is there a router
between your domain network and 192.x.x.x subnet? How are these two
sub-networks connected? Also, is there DC or DFS Root target server in the
192.x.x.x subnet?

2. I also noticed that you mentioned everything starts to work correctly
after restarting the computer. It is a bit abnormal. Could you please run
"ipconfig /all" before and after restarting computer? If the computer is
able to get a valid DNS server from the DHCP server after restart, it would
be able to locate AD and pull necessary information regarding the DFS
namespace.

3. Also, please try to access DFS by using \\w####t.nl\<DFSRootName>
instead of using \\W##\### (domain NetBIOS name). How it works in different
scenarios (before and after restart, in the new network)?

4. Did you enable INSITE option for the DFS namespace? If yes, the DFS
client will not access DFS target servers in other sites, and may cause
similar problems. Please have a look.

5. Meanwhile, I would like to let you know that this is a complicated issue
and is related to server components. (This newsgroup is mainly focus on
Windows client.) I will continue to do my best to help you on checking some
basic settings and mainly focus on the Windows XP side. However, please
know that we may still suggest contacting Microsoft CSS for further
investigation in the future, to ensure your are best served. Thank you
for your understanding.

Again, thank you for your time and efforts on the issue.

Hope it helps.
 
Hi Michiel,

Thank you for your reply.

Before moving on, I would like to let you know I am glad to help you on the
issue and I always doing my best to troubleshoot the issue. Normally, we do
not redirect our customer to Microsoft CSS. But if the issue is out of our
support boundary or if the issue can be resolved efficiently by Microsoft
CSS, it is recommended to contact Microsoft CSS. Thank you for your
understanding.

On my side, I still would like to provide useful information for you. If
you would like to continue handle the issue with me, could you please let
me know the following points?

1. When the problem occurs, just a window hangs? Or whole Windows XP OS
hangs?
2. On the other network, if you open an explorer window, type an non-exist
network address, does the window hang? (such as \\abcdefgh)
3. Could you please let me know why going to access DFS when the computer
on other network?

However, I still would like to recommend that you contact Microsoft
Customer Support Service (CSS) for assistance so that this problem can be
resolved efficiently. To obtain the phone numbers for specific technology
request please take a look at the web site listed below:

http://support.microsoft.com/kb/295539

If you are outside the US please see http://support.microsoft.com for
regional support phone numbers.

Hope it helps.

Best regards,

Robinson Zhang
Microsoft Online Support
 
Hi Michiel,

I have not heard back from you for a couple days. When you get a chance,
please send me an update on your issue. If you need further assistance,
please feel free to let me know.

Thanks for your time and efforts!

Best regards,

Robinson Zhang
Microsoft Online Support
 
Robinson
sorry for not having replied earlier. We've been scratching our heads over
here
We've come to the conclusion that we would like to try to resolve the issue
by contacting CSS

Still I would like to answer your questions:
1. When the problem occurs only the application that accesses the dfs-root
hangs
Most of the time this is the Explorer
2. Accessing a non-existent network address results in short, acceptable
delays
3. Reasons for accessing the dfs-root while on other networks:
- Our MSWord group-templates reside on the dfs-root
- users would like to be able to make subfolders of the dfs-root
Offline-available
- accidentally accessing shortcuts that point to the dfs-root

OK, Robinson
Thanks very much for your support!!
I will post the outcome to this discussion

Michiel Pieters
Wageningen University and Research
+31 317481179
 
Hi Michiel,

Thank you for your reply.

I understand that you will contact Microsoft CSS to resolve the problem.
Thank you for your time and patience on the issue.

On my side, we will monitor the CSS case to report the findings back to the
newsgroup in your thread.

Again, thank you for posting in the newsgroups.

Best regards,

Robinson Zhang
Microsoft Online Support
 
Michiel -

Have you ever resolved this issue? We are having the same issue, and
have been working with Microsoft Phone Support for over 3 weeks and it
is still not resolved. The trouble went away for a couple days, but
returned, and we do not know what changed or make the trouble go away,
but we are still stuck with long delays when accessing dfs shares.

If you have any good ideas, I would appreciate any help you could
offer.

Thanks
Tim S.


Robinson
sorry for not having replied earlier. We've been scratching our heads over
here
We've come to the conclusion that we would like to try to resolve the issue
by contacting CSS

Still I would like to answer your questions:
1. When the problem occurs only the application that accesses thedfs-roothangs
    Most of the time this is the Explorer
2. Accessing a non-existent network address results in short, acceptable
delays
3. Reasons for accessing thedfs-root while on other networks:
   - Our MSWord group-templates reside on thedfs-root
   - users would like to be able to make subfolders of thedfs-root
Offline-available
   - accidentally accessing shortcuts that point to thedfs-root

OK, Robinson
Thanks very much for your support!!
I will post the outcome to this discussion

Michiel Pieters
Wageningen University and Research
+31 317481179



"Robinson Zhang [MSFT]" said:
Hi Michiel,
I have not heard back from you for a couple days. When you get a chance,
please send me an update on your issue. If you need further assistance,
please feel free to let me know.  
Thanks for your time and efforts!
Best regards,
Robinson Zhang
Microsoft Online Support- Hide quoted text -

- Show quoted text -
 
Back
Top