本章描述在安装和配置 Calendar Server 6.3 软件后,可用于迁移日历数据库和 LDAP 数据库的各种数据库迁移实用程序。
本章包括以下各节:
如果要从 Calendar Server 6.0、6.1 或 6.2 版本执行迁移,可运行3.3 csmigrate 实用程序。如果未在之前的部署中对周期事件和任务运行 cs5migrate,则必须在运行 csmigrate 前先在现有的日历数据库上运行 cs5migrate。
如果要从 Calendar Server 5.1.1 执行迁移,可使用3.2 选择正确的 Calendar Server 实用程序中介绍的迁移实用程序来迁移日历数据库和 LDAP 数据库。
如果安装了更早版本的 Calendar Server,则需联系技术支持以获取数据迁移帮助。
本节介绍每一种迁移实用程序。仅使用需要的迁移实用程序,具体取决于之前所安装的 Calendar Server 版本。这些实用程序位于 sbin 目录中。
如果已对数据库运行了 cs5migrate 实用程序,但未使用 -r 选项,则必须在运行任何其他实用程序前再次使用 -r 选项来运行该实用程序。
迁移实用程序如下:
为 Calendar Server 6 数据库中的每个日历指定一个所有者,并将每个日历 ID (calid) 映射到一个所有者(如果需要),这可以支持多域和 LDAP 日历查找数据库 (Calendar Lookup Database, CLD) 插件。
在 cs5migrate 之后和 csvdmig 之前运行该实用程序。
将 Calendar Server 6 站点升级为使用多域,方法是将日历的域 (@域名)添加到每个 calid 中。例如,在域 sesta.com 中,jdoe 的 calid 现在将是 jdoe@sesta.com。此实用程序打包在 Calendar Server 中。
在 csmig 之后和 cs5migrate 之前运行此实用程序。
将日历数据库的格式从 Calendar Server 版本 5 迁移到版本 6.2。必须对数据库运行此实用程序,并指定 -r 选项。如果在此之前已从 Calendar Server 版本 5.1.1 迁移到版本 6.2,但未运行带有 -r 选项的 cs5migrate 实用程序,则必须在运行 csmigrate 实用程序前先运行具有该选项的此实用程序。
在 csmig 及 csvdmig 之后和 csmigrate 之前运行此实用程序。
迁移日历数据库以从 Calendar Server 版本 6.0、6.1 或 6.2 升级到 Calendar Server 版本 6.3。如果需要运行带有 -r 选项的 cs5migrate,则需先运行它再运行此实用程序。
将 LDAP 数据从 Schema 版本 1 迁移到 Schema 版本 2,以为用于 Access Manager(在传统模式下)而做好准备。
本节有助于确定需运行哪些实用程序来使所有日历数据库和 LDAP 数据库都处于 Calendar Server 6.3 软件级别。
使用下表来查找要运行的正确实用程序集合:
以给定的顺序运行实用程序。
迁移前的 Calendar Server 版本 |
数据库文件的条件 |
要使用的实用程序 |
---|---|---|
Calendar Server 6.0、6.1、6.2 |
您正在使用周期事件和任务,并且之前已运行 cs5migrate。 已使用 Schema 版本 2。 |
运行 csmigrate |
Calendar Server 6.0、6.1、6.2 |
您正在使用周期事件和任务,并且之前已运行 cs5migrate。 之前没有使用 Schema 版本 2,但现在需要使用。 |
运行 csmigrate 和 commdirmig。 |
Calendar Server 6.0、6.1、6.2 |
从未对文件运行过 cs5migrate。 已使用 Schema 版本 2,或正在使用 Schema 版本 1 并计划继续使用该版本。 |
运行 cs5migrate 和 csmigrate。 |
Calendar Server 6.0、6.1、6.2 |
从未对文件运行过 cs5migrate。 之前没有使用 Schema 版本 2,但现在需要使用。 |
运行 cs5migrate、csmigrate 和 commdirmig。 |
Calendar Server 5.1.1 |
过去没有使用多域。 |
运行 csmig、csvdmig、cs5migrate、csmigrate 和 commdirmig。 |
Calendar Server 5.1.1 之前的版本 |
您的文件不支持多域或 LDAP CLD。您的 LDAP 数据库正在使用 Schema 版本 1。 |
联系技术支持以使数据库和 LDAP 文件处于 Calendar Server 5.1.1 级别。 |
Calendar Server 5.1.1 之前的版本 |
您的系统已配置为用于受限虚拟域,或您已在 Solaris 10 之前的操作系统上安装了多个 Calendar Server 软件的实例。 |
联系销售代表以对迁移需求进行评估。 |
csmigrate 实用程序用于将 Calendar Server 6.0、6.1 或 6.2 数据库迁移到 Calendar Server 6.3 数据库。可在 Calendar Server 产品的 sbin 目录中找到 csmigrate 实用程序和其他管理工具。
本节包含以下主题:
csmigrate 命令的语法为:
csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir
选项及其用法如下:
指定静默模式且无打印说明。
指定模拟运行模式且不会写入新数据库。
指定日志级别。将迁移日志写入默认日志目录中的 csmigrate.log,将错误写入该目录中的 csmigrateError.log。
指定备份源数据库的目录。程序将源数据库备份到此目录中,然后对此副本进行操作以防止损坏源数据库。默认位置为源数据库目录下的 backup。
迁移前数据库文件所在的目录。
在其中创建迁移后文件的目录。
打印工具的版本信息。
打印工具的使用信息。
程序的退出代码为 255 时表示失败,为 0 时表示成功。
在 csmigrate 命令中使用选项的示例如下:
csmigrate -b /var/opt/SUNWics5/tmpdb /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -q /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -l min old_db /var/opt/SUNWics5/new_db csmigrate -l max old_db /var/opt/SUNWics5/new_db
以超级用户权限身份登录。
停止所有服务。
例如,发出以下命令:
stop-cal
将当前数据库移动到临时目录。
例如,将整个 csdb 目录移动到 oldcsdb。
mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb
确保新目录和该目录中的旧文件的所有者为默认管理员 (icsuser, icsgroup)。
如果拥有权不正确,则使用以下命令来更改拥有权:
chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/
运行迁移工具。
从新备份副本 (oldcsdb) 迁移到 csdb 目录,如以下示例所示:
cd cal-svr-base/SUNWics5/cal/sbin/ ./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb
重新启动日历服务。
例如,使用以下命令:
start-cal
cs5migrate 实用程序用于将 Calendar Server 5.1.1 数据库迁移到 Calendar Server 6.3 级别。此外,如果要从某个较早的 Calendar Server 6 版本执行迁移,并且未使用周期选项,也需运行此实用程序。
cs5migrate 实用程序执行以下任务:
过去,如果您不打算使用 Connector for Microsoft Outlook,可选择运行此实用程序,而不执行周期数据转换。然而,从 Calendar Server 6.3 开始,必须将周期数据转换为新格式。
升级到 Calendar Server 6.3 软件后,可在 sbin 目录中找到此实用程序和其他管理工具。
csmig 实用程序为日历数据库中的每个日历指定所有者,并将每个日历的 ID (calid) 映射到一个所有者(如果需要)。
csmig 实用程序支持多域和 LDAP 日历查找数据库 (Calendar Lookup Database, CLD) 插件。可以使用 LDAP CLD 插件访问已迁移的数据库中的日历。有关 LDAP CLD 插件的信息,参见 第 5 章,在 Calendar Server 版本 6.3 中配置跨多个计算机的日历数据库分发。
本节介绍以下主题:
csmig 迁移实用程序执行以下功能:
csmig 迁移由 caldb.berkeleydb.homedir.path 参数指定的当前日历数据库(*.db 文件)中的用户和资源日历。在新的目标数据库中,csmig 更新日历属性 (calprops)、事件、待办事项(任务)和组调度引擎 (Group Scheduling Engine, GSE) 数据库文件中的 LDAP CLD 插件所需的条目。
csmig 仅对目标数据库执行写入操作,而不更新现有日历数据库。
csmig 为日历数据库中的每个日历指定所有者,并将每个日历的 ID (calid) 映射到一个所有者(如果需要)。所有默认的 calid 都保持不变,并且不进行任何更改。
其他日历按如下方式进行映射:
不具有有效所有者的用户日历将属于通过 -c 选项传递给 csmig 的用户。例如,如果日历 ID jsmith 没有所有者,它将被转换为 orphan:jsmith(其中 orphan 由 -c 选项指定)。
不具有所有者的资源日历将属于通过 -r 选项传递给 csmig 的资源用户。
如果资源日历的名称包含多个冒号 (:),则冒号将被转换为下划线,并使迁移后的名称只包含一个冒号。
例如,所有者为 bkamdar 且名为 football 的日历将被转换为 bkamdar:football。所有者为 bkamdar 且名为 tchang:soccer 的日历将被转换为 bkamdar:tchang_soccer。所有者为 admin1 且名为 auditorium:room1 的资源日历将被转换为 admin1:auditorium_room1。
csmig 更新所有相关的 LDAP 条目的 LDAP 属性,包括 icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和资源日历的 uid。csmig 为 LDAP 目录服务器数据库中的每个日历创建 icsDWPHost 属性。icsDWPHost 指定日历驻留的后端服务器的主机名称。
使用 csmig 的要求为:
日历数据库必须未被损坏。使用 csdb check 命令检查日历数据库;如果需要,运行 csdb rebuild 命令来重新建立数据库。有关这些命令的信息,请参见附录 D,Calendar Server 命令行实用程序参考。
您必须为新的目标数据库准备足够的磁盘空间。如果适用,也应为备份数据库准备足够的磁盘空间。
要运行 csmig,请以 icsuser(或以配置过程中指定的 Calendar Server 运行时用户 ID)身份登录。如果您以超级用户 (root) 身份运行 csmig,则可能需要重置已迁移文件的权限。
您还必须具有管理存储用户首选项的 LDAP Directory Server 中的日历用户属性的权限。
必须停止 Calendar Server。
csmig [-t DestinationDB] [-b Backend-DWPHost] [-o OutputFile] [-e ErrorFile] [-m MappingFile] [-c calendarOwner] [-r resourceOwner] { migrate|dryrun } |
下表列出了实用程序选项,并给出了每个选项的说明和默认值。
csmig 选项 |
说明和默认值 |
---|---|
-t DestinationDB |
指定 csmig 生成的目标数据库。默认值为 MigratedDB。 |
-b Backend-DWPHost |
指定 DWP 后端主机服务器的名称。该名称必须与 ics.conf 文件中指定的 DWP 后端主机服务器名称相匹配。 |
-o OutputFile |
指定输出文件,此文件将捕获 csmig 输出到屏幕的消息以及出现的任何错误。默认值为 MigrateOut。 |
-e ErrorFile |
csmig 向其中写入错误或无法解析的数据库条目的文件。如果数据库项无法解析,则不将它们写入目标数据库。默认值为 MigrateError。 |
-m MappingFile |
指定 dryrun 模式下生成的输出映射文件,它列出了 LDAP 模式中需要更改的条目。例如: 旧的:calid=jsmith 新的:calid=jsmith:basketball 映射文件仅提供了对 LDAP 模式所作的更改的列表。csmig 实际上并不对该模式进行这些更改。 migrate 模式中不使用该映射文件。 |
-c calendarOwner |
为不具有所有者的用户日历指定所有者。 |
-r resourceOwner |
为不具有所有者的资源日历指定所有者。 |
migrate|dryrun |
指定运行实用程序时所使用的模式。使用 migrate 模式执行迁移。在实际迁移之前,使用 dryrun 模式生成输出映射文件。 |
如果拥有 Calendar Server 版本 5.1.1 之前的版本,则在安装和配置 Calendar Server 6.3 之后,运行 csmig 来迁移现有的 Calendar Server 和 LDAP 数据库。LDAP CLD 插件的正常工作需要进行 LDAP 数据的迁移。要使用 csmig 迁移日历数据,请按照以下步骤执行操作:
使用 comm_dssetup.pl 配置 Directory Server。
如果尚未使用 comm_dssetup.pl 为 LDAP 属性创建索引,则现在创建索引。这将大大提高 LDAP 数据迁移的性能。
请使用分步服务器(非产品服务器)执行模拟运行测试。
模拟运行会报告 csmig 在实际迁移过程中将要执行的操作,但模拟运行并不真地迁移任何数据。在模拟运行之后以及实际迁移之前,您可以更正任何错误,并确定处理任何未解析的日历的计划。
有关如何执行模拟运行测试的说明,参见3.5.4 csmig 实用程序迁移步骤。
迁移产品数据
在产品运行过程中,csmig 迁移日历数据库(.db 文件)与 LDAP 数据(用户和组首选项数据)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和用于资源日历的 uid。迁移之后,将为所有日历资源创建 LDAP 项。
有关如何迁移产品数据的说明,请参见3.5.4 csmig 实用程序迁移步骤。
在分步服务器上安装 Calendar Server 6.3(如果需要)。
将日历数据库的快照复制到分步服务器。
通过执行以下任务在分步服务器上模仿生产 LDAP 环境:
安装 Directory Server。
在此服务器上安装 LDAP 数据库的快照。
运行 comm_dssetup.pl 以配置分步 Directory Server。
运行 csconfigurator.sh 以配置分步 Calendar Server。
以 icsuser 身份登录(或者,如果不相同,以配置过程中指定的 Calendar Server 运行时用户 ID 登录)。如果您以超级用户 (root) 身份运行 csmig,则可能需要重置已迁移文件的权限。
转到 cal-svr-base/SUNWics5/cal/sbin 目录。
运行 csdb check 命令检查数据库中是否存在损坏。如果该命令检测出数据库中存在损坏,则运行 csdb rebuild 命令来重新建立数据库。
考虑为不具有所有者的用户日历创建通用的 calid。例如,以下命令将创建 calid 为 orphan 的用户:
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan |
使用 stop-cal 命令停止 Calendar Server(如果需要)。
cal-svr-base/SUNWics5/cal/sbin/stop-cal
运行带有 -dryrun 选项的 csmig。例如,可以输入:
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
该命令将不具有所有者的用户日历(不带有所有者的日历)指定给所有者 orphan,将不具有所有者的资源日历指定给所有者 calmaster。
检查输出的映射文件 (csmig.map)。映射文件列出了 LDAP 模式中需要更新的条目。
检查输出、映射和出错文件。解析发现的任何 LDAP 问题或错误。在进行实际的迁移之前,确定如何处理未解析的日历。
有以下若干选择:
在迁移前,删除任何不需要的日历。
为任何未解析的日历指定所有者。
在迁移期间,使用 -c 和 -r 选项允许 csmig 为日历指定所有者。
运行 csmig 以迁移分步日历数据库。
例如,以下命令将把日历数据库迁移至 /var/opt/SUNWics5/testcsdb/ 目录:
./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster migrate
测试迁移完成之后,请执行以下步骤检查新迁移的日历数据库。
以 icsuser(或在配置过程中指定的 Calendar Server 运行时用户 ID)身份登录。如果您以超级用户 (root) 身份运行 csmig,则可能需要重置已迁移文件的权限。
转到 cal-svr-base/SUNWics5/cal/sbin 目录。
使用 stop-cal 命令停止 Calendar Server。
cal-svr-base/SUNWics5/cal/sbin/stop-cal
备份以下数据:
日历数据库(.db 文件)。
LDAP 数据:slapd 数据库目录和 LDAP 数据库。
ics.conf 文件。此步骤实际上并不需要,但如果要恢复为初始配置,该步骤则会很有帮助。
运行带有 -migrate 选项的 csmig。
例如,以下命令将把日历数据库迁移至 /var/opt/SUNWics5/newcsdb/ 目录:
./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.log -c orphan -r calmaster migrate
检查错误文件 (csmig.errors) 中是否有未解析的日历,并根据3.5.4 csmig 实用程序迁移步骤中的计划解析这些日历。
运行 csdb check 命令以检查已迁移的数据库。如果该命令检测出数据库中存在损坏,则运行 csdb rebuild 命令来重新建立数据库。
将新迁移的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录中。或者编辑此参数,使其指向迁移的数据库的新位置。
通过对 ics.conf 文件中的以下配置参数进行必要的更改来启用 LDAP CLD 插件:
caldb.dwp.server.server-hostname.ip = "server-hostname"(用于包含本地服务器的每个后端服务器)
caldb.cld.cache.homedir.path 指定 CLD 高速缓存目录的位置。默认值为 /var/opt/SUNWics5/csdb/cld_cache。
有关设置 LDAP CLD 插件的配置参数的信息,参见第 5 章,在 Calendar Server 版本 6.3 中配置跨多个计算机的日历数据库分发。
使用 start-cal 命令重新启动 Calendar Server。
登录到 Communications Express 并通过检查几个已迁移的日历来验证配置是否起到作用。
要在检查时禁用警报,将 ics.conf 文件中的以下参数都设置为 "no":
本节介绍了以下提示和故障排除示例:
名为 tchang:myCalendar 的日历的所有者在日历数据库中为 jsmith,csmig 模拟运行将映射显示为 jsmith:tchang_myCalendar。但是,您希望将此日历命名为 tchang:myCalendar,并将所有者指定为 tchang。
在迁移之前,使用 cscal 实用程序将 tchang:myCalendar 日历的所有者更改为 tchang。执行此操作后,迁移操作会将此日历映射为 tchang:myCalendar,并针对用户 ID tchang 向 LDAP 条目中添加 icsCalendarowned。
迁移之后,将启用 LDAP 日历搜索,但日历搜索对话框不返回任何结果,或仅返回部分结果。
启用 LDAP 日历以使 Calendar Server 可以搜索 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))。
使用以下过滤器对 LDAP 数据手动运行两个不同的搜索,并比较输出结果:
使用过滤器 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) 进行 LDAP 搜索
使用过滤器 (icscalendarowned=*substr* ) 进行 LDAP 搜索
因为服务器使用包含 icsCalendarUser 对象类的过滤器,所以可能已在禁用模式检查的情况下部署了 LDAP 服务器,并且可能在没有 icsCalendarUser 对象类的情况下置备了某些日历条目。
csmig 模拟运行映射文件和输出结果文件指示存在重复的日历名称。
例如,在初始数据库中,jsmith 拥有以下日历:
具有 5 个事件的 basketball
具有 10 个事件的 jsmith:basketball
模拟运行的结果表示迁移时将合并这两个日历,生成的日历将为 jsmith:basketball,该日历的所有者为 jsmith 并总共具有 15 个事件
输出文件将包含以下警告消息:
Error modifying calendar properties, error=2
如果不希望合并这两个日历,则在迁移之前将 basketball 的所有者更改为 jsmith 以外的用户。这可以保持这两个独立日历数据的完整性。
默认情况下,csmig 将所有不带有所有者的日历指定给一个所有者,但是我希望为其中的某些日历指定不同的所有者。
csmig 不接受命令行中的映射文件。但是,可以在迁移之前为初始数据库中不带有所有者的日历指定所有者。检查所有不带有所有者的日历的空运行映射文件。然后,在迁移之前使用 cscal 实用程序为不带有所有者的日历指定所有者。在 -dryrun 模式下再次运行 csmig 以验证新的所有者。
如何将用户从一个后端服务器移动到另一个后端服务器?
要移动日历用户,应通过 export 命令导出初始服务器上该用户的每个日历,然后通过 import 命令将日历导入到第二个服务器。移动日历后,可以删除初始服务器上的日历。有关如何移动日历的说明,参见15.6 管理用户日历。
csvdmig 实用程序准备要在多域环境中使用的日历数据库以及 LDAP 用户和组条目。即使计划仅使用默认域,也必须运行此实用程序。
如果在 Calendar Server 6.3 中从非域环境迁移到多域环境,确保在使用此实用程序前先运行 csmig。
本节包含以下主题:
csvdmig 实用程序对数据库和 LDAP 条目执行以下更改:
更改日历 ID (calid) 的格式:
从:userid[:calendar-name]
到: userid@domain[:calendar-name]
更改访问控制列表 (ACL) 访问规则:
从:userid
到:userid@domain
修改用于 Calendar Server 属性的 LDAP Directory Server 用户条目:
将 userid[:calendar-name] 改为 userid@domain[:calendar-name]。
更新日历数据库中事件和任务的所有者和参与者字段。例如:
如果域 sesta.com 中的 jsmith 是事件的所有者,则新的所有者字段将包含 jsmith@sesta.com。
csvdmig 实用程序将对数据库和 LDAP 目录进行相应更新。也就是说,该实用程序并不创建单独的迁移数据库,而是修改正在转换的数据库。因此,为了安全起见,针对数据库和 LDAP 目录的快照运行 csvdmig。
csvdmig 实用程序的语法如下:
csvdmig [-t DestinationDB] [-c ConfigFile] [-e ErrorFile] [-m MappingFile] migrate [DB|LDAP] |
下表列出了 csvdmig 使用的选项,并给出了每一个选项的描述。
选项 |
说明和默认值 |
---|---|
-m MappingFile |
指定映射文件的输入参数。有关映射文件的更多信息,参见3.6.2.1 映射文件。默认值为 MigrateMapping。 |
-c ConfigFile |
指定 Calendar Server 配置文件的输入参数。默认值为 ics.conf 文件。 |
-t DestinationDB |
指定要迁移数据库位置的输出参数。默认值为 MigratedDB。 提示 – 始终使用 -t 选项。 有关此选项的更多信息,参见3.6.2.2 目标 DB。 |
-e ErrorFile |
为无法解决的错误指定错误文件的名称的输出参数。默认值为 MigrateError。 |
DB | LDAP |
指定要修改的数据库: DB—日历数据库 LDAP—LDAP 目录 默认值为日历数据库 (DB)。 |
映射文件是输入文本文件,可将现有用户映射到其各自的域。运行 csvdmig 之前,必须创建映射文件。每行指定一个条目,在旧值和新值之间留有一个空格。例如:
user1 user1@sesta.com user2 user2@siroe.com user3 user3@sesta.com ... usern usern@siroe.com
要迁移的数据库的位置。此实用程序会对文件进行相应更新。确保在使用 csvdmig 实用程序前已备份此目录。
如果未指定 -t 选项,则实用程序会尝试迁移当前目录(通过在命令行执行 pwd 所指定的目录)的内容,并会产生无法预知的结果。
以下为 csvdmig 示例
使用默认值迁移 LDAP Directory Server 数据:
csvdmig migrate LDAP
迁移 Calendar Server 数据库:
csvdmig -t targetDB -e errorFile -m mappingFile migrate
commdirmig 实用程序将 LDAP 数据从 Sun Java System LDAP Schema 版本 1 迁移到 Schema 版本 2,为将 Access Manager 用于验证服务做好准备。如果之前的安装已使用 Schema 版本 2,则无需再运行此实用程序。
此迁移实用程序将 Schema 版本 1 LDAP 数据库迁移到 Schema 版本 2。如果要使用 Access Manager 软件来进行验证,必须通过运行此实用程序将 LDAP 条目转换为 Schema 版本 2 格式。
如果使用的不是 Access Manager,由于 Schema 版本 2 是所有使用 LDAP 的 Communications Suite 产品首选的 LDAP 模式,所以仍应考虑迁移 LDAP 数据。
如果具有单独 LDAP 目录首选项,则必须在该 LDAP 和用于验证的 LDAP 上运行 commdirmig。
在已运行将日历和 LDAP 数据库从 Calendar Server 软件的之前版本迁移到 Calendar Server 软件版本 6.3 所需的所有其他迁移实用程序后,运行 commdirmig。
commdirmig 迁移实用程序需要特殊的准备和规划。它在独立的指南中进行说明,参见《Sun Java Communications Suite 5 Schema Migration Guide》。
commdirmig 实用程序与通过 Communications Suite 安装程序安装的 Delegated Administrator 捆绑在一起。
也可以从技术支持处获得该实用程序的修补程序。