finally, when the network drives dont wory / dfsroot don't sync, if i restart the PC, it literally gets stuck upon exiting and i need to do HARD RESET... as if he's waiting for the dfsroot to update.
when im on wired, again everything runs smooth. that's really the whole picture now.
you orginally pointed to \\domain.com\someshare
What happens if you access that now?
And what do you exactly see when doing \\domain.com (does it show all shares?)
When connected wired both commands give the results you expect?
wired - DFSROOT works
wirelees - DFSROOT hangs
equals your current Cisco setup breaks DFS
DFSROOT fails for everybody using wireless - right?
hi, i just restarted on wired hehehe
\\domain.com works
\\domain.com\someshare works as well.
it's definitely a DFSroot sync issue... for instance, when it doesn't work, i can see that the FREE space and Total size of the drive where is the home folder, that is the very same drive as M, when they don't match, sync doesn't work.
also, when im on wifi, i cannot see other computers but just myself, in the shared neighbourhood. again, on wired, i can see everybody.
anyway, if there's a way to edit the H home folder network location (that i use as backup for my stuff) from the registry (coming from the domain's settings), i can edit that to go to \\servername straight, then everything works and peace....
actually, yes and not even more weird..
my colleague's laptop had same issue for M and S and i fixed his laptop with the S and M workaround (from the registry going to \\servername and not \\domain.com\....) but he can access his H drive just fine so DFSROOT updates properly his pc.
Ask IT department if there's some group policy that denies access to DFS wirelessly.
All did work fine .... even wirelessly. As long as you did logon wired and didn't shutdown. Please confirm.
If so... it can't be a wireless AP problem as as far I can imagine. You can ping all by name. Everything just works... expect reading DFS so forwarding to real share fails
YUP
btw how about this one...
I found the entry in the registry that refreshes at every restart, and i tried to delete the key that specifies my HomeFolder *with the DFSroot* that is not working. guess what, if i delete that key, then the PC restarts in 5 seconds, even on wifi!
HKEY_CURRENT_USER\Volatile Environment
> HOMESHARE
> \\domain.com\dsfroot\HomeFolders
that is the culprit!
but every time it boots up, that key is created again, and there's no way for me to edit it. Otherwise, can i prevent the group policy being downloaded every time when pc boots?
Gab
It has to be there and indeed will be created automatically by group policy.YUP
btw how about this one...
I found the entry in the registry that refreshes at every restart, and i tried to delete the key that specifies my HomeFolder *with the DFSroot* that is not working. guess what, if i delete that key, then the PC restarts in 5 seconds, even on wifi!
HKEY_CURRENT_USER\Volatile Environment
> HOMESHARE
> \\domain.com\dsfroot\HomeFolders
that is the culprit!
but every time it boots up, that key is created again, and there's no way for me to edit it. Otherwise, can i prevent the group policy being downloaded every time when pc boots?
Problem is: \\domain.com isn't working!! dont delete HOMESHARE in registry. It works (a bit) because it caches the data locally (most likely).
You can ping domain.com ... you simply don't have the rights to see the shares. ask IT department if any policies for DFS wirelessly have been applied!
actually here's something we discovered here...from our IT:
It seems to be a problem of authentication at boot....and has nothing to do with the APs either and is a universal problem with all networks that uses 802.1x. On Wireless, before the user is logged on fully the computer cannot log in the user to the network because it does not know which account it should log in with.
http://technet.microsoft.com/sv-se/m...8en-us%29.aspx
The consequences of using only user credentials for wireless authentication are that a user cannot do an initial domain logon to a computer because there are no locally cached credentials for his or her user account and there is no connectivity to the domain controller to authenticate new logon credentials. Moreover, some domain logon operations will fail because there is no connectivity to the domain controllers of the Active Directory domain at this time. Logon scripts, Group Policy updates, and user profile updates fail, resulting in Windows event log errors.
The only right thing to do is to create a GPO that propagates the wireless settings so that the user is logged in to the network before the actual logon process
Quote