ghjconan's blog

[急聘]诚聘MSSQL DBA一名

转眼间五年过去了，这里再次感谢盆盆老大当年的提点。当时在ITECN发Windows Server 2008翻译文章还历历在目，转眼之间Windows Server 2012就要横空出世了。

 

小弟不才，最近被委任为项目主管，在做好技术工作的同时，又要管理项目团队的诸多事宜，因此各位等待FIM 2010的更新的朋友还请原谅，该系列文章的巨坑不知道何时会填上。至于Windows Server 2012 的系列文章会在RC发布后进行更新，还请大家期待。

 

现因为项目需要，诚聘精通MSSQL DBA一名（非电话/邮件技术支持）。该项目为微软CSS内部项目，v-职位，工作地点在上海紫竹。

 

除了一般MSSQL DBA所具备的专业技能（数据库管理，报表开发等等），Windows PowerShell脚本开发将做为可选项，在最终面试中起到一定作用。如果您对微软其它产品也有所涉猎，请在邮件中注明。

 

除了技术技能之外，应聘者需要具备扎实的英文技术文档读写能力，您所撰写的文档将直接被资深的支持工程师审核然后在微软相关站点发布。

有意者请发邮件至 ghjconan#itecn.net，并附上您的中英文简历，一篇200字左右的以英文撰写的排错案例分析。如果你有个人网站或者博客地址也请一并附上。如果您有更多关于本项目的问题，也请通过该邮件地址进行沟通。

 

英雄不问出处，工龄也不是问题，只要您的能力达标，即可应聘该职位。欢迎各位踊跃投递简历，谢谢。

Windows Server 8 Beta 介绍 (07) - 基于策略的IP地址分配（下）

今天，我们来看下Windows Server “8” Beta中和基于策略的IP地址分配有关的PowerShell命令。不过按照习惯呢，还是快速浏览下所有和DHCP有关的命令。获得这个列表的方法如下：

Get-Command *DHCP* -CommandType Function | Group-Object Noun | Sort Count -Descending | FT -A

大家第一眼看上可能会有点晕，实际上再看1分钟左右就知道是怎么回事了，所有名称前缀是由DHCPServer+v[4|6]+子功能名组成的，因此你可以修改刚才的命令将返回的列表缩减到和IPv4有关的命令上，并修改名词部分来更好的看清楚系统管理员可以在PowerShell执行DHCP服务器的哪些配置。

基本上还是很好理解，有常见的Scope操作，然后有对Windows Server 08 R2中新增加的Filter的操作，像保留地址，排除范围这些设置都能操作。当然也提供了对Windows Server “8”中新增加的DHCP Failover功能的操作。不过我们今天的目标是和Policy有关，因此最后锁定的命令是：

因为在中篇的实验中已经建立好了相关策略，此时我就想直接运行Get-DhcpServerv4Policy总会返回什么点东西吧，可惜事不如愿，没有返回任何结果。好吧，那我就来看看有哪些参数。

好吧，Name和ScopeID参数应该是我想要的，先来看看Name的结果。

嗯，可以理解，因为我的策略设置在指定的Scope上，看来Get-DHCPServerv4Policy暂时没法根据名称获得整个列表，那也没关系，那就老老实实的指定ScopeID咯。但ScopeID长啥样子啊，是数字1,2,3还是其它形式？这时我们就需要用Get-DHCPServerv4Scope来看下，结果如下：

原来如此，ScopeID就是之前设置的IP网段，好，那么再来运行Get-DhcpServerv4Policy。

这个结果就是我们想要的了。大家可以通过以上例子可以看出来，由于Windows Server “8” Beta中包含数量众多的Windows PowerShell cmdlets一个个记住那是不现实的，最重要的是学会合理联想，要明确知道我正在进行操作的对象是什么，它的英文名词是什么，哪些命令可能和它有关。希望大家理解这个学习思路。

接下来要回答的是，假设要向多台DHCP服务器创建相同的策略，那该如何做呢？写下这些文字的时候，我也不知道，反正我知道添加这个动词对应的英文是Add，那么就来看看Add-DhcpServerv4Policy有哪些参数。

嗯，不错，有ComputerName参数，但是参数类型是String，而不是String[]，意味着需要借助foreach针对多台DHCP服务器同时执行添加策略操作。接下来，我就向CNSHRRASSVR01,CNSHADDSDC01这两台DHCP服务器添加名为Test 02的策略。条件是MAC地址满足以00155D01*开始的所有服务器。具体命令如下：

$dhcpServers=@("cnshrrassvr01","cnshaddsdc01")
$dhcpServers | %{Add-DhcpServerv4Policy -ComputerName $_ -Condition "Or"-Name "Test 02" -Description "Test 02" -ScopeId "192.168.2.0" -MacAddress "EQ","00155D01*" -Verbose}

这里我也浪费了一点时间去探索，因为现阶段没有该命令的帮助信息，尤其是例子，所以一切对我来说都是未知，我能做的就是根据已有信息去推测命令开发者的想法。以下截图中，第一个例子是命令正确运行后的结果，下面则是我猜测的两个例子，请大家看过之后忽略。

因为这条策略只是用来测试的，我可不想它干扰到后续的其它测试，因此我要从CNSHRRASSVR01,CNSHADDSDC01上移除这两条策略，因为有了之前的经验，一切就变得轻松了，命令如下：

$dhcpServers | %{Remove-DhcpServerv4Policy -ScopeId "192.168.2.0" -Name "Test 02" -ComputerName $_ -Verbose}

的确，在没有完整文档的帮助下，去使用相关Windows PowerShell的确有点困难。但是我希望各位从我的思路中掌握一点东西，来帮助自己更好的学习Windows Server “8”中有关的PowerShell命令。因为我个人精力有限，无法去涵盖所有新功能背后的Windows PowerShell命令，所以我会很开心的看到有朋友站住来和大家分享经验。

好了，本次关于Windows Server “8”中基于策略的IP地址分配的介绍就到此介绍，下次将接着为大家介绍我的其它冒险经历，敬请期待！

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

Windows Server 8 Beta 介绍 (06) - 基于策略的IP地址分配（中）

今天，我们来看下如何配置基于策略的IP地址分配。先来描述下具体环境，由于我是用的测试环境和TechNet文档中的配置并不完全一致，请大家注意分别。

我的测试环境下，Hyper-V主机上配置了三块网络类型为Internal的网卡，分别模拟上海，北京，广州三个站点，对应的IP网段是192.168.2.0 - 192.168.4.0，而192.168.1.0是我的宽带路由器的网段，用于模拟外网，总体来说这是非常简单的网络环境。大家在图中看到的CNSHRRASSVR01这台服务器上启用了路由和远程访问服务以及DHCP服务为以上三个内网自动分配IP。而三台域控制器上也分别安装了DHCP服务。并且利用Split-Scope向导对CNSHRRASSVR01和三台域控制器上的DHCP服务器角色进行了配置。同时在测试网络中还有两台测试用服务器CNSHTSTSVR01和CNBJTSTSVR01。

至此基础环境的配置工作就到此结束了，接下来我们就来看看在Windows Server “8”Beta中新增的DHCP服务策略新建向导。大家也不用担心，向导秉承Windows一向的简洁和明了，通过几次单击就能完成配置。

DHCP策略配置概览

首先通过上篇的描述，大家知道我们可以在服务器和地址池级别来配置策略，这里的演示则是以地址池级别的配置为例进行说明的。要打开配置向导，各位需要选中某个地址池下的策略节点，然后单击右键，在出现的菜单中单击新建策略，打开策略配置向导。配置向导的第一页需要各位输入策略名和描述信息，各位可以根据具体情况填写。

然后向导第二页是策略的条件配置界面，也就是客户端发送的信息中包含满足条件的关键字时，就采用策略。各位可以设置多条策略，然后每条策略之间可以是与或者或的关系，也就是客户端发送的信息是否需要满足所有条件或者只要满足一项条件就应用策略。这里使用大家最熟悉的MAC地址为例进行说明。目前Beta中条件的操作符仅包含等于和不等于，然后条件值处可以使用通配符。然后我这里指定的条件所有MAC地址满足以00155D01开始的Hyper-V虚拟机，在实际环境中大家可以按需指定。因为MAC地址的的前三位是和厂商绑定的，大家可以从IEEE的这个地址下载持续更新的MAC地址分配信息。

配置完成后，单击下一步来到指定IP地址子范围配置页面，我们可以在一个大的IP地址范围中为满足策略的计算机保留一定数量的IP地址。这里我就不指定了，直接单击下一步继续。

在接下来的配置页面中，可以指定DHCP的相关选项，也就是说我们可以在这里为满足条件的计算机设置不同的DHCP选项，比如DNS服务器地址，DNS后缀，网关。完成之后单击下一步，就进入概要界面。包含所有条件以及配置信息。

DHCP策略效果演示

接下来，我们来看下策略的效果，之前我新建了一条策略，指定了一个新的网关，192.168.2.253。它和192.168.2.254的区别在于它的网络延时和带宽。为了更好的体现出这两个网关的区别，可以首先使用 fsutil file createnew c:\users\administrator.corp\downloads\test.txt 104857600 来新建一个100MB的文件用于复制测试。而复制工具可以使用robocopy，因为它能详细提供复制任务的状态。

首先假设DHCP策略没有启用，也就是说客户端（CNSHTSTSVR01）拿到的是192.168.2.254这个网关地址，我们可以使用tracert看下网络情况，然后再用robocopy看下复制结果，结果如下：

在这个例子，我向位于北京站点的CNBJTSTSVR01服务器的共享文件夹上复制了一个100MB的文件，根据robocopy的报告，通过192.168.2.254这个网关进行复制的凭据速度大概在133MB/min。接下来激活CNSHRRASSVR01上的DHCP IP地址分配策略，让CNSHTSTSVR01拿到192.168.2.253这个网关地址，然后在来对比下复制的结果。

这里大家可以看到速度明显不如第一次快了。这个实验的目的主要就是为了说明，在Windows Server “8”中DHCP IP地址分配策略，系统工程师可以配合网络工程师完成一些精确的带宽使用控制。

接下来回答上篇提到的问题，首先如何区分笔记本和移动设备，我们可以通过IEEE提供的MAC地址分配表，以及实际环境中采集的数据，分析并指定策略中使用的条件。第二个问题，服务器客户端混杂环境下的IP地址分配，其实和第一个问题类似，还是依靠MAC地址来进行区分。第三个问题，大型Datacenter中精确的网络流量控制，其实就是这篇文章中演示的。

结语

以前要完成相同的工作，系统工程师可能要求助于网络工程师在网络设备上进行复杂的配置，现在我们可以和网络工程师一起先行分析网络流量，然后合理的根据MAC地址分配IP地址及相关的网关和DNS服务器信息，然后在之后的运维中尽量减少对网络部分的修改，保证网络基础架构的健康。

本次关于Windows Server “8”Beta 中的DHCP新功能，基于策略的IP地址分配就讲到这里，在下篇我们来看看相关的PowerShell命令，因为在Beta版中我发现一台服务器上设置的IP地址分配策略在图形化界面中是无法导出的，当然聪明的各位马上想到了netsh命令，但是呢，netsh命令也将慢慢退出历史舞台了，所以现在正是一个非常好的时机学习PowerShell。

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

Windows Server 8 Beta 介绍 (05) – 基于策略的IP地址分配（上）

大家好，今天要介绍的是Windows Server 8 Beta中DHCP服务器角色新增加的一项非常棒的功能，基于策略的IP地址分配。系统管理员可以通过这项新功能更加准确的控制生产环境中的IP地址分配。

首先我们来看看这项新功能所要解决的典型问题。第一个问题，日益增加的移动设备对无线网络IP地址的需求，这个问题相信大家深有体会。一转眼，离一代传奇操作系统Windows Server 2003发布快十年了，当时802.11g标准也正在酝酿中，可能很少人会预料到无线网络可以在如此短的时间内普及到全球范围内，变成一项无处不在的技术。现在大多数朋友的手机可能都有无线网卡，随时随地利用WIFI热点进行无线上网。除了手机之外，笔记本电脑也需要使用无线网络来访问相关资源。因此对于企业IT部门而言，原先针对笔记本电脑设计和规划的无线网络IP地址划分可能无法满足日益增长的需要。

第二个问题是同一网段内存在多种类型的设备，这种情况在无线网络中也是很常见的。此时企业IT可能会希望对笔记本用户和手机用户取采取不同的租约策略。因为手机用户有着移动性强的特点，来无影去无踪，如果租约时间过长会导致有限的IP地址迅速被耗尽。

第三个问题是在大型数据中心中，由于经常会有客户请求使用大量虚拟服务器资源为某一项面向公众的活动提供服务支持，比如大型的市场宣传活动，有大量的客户可能在短时间内访问特定的站点资源。比如中国用户最有切身体会的就是春运购票，那么假设你作为一家云提供商在面临此问题时如何进行解决呢？

接下来，我们就来看看Windows Server "8" Beta中这项新的基于策略的IP地址分配功能，随后再来看看这项功能是如何为以上问题提供解决方案的，当然在介绍过程中按照我的习惯将会穿插介绍Windows PowerShell的相关命令。

基于策略的IP地址分配

首先基于策略的IP地址分配在定义策略时可以通过以下几个DHCP包中的字段来完成筛选工作，分别是Vendor Class，User Class，MAC address，Client Identifier以及Relay Agent Information。其中最为广大中国IT专业人士熟悉的是MAC地址，其次是Relay Agent Information。在知道我们可以根据何种条件定义策略后，就要看下基于策略本身可以控制哪些设置。首先是IP地址范围，系统管理员可以在某个DHCP地址池中再次划分一个小的IP地址区域供符合条件的客户端使用。然后是标准的DHCP选项，也就是网关地址，DNS地址，DNS后缀啊等等设置。接着是供应商的特定选项，比如微软提供了在关机时释放DHCP租约的选项，虽然可能该选项用的人不多。

然后是策略的处理顺序。由于管理员可以在一台DHCP服务器或者一个作用域中指定多条策略，因此策略使用处理顺序的（Processing Order），这一点当我们在建立多条策略之后就可以看到，如下图所示：

