实验环境使用VMW虚拟机,客户端为WindowsXPSP2,服务器端为WindowsServer2003SP2企业版。首先将服务器端安装好活动目录,无需任何设置,默认安装即可,并将客户端加入到域。下面开始具体操作1、首先在服务器端用ActiveDirectory用户和计算机管理工具建立一个User,我这里以“小五”为用户名,如下图2、在服务器端建立保存用户配置文件的共享文件夹,本文在c盘建立了一个user文件夹,用来保存所有用户配置文件,然后再user文件夹下建立一个“小五”文件夹,用来保存“小五”用户的配置文件。这里面一定要注意权限的设置,在共享文件夹中的权限去掉everyone,然后找到我们域中的用户“小五”,给他所有权限。3、进一步权限设置,如图这样权限方面问题已经设置完成4、在ActiveDirectory用户和计算机管理工具中为“小五”用户设置用户配置文件漫游,如图192.168.1.201为我们的服务器,后面所接的“user/小五”为保存用户配置文件的共享文件夹主文件夹相当于用户的“我的文档”,这里面映射到服务器上,更能保证用户文件安全性与可靠性。现在配置基本完成,我们从客户端登录一下试试看初次登陆之后,我们注销,这样,本地的配置文件,就会自动保存到服务器上对应的文件夹。回到服务器上我们会看到生成好多文件,刚才这里面还是空的这些文件就是我们注销的时候下面提示正在保存配置文件的时候,其实就是把文件写入我们服务器里面了。我们再次重新登陆一下打开我的电脑会发现多了一个磁盘映射这就是我们专门为此用户设计的一个共享文件夹,用户可以把重要的数据等存放在这里,其实就是存放在服务器上,相对来说就更加安全了。至此,漫游用户配置文件就配置完毕了。小提示:如果配置过程中出现一些问题,那么多数是权限设置问题。这时候需要检查一下权限即可。其他方面一般很少出现问题。另外,如果,服务器上共享的文件夹只给予只读权限,那么,用户配置文件所有内容在下次登录的时候都会失效,像还原卡一样。因为,在注销时向服务器更新配置文件的时候是没有权限的,而下次登录的时候再次向服务器请求配置文件,自然而然就是旧的了,而不是最新的。网络环境:网络结构采用VLAN划分部门,服务器单独一个VLAN,通过在核心交换机上配置路由和ACL实现各部门之间不可互访,通过访问服务器进行数据交换。服务器是Win2003企业版,不记得用什么光盘装的了,反正网上下的,装完后打过SP2补丁,安装的Win2000域控制器模式(有Win2000的服务器)。域名:XXX.local主域控制器:192.168.0.6/24192.168.0.254/24(双网卡)这个网段只有网管部门可访问,本来是调试用的,还没有正式迁移到服务器网段,不过可以和服务器网段建立通信。额外域控制器:192.168.2.254/24服务器网段DNS:192.168.2.254DHCP:192.168.2.254已经通过交换机的UDPHelp把各个VLAN的DHCP网段都做好了,只配置了IP、网关、DNS。局域网计算机有Win2kPro和WinXPPro,W2k是用自己封装的ghost批量安装的,xp是用的YlmF_GhostXP_SP3_Y1.0,当然都是会随机产生SID啦,全部采用自动获取IP地址,安装后默认设置不变,XP自带防火墙开启,配置如图1。(图1)在客户端可以Ping通服务器IP地址以及binhu.local。总之网络层的互联互通是OK的,下面的问题全都不是由网络配置问题造成的,如果您确定您的网络配置都正确,并且网络结构和我大致相同或比我的还简单,可以继续往下看.问题1:新计算机在添加到域的过程中,按提示输入了域帐户和密码后,系统提示“找不到网络路径”。答:启动计算机的“TCP/IPNetBIOSHelper”服务。很不幸,我做的w2k镜像和ylmf的xp镜像刚好都把该服务设为了手动。问题2:加入到域的计算机,无法在域控制器上打开“计算机管理”。答:刚把计算机test加入到域,我就迫不及待的登陆到域控制器,想通过AD控制台远程打开该计算机的“计算机管理”,结果又弹出提示“找不到\\test.XXX.local的网络路径”。尝试在域控制器上ping了一下test.XXX.local,居然提示“Pingrequestcouldnotfindhosttest.XXX.local.”,域名解析失败!赶紧检查DNS记录,发现test.XXX.local主机记录安然的躺在正向搜索区域中,看来不是DNS服务器的问题。猛然想起本地DNS缓存,赶紧关闭“DNSClient”服务,再次尝试问题解决。原来即使是在DNS服务器上进行域名解析,也不是直接查找的DNS数据库啊!总结经验:在局域网部署过程中,网络节点变化比较频繁,建议关掉网络计算机上的本地DNS缓存服务,待局域网正常运作之后,网络节点变化较少,再根据DNS服务器响应DNS请求的负荷来考虑是否有必要打开该服务。问题3:加入到域的计算机,在域控制器上打开“计算机管理”,部分项无法管理。答:打开“计算机管理”后,发现“本地用户和组”打,除了可以查看“共享文件夹”下的内容外,其它项目都不能正常查看。在经历了上面2道磨难后,又遇到这种问题,是不是倍受打击呢?其实对于稍微“马虎”一点的管理员,一般都不会碰到这个问题。无奈我配置域管理的目的是为了便于分发安全策略,不得不“精细化管理”,从组策略到服务到共享到防火墙统统折腾了一遍......还是很有收获的!在无数次的“gpupdate”之后,摸索到一些既不影响“计算机管理”,又能一定程度提高安全性的方法。(1)共享:有IPC$即可,其它默认共享都可以关掉。(2)网络组件:必须安装“Microsoft网络文件和打印机共享”,且必须打钩。(3)内置防火墙:需要允许“文件和打印机共享”,且不限制135、137、138、139、445等端口的监听。(当然您可以用更强大的防火墙进行数据筛选,看个人功力了:)(4)服务:需要启动“Server”、“TCP/IPNetBIOSHelper”、“RemoteRegistry”服务。(5)组策略:为了增强网络访问安全性,我在安全选项中启用了“不允许SAM帐户的匿名枚举”、“不允许SAM帐户和共享的匿名枚举”、“限制对命名管道和共享的匿名访问”等三个选项,事实证明不会影响到“计算机管理”。由于进行了(1)~(4)项配置,只有以其它方式来禁止共享文件夹了。我在“用户权限分配”中将“从网络访问此计算机”设为仅有“DomainAdmins”组,又把“拒绝从网络访问此计算机”设为“DomainUsers、Users、PowerUsers、Guests”,不能从域控制器远程打开“计算机管理”了。经过分析,是由于我登陆到域控制器的管理员帐户默认也是“DomainUsers”组的成员,将它拿出来,再试还是不行,直到我把Users组从“拒绝从网络访问此计算机”选项中拿出来以后,又可以正常打开了。原因可能是:1.该管理员帐户同时也是Users组成员,在升级为域控制器之后,没办法从Users组中拿出来了,我没有进一步尝试;2.域管理员帐户通过网络访问客户机,会被自动应用到Users组成员中,纯属猜测,没有详细查资料。总而言之,只好放任Users组成员不管了,好在我禁用了客户机的本地帐户,只能登陆到域,变成DomainUsers就归我管了,嘿嘿,基本解决了禁止文件夹共享的问题了吧,现在即使是在客户机设置了EveryOne完全访问的共享文件夹,普通用户也拒绝访问。当然你也可以完全不理会是否打得开“计算机管理”,那就得自己测试一下是否能正确分发组策略了。问题4:DomainUsers无法运行AutoCADR14等软件的问题。答:说到域环境下部署应用程序的问题,这涉及到企业软件管理制度、计算机管理制度等方面,可谈的话题十分宽泛,这里仅从不控制软件使用的角度上讲一讲在域环境下部署应用程序的一些思路。(1)在FAT32目录下安装的软件、绿色软件等等,很多是可以不用部署直接运行的。(不到万不得已不推荐用FAT32)(2)在组策略上启用“软件限制策略”,按默认即可,大部分软件马上能够正常运行。(3)按(2)设置后,对于Autocadr14这样的老软件,不妨试一试新版本,Autocad2006就可以正常运行,经我测试的Matlab6.5、Protel99se、SolidWorks2006等都可以正常运行。(4)还不能运行的软件,用组策略的“软件安装”功能,先把软件制作成MSI安装包,再放到共享点,再配置组策略。制作MSI包的工具在Win2003的安装光盘上有。(5)软件不能正常运行的原因无非是注册表、文件的访问权限不够,可以以管理员模式来启动软件,同时用FileMon&RegMon等工具来监视其访问了哪些注册表项和文件,然后在组策略的“注册表”和“文件系统”中一一配置权限即可。一般能够正常启动的软件,基本上也都能正常运行了。