活动目录域

其实这个问题，早就遇见过了，没怎么重视他。可是后来发现这个问题出现的频率还是很高的，转个文章以便留作后用

活动目录域AD灾难恢复后没有sysvol和NETLOGON共享:原来我们提到过刚升级的额外域控制器没有自动共享sysvol与netlogon，今天再来看这个案例：WINDOWS 2000 AE SP4虚拟机上做测试，AD灾难恢复成功，第一次启动无法正常进入系统，能够进入安全系统，检查无误再次进入正常模式成功。检查共享，发现只有IPC默认共享。无SYSVOL和NETLOGON共享。C:\WINNT\SYSVOL下面只有一个DOMAIN目录，没有其他的。根据KB文章检查注册表中的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\backup/Restore\Process at Startup\BurFlags的值为00。停止了FRS服务，修改该值为D4，启动FRS服务，发现D4值被重置，无效。这台恢复的DC是一个主DC，生产环境有和其他4台DC通讯的。怎么解决？

回答：Sysvol内保存的主要是组策略的信息，在DC上更改某一级别的组策略后这一目录的内容会做响应更改，并在稍后复制到其他DC上。如果其他DC拥有完整的sysvol目录结构，那么内容还能被修复，否则可能将无法回复这部分信息。
请检查参考下面这篇KB检查您的sysvol目录内容是否完整：
Windows 2000 域控制器上丢失 SYSVOL 和 NETLOGON 共享疑难解答
/kb/257338/zh-cn

请在检查后说明您的SYSVOL目录受损情况，以便我们帮助您恢复其中的内容。也请检查其他DC，以便确定sysvol内容能否被恢复。
Netlogon共享应该会自动被重建，请尝试重启netlogon服务并观察共享是否被产生。具体的操作步骤如下：
1. 停止netlogon和NTFRS服务（net stop命令）。
2. 停止共享SYSVOL目录。
3. 重启netlogon和ntfrs服务。
4. 检查共享是否被建立了。

正常情况下，在\\（您的域名）\SYSVOL\下的确只有一个的文件夹，该文件夹内保存的主要是组策略的信息，在DC上更改某一级别的组策略后这一目录的内容会做响应更改，并在稍后复制到其他DC上。只要是网络连接正常的DC都会互相复制sysvol的内容。您可以通过使用net share命令来查看sysvol和netlogon共享是否创建。

下面的这篇文章提供了详细的sysvol修复步骤，如果您的sysvol出现了问题，以参考步骤修复sysvol的结构：
Restoring and Rebuilding SYSVOL
/WindowsServer/en/library/21280b7f-9f14-4ff9-8c0d-ec0e555522f01033.mspx?mfr=true
上面这篇文章中涉及的一些工具可以从下面这个连接获得：
Windows Server 2003 Resource Kit Tools
/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en
-----------------------------------------------------

如何

解决缺少 SYSVOL 和 NETLOGON 共享的问题
现有域中的副本域控制器上通常会出现缺少 SYSVOL 和 NETLOGON 共享的情况，但是新域中的第一个域控制器上也可能会出现这种情况。可以对副本域控制器执行下面这些步骤，也可以对域中的第一个域控制器执行除复制特定步骤以外的所有这些步骤。 ? NTDS 连接对象存在于每个复制伙伴的 DS 中。

NTDS 连接是单向连接。目录服务使用这些连接复制 Active Directory，“文件复制服务”(FRS) 使用这些连接来复制 SYSVOL 文件夹中系统策略的文件系统部分。“知识一致性检查器”(KCC) 负责建立 NTDS 连接对象以在域和林中的域控制器之间形成连接良好的拓朴。如果没有自动连接，管理员还可以创建手动连接对象。

使用“站点和服务”(Dssite.msc) 管理单元检查问题计算机和现有域控制器之间存在的连接对象。要在计算机 \\M1 和 \\M2 之间进行复制，\\M1 必须具有来自 \\M2 的入站连接对象，并且 \\M2 必须具有来自 \\M1 的入站连接对象。使用 Dssites.msc 中的连接到域控制器命令查看和比较每个域控制器的域内连接对象的透视图。

如果新副本成员没有连接对象，请使用 Dssites.msc 中的检查复制拓朴命令强制 KCC 创建自动连接对象。执行完此操作后，请按 F5 键以刷新视图。