系统管理员可以通过单击右键然后在出现的菜单中调整这个顺序。如果管理员同时在服务器和地址池级别同时定义了策略，服务器将同时采用这两项策略，并首先验证地址池级别的策略，然后验证服务器级别的策略。而地址池基本的策略则根据图上的应用顺序来决定。如果管理员没有在地址池级别定义策略的话，服务器策略将会被应用到地址池级别。

当客户端将DHCP请求发送给DHCP服务器后，DHCP将会按照DHCP中继代理的网关地址或者DHCP服务器上接收到DHCP请求的网卡来判断将使用哪一个地址池来分配IP地址。然后接下来DHCP服务器将会按照之前所说的顺序来验证策略。当策略满足时，DHCP服务器将会把包含特定地址的数据包发送给客户端。当然之前提到了管理员可以指定多个小的地址范围供客户端使用，此时DHCP服务器的IP地址分配顺序是先从低位地址范围内选取可用IP，如果没有可用IP则从高位地址范围内选取可用IP，如果此时还没有空闲IP地址的话，DHCP服务器将处理下一条策略，如果所有匹配策略中的地址池中没有可用IP，那么DHCP服务器将丢弃客户端的数据包并记录事件。如果客户端的数据包不与任何一条策略相匹配，那么DHCP将从地址池中分配除了策略中保留的地址范围外的一个IP地址。

可选配置信息的分配，比如DHCP。这和之前的IP地址分配类似，相应的客户端配置信息获得过程也将遵守之前描述的规则。当然当管理员配置了多条策略后，客户端将得到的是多条策略的集合。

支持关于IP地址分配背后的一些原理性内容就阐述到此，下篇将描述下具体的配置过程，以及针对今天开篇所提问题的回答，然后一并介绍对应的Windows PowerShell命令，敬请期待。

（上篇更新完成）

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

Windows Server 8 Beta 介绍 (04) –Windows PowerShell Web Access简介 (下)

做为最后一篇关于Windows PowerShell Web Access的介绍文章，今天主要来看下关于Windows PowerShell Web Access的一些细节，方便各位在以后部署时使用到这些比较有趣的细节。主要内容是如何登录到Windows PowerShell Web Access，从Windows PowerShell Web Access退出及其默认超时时间，以及Windows PowerShell Web Access和Windows PowerShell应用程序之间的区别及当前的一些限制。

登录到Windows PowerShell Web Access

大家可能会想，登录还有什么好说的，不就是输入用户名和密码，然后一个回车就登录到远程计算机了。但实际上里面是有很多注意事项的。在开始具体介绍之前，先来回顾下完整的登录界面是长什么样子的：

首先是用户和密码。在中篇的演示中，由于我使用了域账号，所以是使用域账号直接登录的，但是作为一台网关服务器，部署在DMZ区域中是在常见不过的一个场景了。因此，你可以使用承载Windows PowerShell Web Access的网关服务器上的本地账号来通过网关的验证。

然后是连接类型，默认是计算机名，还有一种是Connection URI。不过我相信大多数人看了Connection URI的样子后便不会使用它了，因为实在有点难用。

接下来就是Computer Name，这里指的是你要进行管理的那台服务器的名称。

然后是可选项，又是一组用户名和密码，这很好理解。假设你是用网关服务器本地的帐号来进行验证，然后需要管理企业内网域内的一台服务器，那么势必还需要一个域账号才能登录，因此这里就是输入域账号的地方。

配置名，该选项在中篇中已经介绍了，主要是当管理员创建了自定义的配置文件，限制用户能执行的命令后，需要用户在登录时指定相应的配置名。

验证类型，一般选Default就可以了，还有一种比较常见的是CredSSP，主要是为了解决double-hop的问题，所谓double-hop就是在默认验证的情况，你从计算机A上使用PowerShell远程功能和计算机B建立起了远程连接，然后你在这个远程会话中再次使用Enter-PSSession想与计算机C建立远程连接，但此时你会发现连接无法成功建立或者建立成功之后有很多稀奇古怪的问题，这就是一个比较典型的double-hop的问题，需要使用Enable-WSManCredSSP分别在客户端和服务器启用CredSSP验证，具体可以参见这篇文章。

是否使用SSL，一般情况下选否就可以了。因为默认情况下使用PSRemoting在两台计算机建立起连接后，它们之间的数据流就是被加密的。

端口号及应用程序名，除非你使用第三方定制的一些应用时可能需要更改之外，针对Windows本身而言这两项设置是不需要修改的。

从Windows PowerShell Web Access退出及其默认超时时间

退出也分两种情况，即用户主动退出，Windows PowerShell Web Access强制退出两种。主动退出有几种情况，比如用户单击退出按钮，关闭浏览器窗口或者标签，当浏览器正在运行时关闭客户端，执行exit命令。强制退出则是在已登录用户在超过15分钟后没有任何操作，且用户在五分钟退出倒计时之前没有重新登录的情况下，Windows PowerShell Web Access会执行强制退出操作。下面两张截图显示的是Windows Phone中的强制退出效果。

当然各位可能会认为15分钟这个时间太短了，那么我们可以通过编辑$Env:Windir\Web\PowerShellWebAccess\wwwroot\下的Web.config文件来延长这个时间。由于目前是Beta版，文档和实际配置中的设置可能不一样，所以大家要注意下，如果仅是测试的话可以保留默认值。同时这边还有一个选项是，默认配置情况下每用户最多只能建立三个会话。

Windows PowerShell Web Access和Windows PowerShell应用程序之间的区别及当前的一些限制

既然是一个Web应用程序，那么和原始的Windows应用程序还是有区别的。目前主要有只能显示顶级的进度栏，输入颜色无法修改，PSHostRawUserInterface中有些方法没有实现，以及功能键的变化，当然我个人可能是不会太在意这些限制的，因为我更关注我需要的数据是否能正常显示。

说完区别之后再来看看限制。第一点是已经提到的double-hop的问题，在Windows PowerShell Web Access中依然存在。第二点是你虽然可以启动一个图形界面程序，比如记事本，但是你无法和它交互，这在PSRemoting中也存在。究其原因，就是Windows Session的问题，我们可以透过Procexp.exe观察到，notepad是运行在session 0下的。

第三点是自动完成功能在特定条件下不会正常工作，为了保护敏感信息不被泄露。

第四点是如果需要同时建立起到多个Windows PowerShell Web Access会话，请单击Internal Explorer文件菜单下的新建会话，否则你会看到以下提示。

第五点，如果维护任务需要长时间运行，请使用Windows PowerShell的Job机制。因为Windows PowerShell Web Access会在超时后结束当前会话，所有正在运行的脚本或者命令将被强制停止。

第六点，调整Windows PowerShell控制台大小。默认情况下Windows PowerShell Web Access的控制台大小是固定的，可以使用以下示例命令来调整：

$newSize = $Host.UI.RawUI.WindowSize
$newSize.Width = $newSize.Width – 20
$oldSize = $Host.UI.RawUI.WindowSize
$Host.UI.RawUI.WindowSize = $newSize

好了，本次关于Windows PowerShell Web Access的三篇介绍就到此介绍了，下次我们在来看看Windows Server 8中的其它新功能。

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

Windows Server 8 Beta 介绍 (03) –Windows PowerShell Web Access简介 (中)

接着上篇内容，接下来我们来看看Windows  PowerShell Web Access的四层安全模型。在最后一篇中会介绍下登录Windows PowerShell Web Access的几种方式，Web版和应用程序版本之间的区别，然会来看下目前版本中的一些限制。

安全模型

作为一个最终会面向Internet发布的Web应用，同时又是一个可以接触到企业内部Windows核心管理的Web应用，Windows PowerShell Web Access在设计的时候就已经考虑到了安全上的一些问题，并努力将安全威胁降到最低，保证管理员在享受便利的同时，不会被不法之徒有机可乘。

第一层 IIS的安全特性

首先说明一点Windows Server 8中的IIS的版本已经升至第8版，管理界面虽然和7及7.5相比没有太多变化，但是细节上肯定有所增强，这方面的文档我还没时间看，有兴趣的朋友不妨来看一下。而这里提到的IIS的安全特性就也不是新增的功能，而是之前一直存在的客户端证书验证。我们可以在IIS的站点设置启用客户端证书验证功能，使得只有持有有效证书的管理员才能使用Windows PowerShell Web Access。使用这项设置后，系统管理员就可以在用户名和密码验证之前启用一道额外的安全屏障。因此接下来要做的事就是在服务器端启用强制使用客户端证书验证设置，随后为用户申请相关证书。首先是IIS端的设置，和以前相比没有太多变化。

接下来是用户证书的申请，和之前版本的Windows也是类似，然而导出向导这里却有一个不同，可以发现在安全性这里增加了一项组或用户名的设置，这也大大方便管理员在企业分发.pfx的证书文件，即使.pfx文件不小心落入他人之手，但由于该人的组成员关系中不存在对应的组，因此也无法使用这种证书。这里因为我要在测试域之外使用这张客户端证书，因此还是选择旧有的密码方式来保护私钥的安全。导出向导剩下的几步也和以往相同，这里就不多介绍了。

在客户端安装完证书后，再次访问Windows PowerShell Web Access站点，会得到来自IE的提示，让我们选择一张客户端证书。

这里选择刚才申请的客户端证书，然后点击OK，便会再次来到Windows PowerShell Web Access的登录界面。刚才我们看到的是IE中的客户端证书对话框，接下的则是Firefox中的。

其结果还是一样的，我们可以在Firefox中正常使用Windows PowerShell Web Access。

第二层 Windows PowerShell Web Access 基于表单的网关验证

这一层比较好理解，就是我们必须在表单中输入正确的帐号和密码才能继续使用Windows PowerShell Web Access。这里的帐号可以是一个合法的域账号，也可以是Windows PowerShell Web Access的本地服务器上的帐号。如果该账号的有效性得到了验证，Windows PowerShell Web Access便会进一步检查授权规则中的相关设置，如果授权检查通过，Windows PowerShell Web Access便将用户的凭据发送给目标计算机。

第三层 Windows PowerShell Web Access授权规则

这一层在上篇的介绍中，大家已经看到了规则的效果，这里再次重申下，这些规则是用户在通过网关的验证后，在用户能在目标计算机验证之前发生的。接下就通过一个非常小的演示来说明这个规则。首先在测试环境中我已经准备好了三台域控制器（可以推广到其它成员服务器），分别隶属上海，北京和广州这三个站点。现在假设Contoso公司的管理策略是，只有各站点的管理员才能通过Windows PowerShell Web Access对各站点的服务器进行管理，那么该如何实现这个需求呢？首先当然是要做一些准备才行，这里可以使用Windows PowerShell Active Module中的命令来创建相应的组织单元，组和对应的管理员帐号。具体命令其实和Windows Server 2008 R2中是一样，因此这里就略去了，各位可以看看我以前的系列文章。主要使用到的cmdlets是New-ADOrganizationalUnit, New-ADGroup, New-ADUser, Enable-ADAccount和Add-ADGroupMember。最后记得将相关组加入Domain Admins组，这是因为默认的Session的访问控制项决定的。

创建完成之后，在来到CNSHUTILSVR01这台机器上配置对应的Windows PowerShell Web Access授权规则。

创建规则时需要注意计算机名必须以FQDN形式输入，当然如果服务器数量比较多的话，可以通过建组来解决。但是组的话也必须符合“domain\user”的格式。授权规则建立好之后，再来访问下Windows PowerShell Web Access。这里使用的是shanghaiadmin这个帐号去访问CNBJADDSDC01这台位于北京的服务器，由于授权规则的作用，可以发现最终用户是无法登录到Windows PowerShell Web Access的，同时在事件日志中也产生了相应的记录，方便管理员分析日志发现是否存在可疑登录。

第四层 目标计算机的身份验证和授权规则

最终的安全保护层是由目标计算机自身的安全配置构成的。用户必须拥有合适的权限才能访问目标计算机，而这项权限和用户使用Enter-PSSession或者New-PSSession时的验证机制一样，具体权限可以通过运行以下命令查看：Get-PSSessionConfiguration。注意我们需要关注的是名为microsoft.powershell和microsoft.powershell32两项设置。命令的运行结果如下：

如果需要修改这里的访问控制权限的话，可以通过以下命令调出访问控制权限修改对话框：

Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI

该项设置也是控制谁能使用PSRemoting功能的关键所在，如果该项访问控制设置不当的话会引起PSRemoting工作不正常，请大家牢记。因为Windows PowerShell Web Access实质上是通过PSRemoting和远程计算机之间建立起连接的，这也是为什么在连接之前必须保证PSRemoting正常工作的原因。

接下来，要完成的一个实验是，创建一个自定义配置文件，并加载管理员创建的仅用于企业内部的PowerShell模块，其中包含针对特定服务器的命令，整个过程如下。首先创建名为test.psm1的模块文件，里面包含的内容为一个显示欢迎消息的测试函数：Function Show-WelcomeMessage {Write-Host "Welcome to Contoso!"}。接下来准备名为test.ps1的脚本文件，内容为：

Import-Module C:\Scripts\test.psm1
(Get-Command Disable-PSRemoting).Visibility = "Private"

主要作用是导入刚才自定义的模块，并禁止用户执行Disable-PSRemoting命令。然后我们需要使用Register-PSSessionConfiguration注册一个名为PSWA的新配置文件并将启动脚本设置为刚才新建test.ps1。具体命令和执行效果如下：

Register-PSSessionConfiguration -Name PSWA -StartupScript C:\Scripts\test.ps1

完成之后，我们再登录Windows PowerShell Web Access页面进行登录，注意此时登录时要展开可选连接设置，在配置名称输入PSWA，也就是刚才我们新建的配置文件。

登录后，先来看看自定义的模块有没有加载，即能不能运行Show-WelcomeMessage命令，随后再来看看Disable-PSRemoting命令是否禁用：

如同我们设想的一样，自定义的配置文件能正常工作。

以上内容就是关于Windows PowerShell Web Access安全模型的简单介绍，其中安全模型的第四层还有很多值得扩展的内容。相信大家看完这篇介绍之后，也确信了Windows PowerShell Web Access是一项能给管理员在提供远程管理便利性的同时，又能保证安全的Web应用，相信在以后Windows Server 8正式推出后，Windows PowerShell Web Access会被越来越多的人接受和使用。

本次关于Windows PowerShell Web Access的介绍就到此结束了，下次我们将来看看Windows PowerShell Web Access剩下的一些细节信息，敬请期待。

