之前看到DFS文件系统的博客，就想自己也在虚拟机里实践下。下面是我实验的过程，错误很多，但是很想原本的写下来。以后看看也是一次重新的学习啊。

实验目的：dfs文件系统的容错功能：一台服务器down机后，里面的共享文件夹依旧可以提供DFs文件系统来访问。

第一次实验：
环境：两台windows 2003 server 标准版 一台xp sp3
 server1:域控制器 DNS
 server2：DFS文件系统
 guest：xp sp3

因为是想做在域环境下的DFS所以首先在server1上安装上了域控制器，在安装域控制器的时候要求一个DNS服务器，选择了在该台计算机上安装DNS并且设置主要DNS。域控制器很顺利的安装好了之后。把另外一台server2和guest都加入到域。

2.在server 2上管理工具---分布式文件系统。在上面建立一个根：san.local\public。在这个根下面新建里两个链接：san.local\public\server1（这是server1上的共享）和san.local\public\server2（这是server2上的共享）。在xp上输入：san.local\public可以看到这两个共享文件夹和里面的文件。继续下一步为每一个链接都建立了链接的目标，并且进行复制。在server2上建立一个空的共享文件夹作为server1的链接目标。在server1上建立了server2的链接目标。但是建立的时候需要选择主从服务器，但是自己不注意，都默认下一步了。似乎都是server1成了主，server2成了从。然后再guest上访问，两个共享文件夹都是空的。在server1上只能看到server1上有文件，server2上只能看到server2上的文件夹。当时很纠结，但是在共享SERver1上的共享文件夹会复制到server2上，只是之前的看不到了。

3。在网上查了些资料，做DFS文件系统需要R2版本的支持，需要第2张光盘。
这次安装了2003 server 企业版 R2.

环境：2台 2003 server R2 企业版 一个xp
server1：域控制器 DNS 
server2：DFS文件系统

还是一样安装域控制器，一样的把DNS和域控制器安装在一台服务器上了，server1 升级了R2.server2也升级到了R2，在添加组件中安装了DFS管理工具。打开DFS管理工具：添加了一个命名空间：san.local\public 服务器选择在server2.在命名空间里面添加了两个文件夹，两个文件夹都作了复制关系，。
这时候在xp上访问san.local\public 看打了两个共享文件。这时看两台server上的文件夹，也分别复制了对方的内了，一个复制组的内容完全相同。这时我想测试了效果，如果server1这时候down机了，xp还能否访问server1上的共享文件。于是把server1关机了，输入：san.local\public 这时候提示无权访问了。仔细想想确实，域控制器都down了，san.local就无法工作了，自然不能访问了。

4。我把server2也安装了域控制器：
既然是域控制器down了，那为什么不把server2也升级到域控制器呢？于是输入dcpromo命令。运行安装向导，选择域中的额外控制器，作为第2台控制器，在第一台域控制器down了之后，域还可以继续使用。第2台域控制器会直接从第一台域控制器复制数据文件，大概10分钟就可以了。
我再次把server1关机了，重新验证，很遗憾依旧无法访问。为什么？因为server1down机之后，DNS服务器也没有，没有服务器来解析域名：san.local。这样额外的域控制器就成了摆设。

5.我在用第三台server 2003 R2搭建了DNS。
我想既然没有DNS，不如在装一个，在server3上安装DNS之后，创建了主要区域san.loca。这时候DNS上有3条记录，这时候ping san.local 解析的ip：192.168.52.4 这是server3上的IP，可以添加主机记录，但是不能把san.local解析到192.168.52.3或者192.168.52.136（这两个是域控制器server1和server2的IP）.仔细看看原来的DNS和现在的DNS记录少了太多了，这些记录不是很明白什么意思。
我想是不是可以从server1上复制DNS记录呢？在属性里面看到有区域复制的选项，点击了复制，但是不成功，只能作罢。看来这样直接添加是不行的，只能先把域控制器在安装一次了。

6.我对server1做了备份，然后把server1做了降级处理。
首先先备份：命令ntbackup，运行备份向导，备份好需要的内容。然后运行dcpromo命令，删除域控制器。重启之后，这台计算机成了一台普通的域成员。域的备份只能运行在域控制器上，所以在server1上重新升级域。首先把DNS指向192.168.52.4这样在安装好之后就会在DNS上添加相应的记录。在升级域的时候我把域名依旧设为：san.local。但是装好之后发现这个san.local与原来的san.local根本不是一回事。域有两种恢复方式：1.目录恢复 2.把新的域控制器直接与原来的第2台域控制器复制，这样可以理解为server2上安装域控制器的情况。但是现在似乎明显不可能，因为这时候DNS没有相应的记录，san.local是解析不正确的，所以无法复制。所以我先升级了域控制器，安装常规的安装好之后域控制器。这时候DNS服务器上有了相应的记录，ping san.local返回的ip：192.168.52.3.正确。
恢复的时候选择目录还原模式，开机时安F8进入。首先恢复文件，用备份向导还原文件，然后进行授权，命令：ntdsutil命令 在输入：authoritative restore   restore database 。还原之后正常启动。
这时候的域控制器就和原来的数据一样了。我在user添加一个用户Test01 然后再server2 上AD用户和计算机上刷新，就可以看到test01这个用户。这时候AD的还原完成了。能够正常工作了。DNS也可以正确的将san.local解析到192.168.52.3

7：这样主控和DNS确实是分离开来了，但是在server1down机的情况下，DNS怎么把san.local解析到192.168.52.136呢？
情况确实是这样的，虽然6之后DNS可以解析san.local但是只限于一个IP。也就是说这时候server1不工作，域和DFS都是不能工作的。
这一次不需要备份，直接降级server2.降级  重启，在升级。升级的时候依旧选择林中的额外域控制器。升级好了之后。在刷新DNS记录就发现有了相应的记录了。
这时候ping san.local 解析的是192.168.52.3.这样有错吗？没错DNS总是记录最后一个正常工作的服务器的。因为之前解析到192.168.52.3是正常的，之后他就优先解析到这个IP。当这个ping 192.168.52.3不成功时候，才会把san.lcaol解析成192.168.52.136.

这时候把server1关机：ping san.local  结果是：192.168.52.3无法到达。
在ping一次 法相就解析到了192.168.52.136.额外域控制器正常工作。这时候在san.local\public 发现可疑成功访问server1上的共享文件，其实server1上的共享文件早就复制到了server2上了。

8.到这样实验就成功了。做了这么多是有点多余啊，如果直接把DFS部署在server1上，关掉server2.看能否访问server2上的文件内容也是可以认证了。但是这样做了之后就知道：DC和DNS最后不要部署在一台服务器上，这样做了之后，以后额外域控制器就成了摆设。也学习了域控制器的备份恢复这也是很有必要的。DNS服务器自己也自信看了看，一起装上了就好了，顶多在里面添加主机记录。
在搭建服务器的时候一定要有个清晰的拓扑图吧。如果我当初想清楚点也不会做这样工作了。切记切记。
这也如果是server2服务器down机之后，san.local\public也就不能正常访问了。能有什么办法？

这次写的只是自己实验的一个思路过程，没有截图记录。