如果 KCC 无法建立自动连接，管理员必须为没有指向或来自域中其他域控制器的入站或出站连接的域控制器建立手动连接对象。如果您建立了单个有效的手动连接对象，KCC 可以成功建立自动连接对象。从域中同一个域控制器中删除重复的手动或自动连接以避免出现禁止复制的配置。有关此问题的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
251250 (/kb/251250/EN-US/) NTFRS Event ID 13557 Is Recorded When Duplicate NTDS Connection Objects Exist
? Active Directory 复制在域中的新域控制器和现有域控制器之间进行。

使用 Repadmin.exe 确认是否以计划的复制间隔在同一域中的源域控制器和目标域控制器之间进行 Active Directory 复制。同一站点中域控制器之间的默认复制间隔是 5 分钟，不同站点中域控制器之间的默认复制间隔是 3 个小时，最短是 15 分钟。
REPADMIN /SHOWREPS %UPSTREAMCOMPUTER%

REPADMIN /SHOWREPS %DOWNSTREAMCOMPUTER%
FRS 复制依赖 Active Directory 在域中的域控制器之间复制配置信息。如果您认为复制有问题，请在事件查看器中检查复制事件。在潜在源计算机 (\\M1) 和目标计算机 (\\M2) 上将以下注册表项中的“复制事件”项设置为 5，然后执行此操作：
HKEY_LOCAL_MACHINE\System\CCS\Services\NTDS\Diagnostics\
设置此项后，使用 Dssites.msc 中的立即复制

命令或 REPLMON 中的等效命令，从 \\M1 强制复制到 \\M2 并从 \\M2 强制复制到 \\M1。
? 用于寻找 Active Directory 和 SYSVOL 文件夹的源的服务器应该已经自已创建了 NETLOGON 和 SYSVOL 共享。

在 Dcpromo.exe 程序重新启动计算机后，FRS 首先会尝试从以下“副本集父服务器”注册表项中标识的计算机寻找 SYSVOL 共享的源：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\SysVol\域名
注意：此项是临时的，在找到 SYSVOL 的源后或者成功复制了 SYSVOL 下的信息后，会将其删除。

Ntfrs.exe 的 2195 发行版禁止从此初始源服务器进行复制。这会延迟 SYSVOL 复制，直到 FRS 可以尝试通过自动或手动 NTDS 连接对象从域中的入站复制伙伴进行复制。

通常，域中所有潜在的源域控制器已经共享了 NETLOGON 和 SYSVOL 共享，并且已经应用了默认域和域控制器策略。

SYSVOL 文件夹结构： ? domain ? DO_NOT_REMOVE_NtFrs_PreInstall_Directory
? Policies ? {GUID} ? Adm
? MACHINE
? USER

? {GUID} ? Adm
? MACHINE
? USER

? {etc.,}
? scripts
? staging
? staging areas
?
? scripts
? sysvol(sysvol share)
?
? DO_NOT_REMOVE_NtFrs_PreInstall_Directory
? Policies
? {GUID} ? Adm
? MACHINE
? USER

? {GUID} ? Adm
? MACHINE
? USER

? {etc.,}

? scripts(NETLOGON share)


? 必须在域控制器组织单位中的默认域控制器策略中将“从网络访问这台计算机”权限授予“企业域控制器”组。

在使用 Dcpromo.exe 程序的过程中执行的 Active Directory 复制会使用“Active Directory 安装向导”中提供的凭据。重新启动时，会在域控制器的计算机帐户的上下文中进行复制。域中的所有源域控制器都必须成功复制并应用将“从网络访问这台计算机”权限授予“企业域控制器”组的策略。要进行快速验证，请在潜在源域控制器的应用程序日志中查找事件 1704。要进行详细验证，请针对 Basicdc.inf 模板运行安全配置分析并检查日志输出。请注意，这需要为 SYSVOL、DSLOG 和 DSIT 定义环境变量。 有关如何完成此操作的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
250454 (/kb/250454/EN-US/) Error Returned Importing Security Template
在 Windows Server 2003 中，已经没有 Basicdc.inf 模板了。要重新应用默认设置或对当前设置与默认设置进行比较，请使用“安装 security.inf”模板。
? 每个域控制器都必须能够解析 (ping) 加入副本集的计算机的完全限定计算机名称。

对于 SYSVOL，这意味着对域中所有域控制器的完全限定计算机名执行 ping 操作。确认 ping 命令返回的地址与每个副本集伙伴控制台中的 IPCONFIG 返回的 IP 地址

