您可以使用csvde来导出AD中的用户名称和邮件地址，然后，从导出的文件导入到POP客户端的联系人中。这里提供一个例子，导出显示名称和邮件地址，您可以在-l 参数后添加需要导出的属性值，命令如下：
csvde -r "(objectClass=user)" -d "dc=domain,dc=com" -l displayName,mail -f c:\users1.csv
把users1.csv导入到Outlook本地联系人的方法如下：
1. 启动Outlook。
2. 单击文件\导入/导出，选择从另一程序或文件导入，单击下一步。
3. 选择以逗号为分隔符（Windows），单击下一步。
4. 指定.csv文件位置，单击下一步。
5. 指定导入位置，选择联系人，单击下一步。
5. 勾选将“User.csv”导入下列文件夹，在设置映射窗口，把左边的Display 拖动到右边窗口的姓名，把Mail拖到邮件地址，使得用户属性与本地联系人的属性相对应。
6. 单击完成，完成导入操作。
How to export GAL (Global Address List)
http://support.microsoft.com/kb/555397/en-us
2. 定位到RPC 虚拟目录，点击右键，选择属性。
3. 在属性窗口，单击安全页。
4. 在authentication and access control单击编辑
5. 选择 Basic Authentication
6. 在域名后输入您的域名。
7. 右键点击左边窗口的服务器名称，选择所有任务－>重启IIS。
…is not a good idea. In a production deployment a second server should be built using the desired server name, and then all OCS users moved over to it. Or a temporary staging server can be stood up in order to rebuild the original server. Either way, simply renaming an Office Communications Standard Server 2007 can be painful.
Shortly after deploying a standard server in my lab I noticed during server configuration that I had fat-fingered the server's hostname and was not to happy about that. I decided to see what would happen if I just renamed the server without any preparation in OCS. After renaming my virtual guest from JDSSOCS01 to JDSOCS01 I was welcomed with a standard Windows startup message alerting me to a service failure.
A quick scan of the Application event log uncovers event ID 12291 explaining that "the Communications service is registered for a different machine." Microsoft Knowledgebase Article ID 830535 covers this error, but in reference to LCS 2003, and states that changing the FQDN of a Live Communications Server is not supported. So it doesn't appear to be supported in OCS 2007 either.
The article's resolution suggests exporting the RTC SQL database to a file, removing the OCS services, and re-installing the product. Because I had already renamed the server I was unable to deactivate the pool/server using the previous name and was presented with a couple warnings during the uninstall that some configuration information will be left in the Active Directory domain; I took note of this for later troubleshooting. I also completely removed the SQL 2005 Express components in order to wipe the OCS install from the server.
During reinstallation of the OCS Standard Server the setup wizard reported a failure and viewing the install log showed that the server could not be activated for a pool due to a conflict. At this point I decided to just delete the VM and rebuild the server from a fresh image as deploying a clean lab environment was my overall goal. Before creating a new server with the desired server name of JDSOCS01 I went to delete the existing computer object in Active Directory, but oddly enough I was warned that deletion of that object would result in all child objects also being removed from AD. I checked out the existing computer object using ADSIedit and apparently the OCS installation inserts additional objects under the server:
I deleted the computer object and imaged a new virtual guest using the correct server name. This time the OCS Standard Server installation completed successfully, but I received another error after validating the front-end server configuration:
Failure: [0xC3FC200D] One or more errors were detected
Diagnose Server
Check Configuration
Checking all trusted servers
Internal Server JDSSOCS01.lab.schertz.local
DNS Resolution failure: No such host is known
Suggested Resolution: Make sure there are no typos in the Server name. Make sure that the Server name is published in the DNS (A or SRV record) or hosts file entry is configured correctly.
This is the part where I spent some time digging through AD looking for where the old server name was hiding. After running some LDAP queries using the string *pool* I discovered where OCS stores it's configuration data in AD:
CN=RTC Service,CN=Microsoft,CN=System.DC=domain,DC=com
I located and deleted the Pool object for the old server:
CN=JDSSOCS01,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System,DC=schertz,DC=local
But that didn't resolve the validation errors after rebooting the OCS server. I dug deeper and found both the old and new server FQDNs referenced in multiple objects under Global Settings, MCU Factories, Trusted MCUs, and Trusted WebComponentsServers. Using the command ldifde -f output.txt -d "dc=schertz,dc=local" is was able to search the text export file for all the objects with attributes referring to "jdssocs01":
CN=Global Settings,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={DB1226B0-B04E-494F-BF44-6C365A2A4CF1}
objectCategory: CN=ms-RTC-SIP-TrustedServer
msRTCSIP-TrustedServerFQDN: JDSSOCS01.schertz.local
CN=MCU Factories,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={0AAB2557-E5AA-4229-8F43-600554BAE453}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={55753891-89EA-4F18-B020-5FA5928BE97F}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={56B7C1C4-1961-461A-B40F-3ABB3C62BE31}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={E1F6A173-E15D-427A-8E2A-87DD1CAAD947}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
CN=Trusted MCUs,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={459B434F-3099-4049-8A2E-56D0524AFAD4}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={51D7A033-A074-4285-9589-FB78AAB6A460}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={9DE8BC35-D15A-4F8F-8BCD-A819014420F0}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={C5677C4C-7BE6-484D-9CD4-878F1F8427BE}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
CN=Trusted WebComponentsServers,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={93A1A739-3B44-4F0B-935A-170EAAA63026}
objectCategory: CN=ms-RTC-SIP-TrustedWebComponentsServer
msRTCSIP-TrustedWebComponentsServerFQDN: JDSSOCS01.schertz.local
I deleted all objects above and then removed the invalid ServicePrincipalName entries from the RTCService and RTCComponentService user accounts.
I forced AD replication between both domain controllers and rebooted the OCS server, and the validation check no longer reports any failures.