(中篇更新完成)

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

Windows Server 8 Beta 介绍 (02) –Windows PowerShell Web Access简介 (上)

计划总是赶不上变化，原来想为大家介绍Windows Server 8 Beta中大家期待已久的Hyper-V 3.0，但是今天还是调整下计划，为大家介绍Windows Server 8 Beta中提供的全新的Windows PowerShell Web Access。

众所周知，到Windows PowerShell 2.0为止，原生的PowerShell都是一个纯粹的桌面应用程序，虽然第三方公司比如Quest提供了基于Web的解决方案，但是大家可能还是比较期待微软提供原生支持的，因此我们非常幸运的在Windows Server 8中看到了Windows PowerShell Web Access。下面就来看看关于Windows PowerShell Web Access的一些信息。

Windows PowerShell Web Access概述

Windows PowerShell Web Access是微软在Windows Server 8 Beta中新增加的一项功能，它主要扮演了Windows PowerShell网关服务器这样的一个角色，使得管理员可以通过浏览器或者移动设备访问并管理企业内部服务器。由于本身是基于Web平台，因此可以广泛的被客户端设备支持，同时客户端也不需要安装Windows PowerShell，远程管理软件或者浏览器插件来访问Windows PowerShell Web Access。

运行Windows PowerShell Web Access的先决条件

为了运行Windows PowerShell Web Access，我们必须安装.Net Framework 4.0及Windows PowerShell 3.0。然后既然被称为Windows PowerShell Web Access，那么IIS也是必不可少的。由于管理员使用Windows PowerShell可以执行一些潜在对生产环境产生重大影响的操作，因此还需要提前规划Windows PowerShell Web Access的使用者，并在IIS及Windows PowerShell Web Access授权规则中设置好相应的规则，之后还会详细介绍这个过程，请大家留意。

浏览器和移动端设备支持

目前主流的桌面及移动设备都支持访问Windows PowerShell Web Access。比如微软自家的IE8-IE10，Windows Phone 7.0和Windows 7.5。Mozilla的Firefox，Apple的Safari，Google的Android和Chrome都可以访问。

Windows PowerShell Web Access安装三步曲

目前在Windows Server 8 Beta版中，Windows PowerShell Web Access还不能做到仅仅通过添加删除服务器角色和功能安装向导就完成安装和配置工作，管理员还需要手动完成一些设置工作才能使用Windows PowerShell Web Access，然而大家不用担心，这些配置工作也可以通过cmdlet来完成。具体步骤如下：

• 安装Windows PowerShell Web Access
• 配置Windows PowerShell Web Access
• 配置授权规则及站点安全

安装Windows PowerShell Web Access

安装Windows PowerShell Web Access的过程其实并不复杂，习惯图形界面的朋友可以打开Server Manager，然后通过添加删除服务器角色和功能向导，在服务器功能页面中找到Windows PowerShell Web Access项来进行安装。

如果是Windows PowerShell的狂热粉丝的话，可以在以管理员身份（提升权限）的Windows PowerShell控制台中通过以下命令来进行安装：

Install-WindowsFeature -Name WindowsPowerShellWebAccess -ComputerName <computer_name> -IncludeManagementTools -Restart

（CNSHRRASSVR01是另一台虚拟机，这里的截图是为了方便大家看下安装过程，随后我将使用的是另一台虚拟机，CNSHUTILSVR01）

配置Windows PowerShell Web Access

正如之前所说的，在安装完Windows PowerShell Web Access组件后，我们还需要进行相应的配置。相应的配置命令可以通过Install-PswaWebApplication来进行，然而在运行命令之前，还分两种情况。这两种情况是和使用何种证书有关。相信大家也可以理解，为了保证用户和Web应用之间的交互信息不被第三方程序所捕获，为Web应用启用证书，强制用户使用https访问已经是非常通用的做法了，这里也不例外。我们可以通过在运行Install-PswaWebApplication命令时增加UseTestCertificate参数来安装自签名证书，也可以向Windows证书颁发机构或者独立的第三方证书颁发机构申请证书。这里我选择了后者，因为我想快速体验下在Windows Server 8 Beta中安装证书颁发机构和以往是不是有所不同，结论是大致上是类似的。

不过我们可以先把向Windows证书颁发机构申请证书的事放一放，先来看下Install-PswaWebApplication cmdlet，该命令在不输入任何参数的情况会在后台自动调用IIS的相关cmdlet来创建名为pswa_pool的应用程序池，并在默认站点下添加名为/pswa的应用。注意安装完成后只启用了http协议，同时大家也看到了PSWA的具体应用程序位于C:\windows\web\PowerShellWebAccess\wwwroot文件夹中，同时在这个文件夹下也包含一份readme.txt文档来简要描述整个配置过程。

接下来要做的是为默认站点申请证书。这里我就不详细描述申请证书的步骤了，大家可以通过IIS管理控制台，或者运行mmc后添加本地计算机证书管理单元来完成Web证书的申请工作，然后在IIS中为默认站点绑定证书。

在配置完证书后，我们可以打开IE浏览器看下Windows PowerShell Web Access的界面，顺便秀一下这是在IE10中打开的。

配置授权规则及站点安全

在完成Windows PowerShell Web Access的安装和配置工作后，虽然用户可以在浏览器中打开Windows PowerShell Web Access的登录页面，但是却无法登录，因为默认的授权策略会阻止用户登录，需要Windows PowerShell Web Access管理员显示开启策略才行，这也说明Windows PowerShell Web Access的授权策略是以白名单形式实现的。而策略的开启只能使用Windows PowerShell cmdlet，无法通过图形界面来完成。具体命令可以通过以下PowerShell命令来查看：

Pswa模块暂时一共包含五项命令，去除Install-PswaWebApplication，剩下的四条命令都和授权规则有关。由于我事先已经在CNSHUTILSVR01这台机器上配置好了Windows PowerShell Web Access的授权规则，因此我们先来看下Get-PswaAuthorizationRule的运行结果：

这里我们可以看到只启用了一条规则，而且User，Destination，ConfigurationName三项的值都是通配符，那么顺利成章的可以认为目前这台服务器上的Windows PowerShell Web Access允许所有用户进行访问。接下来我们要做的是先来移除这条命令，然后再看下创建过程。

移除过程其实大家已经想到了，可以通过Remove-PswaAuthorizationRule来完成，至于是通过参数指定规则的序号，还是通过Get-PswaAuthorizationRule获得规则对象然后通过管道传递给Remove-PswaAuthorizationRule来删除规则，就看大家的喜好了。因为现在只用一条规则，我就偷懒少打点字，直接用Remove-PswaAuthorizationRule –Id 0来完成。

移除之后，用户是无法通过Windows PowerShell Web Access来访问其他计算机的。

接下来我们就把刚才的规则添加回去，命令如下：

Add-PswaAuthorizationRule -ComputerName * -UserName * -ConfigurationName *

注意默认情况下readme.txt中的命令在没有说明的情况下会让人搞不清楚状况，因此请大家参考TechNet上的命令。命令执行完成之后可以用Get-PswaAuthorizationRule来确认规则是否创建成功，这在之前已经演示过了。接下来我们就赶紧登录然后执行命令看看。

好了是不是挺激动人心的？本次关于Windows PowerShell Web Access的上篇介绍就到此结束了，在Windows PowerShell Web Access的中篇和下篇介绍中，我们将来看下Windows PowerShell Web Access的安全模型以及使用时的一些注意事项。

（上篇更新完成）

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

TechNet 原始文档
http://technet.microsoft.com/en-us/library/hh831611.aspx

Windows Server 8 Beta 介绍 (01) - 重新认识Server Manager

自Windows Server "8" Beta发布已经一周了，相信很多朋友已经开始尝试使用Windows Server "8"了。和学习任何其他新事物一样，总免不了会遇到很多挫折，毕竟曾经熟悉的事物一下子不见了踪影了，我们的确是需要从新好好熟悉这位似曾相识的伙伴。对我来说这个过程也是一样的，从今天开始我在ITECN同大家分享我的学习体验。

在这个系列中每篇文章的构成基本按照新功能介绍，然后是相应的PowerShell命令的使用，因为大家可能或多或少已经知道了Windows Server "8" Beta中包含了2000项以上的Windows PowerShell cmdlets，如何学习自然成为了一个问题，我个人的看法是，在边学习新功能的同时边学习这些命令的使用是一个不错的选择。

同时这个系列的文章也不遵循一般文章的发布步骤，每一篇文章在最开始发布时只包含部分内容，剩下的内容将在尽可能短的时间内进行更新。这样做的目的也是为了让各位能尽快看到一些新东西。

在今天的第一篇文章，先来看看全新的Server Manager。Server Manager的雏形是从Windows Server 2003引入，当时被很多人认为是一个可有可无的窗口。到Windows Server 2008 R2的时候，相信大家已经看到了Server Manager的重要性，添加删除服务器角色和组件都是需要通过Server Manager来进行的。而到了Windows Server "8"，Server Manager就成了管理服务器的中枢管理工具。比如大家熟悉的dcpromo命令已经彻底整合到Server Manager中了。

全新的Server Manager如下图所示，首先打开的页面被称为仪表板视图。主要有右侧的导航栏，上部的前进后退按钮，地址栏以及相应的按钮和菜单组成，以及中间的欢迎图块（Welcome Tile）和缩略图(thumbnail)视图组成。

左侧的导航栏相信各位在第一眼看到之后就知道它的作用是什么。而上方的前进及后退按钮 ，及和资源管理器类似的地址栏则说明了当前我们位于哪个管理节点。

而位于地址栏旁边的旗帜标志则显示了当前有多少个任务正在执行以及它们的状态，比如下面的这张截图中就显示了当前有一个任务已经完成了安装，然后需要启动向导进行配置。

而中间的欢迎图块告诉我们在安装好服务器后，需要继续执行的步骤，比如配置本地服务器，添加删除功能，管理其它服务器，创建服务器组等组成。当然大家可以单击Hide选择屏蔽这些步骤提示，如需再次开启的话单击View菜单下的"Show Welcome Tile"即可。

这里稍微提一下配置本地服务器，在Windows Server 2008 R2的Server Manager中由于不存在仪表板（Dashboard）视图，所以当Server Manager出现的时候，我们可以很快配置IP地址，是否启用远程桌面，是否关闭IE ESC，现在我们需要单击配置本地服务器才能进入到相应的配置界面。

而缩略图视图则提供了不同角色和服务器组的状态。这里的状态共有5个分项组成，分别是可管理性，事件，服务，性能，最佳实践分析结果。可管理性行包含了服务器是否在线，是否向Server Manager汇报信息，当前登录用户是否有合适的权限来访问或者管理远程服务器等等。而事件行则允许你配置相应的警报级别，当服务器产生相应的事件后，以缩略图的形式显示出来。服务行则是当特定服务状态没有满足配置的条件时在缩略图视图中产生相应的信息提示。而性能行则是当服务器性能达到你所配置的警报级别时显示相应的信息提示。最后最佳实践分析结果行则是显示显示相应的服务器角色是否满足最佳实践，如果不满足则显示相应的信息提示。

然后新版Server Manager极大的增强了管理多台服务器的能力，大家可能注意到了欢迎图块（Welcome Tile）中默认有四步，配置本地服务器，添加角色及功能，添加另一台服务器来进行管理，以及创建服务器组。前三部大家或多或少都在Windows Server 2008 R2中有所接触，但是第四步就是Windows Server "8" Beta中新增加的，我们可以通过创建服务器组将具有同一角色（比如AD DS）的服务器信息进行汇总，然后在缩略图视图中输出。

以下这张截图就展示了创建服务器组的向导界面，在界面中提供了多种服务器数据的导入方式，非常友好。

而这张截图则展示了在创建服务器组之后，Server Manager发生的变化。右侧CORP Domain Controllers就是我创建的服务器组。这里大家还需要注意一点，远程服务器上的角色信息也会汇总到同一窗口，方便管理员及时查看状态。

比方说在某几台服务器上的某个服务出现故障的话，通过缩略图我们能很直观的知道这一信息，然后通过单击具体的分类，就可以看到具体是哪些服务发生了故障。然后管理员可以选择是否启动服务。

然后警报信息的设置也在这个窗口完成，大家注意上方的Alert Criteria，我们可以根据需要自定义报警级别。接下来，我以事件日志为例说明Alert Criteria是如何配置的。这里我使用EventCreate命令创建了一个事件号为100的错误事件，通过配置事件的严重级别，发生的时间（过去多小时内，这里是过去24小时内），事件源，事件号，事件日志，以及服务器就能非常简单的事件筛选出来。当然大家可以把它理解为事件筛选器的一个升级，但是这个升级却带来了管理体验的重大提示。由于这里的事件时人为创建的假警报，因此最后可以单击Hide Alerts隐藏掉这个时间，让缩略图的颜色重新回到管理员最喜欢的绿色。毕竟"全系统正常"（System All Green）肯定是管理员最喜欢听到的一句话。

而Performance信息在目前的Beta版本中提供了监测CPU和内存两项资源的功能，当CPU或者内存使用率达到指定阈值时便触发警报。

看到这里，有的朋友可能会问了，既然Server Manager已经变得如此强大，我是不是可以不使用SCOM了？当然不是，因为两者的设计标准不一样，Server Manager属于轻量级的综合管理工具，默认情况下它会以十分钟为一个周期来汇总数据，过短的收集时间也会给服务器产生一定负载，因此大家要合理调节这个值。该值可以通过单击右上方的Manage按钮，在出现的菜单中单击"Server Manager Properties"打开。

至此，简单介绍了下Windows Server "8" Beta中的Server Manager发生的变化，更多细节还是请各位下载下Windows Server "8"的测试版，然后好好体验下。

简单介绍完图形界面发生的变化后，再来看看相关命令行发生的变化。首先当然是打开Windows PowerShell窗口，然后输入以下命令：

Get-Module -ListAvailable | ?{$_.Name -like "*ServerManager*"}

然后可以看到返回的结果中包含两个Module，那么接下来就通过以下命令来看下这两个模块中各包含哪些命令。

Get-Command -Module ServerManager,ServerManagerShell | Sort ModuleName | FT Capability,Name,ModuleName,CommandType -A