一致。
? FRS 服务必须已经创建了 NTFRS jet 数据库。

针对域中的每个域控制器运行 DIR \\计算机名称\Admin$\NTFRS\Jet 命令，以确认 Ntfrs.jdb 文件是否存在。NTFRS 服务运行时，jet 数据库的数据和大小可能不正确。这种现象是设计所导致的。
? 每个域控制器都必须是 SYSVOL 副本集的成员。

在所有副本集成员上，运行 NTFRSUTL DS [计算机名称] 命令。确认域中的所有域控制器都显示在 NTFRSUTL 输出的“SET:DOMAIN SYSTEMVOLUME (SYSVOL SHARE)”部分下。在查看菜单下打开“高级功能”时，SYSVOL 副本集及其成员也可以显示在“用户和计算机 (Dsa.msc)”管理单元中的 cn="domain system volume",cn=file replication service,cn=system,dc=FQDN 下。
? 每个域控制器都必须是副本集的订户。
AD灾难恢复后sysvol无法共享问题
在所有副本集成员上，运行 NTFRSUTL DS [计算机名称] 命令。订户对象显示在 cn=domain system volume (SYSVOL share),cn=NTFRS Subscriptions,CN=DCNAME,OU=Domain Controllers,DC=FQDN 中。这要求计算机对象存在并且已经进行了复制。NTFRSUTL 可在缺少订户对象时生成以下消息：
SUBSCRIPTION:NTFRS SUBSCRIPTIONS DN :cn=ntfrs
subscriptions,cn=W2KPDC,ou=domain controllers,dc=d...Guid :
5c44b60b-8f01-48c6-8604c630a695dcdd
Working :f:\winnt\ntfrs
Actual Working:f:\winnt\ntfrs
WIN2K-PDC IS NOT A MEMBER OF A REPLICA SET!
? 必须打开“复制计划”。
? 承载 SYSVOL 共享和暂存文件夹的逻辑驱动器在上游伙伴和下游伙伴中具有大量可用磁盘空间。例如，空间是您尝试复制的内容的 50% 以及所复制的最大文件大小的三倍。
? 请检查新副本的目标文件夹和暂存文件夹（显示在“NTFRSUTL DS”中），以查看是否正在复制文件。暂存文件夹中的文件必须在被移向最终位置的进程中。暂存文件夹或目标文件夹中文件数量的不断变化，真是一个很有用的信号，我们可以由此了解到文件正在目标文件夹中进行复制，或者正在向目标文件夹转换。
也可以手动解决此问题，即将sysvol的共享权限加入everyone即可



如何限制可登录本机的域帐户
就像可登录域的所有帐户都存储在domain users组里面一样，所有可登录本地计算机的域帐户是保存在本地计算机的users组里面的，打开users的成员一看domain users这个组果然在里面。到此，终于明白为什么所有的域帐户都可以登录任意计算机了。

一般而言，域内一些比较重要的计算机是不想任何人都可以登录的，这样安全性就没有了保证。比如财务部门的计算机，只希望个别财务的帐户能登陆。所以要限制这点，只要把本地计算机users组里面的domain users给删除掉，加入希望登陆的域帐户即可起到限制的作用

-------------------------------------

--------------

11月22日，再次和别人讨论过这个问题后，很是失望，原来结果是这样的，我上面写那个办法只是在本机上的操作权限，也就是说domain users存在于本地的users组里面只是让域用户拥在本地有最低的操作权限而已

请问如何使域用户只能登陆自己的电脑，不能在其他人的电脑上登陆？limitlogon是否能够做到这个功能？感觉应该是一个很常用的功能，怎么就不能实现呢？回答：只有在用户账户属性中设置“登录到”。这个也只能一个一个账户的设置。limitlogon 那是限制一个账户只能登录一次，但不限制登录到哪台电脑上。嗯……那么通常来说，有四个方面来阐述这个问题：
其一，我想这可能是中西方一个文化背景的差异。微软在设计ad的架构的时候是用户的利益为中心的，也就是说无论任何时候要保障用户的应用不受到影响，如果将每个用户账户限制只能登录到哪台计算机，那么一但一批账户在规定的计算机上登录遇到问题的时候，用户短时间内就无法使用其他人的计算机进行工作了。
其二，通常同一个业务部门，具有相同的业务特性，该部门内的安全登录可以这样设置，让业务部门内的用户组可以在该部门内的所有计算机上登录。这样做，可以算是针对上面那种情况，在考虑安全性的前提下的一个折衷方案。
其三，在客户端本地不要保留关键性业务数据。从原则上来讲，企业是不会为用户的私人数据承担安全责任的，客户端仅是为业务运作提供的一个工具，所有的业务数据以及企业智能财产都应该得到集中保存和审核。如果管理员从it基础架构上做好了工作，那么就会发现对于同一业务部门的用户来说，没有必要限制的如此严格。当年，国外很多服务器和笔记本硬盘都很小，只分一个区，就是因为这样一个考虑。
其四，如果按照微软客户端的最佳安全实践来做，默认状态下，domain user是没有权限查看其他账户数据的。----- gnaw0725 您好！

