ADMT 3.2:迁移密码

ADMT工具可以实现对活动目录对象的迁移，但是如果要在迁移用户帐号时，同时迁移密码，就需要同时配置ADMT 3.2及Password Export Service。

本文会利用两台服务器来进行：CFM-SDC.CFM-S.COM，源域域控制器 / CFM-TDC.CFM-T.COM   目标域域控制器。由于ADMT需要使用SQL数据库，因此在CFM-TDC.CFM-T.COM上安装了SQL Server。

创建DNS的Conditional Forwarder

源域：

1. 在CFM-SDC上，打开DNS管理器
2. 右键单击Conditional Forwarders，选择New Conditional Forwarder
3. 输入域名CFM-T.COM，以及CFM-TDC.CFM-T.COM的IP地址
4. 运行命令ipconfig /flushdns
5. 运行命令ping cfm-t.com，确认可以正确解析到IP地址

目标域：

1. 在CFM-TDC上，打开DNS管理器
2. 右键单击Conditional Forwarders，选择New Conditional Forwarder
3. 输入域名CFM-S.COM，以及CFM-SDC.CFM-S.COM的IP地址
4. 运行命令ipconfig /flushdns
5. 运行命令ipconfig /flushdns
6. 运行命令ping cfm-t.com，确认可以正确解析到IP地址

创建信任关系

对于ADMT的迁移，只需要创建一个单向的信任关系（one-way outgoing）即：源域信任目标域，无需创建双向信任。

源域：

1. 打开Active Directory Domains and Trusts控制台
2. 右键单击CFM-S.COM，选择属性
3. 切换到Trusts，点击New Trust…
   
4. 点击Next
   
5. 输入目标域名
   
6. 选择Forest Trust
   
7. 选择One-way outgoing
   
8. 选择Both this domain and the specified domain
   
9. 输入目标域的管理员帐号
   
10. 选择Forest-wide authentication
    
11. 点击Next
    
12. 点击Next
    
13. 选择Yes, confirm the outgoing trust
    
14. 点击Finish完成信任关系的创建
    
15. 在源域中，可以看到如下所示的信任关系
    

目标域

在目标域中，打开Active Directory Domains and Trusts，选择CFM-T.COM的属性，切换到Trusts页面，可以看到信任关系已经创建完成。

 

安装ADMT 3.2

ADMT需要在目标域安装，启动ADMT的安装程序，安装过程很简单，不再赘述。

本例中，ADMT 3.2所使用的SQL Server安装在本地，因此进行SQL Server服务器指定时，直接输入一个点.即可。

为ADMT启用密码迁移功能

密码迁移需要使用到密钥进行加密，该密钥由ADMT创建，再传递给运行Password Export Service的机器。

目标域：

1. 在运行ADMT的机器上，运行以下命令，更改标注的部分。
   admt key /option:create /sourcedomain:CFM-S.COM /keyfile:C:\Key /keypassword:Password01!
   
2. 将生成的key.pes文件复制到源域上

源域：

1. 在源域上，将目标域的域管理员帐号添加到源域的Built\Administrators组中
2. 运行Password Export Service的安装程序
   
3. 注意到key.pes文件已经被自动选中。如果安装程序没有找到PES文件，则选中它
   
4. 输入在利用ADMT进行密钥创建时使用的密码
   
   
5. 指定Password Export Server Service以源域的域管理员帐号运行
   
   
6. 安装结束后，需要重新启动服务器。
7. 服务器重启后，打开Services.msc，找到一个名为Password Export Server Service的服务，把它启动。
   
   这个服务的启动方式应该设置为手动，并且仅在使用ADMT进行密码导出时才启动；ADMT迁移完成后，应及时停止服务，或直接将其卸载。

现在，就可以使用ADMT进行用户帐号迁移，并同时实现密码的迁移了。

 

原创文章，转载请注明出处。George Wu

Exchange Server 2010客户端访问的代理和重定向

从Exchange Server 2007开始，Exchange的客户端访问都由活动目录站点进行划分。也就是说，用户的邮箱在那个站点，用户就必须连接到该站点的客户端访问服务器，才能访问到自己的邮箱。

而从Exchange Server 2010开始，所有的客户端访问都必须通过客户端访问服务器来进行。即使是使用Outlook客户端，从公司内部网络进行MAPI（Exchange RPC）方式连接时，也是如此。

综合前面两点，可以得到一个结论，在Exchange Server 2010的环境中，如果一个活动目录站点中部署了邮箱服务器，那么该站点必须有客户端访问服务器，才能保证用户的访问。当然，同样的结论也适用于Exchange的集线器传输服务器。

客户端访问的代理和重定向是在多站点环境中部署Exchange服务器时需要考虑的问题，如果一个Exchange组织中，所有的Exchange服务器都在同一个站点内，就不需要考虑了。

