Hi, I hope I have chosen the right spot for this, I am an IT admin at a large school, we have started to experince and odd thing with some of our Win7 laptops. After these devices have been out inthe school for a while, the UNC path to the student home drive server becomes innaccessable and they can not get to their work. All other mapped drives work well. We have been going through an extensive fault finding process but have come up blank, it is as though windows has marked that specific UNC path to be bad and blocked it. If I enter a slight variation to the path it all goes okay (bad = \\server\home good = \\server.domain.private\home) I am guessing it is just a case of time until this variation is marked as bad too, this blocked UNC applies to all users that log into the affected PC, the same users can get to the same resources from any of our 1,500 desktops or other laptops. The problematic laptops seem confined to devices that have had a large volume of different users on them, we do not see the same problesm on staff issued laptops. Hope some one might be able to stear me in the right direction as we have come to the conclusion these machines are cursed :-) Peter Sumner (Pedroj1) in Australia

Since you can access it using the FQDN \\server.domain.private\home and not \\server\home that means your not appending dns to domain.private. go to network connection > Right click connection > Properties > IPV 6 (TCIPv4) > Advanced > DNS > check append these dns suffexs and add domain.private. This should allow the user to resolves the share by using \\server\home. FYI this can be added my a GPO Justin | http://patchmypc.net

Justin, it does not appear to relate to a DNS suffix issue, (wish it was though) all shares for users are generated as \\severname\share for all mapped drives and over 1,500 systems connect in this manner successfully, that same PC has several other shares successfully mapped in this same manner. We have created other shares on the same server (Demeter), some on the same point on file structure as the original and others on new file stuctures, these new ones (sharenames) all connect correctly. We have destroyed the original share (\\demeter\home), thinking it had a problem and recreated on a new file structure, and it still fails on the affected W7 laptops, so it is firmly a client side problem. It is ONLY the original share name to the students home share point on these high use laptops that eventually fails and presents it self as "not accessable" not permitted to connect. Original share \\demeter\home is shared to E:\HOME and fails on these high use laptops. New share \\demeter\home3 is shared to E:\Home and works great for even the troubled PC's Change the context of the original share name to be \\demeter.domain.private\home and it now works. It looks to me like Win 7 has some how marked the original UNC name as a threat and prevents all users mapping it on the affected laptops, including domain admins when the login. We had considered changing all the AD records to use the FQDN but we suspect it is only a matter of time until the same thing happens to that UNC path. Regards, Peter Sumner

To any reading this, the MS KB 2194664 located at this URL pretty well describes what we are experiencing http://support.microsoft.com/kb/2194664 I have requested the hotfix's but they appear to be for earlier releases (pre SP1 I Guess) of server 2008 and Win7. Noticed another thread stating that putting the FQDN into the share fixed his problem ( http://communities.vmware.com/thread/287453 ) so that is a last resort for me but would like to know WHY it only happens for some client PC's rather than a knee jerk change that might end up going wrong too. Peter.