根据我的研究，在组策略上是没有具体的设置可以禁止域帐号进行漫游登陆。如果您希望指定域用户只能登陆某台客户端的话，建议您执行以下操作：
1. 点击“开始－>运行”并输入“DSA.MSC” －>打开“Active Directory用户和计算机”。
2. 右键点击需要进行设置的用户－>“属性”－>“帐户”－>“登陆到”－>“下列计算机”。
3. 添加指定的计算机.


很多朋友在学习AD的时候都会遇到这样那样的问题，急于四处寻找解决问题的方法，其实很多的问题都是由于在安装操作时没有遵循规范而导致的，那么这个规范是什么呢？就是 Best Practices 最佳实践。又到哪里去找呢？在这里，Micro

soft Windows Server 2003 TechCenter。虽然目前windows 2003的文档仍然不如windows 2000的多，但较之后者更有系统性，可操作性，而且MS一直在持续完善这个文档库，所完成的部分请参看 New and Updated Collections。一方面，您可以系统的浏览这个文档库的架构，找到各自的最佳实践，另一方面，也可以使用 Best Practices 为关键字来搜索它们。朋友们不妨将这些最佳实践收藏起来，结合自己公司的现状形成自己的操作规范，再根据最佳实践中给出的一些checklist定制自己的表单，同时为日常的部署活动建制自己的文档库。那么无论对于规范系统操作，还是工作汇报，工作总结都能够得心应手！（毕竟Report是很关键的，不是吗：）OK，这个GPO的最佳实践基本覆盖了大家日常策略管理中的操作，给出了不错的建议。就用它为朋友们揭开这一页！组策略对象最佳实践不要执行未经设置的策略设定
? 如果GPO中包含有处于未设置状态的设置，您可以通过禁止用户设置或者计算机设置来避免它的执行。这可以加速那些 受此GPO影响的用户、计算机的登陆、启动过程。
（gnaw0725注：组策略中包含用户设置和计算机设置两个部分，即便您未作任何变动，受此策略影响的用户、计算机在登陆或者启动的时候，本地的组策略扩展仍然会查询所有条目，以确定它们的状态。如果禁止应用其中的一部分，明确告诉系统不要执行那些条目，将会大大降低查询的时间。可能一个GPO节约的时间微乎其微，但数目多了，或者处于慢速链路，就很可观了）
? 防止从站点，域，OU连接整个GPO
（gnaw0725注：同样，当从其他位置链接GPO的时候，尽可能的避免应用整个GPO，我们可以禁止GPO的用户或者计算机部分。如果这个链接是跨域的甚至跨site，那么在客户端启动、登陆的时候，这个查询过程时间可能很长）
? 如果您不再使用某些GPO，请删除它们。
（gnaw0725注：客户端在启动、登陆的时候会查询自己在AD层次架构中所处的位置，对所需应用的GPO形成列表，并依次套用。删除无用GPO无疑能够加快应用的过程。
BTW：一个来自MS的建议，除非必要，一个对象上套用的策略不要超过10个） 使用禁止策略继承和不覆盖，需要谨慎。
? 经常使用它们将会导致策略排错异常困难
（gnaw0725注：从win2k到win2k3，AD在设计到完善，始终保持了层级架构，GPO的层层套用也是基于这一架构，在以最精简为前提下，以默认始终继承上级策略的状态，形成了最终体系。尤其在没有GPMC的win2k的ad中，随意的中断继承，强制向下套用策略，大量使用GPO filter，在一个复杂的ad层级架构中，一旦出现问题进行错误排查，无疑是个灾