首先是ServerManager模块中的命令，其实相信一部分朋友已经很熟悉了，因为在Windows Server 2008 R2中就包含这个模块。当然大家肯能注意到了，我故意把CommandType属性列了出来，如果不做么做的话，是没办法解释Add-WindowsFeature和Install-WindowsFeature这两者之间的区别的。

好了，接下来就来看下Install-WindowsFeature命令的帮助信息：

这里一共有三个语法，第一个语法和Windows Server 2008 R2中的类似，然而第二和第三项语法就是Windows Server "8" Beta中新增加的激动人心的功能，我们可以直接用Windows PowerShell命令向vhd文件中添加Windows Server "8" Beta功能了！其实在图形界面中也有相关界面，这里我就直接跳过图形界面的操作，直接来看下命令行下的效果。

这毫无疑问改善了部署体验，写到这里，我也暂时无法猜测后台是直接通过API实现相关功能，还是通过调用外部命令实现的，因为在Windows Server 2008 R2时代我们也可以通过使用dism命令来达到类似离线编辑的效果。接下来就来我们就来试试看。

首先下来准备一块差异磁盘，由于我提前已经准备好了sysprepped的vhd镜像，因此直接用以下命令完成差异磁盘的创建：

New-VHD -Path F:\WIN8VHDs\Test.vhd -ParentPath 'F:\VHDs\Windows Server 8 Base.vhd' –Differencing

（这个命令会在以后讨论Hyper-V时具体讨论，我现在能说的就一个字，爽！）

完成之后，我们就运行以下命令来安装Telnet-Client作为测试：

Add-WindowsFeature -ComputerName TestServer -Vhd F:\WIN8VHDs\Test.vhd -LogPath F:\WIN8VHDs\Log.txt -Name Telnet-Client -Verbose –WhatIf

先来解释下参数。ComputerName是指挂载vhd的计算机名称，VHD当然是指需要挂载的vhd文件，LogPath则用来记录日志，Name是指要添加的Feature名称。然后先用Whatif参数来看下具体会执行哪些操作，这里我还启动了Procmon来监视F:\WIN8VHDs\下的文件系统活动，因为我想验证下我刚才的猜测，也就是这个命令会和dism有关。以下就是命令运行结果：

然后是Procmon的事件捕捉结果：

很高兴，果然和我预想的一样是和dism有关系，既然已经完成了验证工作，接下来就去掉-Whatif来看下具体的执行结果。

大家看完之后是不是很兴奋啊，这就是云时代的Windows操作系统所具备的功能！

由于其他命令暂时缺少帮助文档，因此暂时也无法准确知道他们的作用，至此Server Manager的介绍就到此告一段落，接下来会来看下Hyper-V的改进。

提示：本文所讨论的是正在开发中的一款产品，如果今后正式版本中的内容与本文不符时，请以正式版本为准。

使用Forefront Identity Manager 2010进行高效身份管理 (07): 入站同步（二）

创建同步规则

在完成管理代理和管理代理运行模式的创建之后，接下来需要做的是在图形化界面中创建同步规则，这也是FIM 2010和前代产品ILM 2007之间最大的区别。

首先需要打开FIM 2010的管理门户网站（https://servername/indetitymanagement/default.aspx），然后单击右侧Administration下的Synchronization Rules进入同步规则管理界面。

在打开同步规则管理界面后，单击New按钮来创建同步规则。在General页面中，需要定义同步规则的显示名，描述信息，依存性（本实验场景中不需要设置），数据流方向（入站，出站，双向）。这里各位可能注意到了同步规则名称中使用到了“->”这样的标记，这其实纯粹是个人喜好的问题，各位也可以在名称中使用“Inbound Outbound |Bi-direction”等字样来标识出数据流的方向，方便在管理界面中分辨。

完成一般设置后，单击下一步进入Scope设置。在这里需要配置Metaverse中的资源类型，外部系统，外部系统的资源类型，外部系统资源筛选器（本实验中无需配置）。由于本实验是以员工信息为例进行说明的，因此Metaverse中的资源类型为person，外部系统（其实这里显示的是管理代理的名称）自然是之前用PowerShell创建的文件，外部系统的资源类型也是person。

在完成Scope设置后，单击下一步进入Relationship配置。Relationship设置中的配置主要就是确定FIM和外部系统的对象之间通过何种条件进行关联，一般的选择就是在各系统中起到唯一标识符作用的属性，比如employeeID。当然这里还要注意勾选在FIM中创建对象这一个选项。

配置完Relationship之后，单击下一步，进入入站属性流配置界面。入站属性流属于FIM 2010中配置比较复杂的一块内容。如果是属性比较多的情况下，配置工作会变成一项体力活，而且配置过程需要极其细心，如果属性类型不一致的话，同步时会触发错误。虽然在当前的实验环境下体现不出，但是当我们后续实验涉及到活动目录时，大家便会有体会了。

刚才给大家打了预防针，接下来我们就来看下如何配置。首先单击界面上的“New Attribute Flow”，在出现的“Flow Definition”界面中，在Source页选择外部系统中的属性，比如EmployeeID。然后单击Destination页面，然后选择对应的属性即可。通常来说属性名是相同的，但是也有特殊情况。比如外部系统是活动目录时，请各位到时小心配置givenName-firstName, surname和lastName的对应关系。还有一种情况是，我们需要利用外部系统中的多个属性值来合成FIM中的一个属性值， 比如FirstName + LastName = DisplayName。这时注意点击“Flow Definition”界面中的“Concatenate Value”，通过点击这个按钮，FIM允许我们选择多个外部系统中的属性。

最后请各位注意属性流配置页面有超时设置，请各位完成几项属性流的配置后，适时点下完成保存下当前的配置进度。

当所有配置完成后，单击下一步，进入概览页面。在确认完相关信息后，单击Submit提交修改。

启用同步规则资源调配

在创建完管理代理，管理代理运行模式，同步规则之后，大家是不是会基于看下FIM 2010到底是如何工作的呢？但是在你触发管理代理中的具体某一个运行模式之前，还有一项工作要做，那就是在Synchronization Service Manager中启用同步规则资源调配。具体步骤是打开Synchronization Service Manager后，单击Tools，然后单击Options，随后勾选“Enable Synchronization Rule Provisioning”复选框，最后单击“OK”保存设置。

初始化入站复制

目前为止，我们已经完成了管理代理的创建，管理代理运行模式的创建，接下来我们要初始化入站复制，具体步骤如下：

1. 将数据导入到FIM服务数据库
2. 初始化FIM同步服务
3. 将数据导出到FIM服务数据库
4. 确认数据导出状态
5. 将数据导入到FIM服务数据库

这一步的目的是将以存在，包括新创建的同步规则导入到FIM MA的连接器空间。具体方法是打开Synchronization Service Manager，然后单击工具栏中的“Management Agents”，然后选中FIM MA，单击右键，然后在菜单中单击Run，打开运行管理代理配置对话框，然后运行“Full Import”。

片刻之后，导入过程便告结束，这时会在Synchronization Service Manager的左下角同步信息出显示概览状态。导入后对象状态分为5类，Unchanged，Adds，Updates，Renames和Deletes。这里由于是第一次导入，因此显示的是有三个对象被导入，单击具体状态后，便会弹出显示对象的详细信息对话框中。这里出现了一个会让部分朋友混淆的的名词Distinguished Name，可能各位都习惯了活动目录中的distinguishedName，对这里用Distinguished Name来表示GUID可能不太习惯，那么只能请大家克服了。

除了在导入后显示的信息中查看相关对象之外，我们也可以使用连接器搜索工具来查看某一个管理代理所对应的连接器空间中的对象。方法是首选选中一个管理代理，然后单击右键，然后在出现的菜单中单击“Search Connector Space...”打开搜索工具。打开之后可以单击“Column Settings”来添加需要的栏位显示对应的信息。

初始化FIM同步服务

当同步规则发生变化时必须运行一次完整同步。具体操作和刚才类似，在打开运行管理代理配置对话框后，选择之前配置好的完整同步配置文件，稍等片刻后我们就能看到同步结果。

和刚才将数据导入到FIM服务数据库时产生的结果有所不同的是，如果针对FIM MA执行完整同步，那么会同时产生入站同步和出站同步，出站同步是由预先配置的属性流导出规则产生的。这里还请大家注意到往Metaverse中创建对象时所用到的专有名词Projection。Projection是指根据创建Projection规则在Metaverse中创建对象，并将该对象连接到连接器空间中某个对象的过程。根据这个定义我们可以推断出，目前在Metaverse中有三个对象。那么之前可以用连接器搜索工具查看连接器空间中的对象，那么Metaverse重对象该如何查看呢？实际上大家马上就能从Synchronization Service Manager的界面中看到工具栏中Metaverse按钮。单击之后，便会打开Metaverse搜索工具。然后对象搜索范围中选择person，排序规则选择默认，然后单击右侧的“Add Clause”按钮添加搜索条件。目前我们使用的搜素条件是“accountName is present”，然后单击搜索按钮。

将数据导出到FIM服务数据库

接下来需要将数据导出到FIM服务数据库。刚才各位在初始化FIM同步服务的结果中已经看到在出站同步中，导出属性流中有两个对象，接下来打开详细信息对话框后会发现标签栏的标题出显示的是“Pending Export”，这也说明我们必须执行一次导出操作。具体操作还是很简单的，同之前类似，我们只要运行相应的导出配置文件就行。

确认数据导出状态

最后为了完成初始同步，还要在进行一次增量导入来确认导出是否成功。这一点同样在上一步导出后所产生的对象状态信息里有显示，“Awaiting Export Confirmation”的含义就是需要再进行一次增量导入。具体方法还是和之前一项，运行相应的配置文件就行。

调整属性流优先级

在测试入站复制之前，还有最后一部要做，那就是调整属性流优先级。首先打开Synchronization Service Manager，然后单击工具栏上的Metaverse Designer，然后在Object types中选中person，在下方的属性中按照Import Flow排序。

然后选中在入站属性流中数字为2的第一个属性，这里的数字2代表有2个属性流会修改这个属性。选中之后，单击右侧的Configure Attribute Flow Precedence，打开属性流优先级调整对话框。然后单击右侧的向下箭头，将CORP FIM MA的优先级调整为2。

如果不调整的话，各位可能会在后续步骤中发现FIM Portal中无法显示用户的显示名，然后查找原因的话便会发现是属性流优先级的问题。如果出现这种情况的话，请在调整属性流优先级后，再次对CORP File MA执行完整同步操作，来修正这个问题。

测试入站复制

在之前一节中，我们完成了测试环境的基本搭建过程，接下来也测试这个环境是不是满足我们的设计需要。主要步骤如下：

1. 从外部系统（数据文件）中导入用户
2. 在Metaverse中创建（Projection）对象
3. 将用户导出到FIM服务数据库并执行增量导入
4. 验证用户状态

从外部系统（数据文件）中导入用户

从外部系统（数据文件）中导入用户和之前的操作是一样的，只不过这次我们要针对CORP File MA管理代理进行操作。大家如果回顾这个代理的创建过程的话，便会发现这个代理只创建完整导入和完整同步两个配置文件。因此第一步要执行的就是完整导入，将数据从外部系统（数据文件）导入到CORP File MA对应的连接器空间中。因为演示用的外部系统（数据文件）中包含五个用户，因此在最后的同步结果中显示为添加了五个对象。还要注意到的一点是，在对象的Distinguished Name中显示的是员工号，也就是我们设置的Anchor属性。

在Metaverse中创建（Projection）对象

接下来，为了能在Metaverse中创建（Projection）对象，我们需要执行CORP File MA的完整同步，这样就能利用CORP File MA连接器空间中的信息在Metaverse中创建对象，并且将Metaverse中所创建对象的唯一标识符（MVObjectID）写入到连接器空间中对应的对象。请大家牢记这个过程，这也是为什么虽然我用了创建这一词，但还是要强调英文对应的术语是Projection的原因。当完整同步执行完成后，我们可以看到入站同步中有五个对象被创建（Projection）出来，同时连机器中也有五个对象被更新。同时出站同步中也有对应的五个待导出的属性流及类型为添加的资源调配。

将用户导出到FIM数据库并执行增量导入

既然在上一步中，产生了五个待导出的属性流，那么接下来就要执行导出操作。注意导出操作是CORP FIM MA执行的。操作步骤和之前的相同，选中CORP FIM MA代理，然后执行对应的运行配置即可。

然后单击数字，在出现的对话框中选择属性，注意此时连接器对象属性对话框中第一个属性页的标题，“Awaiting Export Confirmation”。如果你看到这个短语，就意味着你还要在执行一次增量导入来确认对象的状态。增量导入的过程相信大家也知道了，只要针对FIM MA执行Delta Import运行配置即可。

验证用户状态

验证用户状态其实很简单，只需要打开FIM的门户网站，然后单击左侧导航栏中的Users，在随后出现的页面中单击搜索按钮，确认测试用户已被导入即可。当然还可以单击具体用户确认用户属性是否被设置成功。

至此，我们就完成了FIM 2010的入站同步实验，整个实验还是比较复杂的，涉及到的组件比较多，请各位细心操作。下次我们将主要讲如何使用FIM 2010实现出站同步，敬请期待。

使用Forefront Identity Manager 2010进行高效身份管理 (06): 入站同步（一）

通过上两次介绍，各位了解了FIM 2010同步服务的主要组件和所包含的过程，这篇博客文章的目的将关注如何使用现有知识完成入站同步。我将通过非常简单的例子来进行说明，外部系统将使用一个CSV文件来代替，而不是SQL数据库。实际上CSV在解决实际问题时也会起到非常重要的作用。好了，下面就来看看入站同步需要执行哪些步骤。

下面所要描述的场景来自TechNet上的“Introduction to Inbound Synchronization”。我会按照自己的理解和实际操作体验来为大家减少学习过程中会遇到的困难。同时文本也不是英文原文的翻译，本文不会描述非常具体的操作步骤，我一直以来所抱的愿望就是希望大家多读读英文原始文档，提高下自己的英文阅读能力，这是做好一个好的系统管理员的必备条件。

首先这张图是各位在接触FIM 2010的过程中经常看到的。

其中棕黄色的椭圆形区域代表FIM，椭圆形中的左侧的两个同心圆，内部的圆表示Metaverse,外部被分割的圆代表连接器空间，每一个扇形代表连接器空间的一个分区（division）。这里再强调下连接器空间只有一个，而连接器空间中分区数量取决于FIM所连接的外部系统的数量。

