DFS文件服务器的奇怪问题

全部回复

• 

  

  0

  登录进行投票

  能重现吗？能重现就讨论讨论排错步骤；不能重现的历史问题，即使猜对了，也没法验证啊

  2012年7月18日 9:12

  回复

  |

  引用
• 

  

  0

  登录进行投票

  ＤＦＳ复制不会立即开始。拓扑和 DFS 复制的设置必须复制到所有域控制器上，并且复制组中的每个成员必须轮询最接近的域控制器，以获取这些设置。所需的时间取决于 Active Directory 复制延迟以及每个成员的长轮询间隔（60 分钟）。

  ---

  在IT的路上，You'll never walk alone

  2012年7月18日 9:13

  回复

  |

  引用
• 

  

  0

  登录进行投票

  可以前不是这样啊，有什么好的解决办法呢？ 难道设置好了，用户要等很多小时才能用？不是吧。

  2012年7月18日 11:30

  回复

  |

  引用
• 

  

  0

  登录进行投票

  可以前不是这样啊，有什么好的解决办法呢？ 难道设置好了，用户要等很多小时才能用？不是吧。

  
  把环境、重现问题的步骤、问题的具体表现、你的疑点，都贴出来吧。

  2012年7月19日 3:15

  回复

  |

  引用
• 

  

  0

  登录进行投票

  win2008R2域环境，两台DC用作两个域命名空间服务器，其中一台安装了DFS，最近在DFS管理器里，修改了几个文件夹的共享权限，修改完成后，发现所有用户都无法打开这个修改过权限的共享文件夹了，但等了很多小时以后，这个文件夹又恢复了，可以正常访问。现象就是这些。

  2012年7月19日 4:00

  回复

  |

  引用
• 

  

  0

  登录进行投票

  检查下服务器上系统日志是否正常

  ---

  在IT的路上，You'll never walk alone

  2012年7月19日 4:03

  回复

  |

  引用
• 

  

  0

  登录进行投票

  win2008R2域环境，两台DC用作两个域命名空间服务器，其中一台安装了DFS，最近在DFS管理器里，修改了几个文件夹的共享权限，修改完成后，发现所有用户都无法打开这个修改过权限的共享文件夹了，但等了很多小时以后，这个文件夹又恢复了，可以正常访问。现象就是这些。

  
  好，再扩展一下你的“所有用户都无法打开这个修改过权限的共享文件夹”的具体表现是什么？

  2012年7月19日 4:18

  回复

  |

  引用
• 

  

  0

  登录进行投票

  服务器系统日志看了，找到一些警告：

  1.在没有配置的 DNS 服务器响应之后，名称 _ldap._tcp.dc._msdcs.xxx.com 的名称解析超时。

  2.Remote Insight Agent: The Remote Insight Board/Integrated Lights-Out has detected a controller interface error.
  [SNMP TRAP: 9006 in CPQSM2.MIB]

  3.从计算机 'xxx' 设置会话失败，因为安全数据库 没有包含指定计算机引用的信任帐户 'B-xxx$'。 

  4.从计算机 xxx 设置的会话未能进行身份验证。 发生下列错误:
  拒绝访问。

  现象是，用户尝试打开该共享文件夹的时候，打不开，提示拒绝访问，但实际上用户是有权限访问的。

  过N个小时以后，通常是第二天早晨，就OK了。

  2012年7月19日 6:29

  回复

  |

  引用
• 

  

  0

  登录进行投票

  "现象是，用户尝试打开该共享文件夹的时候，打不开，提示拒绝访问"

  此时如果注销这个用户并重登录，是否可以访问？

  如果重启这台客户端机器，再登录，是否可以访问？

  如果以上都失败，能否用procmon抓一下整个访问过程。

  2012年7月19日 6:35

  回复

  |

  引用