难。
BTW：在Fileserver中目录层级的权限设置，与这一点有些相似。）

不要对不同的GPO使用相同的名字
? 对不同的GPO使用相同的名字，不会造成功能性错误，但可能会导致混乱。
（gnaw0725注：在win2k 的ad中新建一个GPO的时候，名字总是一样的，在win2k3 的ad中系统会需要您另外给出一个名字。对于GPO的命名在日常管理规范中应该做出定义，一般最好能够遵循这样的原则：部门-功能-内容提示）
注意
? 如果GPO的命名查过255个字符，超出的部分将会被截断。
（gnaw0725注：按照上面的那个原则，一般来说255个英文字符，127个中文字符应该够用了。
BTW：ad中无论什么命名最好能够使用英文；DC的语言版本最好能够统一；如果使用工作站安装adminpak进行远程管理，最好能够对语言和gpedit的编辑器版本进行统一，比如win2k pro <-> win2k sever winxp pro<->win2k3 server，以避免GPO语言混乱或者发生版本支持性等问题）

最小化GPO使用WMI过滤的数目。
? 对GPO应用过多的WMI过滤将会导致执行时间变长。
（gnaw0725注：WMI过滤的实质就是执行VBS脚本，老实说，即便是win2k3 server sp1搭配winxp pro sp2的架构上，VBS执行效率也不高，特别是在计算机启动或者用户登录的时候。）

基于安全组成员关系过滤策略。
? 如果用户在被应用到的GPO上根本没有访问控制项，那么就可以避免相关的登陆延迟，因为用户根本没有执行那些GPO。
（gnaw0725注：这个就是所谓的GPO Filter了，关于它这里有个例子 。一个对象最终能够套用到策略，需要具备两个权限，一个是允许套用套用策略，一个是允许读取该GPO，Filter就是在这上面作手脚了。
BTW：上面我们提到，为了避免GPO Troubleshooting的问题，这个技巧还是少用 ：）
? 过滤仅能作用于安全组成员。
（gnaw0725注：显然发布组不是用来做这个的。关于过滤得描述请参看 Filter the scope of Group Policy according to security group membership）
/resources/documentation/windows/xp/all/proddocs/en-us/filter.mspx?mfr=true
/kb/322176
? 通过在GPO上查看属性对话框中的安全页，可以获取ACE的信息

只在必要的情况下，使用基于计算机的组策略覆盖用户策略。
? 只在不论谁登陆，都需要保持统一的桌面设置的情况下，使用基于计算机的组策略覆盖用户策略。这种机制就是策略环回，它是在某些特殊环境下应用的一种高级策略，例如实验室，教室等公共环境。同样在组策略编辑器中计算机策略管理模板中，您可以用户组策略环回处理模式。 详见：Order of processing settings
（gnaw0725注：使用策略环回，客户端组策略扩展要么只套用计算机

策略，要么就在套用完用户策略后，再次执行计算机策略，以便覆盖。
BTW：策略环回仅能作用于win2k纯环境，并且只有win2k以上客户端可以支持。）

使用组策略，而非系统策略
? 系统策略仅用户管理运行windows 2000之前系统的计算机，或者您需要管理独立计算机上的多个用户。
（gnaw0725注：许多从winnt过渡的管理员，都还保持之前惯例，习惯用工作组和系统策略pol来管理用户，这个状况在win2k以上版本的ad中需要得到改善）

避免跨域指派GPO Avoid assigning Group Policy objects across domains.
? 如果从其他域获取组策略，那么在启动和登陆过程中，应用GPO会比较慢。 不要在特殊的驱动器或者目录上使用文件系统策略，比如为NTFS文件复制系统（FRS）所同步的Sysvol。
? 在这些对象上使用文件系统策略，将导致不必要的复制，并且会消耗网络带宽。
（gnaw0725注：这里所说的文件系统策略，在计算机设定-windows设置-安全设置-文件系统，通常用于通过策略定制客户端特定路径上的权限设置。通常，我们在需要定制用户访问某个路径或者文件的时候，就能用到它了。这里有个例子） 不要将一个GPO多次应用于相同的OU
? 当针对同一OU的策略链接多次被应用于单一对象的时候，客户端组策略扩展可能会对这些连接做出不同的解