用户连接的客户端访问服务器与其邮箱服务器不在同一个站点时，就需要通过代理或重定向方式来实现了。而关于代理或重定向的概念，最简单的说法就是，此时如果用户直接就连接到自己的邮箱，那么就是代理；如果用户被要求重新到另一台客户端访问服务器上登录，那么就是重定向。

在Exchange Server 2010中，重定向一般只出现在用户使用OWA/Mobile这两种客户端方式发起访问时出现；而可以被代理的客户端访问方式包括：Outlook Anywhere/POP3/IMAP4/OWA/Ecp/Exchange Web Service/ActiveSync。

注意一点，作为内网用户最常用的MAPI方式，是不支持代理的。

考虑下图所示的配置：

例如用户TestUM1使用OWA连接到Site2的客户端访问服务器上，而该用户的邮箱当前在Site1被激活，那么用户就会收到如下提示，告知其需要访问另一个位置。这就是一个典型的重定向现象。

对于TestUM3这个用户，其邮箱在Site2上被激活，当其连接到Site1的OWA时，却能够直接登录，而没有被要求到Site2的OWA重新登录，这就是代理的情况。

那么，Exchange是怎样来确定是使用代理还是重定向呢？这个选择的关键在于，用户邮箱所在站点的客户端访问服务器是否被配置为面向Internet（Internet-Facing）。如果是Internet-Facing，就会使用重定向；如果是Non-Internet-Facing，代理就会起作用。

要判断一台客户端访问服务器是否Internet-Facing，可以通过检查这台服务器上，通过IIS发布的服务，例如OWA/Ecp等，是否配置了ExternalURL值来实现。

例如对于OWA配置的检查，可以通过Exchange Management Console打开OWA属性，也可以通过Get-OWAVirtualDirectory，并列出ExternalURL值来进行。如下图所示：

根据这个结果，可以判断出，第1、2两台服务器是Internet-Facing的，而3、4两台服务器是Non-Internet-Facing。在这种配置下，所有用户都可以通过cas.pcoe.com来作为客户端访问入口，并使用OWA/Outlook Anywhere/POP3/IMAP4/AcitveSync等多种方式来访问自己的邮箱。

Microsoft有专门的文档说明代理和重定向。http://technet.microsoft.com/en-us/library/bb310763.aspx 该文档的中文版本里，专门提到Exchange 2010不支持POP3和IMAP4的代理；而英文版本却没有这个说明。根据使用Exchange Server 2010 SP1 with Rollup 3-V3实际测试的结果，是可以实现POP3的代理的，其它版本没有进行测试。

以下是对POP3代理的测试情况，可以看到，POP3的代理与服务器是否配置为Internet-Facing无关，Site1的用户可以通过POP3连接到Site2的客户端访问服务器，并最终连接到自己的邮箱；反之亦然：

原创文章，转载请注明出处。George Wu

Exchange DAG跨站点转移

 

Exchange Server 2010在跨站点部署数据库可用性组（Database Availability Group, DAG）时，需要考虑站点间的转移问题。即：一个站点的Exchange服务器宕机时，另一个站点的Exchange能否自动切换，并保证客户端访问的不间断。

 

事实上，跨站点的转移有两种，一种是故障转移Fail over，另一种是切换Switch over。故障转移是服务器自动进行的一种行为；而切换则需要管理员的人工干预才能够完成。

 

在理想状态下，总是希望实现Failover，因为Failover是不需要任何人工干预而自动进行的，Failover可以最大限度地保证服务的可用性。

Exchange组织拓扑

邮箱数据库

组织中配置了3个数据库，每个数据库有3个副本，分别位于加入DAG的3台Exchange Server 2010邮箱服务器上。

Client Access Array

各活动目录站点中配置的Client Access Array。

邮箱数据库上配置的Client Access Array

这里需要说明一下Client Access Array，结合Mailbox Database上的RpcClientAccessServer这个参数，可以发现，这个功能用于且仅用于公司内部的Outlook客户端使用MAPI方式进行连接时使用。对于每一个活动目录站点，可以创建并仅能创建一个Client Access Array。一旦创建了Client Access Array，它将自动把本站点所有的客户端访问服务器作为自己的成员，而且这个成员是不允许进行编辑（添加或删除）的。对于Exchange的管理员，只能对Client Access Array的名称和FQDN进行配置。

由于Exchange Server 2010的客户端访问是按照活动目录站点进行划分的，而为了节省站点间的网路带宽，管理员应该尽可能使用户访问Exchange邮箱时，使用其所登录站点的Exchange服务器。例如这里的配置，DB#3上存放的是2ndSite内的用户邮箱，默认会在ExchAllinOne上被激活，而DB#3上的RPCClientAccessServer设置为2ndSite上的Client Access Array，这样就可以保证，在正常情况下，2ndSite的用户只需要连接到ExchAllinOne就能完成邮箱访问，而不需要使用1stSite内的Exchange服务器。