• 

  

  0

  登录进行投票

  此时如果注销这个用户并重登录，不能访问

  如果重启这台客户端机器，再登录，依然不能访问

  procmon抓一下，我去试试看

  在该服务器应用程序日志里看到有许多这样的警告日志：

  日志名称:          Application
  来源:            Microsoft-Windows-CertificateServicesClient-AutoEnrollment
  日期:            2012/7/18 16:41:51
  事件 ID:         64
  任务类别:          无
  级别:            警告
  关键字:           经典
  用户:            暂缺
  计算机:           xxxx.xxx.xxx
  描述:
  具有指纹 d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e 的 本地系统 的证书将到期或已到期。
  事件 Xml:
  <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
      <Provider Name="Microsoft-Windows-CertificateServicesClient-AutoEnrollment" Guid="{F0DB7EF8-B6F3-4005-9937-FEB77B9E1B43}" EventSourceName="AutoEnrollment" />
      <EventID Qualifiers="32768">64</EventID>
      <Version>0</Version>
      <Level>3</Level>
      <Task>0</Task>
      <Opcode>0</Opcode>
      <Keywords>0x80000000000000</Keywords>
      <TimeCreated SystemTime="2012-07-18T08:41:51.000000000Z" />
      <EventRecordID>44341</EventRecordID>
      <Correlation />
      <Execution ProcessID="0" ThreadID="0" />
      <Channel>Application</Channel>
      <Computer>SHSPDC2.spangchem.com</Computer>
      <Security />
    </System>
    <EventData>
      <Data Name="Context">本地系统</Data>
      <Data Name="ObjId">d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e</Data>
    </EventData>
  </Event>

  • 已编辑 sunkaiwin 2012年7月19日 8:51

  2012年7月19日 8:20

  回复

  |

  引用
• 

  

  0

  登录进行投票

  证书警告是另一回事，你mmc加载计算机证书，进去搜一下指纹为d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e的证书，看看他的有效期就知道了。。。

  这个，和DFS问题99%无关

  2012年7月19日 9:12

  回复

  |

  引用
• 

  

  0

  登录进行投票

  其实感觉就是文件服务器在接受用户访问的时候，身份验证上的问题，我每次改动过共享文件夹的共享权限后，就要很久以后才能生效，而以前不是这样的，是立即生效的，我就搞不明白，为什么改动DFS共享文件的权限后，要那么久才能生效，究竟问题出在哪里？

  2012年7月19日 11:36

  回复

  |

  引用
• 

  

  0

  登录进行投票

  其实感觉就是文件服务器在接受用户访问的时候，身份验证上的问题，我每次改动过共享文件夹的共享权限后，就要很久以后才能生效，而以前不是这样的，是立即生效的，我就搞不明白，为什么改动DFS共享文件的权限后，要那么久才能生效，究竟问题出在哪里？

  请问你改的是哪里的权限？DFS Folder/DFS Target Folder/Folder in DFS Target Foler？

  改的是sharing permission还是NTFS？

  如果所做改动是对权限的放大，最终用户还会被Deny吗？

  2012年7月20日 1:51

  回复

  |

  引用
• 

  

  0

  登录进行投票

  对我改的就是DFS管理器里面目标文件夹的共享权限 是Sharing permission 不是NTFS

  经过测试发现，如果改动的是域用户的权限，是立即生效，如果更改的是组（全局，安全组）权限是要很久才能生效，通常要到第二天早晨。

  2012年7月20日 8:04

  回复

  |

  引用
• 

  

  0

  登录进行投票

  如果更改的是组（全局，安全组）权限是要很久才能生效

  这句话很关键啊。。。

  你是不是把Infrastructure Master和GC放在一台机器上了？

  如果所做改动是对权限的放大（例如只是往ACL里加Allow条目），最终用户还会被Deny吗？

  • 已编辑 Finy 2012年7月20日 8:51

  2012年7月20日 8:37

  回复

  |

  引用
• 

  

  0

  登录进行投票

  没错，我的架构主机的角色在第一台DC上，DFS所在的第二台DC上

  第二个试验还没做，之前我实际操作过的是，改动权限，比如删除一些组的访问权限，加上一些新组的访问权限。

  2012年7月20日 9:21

  回复

  |

  引用
• 

  

  0

  登录进行投票

  我实际操作过的是，改动权限，比如删除一些组的访问权限，加上一些新组的访问权限。

  这个操作做完后的现象是不是这样：在短时间内，新加组的用户无法访问，但被删除的却依然可以访问？
  
  突然还想补充一句：假如你同样更改一个非DFS下的（普通的UNC共享）文件夹，会有此问题吗？（因为我感觉你的问题标题可能有点misleading。。。）

  • 已编辑 Finy 2012年7月20日 10:03

  2012年7月20日 9:41

  回复

  |

  引用
• 

  

  0

  登录进行投票

  被删除的用户能不能访问还真没试过，UNC的没来得及测试。

  
  

  • 已编辑 sunkaiwin 2012年7月20日 12:31 纠正错误

  2012年7月20日 12:30

  回复

  |

  引用