由工作组向域转型应该注意的
首先让我们来了解一下工作组，工作组模式是基于广播来通讯的，工作组中的每台计算机互为服务器，互为客户端。为了保持每台计算机都能够获得工作组中的资源共享列表，每当一台计算机启动或者连入网络或者产生新的共享资源，它都会向当前工作组中所有的计算机发送广播，宣告自己的身份、位置及共享资源等，这个宣告将遵循一定的规则进行选举，以最终确定主浏览服务器，获得该身份的计算机负责维护工作组中的浏览列表，并定期向其他计算机广播。这个规则通常是以OS的版本或者在工作组中担任的角色作为评判标准（关于主浏览服务可以参考 /default.aspx?scid=kb;zh-cn;188001）。但是大家都知道，广播在网络中不稳定的，这就可能导致工作组中的每台计算机所持有的浏览列表各不相同，在导致工作组中的计算机互相访问出现问题的同时（此类问题请参考 /default.aspx?scid=kb;zh-cn;318030），也会产生更多的广播，这可能导致工作组中的计算机加剧对于主浏览服务器的选举（这样类似的问题请参考 /default.aspx?scid=kb;zh-cn;143153），进而又加剧了这些问题的出现。

ActiveDirectory活动目录的出现解决了这个问题，由目录服务统一的维护和发

布域中的资源，这个资源列表可以使用LDAP进行方便快捷的查询，并可以结合DNS进行定位，这就可以让用户不再需要关心那些资源的物理位置，用户可以以一种逻辑的方式来搜集和整理自己所需要的资源。
相对于工作组那种不稳定的工作模式，ad对于网络管理来说是一个巨大的成功，那么作为管理员应该尽快的适应和使用新的管理模式，而对于工作组的网络邻居访问予以摒弃。

那么在ad中如何发布那些共享资源呢？MS为此推出了一系列的服务，比如printer server、file server sql server、dns server、wins server、ISA、SMS、WSS、EXG、SPS、WSUS 等等，而这些服务都可以一定的形式整合到ad中来，在services container中创建连接点，在与ad整合的dns中创建资源记录。那么下面针对您的描述，给出一些说明。您的这些问题，在很多小型网络环境中经常遇到，也是非常典型的。

Q:其中一台Winxp安装了双网卡，利用其中一只网卡连接ADSL拨号上网，另一只网卡连接局域网的交换机，此机安装Sygate服务共享上网，其他所有电脑都可以正常通过此电脑浏览Internet。
A:作为企业内部的安全关控，不建议让用户直接共享上网，应该实施Proxy Service，而MS对应的产品是ISA 2004，这个产品比较熟悉，功能也很强大。这个产品您可以浏览 /china/isaserver/

Q:每一台客户端都分别建立了一个具有本机超级管理员权限的用户，在服务器上添加了相应的只具有普通user权限的用户。
A:在域中，除非有特殊需求，都不应给予用户管理员权限。每个用户所使用的计算机在加入域后，可以使用域帐户登陆到域。通常，域用户在登陆到域后，可能会在软件使用上遇到问题，关于此问题，请参考 /logs/4888573.html。但对于企业中大规模部署软件及应用，应该使用SMS，关于这个服务请参考 /china/smserver/

Q:所有客户端和服务器都只安装了 norton antivirus 8.0 企业版病毒防火墙，全部都没有安装木马防火墙。
A:一旦将企业内部网络与外界隔离开，并对于网络出口实施管制，外界木马和病毒应该得到有效控制，而企业内部用户只需要部署一些小型的防病毒客户端即可，比如norton antivirus enterprise edition client。norton firewall在安全防范上比较严格，但这也妨碍了dc与client之间的有效通讯，在隔离病毒和木马的同时，往往也阻挡了dc的远程控制和策略分发，即便实施winxp firewall，也需要使用策略模板对其行为实施控制，否则，过于严格的防火墙可能切断ad的管理架构。在域中实施防火墙，应该谨慎。

Q:平时客户端登录的时候默认使用本机超级管理员用户登录到域

。
A:在计算机加入域后，那么无论是用户还是群组，安全主体通常会区分为两类，一是本地安全性主体，而是域安全性主体，而前者仅作用于本地。本地帐户是不能登陆到域的。之所以会出现使用本地帐户进行本地登陆后，不需要用户参与即可使用网域资源，通常是由于两者的用户名和密码相同。由于此时计算机或者用户并没有登陆到域，那么当前所建立的连接是基于工作组的NTLM验证，而不是域的Kerboers。同样，不应该给予用户管理员权限，这将会导致客户端和网域维护成本的上升。