DAG的配置

虚拟目录

Client Access Server上虚拟目录的配置情况，以OWA为例，其它虚拟目录如OAB/ECP等服务，它们与OWA所使用的主机名完全相同：

也就是说，只有PCOEExchHTCAS1和PCOEExchHTCAS2，它们组成的cas能够在外部被客户端访问。而且，也只在这两台服务器上启用了Outlook Anywhere。

客户端连接

对于一个邮箱位于DB#3上的用户，通过AutoDiscover获取的默认Outlook配置如下：

Outlook的连接状态

模拟服务器故障

关闭ExchAllinone，数据库DB#3切换到1stSite的PCOEExchDAG2上。此时，相当于2ndSite内所有的Exchange服务均不再可用。结合前面提到的RpcClientAccessServer的设置情况，想像一下对于邮箱在DB#3上，并且正在使用MAPI方式连接到Exchange的用户会出现什么情况？

答案是：这类用户将无法继续使用MAPI方式进行连接了。

对客户端的影响

Outlook客户端重新发起连接，使用Outlook Anywhere方式进行。

注意：这种情况仅限于2ndSite不面向Internet（None-Internet-Facing）的情况，也就是在ExchAllinOne上没有配置ExternalURL，也没有启用Outlook Anywhere的前提下，客户端才能够自动切换到Outlook Anywhere方式，并且由cas.pcoe.com实现客户端访问的代理。这就是Failover的情况，服务器自动完成切换，客户端自动恢复连接。

如果2ndSite也是Internet-Facing的，就只能采用Switchover方式，由管理员手动干预才能够恢复客户端的访问了。

这里牵涉到的另一个问题就是客户端访问的代理（Proxying）及重定向（Redirection）。将在后续文章中加以说明。

关于DAG切换和故障转移的更多详细信息，请参考：
http://technet.microsoft.com/en-us/library/dd298067.aspx

原创文章，转载请注明出处。George Wu

“下次登录时需要更改密码”的用户如何登录OWA

如果一个用户的活动目录帐号被标记为“下次登录时需要更改密码（User must change password at next logon）”，那么当该用户登录到OWA时，即使输入的身份验证信息正确，OWA也会拒绝用户登录。Exchange Server 2010 SP1的OWA解决了这个问题，管理员可以通过配置客户端访问服务器来实现：

1. 在Exchange Server 2010 SP1的客户端访问服务器上，打开注册表编辑器（这个功能必须安装SP1之后才有）
2. 找到HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA
   添加一个DWORD值，名称为ChangeExpiredPasswordEnabled，值设为1
3. 运行IISRESET重启IIS
4. 之后再登录OWA时，这类用户在输入原来的密码后，就会看到下面的页面，用户可以在里面进行密码修改。
   

 

原创文章，转载请注明出处。George Wu

利用Transporter Suite实现从第3方邮件系统到Exchange的迁移

在从其它邮件系统迁移到Exchange的过程中，Transporter Suite可以从Domino自动进行用户帐号的同步，而对于Domino以外的邮件服务器，管理员需要进行手动的用户数据导入。也就是说，需要先获取其它邮件系统上的用户名称列表，然后在Exchange中为这些用户创建用户帐号和邮箱，最后使用Microsoft Transporter Suite工具进行邮件数据的导入。

 

简单地说，Transporter Suite的工作原理是：利用配置好的用户信息，通过POP3或IMAP4协议从第3方邮件系统中读取用户的邮件数据，再通过Exchange Server 2007的客户端访问服务器所提供的Web Service，将数据写入到指定的Exchange用户邮箱中。需要注意的是，由于Exchange Server 2010的Web Service与Exchange Server 2007不同，因此这个工具只能支持将邮箱数据写入到Exchange Server 2007，而不支持直接向Exchange 2010的迁移。

 

Microsoft Transporter Suite下载位置：http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=35fc4205-792b-4306-8e4b-0de9cce72172

下面是大致的迁移步骤，前提是所有用户在Exchange所在的活动目录中已经存在帐号。

1. 在一台与Exchange Server 2007同在一个域的机器上，安装Transporter Suite。也可以安装在Exchange 2007自身
2. 确保所有用户在Exchange 2007上都已经分配了邮箱
3. 用管理员登录到Exchange 2007服务器，打开命令行窗口，运行以下命令，为管理员授予Impersonate权限：
   Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity Administrator | select-object).identity -extendedRight ms-Exch-EPI-Impersonation