在本次实现中一共会使用到两个管理代理（MA），CORP FIMMA及CORP FileMA。然后整体配置过程分为三步，配置，初始化及测试。先来看下配置过程，配置过程分为四步，创建管理代理，创建运行配置文件，创建入站同步规则，启用同步规则资源调配(provisioning)。

首先来创建COPR FileMA。因为通过之前的学习大家知道管理代理的作用就是连接外部系统，因此先要创建外部系统出来，各位可以使用以下PowerShell命令来准备这个外部系统，这个外部系统的本质就是一个包含用户身份信息的CSV文件。

New-Item -Path C:\ -Name DataSource01 -ItemType Directory -ErrorAction SilentlyContinue | Out-Null

$users = @()

for ($i=1;$i -le 5;$i++)

{

$user = New-Object PSObject

$user | Add-Member -MemberType NoteProperty -Name "EmployeeID" -Value $($i.ToString("D3"))

$user | Add-Member -MemberType NoteProperty -Name "Name" -Value "Test $($i.ToString("D3"))"

$user | Add-Member -MemberType NoteProperty -Name "DisplayName" -Value "Test $($i.ToString("D3"))"

$user | Add-Member -MemberType NoteProperty -Name "FirstName" -Value $($i.ToString("D3"))

$user | Add-Member -MemberType NoteProperty -Name "LastName" -Value "Test"

$users += $user

}

$users | Export-Csv -Path C:\DataSource01\datasource01.csv -NoTypeInformation -Encoding UTF8

创建管理代理

然后打开Synchronization Server Manager，随后单击工具栏上的Management Agents，并单击右侧Actions栏中的Create按钮，打开管理代理创建向导。

随后在下拉框中选择Delimited text file作为管理代理的类型。然后输入合适的名称和描述之后单击下一步。在接下来的模板输入文件界面中选择刚才创建的模板文件及和合适的代码页（UTF-8，为了适应中文环境）。然后单击下一步。由于分隔文件中的分隔符可以是逗号，制表符，或者其它符号，因此在这个界面需要让管理代理知道分隔符是哪一个，同时告诉管理代理使用第一行中的名称作为每一列的列名。还有小知识点和CSV文件有关，一个合格的CSV文件，其中的值必须被双引号引起来，在RFC 4180中有详细的描述，大家可以看一下。

所有配置完成后，单击下一步。接下来要选择需要导入连接器空间（Connector Space）的对象属性，因为有些时候并不需要所有属性。这里有个设置（概念）需要注意，大家可能注意到了“Set Anchor”按钮，那Anchor到底是什么，在这里扮演了什么样的角色？被标记为Anchor的一个或多个属性通常是不变的，通常代表了外部系统中的对象和连接器空间中对象是通过这一个或多个属性链接的。一般会选择起到全局标识符作用的属性作为Anchor，常用的有员工号或者用户ID。设置完成之后单击下一步。

接下来来定义对象类型，在本实验环境下，对象类型是person。然后可以在这里设置属性的名称及这些属性是否必须在导入的时候包含值。因为有些属性虽然是需要的，但是导入的时候可能没有值，因此需要在这里控制这种情况是否被允许。完成之后单击下一步。

在连接器筛选器配置界面，单击下一步，因为暂时不需要配置。在配置结合（Join）及创建（Projection）界面，单击下一步。在属性流配置界面中，单击下一步，因为属性流的配置将在FIM Portal中完成。在Deprovisioning配置界面，单击下一步。在扩展配置界面，单击完成。

接下来来配置FIMMA。在设置FIMMA之前，需要准备一个专用帐号，不过这项工作已在之前的实验环境准备阶段就已经完成。因此接下来要做的就是打开管理代理创建向导，然后在管理代理类型下拉框中选择FIM Service Management Agent，并设置合适的名称和描述。

接下来，在数据库配置界面，需要填写实验环境中的FIM Service和FIM Synchronization Service的信息。以下截图是我实验环境中的配置。这里需要注意一点，FIM Service base address的值，由于实验环境中FIM Service和FIM Synchronization Service是安装在一台服务器上的，所以这里的服务器地址中使用localhost。同时还有一点需要注意FIM Service使用的端口是5725。当使用扩展部署时，请选择环境中FIM Service所在的服务器地址，这里可能还有使用负载均衡器的情况，以后如果有机会的话，会和大家分享。在所有配置完成后，单击下一步。

在对象类型配置界面中，除了默认选中的对象之外，还需要选择person。这里请各位注意到一点，ExpectedRuleEntry和SynchronizationRule在在之前已经解释过了，那么DetectedRuleEntry是什么东西？根据MSDN上的解释，DetectedRuleEntry（简称DRE）中保存了指向同步规则的引用数据。DRE由FIM同步服务创建并用来确定一个FIM资源是否会从FIM Service中调配（provisioning）到FIM Synchronization Service中。该对象的创建需要同时满足两个条件，一是勾选同步规则中的存在性测试，二是FIM Service验证完成之后。完成之后，单击下一步来到属性选择页面。

在当前的测试场景下，属性选择页面不需要进行额外设置，可以单击下一步继续。

然后在连接器筛选器页面，根据"Miss MIIS" Carol Wapshere的最佳操作实践的建议，需要为管理员和同步服务帐号建立筛选器。筛选器的建立方法如下：

在Filter Type中选择Declared，然后单击按钮“New...”，在出现的筛选器创建页面中选择MVObjectID作为筛选条件。然后分别添加GUID即可。而管理员和同步服务账号的GUID是已知GUID，因此可以作为筛选条件。

Administrator: 7fb2b853-24f0-4498-9534-4e10589723c4

Sync Account: fb89aefa-5ea1-47f1-8890-abe7797d6497

完成之后，下一步就来到配置对象映射的页面。高亮Person之后，单击Add Mapping按钮，然后选择person。这样就能确保外部系统中对象能被正确映射到Metaverse中，完成之后单击下一步。

接下来就是属性流配置页面，由于测试用的外部数据源只有五个属性，员工号，姓名，显示名，姓和名。因此配置起来相对比较容易。但是大家注意为了让用户能在FIM Portal中正常显示，姓名会被映射到多个Metaverse属性。我们先来看配置好的效果。

具体配置过程是，先选中“Object Type: Person”行，然后在“Build Attribute Flow”框中分别选择数据源中的属性和Metaverse中属性，并选择Row Direction中选择Import。最后单击New按钮，完成一个入站属性流的创建。接下来将Flow Direction改成Export，然后单击New按钮，随后就是为剩下的属性依次创建属性流。完成之后单击下一步。

在配置Deprovisioning选项页面中，目前可以保持默认的“Make them disconnectors”选项即可。完成之后单击下一步。

在配置扩展页面中，由于暂时不需要额外的扩展，因此单击完成即可。

通过以上的介绍，各位了解到了管理代理的创建过程，然后这只是万里长征中的第一步，接下来需要为管理代理配置创建运行配置信息，也就是定义管理代理的运行模式。

定义管理代理运行模式

首先是CORP File MA。因为该管理代理连接到的外部系统只是一个普通的文本文件而已，是无法实现所谓的增量导入和同步功能。因此与此相对应，Corp File MA的运行配置信息中只需要Full Import和Full Synchronization即可。运行配置信息的创建步骤如下：

选中某一个管理代理后，单击右键，在出现的快捷菜单中单击“Configure Run Profile”菜单项。随后就会出现“Configure Run Profile for "Corp File MA"”对话框，然后单击New按钮。依次设置配置信息名称，所要执行的步骤和File类型MA所需的数据文件。各位可以将最开始创建的CSV文件复制到界面中所示的位置。

随后我们在新建另外一个步骤为“Full Synchronization”的运行配置。完成后的效果如下图所示。

至此，File Corp MA的配置工作暂时就告一段落。接下来要为FIM MA配置相应的运行配置信息。由于FIM MA支持增量信息导入方式，因此在创建运行配置信息的时候需要把这个特性反映出来，所以需要为FIM MA创建5个运行配置信息。具体步骤和之前的相同，只需要注意在Configure Step的时候选择合适的Step即可。

(未完待续)

使用Forefront Identity Manager 2010进行高效身份管理 (05): Forefront Identity Manager 2010 架构介绍（二）

首先请原谅我将这么重要的内容拆成两篇，考虑到大家平时读长文档读的太多了，因此将内容做一些细分，方便各位理解和吸收。

在上篇博文中，主要分析了FIM 2010的作用，高层次架构以及同步服务所连接的两端，外部系统及FIM 2010本身。这篇博文的焦点将关注同步服务本身，也就是身份数据是如何进入Metaverse，以及向其他外部系统提供身份数据。同时在这个过程中包含很多FIM 2010的专业术语，这些专业术语是不能混淆的，请各位在阅读时候多注意。

首先假设以下问题情境。Contoso公司最近希望通过FIM 2010实现活动目录用户账户的自动创建。用户数据来自人力资源部门使用的基于Microsoft SQL 2008的数据库。

毫无疑问，人力资源部门使用的数据库相对于FIM 2010来说是外部系统，这里为了简化描述使用ES1来代替。如果回溯下上次的课程内容，大家可能已经想到了需要利用管理代理（MA）建立起连接。这里具体建立过程会在之后的博文中进行详细描述。假设管理代理创建正确，下一步就要创建管理代理上的运行配置信息（Run Profile）。配置界面如下：

可以注意到，FIM 2010中的运行配置种类粗分为3种。导入（Import），同步（Synchronization），导出（Export）。细分的话为五种，即导入和同步分别增加增量模式。而截图中的剩余几种类型都是导入和同步的组合。需要根据实际环境来决定。

而将外部数据源中的的身份信息引入到连接器空间（Connector Space，CS）的过程称为导入（Import）。在连接器空间中，身份数据集结完毕之后，便经由入站同步（Inbound Synchronization）进入Metaverse。Metaverse中的对象创建都是由连接器空间中的对象触发的，这个过程被称为投射（Projection）。在入站同步过程中，投射只是其中会发生的一种情况，通过前文的叙述，各位应该意识到FIM 2010可以连接到多个外部系统，因此当Metaverse中已存在相关的身份对象时，FIM 2010允许管理员通过一个唯一属性（标识符，比如员工号）来将数据结合（Join）起来。因此大家可以注意到入站同步是以连接器空间为中心的。

综上所示，从一个外部系统中将用户身份信息引入到Metaverse中的过程如下图所示：

然而出站同步过程并不像入站同步那么简单，出站同步牵涉到的组件更多，接下来就来分析下出站同步。出站同步的起始点是Metaverse中的对象，当用户身份信息发生变更后，同步服务需要确认用户身份信息的变更需要同步到哪些连接器空间。这里需要引入一种机制将出站同步规则和Metaverse中的对象链接起来。在FIM架构中，这种机制通过一个被称为Expected Rule List（ERL）的属性来实现。存储在这个属性中信息能够让同步服务定位一个对象所需的所有出站同步规则。

由于FIM 2010可以链接多个外部系统，因此ERL属性必须是多值的。然而这个ERL属性中的值并不直接指向同步规则，而是指向一个被称为Excepted Rules Entry（ERE）的中间对象。ERE可以用来跟踪身份对象及同步规则之间的关系状态等信息。ERL属性由FIM Service管理。因此所有受管理的身份对象必须引入到FIM Service数据库中。在FIM Service数据库中保存了对象和特定出站同步规则间的连接关系。这个结构可以用下图描述。

总结起来，对和出站同步有关的操作而言，将受管理的对象与对应的出站同步规则绑定在一起是必须的。在FIM 2010中，这种连接关系是以Expected Rules Entry（ERE）对象的形式来实现的。这意味着，受管理的身份对象中包含由ERE组成的ERL属性，而每个ERE属性指向相关的出站同步规则。在FIM中，一个完整的出站同步对象拥有一个特定的名称：出站同步集合（outbound synchronization triple，其中triple特指该集合中包含三个对象）。该集合由FIM Service管理，由FIM Synchronization Service应用。

同步策略

创建出站同步集合的过程可以理解成“将一个对象引入到某个出站同步规则的管理范围之内”。反向的操作被称为“将一个对象从某个出站同步规则的管理范围内移除”。这两个操作都将涉及到三个额外的FIM对象。它们分别是对象集（SET），工作流（WORKFLOW），管理策略规则（Management Policy Rule）。而同步策略则是由对象集，工作流对象，同步策略规则以及出站同步规则组成。可以使用以下图示描述这个结构：

当你设计出站同步逻辑时，需要定义在何种条件下将一个对象引入某一条同步规则的管理范围。在FIM中，可以通过集的方式表达这种条件。例如，商业策略决定所有全职员工必须在公司域里面有一个帐号。通常建议创建一个名为All full-time employees的集来跟踪所有相关对象。当一个用户成为All full-time employee集中的成员后，就能可以利用集中成员的变更将相关对象的ERL中添加连接到AD的出站同步规则之中。在这个过程起到控制实体作用的是被称为基于集变化的MPR。MPR中定义了FIM环境中针对各条件所需要的各种应答。当前例子中的条件是一个对象被加入到All full-time employees集。基于集变化的MPR将触发工作流作为对条件的应答。在FIM的工作流中你可以将一个操作与一条同步规则绑定在一起。和一条同步规则绑定在一起，可以使得工作流能将一个对象引入或者移除一条出站同步规则的的管理范围之内。总结起来，一个受管理对象同一条出站同步规则之间的关系是由基于集变化的MPR所管理的。出站同步的简要示例图如下：

FIM Service Management Agent简介

在FIM中，管理代理是用来在同步服务与外部系统之间交换数据的组件。这也包含同步服务（FIM Synchronization Service）与FIM服务（FIM Service）之间的数据交换。然而，尽管交换数据的接口是一致的。FIM 2010管理代理在FIM架构中有一个特殊的角色。在之前的介绍中，各位知道了如何将所有受管理资源引入到FIM Service数据库中。这意味着对FIM connector space来说只有一个特定的商业规则，作为Metaverse的镜像而存在。因此，不需要为Metaverse和FIM connector space之间的数据交换配置入站或者出站同步规则。在FIM中，Metaverse和FIM connector space之间的数据交换是由一组非显示申明的规则（nondeclarative rule）所管理的。当打开MA设计器时，各位可以为非显示申明规则配置相应的属性流。这包括对象类型列表，属性列表，连接过滤器，对象类型映射，属性流以及Deprovisioning。除了对选定对象类型及对象类型之间的匹配外，所有场景通常要求配置额外的入站和出站属性流映射。