• 

  

  0

  登录进行投票

  被删除的用户能不能访问还真没试过，UNC的没来得及测试。

  
  

  
  如果普通共享也存在相同问题，那就和DFS完全不相干了。。。

  2012年7月20日 12:47

  回复

  |

  引用
• 

  

  0

  登录进行投票

  如果和DFS不相干，那您判断究竟是哪里出了问题呢？我应该从哪里着手去查？ 如何解决呢？

  2012年7月21日 1:30

  回复

  |

  引用
• 

  

  0

  登录进行投票

  如果和DFS不相干，那您判断究竟是哪里出了问题呢？我应该从哪里着手去查？ 如何解决呢？

  先确认完到底和DFS相不相干吧，确认完后说一下。

  后续排错找原因还需要收集更多的信息，之前的信息还不足以下任何结论。

  2012年7月23日 3:18

  回复

  |

  引用
• 

  

  0

  登录进行投票

  经过试验测试，确实是DFS的问题，我在该服务器上随便新建了一个普通的共享文件夹，设置并修改权限，结果全部是立即生效，一点问题都没有

  2012年7月23日 5:05

  回复

  |

  引用
• 

  

  0

  登录进行投票

  那这些出故障的DFS下的文件夹，是否都是加入DFS复制集的（在两台机器间经NTFSR或DFSR复制的）？

  2012年7月23日 6:01

  回复

  |

  引用
• 

  

  0

  登录进行投票

  没有加入任何复制，我的DFS所有共享文件夹根本没有启用复制功能，仅仅是用DFS的分布式文件服务器功能。

  2012年7月23日 8:29

  回复

  |

  引用
• 

  

  0

  登录进行投票

  对我改的就是DFS管理器里面目标文件夹的共享权限

  请问，你改动的是 DFS管理器左侧树下的文件夹的“属性”/"高级"/"在DFS文件夹上显式设置查看权限" 吗？

  还是在哪改的？

  2012年7月23日 10:20

  回复

  |

  引用
• 

  

  0

  登录进行投票

  对，就是改DFS管理器里面左侧树下文件夹属性的共享权限。

  2012年7月23日 13:48

  回复

  |

  引用
• 

  

  0

  登录进行投票

  对，就是改DFS管理器里面左侧树下文件夹属性的共享权限。

  再确认一下，你改的是"在DFS文件夹上显式设置显式查看权限" 吗？

  这不是共享权限！这是“基于访问权限的枚举”（Access-based Enumeration）

  请务必确认

  2012年7月24日 3:30

  回复

  |

  引用
• 

  

  0

  登录进行投票

  再次确认，我实在DFS管理器里，改的共享权限，没有在资源管理器里改的文件夹共享权限，这样做有什么问题吗？我一直这样做，没遇到问题，只是最近出问题。

  2012年7月24日 3:55

  回复

  |

  引用
• 

  

  0

  登录进行投票

  我还是有点奇怪，怕我所理解的操作和你做的操作不是同一个。。。所以必须再问你一遍。

  你为什么总是强调你修改的是“共享权限”？

  "在DFS文件夹上显式设置显式查看权限"是Access-based Enumeration，这个不是共享权限。你改的就是这个吗？

  2012年7月24日 4:30

  回复

  |

  引用
• 

  

  0

  登录进行投票

  

  

  2012年7月24日 4:55

  回复

  |

  引用
• 

  

  0

  登录进行投票

  嗯，这样就准确了，确实不是我之前问你的 DFS管理器左侧树下的文件夹的“属性”/"高级"/"在DFS文件夹上显式设置查看权限"

  还好再三问你。

  这样的话，你所改的就是 被引用的 共享文件夹 本身的 共享权限，跟Explorer看到或改动的是一回事。

  麻烦再把改动细节描述一下。
  
  
  另外，突然补一句，问题发生前，是否刚在服务器上装了什么杀毒软件？杀软是在微软技术支持Case中遇到的比较常见的引起间歇性Access Deny的原因之一。

  • 已编辑 Finy 2012年7月24日 5:44

  2012年7月24日 5:25

  回复

  |

  引用
