在AD中，默认的KCC（Knowledge Consistency Checker）会在15分钟内建立复制拓扑，可以通过在DC上设置注册表键值来更改这个周期，更改后的周期只在当前DC上有效，具体的键值在HKLM\System\CurrentControlSet\Services\NTDS\Parameters下，新建"Repl topology update period (secs)" Dword键值，以秒为单位，例如，可以更改为3600秒（60分钟） 这只是一个前奏。 在AD中，当一个对象被删除时，它并不会被从AD数据库中马上移除，而是被标记上一个特殊状态-墓碑，具体就是在对象的isDeleted属性被标注为Ture，一些属性会被移除，只是在目录中留下一部分属性子集。此时，对象已经被看做删除的并且不能再被使用。 墓碑状态（Tombstone）确保每个DC获知此对象已经被删除，如果对象马上被删除，那么并不能确保存在于其他DC的这个对象能被删除，因为在进行DC之间的复制时，这个对象已经没有了，那么对象删除的信息也就无法复制到其他DC上。所以这个墓碑状态非常重要，能确保每一个DC知道对象已被删除。

The requested search root domain.local/Users’ is not within the scope of this operation. Cannot perform searches [...]

For taking notes. Forefront Threat Management Gateway (TMG) 2010 supports several protocols for establishing a site-to-site [...]

Taking notes. We encourage you to enhance this guide by identifying missing areas (scenarios, features, lifecycle…), [...]

最近公司部署了基于微软DFS技术的文件服务器。其中最吸引人的技术恐怕就是DFSR（DFS Replication）了。但是经过一段时间的运营，用户在抱怨为什么其他省的文件，自己却看不到？经过一番查找，发现问题居然是，这些文件的属性是Temporary（临时性）的。而DFSR默认的设计，则不会阀值这些带有Temporary属性的文件，并且DFSR的这个特性目前为止还不能配置（2008R2）。 事实上，你根本无法轻易的看到一个文件的文件属性是否是Temporary的。甚至微软提供的一些命令行，例如Attrib.exe，FileSystemObject或者WMI中的CIM_Datafile都无法查看一个文件的Temporary属性，更悲情的是：DFSR本身对这些文件的处理（不同步）不会留下任何的Log，对DFSR来讲，这更不是一个Error或者是Bug了，因为本身就是这么设计的。 理论上，这些文件Temporary属性的文件是指只会临时性使用的文件，而不是用户想要真正存档的，DFSR不复制这些文件是基于提升整个复制效率来考虑的，同时，应用程序为了提升自我的处理效率，也必然会产生大量的临时属性文件。当应用程序要创建一个文件（CreateFile）时，可以使用FILE_ATTRIBUTE_TEMPORARY来创建一个temporary属性文件，但更好的方式是同时指定FILE_FLAG_DELETE_ON_CLOSE属性，这样当程序所有的进程都关闭的时候，temporary文件也可以被删除。 但事实上在Leo的实际生产环境中，用户正常的Office文件，Adobe PDF文件等许多的文件都莫名奇妙的有了Temporary属性，事实这些文件都一定是要被复制到DFS的其他服务器上；于是，Leo只能需求去掉Temporary属性的方法。 使用Fsutil命令查看Temporary属性。 Fsutil是包含在Windows系统中的一个命令工具，用法：

File Attributes是一个位掩码，表示文件属性的设定值。在上面的例子中，0×120表明为一个临时文件，计算方式是： 0×100 × 0×20 (Archive) = [...]