正如之前所描述的，这里你需要确保Expected Rules List属性被正确配置。因为在Metaverse和FIM connector space的数据交换之间没有显示存在的入站和出现同步规则，因此需要另一种机制激活Metaverse到FIM connector space之间的置备。在FIM中，这项任务通过入站同步规则的Create Resource In FIM设置来实现。由于FIM 连接器空间可以被认为是Metaverse的镜像，所有由入站同步规则进入Metaverse的对象将会在FIM连接器空间中自动创建，假设连接器空间中没有相关对象的话。

属性优先级

接下来要介绍一个非常重要的概念，属性优先级。大家已经知道FIM 2010可以连接到多个外部系统，这意味着Metaverse中的单一对象的某一个属性值会有多个来源。因此FIM 2010的开发团队制定了一些列规则来保证属性被正确写入，具体规则如下：

• 只要Metaverse中对象的属性未被填充，所有具有相关属性入站属性流映射的MA都可以填充一个值。

• 一旦Metaverse中对象的属性值存在之后，该值只能被与最后一个写入该值的MA具有相同或更高优先级的MA所更新。

• 如果和最后一次写入该值的MA相比，正在尝试更新该值的MA具有较低的优先级，那么这次更改将会被拒绝。

当然FIM 2010也允许管理员使用平等属性优先级，当设置开启后，同步服务将使用最后一个写入者胜出的判断逻辑。

同步规则优先级

除了属性优先级之外，同步规则也有可能需要优先级。和属性优先级的一个本质区别是，只有当FIM在同步规则中检测到重叠设置时，同步规则优先级才会生效。同步规则优先级对入站同步和出站同步同时生效。

设计数据同步模型

最后来看下如何设计数据同步模型。针对每一个连接的外部系统及每一个需要同步的对象类型，你需要考虑当下列事件发生时FIM 2010将要采取的措施：

• 创建 - 当一个新对象被导入时

• 更新 - 当对象的更新信息被导入时

• 删除 - 当对象被从外部系统中删除时

这其中删除是需要额外注意的，从Metaverse角度来说，删除是无法被检测到的。当处理一个已经准备好的删除操作是，对Metaverse来说唯一能做的就是删除连接器空间和Metaverse对象之间的连接关系。然后，在入站同步阶段，连接的删除操作也有可能是有连接器筛选器造成的，因此需要小心。除了这三种最基本的操作之外，你还需要考虑以下两种情况：

• 建立连接 - 当连接器空间中的对象和Metaverse中的对象建立连接时
• 移除连接 - 当连接器空间中的对象和Metaverse中的对象间的连接被移除时

你可以使用当条件发生时，执行该步骤这样简单的逻辑来进行记录。除此之外还有一些需要值得注意的地方。比如在出站同步阶段移除连接，在FIM术语中，该项行为被称为deprovisioning。移除连接这项操作通常是deprovisiong的触发器，需要根据实际情况配置对应的相应措施，这些措施决定了如何处理断开的连接器对象。一共有以下几种措施：

Make them disconnectors
Make them explicit disconnectors
Stage a delete on the object for the next export run
Determine with a rules extension

举例来说，需要在当Metaverse中的对象和连接器空间之间的对象连接断开时，需要删除外部系统中的对象。需要配置deprovisioning选项为“Stage a deletion on next export run”。然而实际上这个选项的具体执行分为两步，首先向外部系统发出删除信号，然后你必须再执行一次Import来删除连接器空间中的对象。

总结

说实话，光讲理论知识，各位绝对看的云里雾里。因此从下次开始，将使用具体的例子来让大家理解FIM 2010的精髓，同步服务，敬请期待。

使用Forefront Identity Manager 2010进行高效身份管理 (04): Forefront Identity Manager 2010 架构介绍（一）

好了，从今天开始将正式为大家介绍Forefront Identity Manager 2010。说实话，前三篇博客呢，主要是满足各位动手党的好奇心，因为如果光学理论知识的话，学完就忘，所以需要有个实际环境来进行不断操作来掌握知识。不过从我个人的学习过程来看，FIM 2010对系统工程师的基础能力要求还是很高的。这点大家已经可以从实验环境的准备过程中有所体会了，在折腾FIM 2010之前，可能还要学会折腾其它微软产品。关于这一点，我个人的理解是，因为FIM 2010所要解决的问题是位于基础架构的核心位置，会牵涉到很多东西，所以难度可想而知。编写这一系列博客的目的，主要是凭借我自身的能力，来降低大家学习FIM 2010的门槛。所以好戏现在才正式开演。

在开始具体介绍之前，我想打一个比方来告诉大家FIM 2010所处的位置。各位知道，身份管理其实是非常纷繁复杂，在本次课程中实验环境只是基于微软服务器端产品，然而在现实生产环境中，各式各样的产品可为种类繁多，如果要为每个产品提供身份管理支持，那FIM 2010真的是处在争论的中心，各个数据源都会强调自身数据的重要性，用户的某一个属性值必须有它来决定，而不是其它数据源。那么如果要在争论中心还能独善其身的话，FIM 2010本身就必须非常强壮，而要支持这份强壮的体格，那么它本身的架构就必须非常健壮。这也是接下来要讨论的话题。

如果大家看过FIM 2010 Rampup文档，或者其它文档/PPT介绍的时候，会发现FIM 2010的高阶架构是这样的：

虽然文档里面配了很多说明，但是作为初学者的话一下子肯定接受不了这么多信息。而且做为系统管理员，因为平时学过很多产品，一看到这些组件，就开始忍不住要马上记忆，但是记得越多，就越发现FIM 2010的复杂，然后会发现自己学不进了。

那么实际上，再往高阶上迈一步，让鸟瞰的范围更大一点。FIM 2010其实就是一套身份管理系统（Identity Management System，缩写成IdM System），其存在的意义就是在一个统一的数据库中保存企业中的各种身份信息，并强化企业的身份管理流程。同时FIM也是基于状态的身份管理系统，当其它数据源发生变化时，FIM 2010并不会急着将变化的内容同步到其他系统中，这一点在日后的说明中大家变化有体会。基于这一点，我们可以得到以下这张图。

有了这么一个笼统的概念之后，接下来各位就想要知道FIM 2010到底是如何实现身份信息在各个系统中流转的。就像大家知道在Exchange中，服务器从客户端接收到了一份邮件然后在发送给另一个邮件系统需要经历一个复杂的过程， 对FIM 2010来说也是一样的，身份信息在FIM 2010中的流动过程也是非常复杂的。在接下来的时间里，各位首先就要直面FIM 2010中的核心功能：同步服务。

在FIM架构中，同步服务起到的作用是根据商业需求将身份信息同步到各个应用系统中。在FIM 2010的术语中这些应用系统被称为外部系统，这当然是以FIM 2010本身作为观察视角所下的定义。因此与此相对的所谓“内部系统”就是指FIM 2010身份信息数据存储组件。这里为了简化问题，先假设同步服务只连接两端，一端是外部系统，另一端是FIM 2010本身的数据存储组件。

外部系统就不用多介绍了，它们可以是SQL数据库，CSV文件或者各个厂商的目录服务。

然后要搞清楚FIM 2010的数据存储组件的具体组成。如果把这个数据存储组件看成两个同心圆，那么外层称为连接器空间（Connector Space，CS），内层称为Metaverse（MV）。Metaverse这词本身具有传奇色彩（WIKI），目前没有合适的中文术语可以进行表述，因此在接下来的表述中会保留这个英文单词。

先来看下Metaverse。从之前的宏观介绍中，大家可以看到描述企业内一位员工的信息在各外部系统中是不同的，然而这些信息的拥有者是一致的，显而易见为了统一管理这些信息，管理者需要一张统一的视图来方便信息的存放和读取。而这张视图在FIM 2010的术语中便被称为Metaverse。

那么接下来的一个问题就是连接器空间（CS）是什么以及存在的意义。这里不妨设想下用户改名这一个场景。假设Anna Smith和Bob Black结婚之后，根据当地风俗Anna Smith要改随夫姓，变成Anna Black，于是Anna在FIM 2010中发起了姓氏更改请求。然而由于种种原因，变更申请中姓氏填错了，于是她又要重新发起另外一个请求进行更正。于是在短短的几分钟内产生了两个请求。然后我们把这个问题放置到一个大型环境，那么可以发现这些人为错误的数量是惊人的。而Metaverse本身作为一个统一管理视图，尽量避免其中的信息错误是应当予以重视的。因此开发人员在这里引入了连接器空间，来解决包括人为错误的各种问题。而连接器空间也作为一个准备区域（Staging Area）而存在。因为FIM本身是基于状态而不是变更来管理身份信息，通过使用连接器空间，可以使得FIM 2010不需要实时维护一个同外部系统之间的连接，减少FIM 2010本身的资源消耗。连接器空间中数据存放的目的主要是用来支持数据同步，同时按照设计需要，每一个外部系统的身份对象必须在连接器空间中有一个它表他的对象。

注：Staging Area原本是一个军事术语，中文为集结待命区，这里为了淡化军事色彩，我使用了准备区域。当然这个词在数据库领域中也有所使用，微软术语网站上的翻译为临时区域，但我个人觉得准备区域更加贴近FIM 2010中使用场景。

在连接器空间中存在三种类型的对象，第一种类型是连接器（Connector），指的是该对象至少和外部系统或者Metaverse两者中的一者存在连接关系。第二种是非连接器（Disconnector），也就是和第一种类型相反的对象，它本身与外部系统或者Metavserse之间没有连接关系。最后一种类型是占位符（Placeholder），该对象存在的一个典型场景是活动目录中的经理属性，我们知道活动目录中的经理属性实际上是一个链接，在实际存储中该值是以distinguishedName的形式保存的。然而在FIM 2010导入数据时这种情况会导致一些问题，因为绝对数量上的关系，员工的身份信息通常会先于经理的身份信息导入，这时需要一种机制来保存这种连接，而FIM 2010开发人员给出的方案就是在连接器空间中使用所谓占位符对象。

在实际数据库中，连接器空间对应FIMSynchronizationService数据库中的mms_connectorspace表。

在了解完同步服务所连接的“内部系统”之后，再来看看FIM 2010是如何连接外部系统的。这里将引入另外一个术语，管理代理（Management Agent）。

Management Agent在FIM 2010中的作用是连接各个外部系统，它本身规定了需要进行同步的身份信息，信息处理规则，以及如何进行同步。简而言之，管理代理是FIM 2010和其它数据源进行联系时的代理人。FIM 2010本身自带了很多管理代理，系统管理员可以通过FIM 2010与很多信息系统进行连接。当然这也是FIM 2010考验Windows管理员的地方，因为可能其它异构系统的管理员并不清楚FIM 2010的工作机制，他们在你的配置过程中不一定能帮上忙，这点是需要各位注意的。

当然，我写本系列博客的目的就是降低大家对FIM 2010的恐惧感，至少可以先试着把微软这一侧的东西摆平，其它系统那就是人挡杀人，佛挡杀佛，看各位的功力了。关键一点是你是否有足够的信心说出“我不怕”这三个字？

扯远了，在回到管理代理本身，大家看到有这么多代理中，有一个非常特殊。那就是FIM Service Management Agent。因为它所连接的是FIM连接器空间，而这个连接器空间的作用就是作为Metaverse的镜像。Metaverse和FIM连接器空间之间的数据同步是通过非声明性规则（nondeclarative rule）来配置的。好的，各位又被我吓到了，什么叫非声明性规则？暂时可以把它理解成这是来自ILM的馈赠品，也就是所谓的老的同步规则。这个名词本身主要是用来区分在SharePoint中所配置的属于FIM 2010的新型同步规则（Synchronization Rule）。以下是一张配置好的截图：

不过请大家注意一点，这张图中的配置是为了简化后续的讲解过程，所以仅选择了非常少的属性进行映射。一旦涉及到活动目录将会变得非常复杂，这也是FIM 2010的配置过程中最复杂的一项工作，这里先给大家打下预防针。

接下来的一篇博文中将重点介绍同步规则以及在同步规则中使用的专用术语，敬请期待。

使用Forefront Identity Manager 2010进行高效身份管理 (03): Forefront Identity Manager 2010 安装过程概述（下）

在上次课程中，FIM 2010所需要的各种先决条件已经准备就绪，接下来就要开始进行正式的安装。具体安装过程其实并不是很复杂，你还可以用无人值守安装选项，复杂的是安装后需要进行设置。但无论如何，先来走一遍安装过程。

首先各位可以在下载中心下载FIM 2010的测试版软件。然后将下载后的文件解压缩，双击运行其中的FIMSplash.htm，可以注意到安装向导会以左右两栏的形式显示，在本系列课程中，主要关注四个组件，Identity Manager Service and Portal，Password Change Notification Service，Identity Manager Synchronization Service，Identity Manager Clients, Add-ins and Extensions.

首先需要在CNSHFIMSVR01这台服务器上安装的是Identity Manager Synchronization Service，在单击FIMSplash.htm中对应的链接之后，会出现安装向导，接下来只需要按照向导的提示进行配置即可。当然各位可能会担心出现各种不可预知的情况，那么也可以用msiexec /i /lv* 的形式来启用安装日志，当异常发生时可以进行排错。这里给出几张截图，以及一些需要注意的地方。

在确认完一些常规事项后，首先需要连接远程数据库。这里如果大家是用fimadmin而非administrator这个帐号安装的话，需要注意授予fimadmin相应的数据库权限。因为是测试环境，我授予的是sysadmin权限，在生产环境中需要根据安全策略进行调整。包括接下来的SQL Instance的选择，也需要根据实际情况来确定。我这里使用默认的命名实例。

然后是配置Synchronization Service的服务帐号，因为已经提前准备完成，所以这里直接输入对应的帐号及密码即可。

然后确认勾选了启用入站RPC通讯的防火墙策略。

然后需要创建一个备份文件夹，用于备份加密密钥。

至此，FIM 2010的一个核心组件，Synchronization Service便安装完成，稍后还需要安装补丁，不过接下来还是先来安装FIM 2010 Service and Portal组件。