4. 创建一个纯文本文件，命名为UserList.csv，包含以下内容:
   

   SourceIdentity	Sourceserver	SourceLoginID	SourcePassword	TargetIdentity
   administrator@crm3.com	mail.crm3.com	administrator	123	administrator@george.com
   用户在其它系统上的邮件地址	其它邮件服务器名称	用户在其它系统上的登录名	用户在其它系统上的密码	用户在Exchange 2007上的邮件地址

5. 用管理员登录到Exchange 2007服务器，打开Transporter Suite工具的管理控制台
6. 在左边的导航栏上，右键单击All Mailboxes节点，在弹出菜单上选择Add Mailboxes…，在弹出的对话框中，选中前面所保存的CSV文件，将其导入
7. 此时，在Mailboxes Ready for Migration中，可以看到这些邮箱
8. 从控制台中间的窗口中，选中所有用户，点击右边的Migrate Selected Mailbox，在导入向导中，选择如下图所示，然后点击下一步：
   
   选择All e-mail，点击下一步
   
   确认信息，点击Migrate
   
   迁移完成
   
9. 迁移完成后，可以在Mailboxes Already Migrated中，看到这些邮箱
10. 用户登录到自己的Exchange邮箱后，就能够看到这些迁移完成的历史邮件了。

原创文章，转载请注明出处。George Wu

利用签名和加密技术保护邮件信息

在保护邮件有多种方式，除了前面提到的使用RMS进行保护外，还可以利用签名和加密等技术来实现。RMS是Microsoft专有的技术，默认情况下，只有Office的文档，如WORD、Excel、PowerPoint等可以使用RMS，其它应用程序需要专门进行开发才能够用到RMS。而签名和加密是行业标准，大多数邮件系统都提供了这两个技术。

 

RMS是通过权限管理模板，根据用户的帐号信息来规定访问权限。而签名和加密则是使用用户证书来实现的。也就是说，要实现签名和加密，用户需要首先获取个人证书，然后在邮件客户端中使用该证书来实现。这张个人证书需要有相应的用途及正确的配置，才能用于邮件的签名和加密。

 

在Windows中，运行MMC，然后点击文件=>添加/删除管理单元（File=>Add/Remove Snap-In），在列表中选择证书=>我的用户帐号（Certificates=>My user account）来添加证书管理控制台。然后从个人=>证书（Personal=>Certificates）中，就可以看到当前用户在当前系统上的个人证书情况。然后双击证书，检查常规（General）页面中的信息。

这里有两个重要信息，在图中用红色标记的部分：保护电子邮件信息（Protects e-mail message）和您有一个与该证书对应的私钥（You have a private key that corresponds to this certificate）。保护电子邮件信息表示该证书能够用于邮件的签名和加密；拥有私钥表示当前用户是该证书的所有者。

 

邮件的签名和加密都是利用证书，也都是用于保护邮件信息的安全，但是侧重点有所区别。

1. 保护的对象
   对邮件进行签名，被保护的是收件人的权益。收件人可以通过对该签名的检查，来确认邮件确实来自其声称的发件人，而不是由其他人冒名发送的。
   对邮件进行加密，保护的是发件人权益。发件人通过邮件加密，可以保证该邮件只能被指定的收件人看到。
2. 使用的证书
   邮件签名，使用的是发件人的个人证书；而邮件加密，使用的则是收件人的个人证书。

为什么加密会使用到收件人的个人证书呢？每个证书都包含两个密钥，一个是私钥；另一个是公钥。顾名思义，公钥是其他人能够获取的；而私钥只有证书的所有者才能够使用。利用证书对邮件进行加密，其实就是利用收件人的公钥进行加密；邮件的收件人再利用私钥进行解密。这就要求了，在发送加密邮件时，发件人必须有收件人的证书才能够进行加密。

 

如果没有收件人的证书，在试图发送加密邮件时，就会出现下图所示的错误：

 

那么，发件人如何获取收件人的个人证书呢？收件人需要主动将个人证书导出并发送出来，然后在发件人的客户端进行导入。例如A要发送加密邮件给B，对于使用Outlook的用户，那么需要做的步骤是：

1. B将自己的个人证书导出为CER文件。导出时需要注意，不要导出私钥。
   
2. B将这个证书文件发送给A。CER后缀的文件作为附件发送时，在大多数邮件系统上会被屏蔽，因此需要先压缩然后在发送
3. A收到证书后，在自己的Outlook里创建一个联系人
4. 点击证书Certificates，在点击Import将B发送来的证书导入
   
5. 导入成功后，就可以从联系人的属性中看到这个证书了。此时，用户A就可以利用这张证书来向用户B发送加密邮件。
   

 

而对于使用同一个Exchange组织的用户，还有另一种方式来获取彼此的证书，就是用户将个人证书发布到Exchange的GAL里。这样整个Exchange组织内的用户就都能够获取到这张证书。

 

