背景
我们在环境中更改了我们的环境configuration后，遇到了DFS命名空间方面的一些问题，并且在与Microsoft进行支持电话联系之前，我希望了解如何排除故障。
我们使用干净path的DFS命名空间，但不使用DFS复制。 在更改之前，我们有一个名称空间，我们称之为\\my.domain.com\main 。 这个领域工作的很好，但是我们支持5个部门，所以我们决定为每个部门创build命名空间。 \\my.domain.com\Div1 ， \\my.domain.com\Div2等
在更改之前，每个人都映射了一个类似于Q: \\my.domain.com\main\Div1Dept的驱动器，并在更改之后映射了类似于Q: \\my.domain.com\Div1\Folders的驱动器。 \\my.domain.com\main\Div1Dept将与\\my.domain.com\Div1\Folders位置相同。 唯一的区别是名字空间。
问题
“Standard_DriveMaps_Divisional {5559ca2b-79af-4a37-82d8-451d2fb71543}”中的用户“Q：
组策略对象不适用，因为它失败，错误代码0x80070035networkingpath未find。 这个错误被压制了。
我们有各种各样的场合（我们支持2000个用户，每周接听几个电话），当用户login的位置不可用，驱动器无法映射。 我们可以确认有一个高质量的networking连接，可以到达域控制器和命名空间服务器。
当我们使用main名称空间时，这个问题永远不会出现。 当用户手动导航到path时，它变为可用。 解决方法是运行gpupdate来重新映射驱动器，但是我们不能要求用户每次都这样做。
我们确实有一个非DFS驱动器，每当这些DFS相关映射失败时都能成功映射。 这导致我相信它不完全是networking连接。
执行故障排除
我远离DFS专业版，但是我知道如何制作文件夹目标等。
使用DFSpipe理，我查看了高速caching持续时间和名称空间之间的其他设置，它们都匹配。 他们也使用相同的命名空间服务器。
使用DFSDiag命令，我们对所有的命名空间都有正确的testing结果。
题
鉴于提供的信息，任何人都可以想到一些具体的事情，我可能会过度看？ DFSpipe理GUI之外是否有可能影响非main命名空间可用性的设置，因为main总是可用的。
也许GPO得到应用没有networking访问，所以他们不能得到改变（Networkdrive映射）
这发生在同一个人？
有一个GPO策略等待networking，但确保它只在内部域客户端上活动，而不是在移动/便携式计算机上
检查这个 https://technet.microsoft.com/en-us/library/gg486839.aspx
如果没有此设置，客户端可能使用本地证书存储进行身份validation，但networking堆栈未完成加载。
我们在我们的网站上遇到了这个问题，但是Networkdrivers / Stack的初始化/加载花费了很长时间的计算机/networking驱动程序问题。