同样这里可以从FIMSplash.htm或者以msiexec /i /lv*来启动安装程序，我这里选择从FIMSplash.htm中直接安装。等安装程序启动，确认完EULA和CEIP之后，出现在各位面前的是选择自定义组件，这里我们暂时先不安装FIM Password Reset Portal，因为自助密码重设是可以单独成篇的一个组件，到时涉及到后会再启用。

当出现数据库选择界面后，注意选择对应的数据库，然后单击下一步。

之后会出现Exchange服务器信息配置界面，这里需要填写测试环境中可用的Exchange 2010服务器，并清除"USE SSL"以及"Mail Server is Exchange Server 2007"选项前的复选框，然后单击下一步继续安装。接下来的一个页面是服务证书，这里需要注意到一点，FIM 2010所需要的证书有着特殊的选项，因此选择创建自签名证书即可。

接下来还需要按照向导配置相应的帐号信息，截图如下：

安装完成后，接下来我们需要安装补丁，各位可以使用关键词“Forefront Identity Manager 2010”，从Microsoft Update目录下载相应的补丁文件。至于FIM 2010的版本历史变更信息可以参考TechNet上的这篇Wiki。

补丁的安装过程就不在详述了，唯一需要注意到的一点是，打补丁之前需要停止FIM 2010的两个后台服务，这个任务可以通过使用命令来完成：

sc stop FIMService

sc stop FIMSynchronizationService

接下来，需要执行一些后续配置任务，如果大家对照着测试环境搭建指南的话，会发现我这边省略了一些步骤，这主要是因为，有些步骤我已经在创建帐号的时候已经完成了，因此还请大家留意。

首先，我们需要将FIMService加入本地管理员组，这是一件相当轻松的活，一行命令就可以搞定：

net localgroup FIMSyncAdmins corp\fimservice /add

接下来，需要关闭FIM Portal的NTLM验证，同样的我们需要编辑网站根目录下的web.config文件。为此我还是为大家准备了PowerShell脚本来完成这项工作：

Copy-Item C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config.backup

$webConfig = Get-Content C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config

$webConfig = $webConfig -replace "timeoutInMilliseconds=`"60000`" />","timeoutInMilliseconds=`"60000`" requireKerberos=`"true`" />"

Set-Content -Value $webConfig -Path C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config -Force

iisreset

接下来由于FIM Portal是基于SharePoint的，在默认安装的情况下，SharePoint会在后台进行爬网，并对数据进行索引。但是对于FIM Portal来说并不需要启用这项功能，因此需要通过SharePoint 3.0 Central Administration关闭索引服务。

在打开SharePoint 3.0 Central Administration之后，依次单击Operations，Global Configuration下的Timer Job Definations，“SharePoint Services Search Refresh”，然后单击禁用按钮。

接下来，还需要强化FIM Portal的安全，也就是为网站启用SSL。这里我采取的方法和测试环境搭建指南中的步骤有些不同，因为会使用到所谓的SAN证书。对熟悉Exchange配置的朋友来说，这项工作肯定不陌生。实际上总结起来，就是使用特殊的证书模板，基于这个模板的证书允许用户使用多个地址来访问网站，浏览器中也不会提示错误。这里我并不想详述相关的配置过程，有需要的朋友可以自己找下资料来研究下。这里提醒一点，千万别忘记在证书模板的安全选项卡上赋予相应的权限，因为我们正在使用fimadmin这个帐号进行操作。当然你也可以使用其他账号来申请证书，这取决于企业内的证书申请流程。这里只是提醒一下各位留意下这个问题。

由于Windows Server 2008 R2中本地计算机的证书管理单元得到了极大的增强，因此我们可以通过这个管理单元来申请证书。具体操作步骤就是，打开一个空白的管理单元控制台，然后添加本地计算机证书管理单元。接着在Certificates(Local Computer)>Personal>Certificates节点上单击右键，然后选择申请新的证书。

申请完证书后，只需要在IIS管理控制台中配置一下即可，然后再在IE中进行验证。

接下来，各位需要将相关地址加入到Intranet Sites中。完成之后，还需要修改User Administrators集，保证只有少数人员才有管理员权限。具体操作步骤，各位可以参考测试环境配置指南"Restrict Membership in the User Administrators Set"一节的内容，这里只给出相应的配置截图：

最后，整个安装步骤的最后一步是调整FIM Service DB和FIM Synchronization Service DB的初始数据库大小，因为根据最后实际情况来调整数据库大小，从而优化性能。而修改是否成功我们也可以通过T-SQL来确认。

好了，本次关于FIM 2010测试环境的安装及配置说明就到此结束了，从下次开始将要深入了解FIM 2010的一些核心概念。

这里再引用Exchange MCM Hanbing Yang同志的一席话，“en, 要搞这个产品，得比较清楚 ILM, AD (包括SPN, Kerberos, Certificates), Exchange, Sharepoint, SQL, Domino, .Net编程, Web Service, WCF... 遇到异种系统，甚至还要熟悉 Sun, Oracle, SAP。简直不是一个人能玩得下来的东西，的确很有意思的啊。”

如果你做好心理准备的话，那敬请期待。

使用Forefront Identity Manager 2010进行高效身份管理 (02): Forefront Identity Manager 2010 安装过程概述（上）

大家好，今天我接着和大家分享如何使用FIM 2010进行高效身份管理，看过上次课程的朋友可能已经正在摩拳擦掌准备跃跃欲试了吧，那么今天我就要和大家分享如何搭建一套FIM 2010的测试环境。

根据官方的测试环境搭建指南，我们的安装过程分为以下几个部分：

• 基础实验环境准备
  • 安装Exchange 2010 SP1
  • 安装SQL Server 2008 SP2

• 安装FIM 2010 的先决条件
  • 安装必要操作系统组件及软件
  • 准备FIM 2010的服务账号及配置相关程序

• 安装FIM同步服务及门户站点
• 执行后续配置任务

基础实验环境准备

为了完成FIM 2010的典型场景的实验，需要完成以下基础环境的配置。比如每台虚拟机的网络配置，在我的环境中，我专门在Hyper-V虚拟网络管理器中新建了网络类型为内部的虚拟网络，所有FIM 2010测试环境的虚拟机都将使用这个虚拟网络来进行通信。随后我们需要准备以下几台虚拟机：

这里域控制器和证书服务器的准备应该是比较简单的，相信每个SE都应该掌握这两种服务器安装。接下来是Exchange 2010服务器，这对部分人来说，可能从来没有接触过，但么大家可以按照这篇测试环境安装指南来完成Exchange 2010 服务器的安装，包括安装SP1补丁。Exchange 2010安装完成之后可以开启一个测试帐号来验证Exchange服务器是否工作正常，包括OWA的访问及服务器证书的配置。接下来是SQL服务器的配置，由于FIM 2010需要利用SQL Server 2008中的一些新特性，因此我们需要安装SQL Server 2008，并且安装最新的Service Pack补丁包。至于是否要安装Northwind示例数据库，大家可以视自己的情况而定，我们可以使用Northwind中的员工信息数据库来模拟一家企业中的HR数据库，也可以使用在后续介绍中会提到的另一篇测试指南中的SQL语句来创建示例数据库。接下来是是测试服务器，虽然大家可以使用Windows 7作为测试平台，但是为了方便两位终端用户同时进行登录，这里还是推荐大家使用Windows Server 2008 R2。

接下来是可选服务器Lync 2010和SharePoint Server 2010，即使没有这两台服务器，我们也可以了解如何使用FIM 2010来实现用户邮件帐号的自动开启，但是有了这两台服务器，我们可以了解到更多的内容。虽然这两台服务器本身的安装也可以单独成篇，但是这取决于各位目前是否有精力去准备，因此这里将这两台服务器标记为可选。

安装FIM 2010 的先决条件（组件）

接下来，我们就来看下安装FIM 2010的具体步骤，使用到的服务器是CNSHFIMSVR01。以下安装步骤，我根据具体的安装过程做了相应的调整，和测试环境安装指南有细微差异，大家注意区别。虽然我认为写的步骤可能更加顺畅一点。当然我还是建议大家有时间的话，通读英文原版文档。

首先要做的就是安装一些必要软件（服务器组件）。首先需要安装 .NET Framework 3.5.1, IIS 7.5 以及Windows PowerShell ISE.

由于实验环境中使用的操作系统是Windows Server 2008 R2，因此我们可以非常轻松的使用以下命令完成这些组件的安装。这里需要注意IIS 7.5并不需要安装所有组件，详细的组件列表请大家参阅测试环境安装指南。然后我们来看看具体命令：

Import-Module ServerManager

Add-WindowsFeature NET-Framework,PowerShell-ISE

Add-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Redirect

Add-WindowsFeature Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter

Add-WindowsFeature Web-Http-Logging,Web-Request-Monitor

Add-WindowsFeature Web-Basic-Auth,Web-Windows-Auth,Web-Filtering

Add-WindowsFeature Web-Stat-Compression,Web-Dyn-Compression

Add-WindowsFeature Web-Mgmt-Console,Web-Scripting-Tools,Web-Metabase,Web-WMI,Web-Lgcy-Scripting,Web-Lgcy-Mgmt-Console

然后我们需要通过Server Manager关闭IE的增强的安全配置(IE ESC)。接下来需要在CNSHFIMSVR01安装Exchange 2010 SP1的控制台，具体过程就在这里省略了，因为毕竟是很简单的一项工作。然后需要安装Windows SharePoint Service 3.0 SP2。大家可以从下载中心下载64位版本的安装程序。由于是测试环境，因此在安装Windows SharePoint Service 3.0 SP2时选择Basic类型即可。安装完成之后，可以打开IE，访问http://cnshfimsvr01确认是否能成功访问。然后，需要在cnshfimsvr01上安装SQL Native Client组件，该组件可以在SQL Server 2008的安装DVD下的\x64\Setup\x64目录下找到。

接下来登录cnshsqlsvr01确认SQL的“全文搜索（Full-Text Search）”组件是否安装。如果没有安装，则需要安装，然后在重新应用SP2补丁。

支持，FIM 2010所需要的必要软件及组件就已经完成了，接下来需要准备准备FIM 2010的服务账号及配置相关程序。具体操作过程如下。

首先可以使用以下命令，准备FIM 2010的服务帐号，因为测试环境中域控制器的操作系统版本是Windows Server 2008 R2，因此可以通过以下PowerShell命令来准备服务帐号。

Import-Module ActiveDirectory

$secuPwd = ConvertTo-SecureString -String "abcd@123" -AsPlainText -Force

$dNSRoot = (Get-ADDomain).DNSRoot

New-ADUser -Name "FIMService" -SamAccountName "FIMService" -UserPrincipalName "FIMService@$dNSRoot" -GivenName "Service" -Surname "FIM" -DisplayName "FIMService" -Description "FIM Service" -AccountPassword $secuPwd -PasswordNeverExpires:$true -Enabled:$true -TrustedForDelegation:$True -OtherAttributes @{'servicePrincipalName'=@("FIMService/CNSHFIMSVR01","FIMService/CNSHFIMSVR01.$dNSRoot")}

New-ADUser -Name "FIMSynchService" -SamAccountName "FIMSynchService" -UserPrincipalName "FIMSynchService@$dNSRoot" -GivenName "SynchService" -Surname "FIM" -DisplayName "FIM SynchService" -Description "FIMSynchService" -AccountPassword $secuPwd -PasswordNeverExpires:$true -Enabled:$true

New-ADUser -Name "FIMMA" -SamAccountName "FIMMA" -UserPrincipalName "FIMMA@$dNSRoot" -GivenName "MA" -Surname "FIM" -DisplayName "FIM MA" -Description "FIM MA" -AccountPassword $secuPwd -PasswordNeverExpires:$true -Enabled:$true

New-ADUser -Name "FIMADMA" -SamAccountName "FIMADMA" -UserPrincipalName "FIMADMA@$dNSRoot" -GivenName "ADMA" -Surname "FIM" -DisplayName "FIM ADMA" -Description "FIM ADMA" -AccountPassword $secuPwd -PasswordNeverExpires:$true -Enabled:$true

New-ADUser -Name "SPService" -SamAccountName "SPService" -UserPrincipalName "SPService@$dNSRoot" -GivenName "Service" -Surname "SP" -DisplayName "SP Service" -Description "SP Service" -AccountPassword $secuPwd -PasswordNeverExpires:$true -Enabled:$true -TrustedForDelegation:$True -OtherAttributes @{'servicePrincipalName'=@("HTTP/CNSHFIMSVR01","HTTP/CNSHFIMSVR01.$dNSRoot")}

接下来，简单说明下这里的命令。看过之前我关于PowerShell AD Module介绍的朋友自然不会对这里所用到的命令感到太陌生。首先因为打开的是一个普通的PowerShell窗口，因此需要导入AD Module。接下来因为创建服务帐号需要密码，这里通过ConvertTo-SecureString生成。接下来，为了使得脚本在各式各样的测试环境（不同的域名）中都能正常运行，这里使用Get-ADDomain命令将当前域名保存到变量中，供后续命令使用。这里还需要注意，某些帐号需要设置ServicePricipalName属性，请大家注意下我在命令里是如何输入的。至于具体说明，还请各位查阅下之前我所写的PowerShell AD Module的命令。

服务帐号创建完成之后，接下来需要为FIMService这个帐号启用邮箱，并根据实验手册中所提到的设置来强化这个邮箱的安全。而这一切，也可以用Exchange Management Shell来完成。具体命令如下：

Enable-Mailbox -Identity 'corp.contoso.com/ServiceAccounts/FIM/FIMService' -Alias 'FIMService'

Get-Mailbox -Identity FIMService | Set-Mailbox -RequireSenderAuthenticationEnabled $true -MaxSendSize 1MB

接下来，我们需要增强FIMService以及FIMSynchService帐号的安全，不允许它们以批处理以及本地方式登录，并拒绝从网络访问。操作本身也是很简单的，在打开本地安全策略控制台（secpol.msc）之后，依次设置即可。

接下来我们需要检查SQL Server Agent是否已经设置为自动启动，并且启动SQL Server Agent。同样的，也可以使用命令来完成这项工作（从CNSHFIMSVR01上进行远程查询，CNSHSQLSVR01是数据库服务器）。

sc \\cnshsqlsvr01 query SQLSERVERAGENT

sc \\cnshsqlsvr01 qc SQLSERVERAGENT