首先要确保在运行Outlook的操作系统上，已经正确安装了当前用户的个人证书，并且证书的目的中包含有“保护电子邮件信息（Protects e-mail message）”一项。在Outlook中，打开文件=>选项=>信任中心=>信任中心设置=>电子邮件安全（File=>Options=>Trust Center=>Trust Center Settings=>E-mail Security）。

先点击设置（Settings），启用安全设定。主要完成的操作就是选择合适的证书。

然后，点击“发布到GAL（Publish to GAL）”

Publish to GAL的操作，实质就是将设定的个人证书导入到活动目录的用户对象中。从活动目录的用户帐号属性里，可以看到已经发布的证书，Exchange在生成GAL，就会包含这个证书。而Exchange组织中的其他用户，也可以通过GAL获取这张已经发布的证书信息。

 

完成了这些操作，用户就可以在发送邮件时，选择签名和加密方式，来保障邮件的安全性。下面的例子，可以反过来证明加密邮件时所使用的证书。用户Test UM1发送了一封加密并签名的邮件，收件人有两个，分别是Test UM2和George Wu。

Test UM2打开这封邮件，点击右边的加密图标时，出现的邮件安全属性（Message Security Properties）中，所显示的信息如下：

George Wu打开这封邮件，点击右边的加密图标时，出现的邮件安全属性（Message Security Properties）中，所显示的信息如下：

注意到两者的不同了吗？

原创文章，转载请注明出处。George Wu

Exchange Server 2010与RMS集成

与权限管理服务（Rights Management Services/RMS）集成是Exchange Server 2010的新功能，也是一大亮点。随着RMS还会提到一个名词是IRM，即：信息权限管理/Information Rights Management。实际上，RMS是服务，而IRM是具体实现。安装RMS之后，才可以使用IRM。在 Exchange Server 2010 中，可使用信息权限管理 (IRM) 功能对邮件和附件应用持久保护。

通过与RMS的集成，Exchange邮件用户可以控制收件人对电子邮件拥有的权限，允许或限制某些收件人操作，例如向其他收件人转发邮件、打印邮件或附件，或者是通过复制和粘贴提取邮件或附件内容。

用户可在 Microsoft Outlook 或 Outlook Web App 中应用 IRM 保护，或者可以根据组织的邮件策略并使用传输保护规则或 Outlook 保护规规则应用 IRM 保护。与其他电子邮件加密解决方案不同，IRM 还允许组织解密受保护的内容，以强制执行策略遵从性。

IRM 可以实现：

• 防止受 IRM 保护的内容的授权收件人转发、修改、打印、传真、保存或剪切和粘贴该内容；
• 用与邮件相同的保护级别保护所支持的附件文件格式；
• 支持受 IRM 保护的邮件和附件的过期，使其在指定时间段之后，无法再进行查看；
• 防止使用 Windows 中的截图工具复制受 IRM 保护的内容。

但是，IRM 无法防止：

• 第三方屏幕捕获程序；
• 使用照相机等图像处理设备对显示在屏幕上的受 IRM 保护的内容进行照相；
• 用户记住或手动抄录信息。

 

Exchange Server 2010与RMS集成，可以应用在以下几个方面：

1. 传输保护规则
   可以根据传输规则中定义的筛选条件，为满足条件的邮件自动应用指定的RMS模板，以利用IRM来保护邮件信息；
2. 传输解密
   被IRM保护的邮件可以被解密并进行防病毒扫描，之后再次加密进行后续传递；
3. 日记报告解密
   被IRM保护的邮件，如果被日记规则归档，可以先解密再归档；
4. 为Exchange Search实现IRM解密
   使Exchange Search能够搜索受IRM保护的邮件内容；
5. OWA/Outlook
   用户可以在Outlook和OWA中发送/接收利用IRM保护的邮件，而不需要额外安装任何插件；
6. 保护语音邮件
   可以利用IRM来保护语音邮件，特别是私人的语言邮件，可以设置“不可转发(Do not forward)”模板进行保护；
7. 预授权
   在受IRM保护的邮件中，插入一个RMS的预授权。这样可以实现客户端的脱机浏览，而不需要联系RMS服务器来获取授权；
8. Outlook保护规则（需要Outlook 2010/Exchange Server 2010 SP1）
   在发送邮件之前，通过应用 Outlook 2010 中的RMS模板，来使用信息权限管理 (IRM) 保护邮件。

要使用RMS，特别是进行解密工作，需要特殊的权限；Exchange为了简化管理，并且减少Exchange与RMS直接的访问请求（用于获得RMS授权），在安装Exchange Server 2010时，会在活动目录中创建一个专门的用户帐号，显示名称为FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042。将这个帐号加入到RMS的Super Users组中即可获得相应的权限。后面会再作说明。

Exchange与RMS的集成主要分为3个步骤：