Q:有时重新启动或注销一次后就可以重新打得开网上邻居里域的计算机列表窗口，有时候重启多少次都不行。
A:这个问题，就是由于工作组工作模式的弊端，原因在前面已经说明。

Q:一般在资源管理器的地址栏中输入“计算机名”不能连接到目标计算机的话，一般重启后就可以了，但域的计算机列表还是无法打开。
A:同上

Q:有时候在资源管理器的地址栏中输入“ip地址”打不开目标计算机，出现“ip地址 无法访问。您可能没有权限使用网络资源。请与这台服务器的管理员联系以查明您是否有访问权限。目前没有可用的登录服务器处理登录请求。”
A:同上※出现上面“......没有可用的登录服务器处理登录请求”这一错误的时候一般重启服务器就可以消除这个错误同上，如果在域中正确部署了那些服务，并正确的予以登陆、验证，仍旧产生这些问题，那么则可能是由于诸如dns、dns suffix或者是网络参数设置错误以及相关的网络服务尚未可用所致，关于这样的问题debug，请参考 /logs/2005/04/4888511.html
后话：还有一些从Winnt过渡的朋友，或者习惯于工作组管理的朋友们，也会经常的问到这些问题：
1、如何在ad的网上邻居中，想工作组一样，将那些计算机按组分类放置呢？ad的网上邻居看起来乱糟糟的 。
如同前面我们所讲到的，ad已经脱离了物理的管理模式，取而代之的是逻辑的更为便捷的管理模式，故而对于物理的管理模式予以摒弃。在ad中通过将计算机、用户帐户放置于不同OU及群组中并实施策略，进而将网域中的资源自动分发给用户，用户无需再关心那些资源的物理位置，甚至可以象使用本地资源一样使用它们。而另一方面，管理员可以LDAP查询、DNS资源记录更为方便快捷的管理网域中的资源，而这种定位方式，用户只需简单的演示就可以让自己的工作更为高效。通过这些体验，无论是管理员还是用户，都会感觉到，ad比工作组要好看、好用的多了。关于客户端使用LDAP and DNS定位，请参考 /logs/4888504.html

2、用户怎样才能共享和搜索共享资源呢？比如共享文件夹、共享打印机？进入ad的管理模式之后，管理员应该真正改变自己的管理模式，以有限的资源提供高效而安全的服务，从而有效的改善用户体验。管理员不应该再高高凌驾于用户之上，而让用户百般等待，当您真的做到这一点的时候，会发现用户有多么的感激，在您向财务部门申请资金的时候，也会减少很多阻力，当然年终绩效考核的时候，自然会为您添上浓重的一笔。
那么作为管理员为什么不把这些共享资源送到用户手边，而让他们自己费时费力的去搜索呢？其实用户也不愿意这么作。我们该如何作呢？通过架设FileServer 和PrintServer，就可以将网域中数据和打印机集中共享出来，然后通过用户登陆脚本直接将这些资源分发给用户，当用户登录后，就会发现这些资源已经可以使用了，真是方便。通过集中共享，一方面能够减少硬件资源，降低成本，另一方面可以为这些共享资源提供管控和审核机制，之前在工作组中随意共享的病毒问题、资料数据泄漏问题、成本核算问题、使用记录问题等等都迎刃而解了。
同时还可以利用MSCS、NLB来提高这些共享资源的高可用性，让用户进一步体验到IT部门的优质服务。
关于FileServer架设过程中创建目录及共享的原则，可以参考 /logs/4888506.html
关于启用审核机制及安全机制 ，可以参考 /china/technet/security/guidance/secmod144.mspx，/default.aspx?scid=kb;zh-cn;315416，/kb/301640/zh-cn ，或者采用一些第三方的审核程序 。
关于架构MSCS、NLB，可以参考 /china/technet/prodtechnol/windowsserver2003/technologies/clustering/newclust.mspx
关于发布share folder and share printer，可以参考
/default.aspx?scid=kb;zh-cn;234270，/default.aspx?scid=kb;zh-cn;234619，
/forum/itemdisplay.asp?boardid=6&rootid=341773&id=341773，
/logs/4888704.html
3、客户端的应用及服务无法运作了，用户为之抱怨。
进入ad管理模式之后，用户登陆到域所使用的是domain user帐户，这个帐户在客户端计算机本地的权限基本等同于users受限用户。那么之前用户在管理员权限下所运行的一些应用及服务可能无法正常启动，但您会发现如果客户端的磁盘分区格式如果是FAT32就没有问题。很好，您注意到了一个解决问题的切入点。应用和服务在管理员环境下能够运行，而受限用户无法运作，大多有两种，一是权限，二是策略。另外一些是由于应用和服务自身的设置，例如或者一