如果SQL Server Agent在安装时没有被设置为自动启动，那么我们可以通过以下命令来设置：

sc \\cnshsqlsvr01 config SQLSERVERAGENT start= auto

sc \\cnshsqlsvr01 start SQLSERVERAGENT

完成SQL Server Agent的设置之后，需要设置SQL服务器上的防火墙例外，允许远程服务器连接数据库。当然如果域内安全策略允许的话，我们可以直接关闭Windows的防火墙。顺带说一句，可以使用netsh设置防火墙例外，具体命令如下：

netsh advfirewall firewall set Rule group Name="File And Printer Shareing" dir=in action=allow

netsh advfirewall firewall Add rule name="Allow SQL TCP Port" dir=in protocol=tcp localport=1433 action=allow

netsh advfirewall firewall Add rule name="Allow SQL UDP Port" dir=in protocol=udp localport=1434 action=allow

最后别忘了开启SQL Server的Named Pipe协议。

接下来，我们要检查SharePoint中的一些设置。首先是用于安装FIM 2010的帐号是否拥有SharePoint站点的管理员权限，虽然实验手册里面用了域管理员帐号（Administrator），但是这里还是推荐大家按照FIM MVP Carol Wapshere的最佳操作实践使用独立账号，比如fimadmin来安装FIM 2010，当然这里也要注意需要授予这个帐号对SQL的管理权限。关于这篇最佳操作实践中涉及到的其它注意事项，我也会在后续的介绍中涉及，请各位到时留意。然后回到SharePoint的设置，在打开SharePoint管理中心后，依次点击Application Management，Site Collection Administrators，并在Site Collection的下拉列表中确保默认站点处于选中站点，然后我们添加fimadmin作为次要站点集管理员。

然后要设置SharePoint默认站点应用程序池的帐号为之前创建的SPService。单击Operations标签之后，再单击Service Accounts连接，打开服务帐号配置页面。然后大家可以参考以下页面的设置。单击OK保存设置后，需要在命令提示符下执行 iisreset 来重启IIS。

接下来是比较tricky的一个地方，我们需要手动修改IIS服务器上的ApplicationHost.config文件，开启对Kerberos协议的支持。ApplicationHost.config改起来比较麻烦，因为是一个XML文件，没有好的编辑器的话，容易改错，导致整个IIS不能正常工作。这里我为各位准备了以下PowerShell命令，减少大家因为配置出错而产生的问题。当然为了防止出现意外，一开始会备份applicationHost.config文件，如有需要大家可以还原。

Copy-Item C:\Windows\System32\inetsrv\config\applicationHost.config C:\Windows\System32\inetsrv\config\applicationHost.config.backup

$appHostConfig = Get-Content C:\Windows\System32\inetsrv\config\applicationHost.config

$appHostConfig = $appHostConfig -replace "windowsAuthentication enabled=`"true`"","windowsAuthentication enabled=`"true`" useKernelMode=`"true`" useAppPoolCredentials=`"true`""

Set-Content -Value $appHostConfig -Path C:\Windows\System32\inetsrv\config\applicationHost.config -Force

iisreset

至此，FIM 2010所需要的各项安装准备工作就此完成，下次将开始正式的安装，敬请期待。

使用Forefront Identity Manager 2010进行高效身份管理 (01): Forefront Identity Manager 2010 概览

本系列文章仅在ITECN和我的个人网站powershellfans.com上发布，恳请各位看官手下留情，转载时请附上原始出处及作者姓名。因为我不保证本系列博客的更新速度，还是请各位自己研究下文章最后的英文资源吧。

大家好，从今天开始将由我为大家介绍Forefront Identity Manager 2010这一款企业级产品。该款产品是微软公司为了解决当今企业身份管理领域中所面临的各种问题而推出的一款高端产品。之所以说高端，是因为Forefront Identity Manager 2010所要解决的是核心基础架构优化中动态化阶段所面临的问题。

• Forefront Identity Manager 2010的产品定位

这里我们先来简单回顾下核心基础架构优化（CoreIO）的四个阶段。

大家可以注意到在这张图中，每个管理维度在核心基础架构的不同阶段，都使用了几个非常明显的特征进行描述。可能部分特征是很多IT专业人士曾经经历或者已经经历的，读到的时候嘴角也许会泛起一丝苦笑吧。这里我们或者更准确的说是Forefront Identity Manager 2010所要关注的是身份和访问管理维度在动态化阶段中的“自动化账户管理”（对应的英文术语是Automated Account Provisioning，或者在仅讨论FIM 2010 时，会使用更简单的缩写，Auto-Provisioning。当然这个词也会被用在其他领域，比如虚拟机的Auto-Provisioning。）所以在开篇之所以称FIM 2010是一款高端产品的原因就在于此。

不可否认核心基础架构优化犹如在一个企业中实现“登月”计划，要达到最高阶段，动态化，需要从管理层到运维团队各级人员耗费好几年，甚至十几年的时间才能完成。而且整个过程中各种技术以及非技术的因素会使得整个项目停滞甚至倒退。然而要成为一名优秀的IT基础架构管理人员，如果将核心基础架构优化设定为你的职业目标，那么相信你在十年后再来回顾你走过的这一段充满荆棘和陷阱的旅程后，你一定会为此感到自豪。

• 目前企业身份管理中遇到的各种挑战

随着企业信息化建设的不断深入，作为IT管理人员，我们会发现企业的生产环境中引入了各式各样的系统。这里以微软的产品为例来举个简单的例子。比如在一个上规模的中型企业（CONTOSO）中，我们会发现有基于Exchange 2010的邮件系统，基于Lync 2010的即时消息系统，基于SharePoint 2010的协作系统，以及为支撑这些系统运行的SQL Server 2008。然而企业管理员不久之后就会发现当新员工入职时，仅仅是开通各个系统的用户帐号就是一件非常繁琐的事，因为各个系统都提供了各自的管理工具来开启帐号，而帐号管理员不得不在各个系统管理控制台之间游走，进行手动的帐号开启工作，既费时又容易出错。

而管理层对IT基础架构的要求越来越高，比如人事及各部门经理会关心新员工入职需要花费多久才能形成战斗力。而新员工形成战斗力的关键在于他需要花多少时间才能有各个系统（包括用于学习的测试系统）的访问权限，很明显这个重担又落在IT基础架构管理员的肩上。

刚才谈论的是员工入职的情况，当一位员工在一家企业工作时，可能会经历多个岗位，这也意味着在后台IT系统中他的信息将会发生变更。比如在Exchange中需要将异动员工加入对应部门的通讯组，相应的安全组成员身份也要发生变更，否则各种基于RBAC(Role-Based Access Control)实现的安全控制将失去作用。

最后当员工离职时，需要及时关闭离职员工在各个系统内的权限，防止心有不满的员工做出各种有害于企业信息系统的恶意破坏事件，这点在各个业务系统包括IT系统之内的管理员离职时尤为重要。

以上简单描述了在当今企业中，仅用户身份管理这一块所面临的各种挑战。接下来我们就来看看FIM 2010是如何解决这些挑战的。

• Forefront Identity Manager 2010的前世今生

在正式开始介绍Forefront Identity Manger 2010的功能之前，我们先来简单回顾下Forefront Identity Manager 2010的产品发展历史。也许大家会和我一样认为Forefront Identity Manager 2010是在2010年突然冒出来的Forefront家族中的一款新产品，但实际上不是。Forefront Identity Manager 2010实际上已经是第三代产品，前两代产品分别是Microsoft Identity Integration Server 2003和Identity Lifecycle Manager 2007。

前两代产品的定位主要是探寻身份管理的解决方案，他们的目标用户群是企业中的管理员，帮助后台管理员实现各个系统之间用户身份信息的同步。那么到了Forefront Identity Manager 2010，产品组经过这么多年不懈的努力后终于将身份管理这项工作推向了前台，允许最终用户参与到身份管理工作中，降低了IT专业人士在身份管理方向投入的工作量。

而且产品本身在经历过两代产品的历练之后，在形成后台成熟的管理模型后，终于在Forefront Identity Manager 2010中实现了基于SharePoint的面向最终用户和管理员的友好管理界面，并在处理常规场景时省去了二次开发的步骤，允许用户直接借助FIM 2010处理常规场景下的问题。接下来我们就来看看FIM 2010中到底有哪些功能。

• Forefront Identity Manager 2010 功能概览

Forefront Identity Manager 2010在进行产品设计时，考虑到了以下两方面的管理工作，一方面是身份（Identity）管理，另一方面是证书管理。本系列博客文章将仅包含身份管理这一块的知识点，带领大家熟悉身份管理这一块的各项功能和术语。在身份管理这一块，FIM 2010为管理员和普通用户提供了以下几方面的内容：

• 用户管理
• 组管理
• 自助密码重设
• 最终用户操作体验

接下来在深入了解FIM 2010身份管理的各个知识点之前，我们先来看一下当一切配置完毕之后FIM 2010给我们带来的体验。

• 用户管理

在CoreIO动态化阶段，我们通常提倡所谓的“人事驱动”（HR-driven）用户身份管理模型，也就是以人事系统的数据库作为员工信息的权威数据源。这其实是非常符合企业流程的一个模型，然而有时候某些情况会挑战这个模型。比如员工的移动电话信息，个人住址变更，姓名变更（比如港台地区，女性员工结婚之后需要添加丈夫的姓。）等等。对平时工作异常忙碌的人事专员而言，管理这些信息可能会带来的额外的负担，因此企业管理者通常希望IT基础架构管理者能提供一个系统，允许最终用户自助修改这些信息。而FIM 2010则允许管理基础架构的IT专业人士将FIM 2010的门户网站进行配置（借助Management Policy Rules，后续课程会进行详述），允许最终用户修改特定的信息。

• 组管理

长久以来微软一直提倡在进行权限管理时，使用组而不是单个用户来分配权限，其实这项原则本身也是一项工业标准，基于权限的访问控制（Role-based Access Control, RBAC），在各个厂商的产品中都有一定程度的体现。然而相信很多经历过Windows Server 2003时代的系统管理员都为缺乏一个对最终用户友好的组成员管理工具而感到十分痛苦。然而当微软发布各项冠以2010年份的服务器端产品之后，我们会发现简单的组管理已经出现在Exchange和SharePoint中了。

其实也难为了Exchange和SharePoint的开发人员，因为这两款产品本来就不是为身份管理而设计的。假设FIM 2010能够在强壮一点……呵呵，接下来我们就来看下FIM 2010的组管理。
FIM 2010对活动目录中的组实现了全面的支持，无论组的类型是安全组还是三种组作用域都能实现很好的支持。除此之外，FIM 2010 在它的门户站点中也已三种方式实现了组成员身份管理：

• 基于手动设置
• 基于相同经理
• 基于特定条件

以下三张截图分别呈现了这三种不同的管理方式，在后续的课程中我会进行详述。

基于手动设置

基于相同经理

基于特定条件

• 自助密码重设

长久以来困扰很多IT系统的一个问题就是用户密码的重置，虽然通过在企业内部实现SSO可以在一定程度上降低这个问题的发生次数，但仍然避免不了长假归来之后，会出现大量员工需要重置密码的情况。企业规模越大，这个问题就会越明显，IT服务台在处理其他请求的同时，需要承受这额外的工作负担，的确会感到力不从心。

虽然在FIM 2010横空出世之前，已经有第三方产品实现了自主密码重设，但是那款产品设计目标单一，不像FIM 2010会涵盖其他身份管理领域的问题，因此我们不妨来看看FIM 2010中的自助密码重设。

首先自助密码重设需要在客户端安装FIM 2010的客户端插件，这一点其实并不意外。当然有朋友会问在大环境下的客户端部署问题。的确这是一个需要综合考虑的问题，首先在初始部署阶段，我们可以利用组策略或者SCCM进行推送。接下来需要做的就是修改客户端操作系统部署镜像。这两点是需要耗费一定的工作量，在进行项目实施的时候需要注意到。但是一旦我们部署完成后，就能享受自主密码重设带来的便利。

首先，客户端插件会如下图所示会修改登录界面，用户可以单击新增加的“Reset Password”打开自助密码重设向导：

当向导打开之后，用户需要回答管理员预先设置的“安全问题”（WIKI），而这些问题的数量和具体内容都是可以通过FIM 2010的后台管理界面进行调整。

而关于如何设置安全问题，各位可以参考以下连接：

http://www.goodsecurityquestions.com/examples.htm

当回答完安全问题后，我们只需要输入符合密码复杂性策略的新密码，便能完成密码重置工作。

（新密码必须符合密码复杂性策略）

（成功通过自助密码重设服务完成重置）

• 丰富的最终用户操作体验

FIM 2010为最终用户提供了丰富多彩的操作体验，首先我们来看下面向最终用户的基于SharePoint的门户网站。

在默认配置下，最终用户可以通过门户网站管理通讯组，个人信息及密码。同时也可以查看提交的申请有没有获得经理批准。总的来说，由于是基于SharePoint的操作，因此整体操作体验还是非常友善的。

自助密码重置插件在刚才的介绍中大家已经看到了，所以我们接下来再来看下另外一个客户端的Outlook插件。

最终用户也可以通过和Outlook集成的插件完成加入组的工作，而经理对用户的加入申请的批准工作也可以在Outlook中完成。

以上就是今天我要和大家分享的全部内容，相信有部分朋友已经迫不及待的想要去了解FIM 2010了吧。那么这里给列出一些学习资源（英文，中文我正在写 :-)）。

Rampup: Implementing Forefront Identity Manager 2010 （必读）

http://technet.microsoft.com/en-us/forefront/ff793470

Test Lab Guide: Forefront Identity Manager 2010 （必读）

http://www.microsoft.com/download/en/details.aspx?id=10269

Test Lab Guide: Managing User Identities with Forefront Identity Manager 2010（必读）

http://www.microsoft.com/download/en/details.aspx?id=26142

FIM 2010 TechNet Library

http://technet.microsoft.com/en-us/library/ee621258(WS.10).aspx

FIM 2010离我们很远么？不FIM 2010的核心功能已经在你身边了……

SharePoint 2010中的用户配置文件同步服务（UPS Service）

这里是论坛上一位朋友实现后的效果。

http://bbs.winos.cn/thread-120897-1-2.html

好了，这次的介绍就到这里，敬请期待下次的介绍。