• 

  

  0

  登录进行投票

  经过仔细的测试，我发现，更改权限如果是用户，那立即生效，如果是组，要很久才能生效。啥意思呢，比如我把自己的域账号添加进一个共享文件夹的读取权限，然后尝试访问该文件夹，立马生效，没问题。但当我这个共享文件的权限的主体是一个全局安全组的时候，我在AD里把我的域账号加入这个全局安全组，而这个组被设置为这个共享文件夹权限的主体，结果发现问题出来了，没生效，要等很久，具体时间没计算过，一般下午做完，要第二天早晨来才生效。

  
  服务器上近来没有安装或卸载过任何软件，没有做过任何的系统设置的改动，仅仅是最近才装了Windows的更新而已，每月一次，你懂的。

  • 已编辑 sunkaiwin 2012年7月24日 6:22 追加

  2012年7月24日 6:20

  回复

  |

  引用
• 

  

  0

  登录进行投票

  哈哈，论坛答疑，真相总就是被追问出来的。。。

  你这操作有一点值得推敲：你是在给一个Folder加一个安全组的同时，往这个组里加了一个用户。

  假如你在给一个Folder加一个安全组时，那个用户早就已属于那个组，还会有问题吗？

  这是个关键问题，也可能是Group Access Token延迟被Apply的关键原因。

  2012年7月24日 6:51

  回复

  |

  引用
• 

  

  0

  登录进行投票

  答曰：“没问题”

  我有点欣喜，感觉快水落石出了。

  
  看来就是在改动安全组的用户成员后，很久才生效，这是问题的根本。

  • 已编辑 sunkaiwin 2012年7月24日 7:41 补充说明

  2012年7月24日 7:39

  回复

  |

  引用
• 

  

  0

  登录进行投票

  嗯，基本上走对路线了。

  你再回头看看你首帖的问题描述，只字未提“改动安全组的成员”，害人啊。。。

  而且，我相信这个问题不但仅存在于DFS NameSpace下，普通Folder Sharing UNC也是一样的吧？
  

  也许，这篇文档就可以最终解释并解决你遇到的问题了

  Configure Universal Group Membership Caching in Active Directory

  http://technet.microsoft.com/en-us/magazine/ff797984.aspx

  • 已编辑 Finy 2012年7月24日 8:03
  • 已标记为答案 sunkaiwin 2012年7月24日 8:39

  2012年7月24日 7:56

  回复

  |

  引用
• 

  

  0

  登录进行投票

  经过测试，成功解决，但客户端需要注销，重新登录才能生效。

  首先，非常感谢你对我的帮助，你太棒了。

  其次，在我看完这篇文档之后，我enable  Universal Group Membership Caching，但我不明白其中的原理，启用和禁用究竟区别在哪里呢？为什么启用了通用组成员缓存就OK，禁用了就要那么久后才生效这是什么原因呢？

  
  

  • 已编辑 sunkaiwin 2012年7月24日 8:41 错别字

  2012年7月24日 8:39

  回复

  |

  引用
• 

  

  0

  登录进行投票

  补个更彻底的步骤（也许客户端都不需要注销了）：XP的话，拷个klist工具（Win7应该自带了），执行klist purge，然后再访问

  然后再答你的疑 “为什么启用了全局组成员缓存就OK，禁用了就要那么久后才生效这是什么原因呢？”

  你这句话应该反了吧。。。是 “启用后，要等很久才生效”

  文档链接里已经透露了：By default, a refresh occurs every eight hours on each domain controller that’s caching membership locally

  • 已编辑 Finy 2012年7月24日 8:44

  2012年7月24日 8:43

  回复

  |

  引用
• 

  

  0

  登录进行投票

  我没说反，我本来没有启用（这个选项没有打钩），现在启用了缓存（打上勾），经过测试才解决的。

  2012年7月24日 14:45

  回复

  |

  引用
• 

  

  0

  登录进行投票

  我没说反，我本来没有启用（这个选项没有打钩），现在启用了缓存（打上勾），经过测试才解决的。

  呵呵，有意思，我想我应该没理解错这个Caching功能。。。你这么说来，实际和理论不符了咯？

  你读了文档理解它是怎么样的呢？

  2012年7月25日 2:05

  回复

  |

  引用
• 

  

  0

  登录进行投票

  Universal membership caching eliminates the dependency on the availability of a global catalog server during logons. When you enable this feature on a domain operating in Windows Server 2003 or higher functional level, any domain controller can resolve logon requests locally without having to go through the global catalog server.

  2012年7月25日 3:59

  回复

  |

  引用