1. 安装RMS并注册服务连接点（Service Connection Point/SCP）；
2. 设置Exchange在RMS服务上能够使用的权限；
3. 创建并配置RMS的Super Users组。

安装Rights Management Services

在Windows Server 2008/R2中，RMS是作为操作系统的组件直接提供的，不再像Windows Server 2003中需要额外下载并安装。要实现Exchange Server 2010与RMS的集成，运行RMS的操作系统需要是Windows Server 2008 R2，或者Windows Server 2008 SP2，并且安装了KB973247补丁。通过Windows Server 2008/R2的服务器管理控制台，通过添加角色菜单，启动RMS的安装向导。

1. 选择Active Directory Rights Management Services，向导会提示需要安装IIS角色，点击Add Required Role Services进行添加
   
2. 复核需要安装的角色
   
3. 在RMS介绍页面点击Next，进入到选择RMS的服务页面，如下图所示。其中没有核选的Identity Federation Support是用于与ADFS集成的。
   
4. 选择创建一个新的AD RMS Cluster
   
5. RMS将使用SQL数据库作为存储。可以使用Windows自带的数据库引擎，也可以指定一个已经安装好的SQL实例。
   
6. 指定RMS服务的运行帐号，这个帐号需要是域帐号，不能是域管理员帐号，并且已经加入到本机的Local Administrators组里
   
7. 选择RMS Cluster的密钥存放位置
   
8. 输入用于灾难恢复的密码
   
9. 指定RMS使用的IIS站点名称
   
10. 指定RMS的发布位置和访问方式
    
11. 指定RMS使用的服务器证书友好名称
    
12. 后面是关于IIS的组件安装，接受默认配置即可
13. 检查配置信息，点击Install开始安装
    
14. 如果已经在其它服务器上安装了RMS Cluster，需要额外添加一台服务器，可以在前面第4步时，选择Join an existing AD RMS cluster
    
15. 输入已经存在的RMS服务器所使用的SQL数据库信息
    
16. 输入已经安装的RMS上，用于密钥保护的密码
    
17. 输入本机用于运行RMS服务的帐号
    
18. 选择本机上用于发布RMS的IIS站点
    
19. 接受关于IIS的默认配置
20. 复核配置信息，点击Install开始安装
    

需要注意的是，不支持在实际生产环境中，将RMS与Exchange安装在同一台服务器上。

配置RMS的访问连接点SCP

安装好RMS后，打开管理工具中的RMS管理控制台，打开服务器的属性页面后，切换到SCP页面，可以看到SCP的值，这是一个URL，RMS的用户将使用这个URL来进行访问：

这个属性会被记录到活动目录的Configuration中，位置如下：

设置RMS的访问控制权限

RMS通过Web Service方式来提供服务。默认情况下，这些Web Service的权限（Discretionary Access Control List /DACL）是受到限制的，Exchange服务器没有足够的权限来实现对RMS的调用。需要手动指定正确的权限，才能够实现Exchange与RMS的集成。步骤如下：

1. 在安装了RMS的服务器上，打开资源管理器
2. 浏览到%systemdrive%\Inetpub\wwwroot\_wmcs\Certification
3. 选中ServerCertification.asmx，打开其属性页面，切换到安全，然后点击编辑
4. 添加活动目录中的Exchange Servers组，并设置为允许“读取”和“读取及运行”（”Read & execute” 和 “Read”）
   
5. 如果访问控制列表中没有AD RMS Service Group组（这是一个本地组），那么重复第4步，添加该组，权限也是允许“读取”和“读取及运行”
6. 应用更改后，关闭属性对话框
7. 如果RMS Cluster中有多个成员，需要在每个成员上重复前面的操作

设置RMS Super Users组

RMS的Super Users组中成员，可以不受限制地访问所有被IRM保护的数据，也就是说，该组的成员可以进行解密工作。默认情况下，Super Users组是禁用状态，需要手动进行启用。同时，这个组需要是一个启用了邮件功能的通用组（universal group ）。前面提到的FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042用户帐号需要加入到这个组中，这个帐号是系统邮箱，从Exchange Management Console中是看不到的，需要使用Exchange Management Shell命令行工具，通过Add-DistributionGroupMember 进行添加。

1. 在Exchange Management Console中，创建一个名为RMS_SuperUsers的通讯组
2. 打开Exchange Management Shell，输入命令
   Add-DistributionGroupMember RMS_SuperUsers -Member FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
3. 打开RMS管理控制台，展开Security Policies，右键单击Super Users，选择Enable Super Users
   
4. 将前面创建的RMS_SuperUsers组选入
   

在Exchange中检查IRM是否可用

配置好前面的步骤后，Exchange Server 2010就可以实现利用RMS进行邮件数据保护的功能了。使用前，可以检查一下配置是否正确。