些第三方的程序。通过查看是否是NTFS，通过执行GPresult，我们就可以很好的切入这个问题。那么通常权限有两种，一是安装目录，二是注册表键、值，三是服务的启动帐户。前者可以在相应的目录上编辑ACL，二者可以通过执行regedt32来编辑注册表键、值的ACL，而后者可以通过诸如services.mscdcomcnfg等修改用户或者用户组来达到目的。通过这些修正，往往可以使这些应用及服务得以运行。具体的操作方式，可以参考。但这些手动调试的方式方法，仅限于个案，大规模的部署，还需要架构SMS或者相应的服务。关于SMS，请参考 /china/smserver/

gnaw0725注：通常，无论是ITPro还是Programmer，把握一个排查问题的分水岭或者说切入点是很重要的，这也是在工作中所要用心去不断体会积累的。朋友们经常会发现面临一个问题无所适从，或者解决起来事倍功半，那么就是没有把握好这个切入点。比如通过了解问题发生在所有的工作站上还是某些个别的工作站上，往往能够迅速判断问题到底是出在一些服务性的资源上还是仅是一些个案；比如通过查看用户端是否应用了服务端的控制措施，能够判断到底是控制措施出了故障，还是客户端的问题；比如通过查看运行环境是否是NTFS，就能够判断问题是否是因为权限；等等诸如此类。那么如果这个问题之前未曾遇到过，该如何做呢？通过了解整个运作环节和机制，来对整个流程分段排查，如果不能断定某个环节是否正常，那么我们不妨架设这个环节是没有问题的，而对其他环节进行排查，往往在对其他环节的排查过程中，我们能够印证或者推断前面的环节。但尝试一定要有策略性和针对性，否则只能是费时费工而又毫无意义的。
更多活动目录及网络管理文章请看 /c1404552/
编后：
AD的管理模式，就是让用户不再关心资源的物理位置，尽可能减少客户端之间c2c的传递模式，而转向客户端与服务器之间c2s的通讯模式，那么一方面让数据、应用、服务脱离客户端，另一方面将工作重点转移到管理这些Server及其中的共享资源中来，这无论从灵活的拓展网络架构，还是降低维护成本，或者提高资源及数据安全性、可用性，提高客户满意度，或者提升商业软件及管理人员自身价值等等来说都是至关重要的。这种模式不仅在MS的架构平台上适用，也适用于其他厂商的基础架构，同样也通行于其他行业。但这个模式的实施与方式需要一个过程，同时这个模式也并不能替代P2P所具有的价值。
诚然一个新的事物推出，需要考虑到向前兼容性，需要考虑用户投入使用的成本。但一些基本架构性

的变化，对于这些问题 就无法避免了。故而向域管理模式转型过程中必然会遇到各种问题，而面对这些问题就需要作为管理员的我们，需要积极的去思考、求证，通过把握一些规律性的东西，通过了解MS产品架构体系（关于MS产品体系的把握，可以参考郭安定的Webcast /china/technet/webcasts/ondemand/episode.aspx?newsID=msft092104vx），来达到快速掌握MS产品特性的目的，从而让自己得以提升。在掌握原理并得以成功部署之后，您会发现成倍的提升工作效率是完全可行的。
关于这个转型过程中所遇到的一些典型问题，一时只想到这些，如果朋友们有其他一些代表性的问题，欢迎提出来，我再作些适当补充。同时建议同时建议大家，多关注Technet，多参加Webcast，比如之前的从管理和运营的角度看IT 系列，对于开拓管理员的视野，以及提升管理员价值，提升服务品质，提升用户体验都很有助力。在Webcast之后提交反馈调查表时，大家可以将自己感兴趣的产品以及了解MS产品的方式勾选上，MS相当注重您的选择，Technet将会适时的以各种形式将您所关注的资料送到您的手中。记得之前Technet发出的关于构建安全机制和构建企业IT基础架构等小册子都很不错。