可能碰到过这样的问题：把Novell网的NetWare迁移到 2000这项非常艰巨的任务。在你的Novell目录服务（NDS）树下，可能有成百上千的用户，所以用手工的方式重新创建这些账号是不可能的。你需要一个解决方案，但是管理部门却不允许购买第三方的移植工具。提出这个难题后，我将对微软提供的同步工具MSDSS做简要介绍，解释它是如何工作的，然后描述一下我在一个从NetWare到迁移工程中取得的教训。
MSDSS及其工作原理 MSDSS是微软目录同步服务（Microsoft Directory Synchronization Services）的首字母缩写，是微软开发的NetWare服务（Services for NetWare，SFN）v5.0工具包中的一部分。SFN中另一个主要的组件是NetWare的文件和打印服务（FPNW），通过它，Windows 2000就可以从本质上来模仿一个NetWare。MSDSS确实是能如其名：实现同步目录。它完成Novell网的NetWare目录服务（NetWare Directory Services，NDS）和微软的活动目录（Active Directory，AD）之间的用户、组、容器对象之间的同步。
MSDSS在AD和NDS之间是通过轻量级目录访问（Lightweight Directory Access Protocol，LDAP）来实现通信的。创建的会话能实现AD中容器与NDS中容器间的映射。一个原始的逆同步发生时，可以把整个NDS树读出来，并把NDS中的用户、组及组织单元（OU）对象拷贝到AD中。不过，NDS中的打印机、应用程序和其它对象并不会获得同步。如果有计划进行长期的从NDS到AD的迁移或者两者共存，那么就应该确定时间表，来完成从NDS到AD的逆同步，或者正同步，或者两者都进行。
完全迁移VS长期迁移或共存 完全迁移非常简单。最初的逆同步是这类工程中最主要的任务，不过文件和打印服务、客户端配置以及其它问题这类工程中也有不少的份量。MSDSS能很好地实现这些无缝迁移。
对于长期迁移或者共存的情况，你不得不做更多的更仔细的计划。你必须仔细考虑诸如如何做好从AD、NDS或者两者共存时进一步的管理，考虑口令修改和同步这类的问题。
同步方式：单向VS双向 一旦最初的迁移同步完成了，那么对象就会在两个目录中同时存在，你必须先决定将在哪个目录下进行同步。一个逆同步将从NDS中读取所有的对象，过滤掉那些没有更改的对象，把更改过的对象写到AD中。正同步则更有效，它仅从AD中读取那些更改过的对象，然后把那些经过更改的对象的属性写回NDS。
虽然正同步更有效，可以同步口令（见下节），但正同步中仍然会出现逆同步的现象或者双向同步的现象。让我们看看三种情况下使用何种同步方式最合适。
公司A是主要使用Novell，而且计划依然使用Novell。创建了一个Windows 2000域，来集中管理一个终端服务器的账号。也没有计划迁移到Windows 2000，Novell仍做为基本的网络操作系统（NOS）。在这种情况下，逆同步将是最好的选择。所有的资源管理将由NetWare的管理器或者其它NetWare工具来完成。所有在微软管理控制台（MMC）下做的修改都不会同步到NDS中。
公司B计划做一个完整的迁移，迁移到Windows 2000，还要求管理员使用MMC来完成管理。这种情况下，正同步是最好的选择。NetWare管理员所做的任何改变都不会被同步到AD中。所有的管理工作在MMC下完成，还能使用正迁移这种最有效的同步方式。
公司C想实现一个长期的、两种网络共存的方案。Novell的ZENworks用来实现应用程序配置，微软的Exchange 2000完成邮箱的配置。管理员管理时需要对NetWare的管理器和MMC同时进行访问。在这种情况下，双向同步是必须的，需要把任何一方目录的改变同步到另一方。
口令同步 当创建了一个同步会话之后，有四种方式来为AD中的用户设置口令：
设置空口令。
设置与用户名相同的口令。
以随机数做为口令（口令要存贮在一个文件中，以免出现错误）。
为所有的口令设置一个静态值。
如果是从NDS向AD迁移，那么你就应该记住AD中口令的一些要素：AD并不能从NDS中读得口令的值。如果一个用户或者管理员在NDS中改变了账号的口令，该口令不会在迁移中同步。
不过AD可以设置NDS中口令的值。当同步发生时，NDS查看口令是否有改变，并且不论是用户还是管理员修改的，都统统认为是管理员修改。在NDS中，当一个口令被管理员修改后，系统将自动终止该账号。
因为以上所列举前两种情况，所以唯一的同步口令成功的方法就是在AD中修改所有的口令，并且关闭掉NDS中口令终止账号的功能。
口令的改变需要过一段时间才能生效，因为你必须等同步发生，使得两个目录中的口令相同才可以有效。微软开发了一个基于Web方式的口令设置工具，可以绕过同步的等待时间，但只有管理员才能使用。
从最近的一个工程中得到的体会 我的一个客户（就叫它XYZ吧）有一个相当大的网，由一个网络中心、大约1500个用户/工作站，分布在50个远程站点。最基本的网络操作系统是Novell的NetWare 5.0/4.11，还有一小部分是Citrix的Windows NT域。此项工程的目标就是创建一个新的Windows 2000的AD结构，与NDS的树同步。因为NetWare还要继续存在（至少在很长的一段时期内），所以长期的共存方式是需要的。
因为Windows 2000的域要求账号名必须是单一的，所以我首要的任务是从NDS结构中删除那些重复的账号。顺便说一下，MSDSS处理重复的账号的方法是在原来的账号后添加数字；例如NDS中重复的账号JSmith，在AD中就成为了JSmith、JSmith1、JSmith2等等。一旦这一步完成，就需要为新的域建立域控制器。按照微软的要求，MSDSS应该以Novell的客户方式安装在域控制器下。
接下来，就开始创建同步会话。这是一个基本的、比较简单的域，所以我可以花上一些时间，找到最好的方法来完成这次同步。在这段时间内最大的体会就是我需要首先同步目录树中的最高层。还有，如果创建了多个会话（例如每个主原始单元一个会话），那么交叉原始单元中任何组的成员资格或者许可都不能保存起来。
我们以XYZ公司为例，做个介绍。在NDS结构中，XYZ公司是基本组织，NE、CO和IA都是组织单元。现在，假设我们为每个组织单元创建一个会话，假设用户JSmith是在CO单元，并且是IA单元中应用程序X组的一个成员。经过对所有会话进行逆同步后，用户JSmith在AD适当的单元中，应用程序X组也在AD中适当的单元中，但是JSmith不再是该组的一个成员了。更进一步，如果接下来进行正同步，这个变化就会写回到NDS中。这就是问题。在此，我要提醒大家，创建一个会话，用来在AD域和NDS组织中实现映射就够了。
大约在双向同步会话建立后的一个月，很多事情运行正常，但也有奇怪的事情发生。在CO组织单元下的所有用户对象突然回到了一个月之前的设置状态，组的成员资格、口令改变等等都丢失了。我立即关闭掉了同步，以免正同步把NDS下的账号也删除掉。接下来的好几天，我打电话联系微软的产品支持服务，询问此事，但是没有结果。
后来我发现问题出在NDS上。接下来的一个月中，出现MSDSS不再是图形化的问题，同样也是因为NDS出现了问题；所有在NDS上的对象回复到它们一个月之前的状态。这表明不同版本的DS.NLM之间产生了冲突，很明显，由于这个故障，使得NDS在试图同步其它目录服务时不能够很好地工作。
在这个工程中得到的另一个比较大的教训是，在两个目录之间没有办法手工进行单个的对象映射。那时我对问题的描述是这样的：在NDS中，由于进行了太多的修改，使得该目录回复了该同步会话。创建一个新的会话就允许再次创建大量的新用户。一旦系统崩溃，就没有好的办法来修复。
用MSDSS值吗？ 总而言之，我认为MSDSS比微软以前的目录同步工具要好的多。我可以明确地推荐该产品也可以是短期迁移策略的上好选择。不过，MSDSS也有它的不足，这就缺乏用户自定义的操作方式，还有就是不能对系统崩溃造成的破坏进行修复，这使得该工具不适合于长期的迁移或者共存方式。有关MSDSS更多的信息，可以到微软的MSDSS主页去查看。
【责编:admin】
--------------------next---------------------