1. 打开Exchange Management Shell
2. 运行命令Get-IRMConfiguration，确保其中的InternalLicensingEnabled是True状态。
   
3. 运行命令Test-IRMConfiguration -Sender User@Sample.com
   其中的User@Sample.com是一个Exchange邮件用户的邮件地址
   

现在，就可以确定Exchange与RMS的集成成功了。后面会讨论用户如何使用RMS来保证邮件安全。

原创文章，转载请注明出处。George Wu

利用Windows Server Backup备份Exchange DAG

Exchange Server 2010在部署了DAG模式之后，由于每个数据库都有至少2个复制副本，从理论上讲，对数据库进行备份的工作已经不再像以前那么重要。一般来说，如果DAG包含多于3个节点，而每个数据库有多于3个复制副本，那么这些服务器同时宕机，或者这些副本同时损坏的可能性已经极低。在大多数情况下，可以通过对损坏的数据库副本进行reseed进行恢复，而不再需要从备份中恢复了。

 

对于DAG数据库的备份，主要的作用在于，如果用户误删除了邮件，并且已经超过了恢复周期（默认是14天），无法直接恢复的情况下，才会考虑从数据库备份中恢复邮件数据。

 

对于已经启用了DAG的数据库，利用Microsoft自己的产品进行备份的话，可以使用Windows操作系统自带的Windows Server Backup组件，也可以利用System Center中带的DPM Data Protection Manager。本文讨论的是使用Windows Server Backup进行备份的方式。

1. 通过Windows Server 2008/R2的服务器管理器，从添加组件（Features）中，添加Windows Server Backup组件
2. 对于每一个DAG节点，修改注册表。定位到：HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters
   添加双字节数据，名称为EnableVSSWriter，类型为DWORD，设置值为0
3. 对于每一个DAG节点，重启Microsoft Exchange Replication服务
4. 先检查一下数据库所使用的事务日志的数量。本次测试时，在备份前日志文件夹的文件数量为183个
   
5. 打开Windows Server Backup管理器
6. 在右边的操作栏中，点击备份
7. 选择自定义要备份的数据
8. 选择存放Exchange数据库的目录，然后点击高级
   
9. 在高级中，切换到VSS Settings页面，选择VSS Full Backup
   
10. 指定备份位置。完成备份设置向导后，开始备份
11. 备份完成后，从Exchange Management Console中，检查数据库的状态，可以看到，数据库上一次完整备份的时间已经更新
    
12. 再次检查事务日志数量，备份完成后，日志数量已经减少到31个
    

原创文章，转载请注明出处。George Wu

利用网络负载均衡来实现客户端访问的高可用性

Exchange Server 2010的3个核心服务器角色，Mailbox/HUB/CAS等，在实现高可用性时，有不同的解决方法。所谓的“高可用性”，通俗地讲，就是在有限台服务器故障（硬件中断、软件故障、安装补丁需要重启等）的情况下，整个系统服务不出现中断。

 

对于邮箱服务器，前面提过可以利用Exchange Server 2010的DAG方式来实现；对于集线器传输服务器，在Exchange Server 2010中默认会使用Shadow Redundancy功能，该功能能够自动实现传输的高可用；而对于客户端访问服务器，就需要使用网络负载均衡（Network Load Balancing，NLB）来实现了。

 

NLB可以使用硬件来实现，也可以使用软件进行配置。本文将介绍使用Windows操作系统自带的NLB功能来实现的方式。在所有的Windows Server操作系统上，都包含有NLB功能组件，并非必须使用企业版操作系统。

 

首先需要注意的是，如果Exchange Server 2010是安装在Hyper-V上的虚拟机，那么需要根据Hyper-V的版本进行不同的配置。

在Windows Server 2008 R2的Hyper-V上,可以直接启用“Enable spoofing of MAC addresses”选项。

在Windows Server 2008上，就需要按照以下这篇KB的内容进行配置了。
http://support.microsoft.com/kb/953828

 

配置好虚拟机的属性后，就可以进行NLB的配置。这个步骤实际上是Windows的配置，与Exchange本身没有什么关系。

1. 安装网络负载均衡组件。这个组件可以通过Windows Server 2008/R2的服务器管理器，在添加功能的模块中进行。所有计划加入NLB的服务器上，都需要进行安装。
2. 安装结束后，在任意一台服务器上，从管理工具中，启动网络负载均衡管理器
3. 右键单击根节点，选择New Cluster，启动NLB配置向导
4. 连接到计划配置NLB的任意节点，连接后，会列出可供NLB使用的网络连接，点击下一步。
   
5. 选择需要部署NLB的网卡，点击下一步
   
6. 设置NLB虚拟服务器IP地址
   
7. 设置NLB虚拟服务器名称，以及NLB的运行方式
   
8. 定义端口规则。默认情况下，所有的端口都会开放。点击Finish结束向导
   
9. 回到NLB管理器，可以看到该节点已经添加，并且注意右边的Status是“已聚合Converged”状态。
   
10. 接下来，向这个NLB中添加主机。右键单击刚刚创建出的NLB虚拟机名，选择“Add Host”
    
11. 连接到另一个计划加入NLB的机器
    
12. 选择供NLB使用的网卡
    
13. 选择端口规则。点击Finish完成加入节点的工作
    
14. 从NLB管理器中，检查网卡均处于“已聚合”状态。NLB的创建完成
    
15. Windows的NLB最多可以支持32个节点。如果需要添加更多的节点到NLB中，重复前面的10～14步即可。

原创文章，转载请注明出处。George Wu

配置Exchange Server 2010 DAG

从Exchange Server 2003到2007，再到Exchange Server 2010，对于数据库的高可用性经历了简单=>复杂=>简单的演化过程。Exchange 2003时，只有一种模式，就是先构建Windows群集，使用共享存储的方式实现；Exchange Server 2007出现了许多新概念：LCR/SCR/CCR/SCC，以及这些方式的配合使用，可以成功地让有经验的Exchange 2003管理员晕头转向；Exchange Server 2010利用数据库可用性组(Database Availability Group，DAG)这种新功能，实现了数据库高可用性解决方案。除了对Exchange 2007多种高可用性方案的简化外，这一模式的优点是显而易见的。

首先，DAG模式使Exchange的管理员从配置和维护Windows群集的工作中解放出来。DAG的配置虽然会在内部调用Windows群集模块，但在整个配置维护过程中，不需要和Windows群集打交道，一切都可以从Exchange管理工具中进行。

其次，实现了DAG成员的灵活管理。在原来的版本中，都是需要先配置Windows群集，然后再安装Exchange。DAG节点的加入/去除都很灵活，可以随时进行。

第三点，DAG不需要共享存储，对于企业来说，可以节省在硬件设备上的投入。

DAG可以看成是Exchange Server 2007 CCR功能的高级版本。CCR中只能配置两个节点，而DAG的节点数扩展到了16个。

DAG的系统要求是，Windows操作系统必须是企业版，DAG的成员必须在同一个Windows域中。而Exchange Server 2010自身，使用标准版依然可以实现DAG功能。

完整的DAG创建可以分为两个部分：创建DAG群集；创建数据库副本。需要注意的是，DAG要求数据库副本配置的存储位置在所有的的节点上一致，因此建议在配置DAG之前，先移动数据库的存放位置，这个位置包括数据库位置和日志位置，否则创建DAG之后再进行移动就耗时过长了。

安装好Exchange Server 2010的邮箱角色后，就可以进行DAG的创建了。

1. 打开Exchange Management Console，定位到Organization Configuration=>Mailbox
2. 点击中间结果栏中的“Database Availability Groups”，然后点击右边操作栏中的“New Database Availability Group…”启动DAG的配置向导
3. 输入以下信息，然后点击新建（New）：
1. DAG名称：这个名称其实就是Windows群集虚拟机的名称，将用于Windows域成员及DNS注册；
2. 见证服务器：一台加入域，运行着Windows Server版操作系统的机器
3. 见证目录：见证服务器上的一个文件夹
   
4. 如果提供的见证服务器上没有安装Exchange Server 2010，会收到以下警告信息，需要把活动目录中的Exchange Trusted Subsystem组添加到见证服务器的本地管理员组里，以确保权限的正确性。如果使用的见证服务器是域控制器，那么需要把Exchange Trusted Subsystem添加到活动目录的Builtin\Administrators组里。

   

5. 向数据库可用性组中添加成员：回到Exchange Management Console，可以看到在Organization Configuration=>Mailbox=>Database Availability Groups里看到前面创建的DAG。右键单击后，选择“Manage Database Availability Group Membership”
   
6. 将另一台安装好邮箱角色的Exchange Server 2010服务器加入，以下是运行结果
   

这样就完成了DAG本身的创建工作，接下来是为邮箱数据库添加复制副本的工作。

1. 在Exchange Management Console中，依次打开Organization Configuration=>Mailbox=>Database Management
2. 右键点击其中的邮箱数据库，然后选择“Add Mailbox Database Copy..”。要确保选择的邮箱数据库是在DAG的成员节点上。
   
3. 指定需要放置数据库副本的DAG成员
   
4. 为DAG成员节点上的所有邮箱数据库重复上面的操作
5. 现在，从EMC中就能够看到DAG的成员情况，以及数据库的复制情况了
   

DAG是一个比较大的话题，这里只介绍了DAG的创建方式，而且是最简单的双节点模型。更多信息，将在后续文章中讨论。

原创文章，转载请注明出处。George Wu