欢迎光临 Enjoy IT (ITECN.NET) 登录 | 注册 | 帮助

分享:Windows Server 2012 Test Lab Guides

从Windows Server "8" Beta开始,TechNet wiki页面上分享了一套非常棒的测试环境搭建指南,这些指南可以帮助全世界的IT专业人士快速熟悉如何使用Windows Server 2012 在实验室条件下配置相应的测试环境,对有一定经验的人来说,这套测试环境搭建指南又可以巩固以往学习的知识,将其发挥到新一代的操作系统平台之上。

同时实验环境中的一些建议和操作步骤可以作为我们以后搭建真实生产环境的一个良好参考。

以下是WIKI链接,欢迎各位朋友前去围观。

http://social.technet.microsoft.com/wiki/contents/articles/7807.windows-server-2012-test-lab-guides-en-us.aspx

发表于 作者 ghjconan | 1 评论

快速更新: 享受升级到Windows Server 2012的乐趣

大家知道Windows Server 2012昨天正式发布了,然后经过一昼夜的下载,今天早上我下载完了ISO文件。然后晚上回家之后我迫不及待地开始升级工作了。 原先我有两台测试机,一台Windows Server 2012 RC,另一台是Windows Server 2008 R2,两台机器上一共有40台以上的虚拟机。然后由于之前已经阅读过产品组的相关文档,知道Hyper-V 3.0的导入功能异常强大,当系统崩溃然后重新安装完操作系统之后,只要提供相应的文件夹路径,Hyper-V 3.0就能导入这些文件。 于是我采取非常果敢的行动,直接重装操作系统,不做任何备份,然后结果正如产品组设计的那样。废话不多说了,直接上图: image image

图形界面中唯一不能做的是批量选取虚拟机,这应该是产品组决定交给PowerShell去解决了,稍后我会带来相关的截图。 总结起来一个字:

爽!

更新截图:

以下截图是在原先操作系统是Windows Server 2008 R2的测试机上截取的,最开始我直接尝试导入的时候提示导入失败,然后使用Compare-VM查找原因的时候发现是命令无法找到对应的虚拟交换机。

PS C:\> Get-ChildItem 'D:\VMs\Virtual Machines' *.xml | %{Compare-VM -Path $_.FullName} | Select-Object -ExpandPropertyIncompatibilities | FT -AutoSize image

然后执行以下命令断开虚拟网卡,并尝试重新导入,该命令修改自Compare-VM中的示例。该命令仅在我的测试环境下进行测试,各位应根据自己的环境作出相应的调整。 PS C:\> Get-ChildItem 'D:\VMs\Virtual Machines' *.xml | %{$report = Compare-VM -Path $_.FullName; Disconnect-VMNetworkAdapter $report.Incompatibilities.Source -Verbose; Import-VM -CompatibilityReport $report -Verbose}

image

当然导入完成之后,需要重新配置虚拟机的虚拟网卡,但是相信这并不是一件挺麻烦的事,命令很简单

Get-VM One* | %{Connect-VMNetworkAdapter -VMName $_.Name -SwitchName 'Shanghai(192.168.2.0/24)'}

最重要的是我们的虚拟机又能在最少量的配置修改后,又能使用了,而且是在操作系统重装之后!

重要提示:以上方法在测试环境中用用就可以了,因为有时需要在虚拟机内重新设置网卡。生产环境呢,请避免这样粗线条的管理方式,生产环境的应用真心伤不起啊!

我见过一个重要的生产应用的授权和网卡IP绑在一起,导致都没法迁移……汗……

发表于 作者 ghjconan | 0 评论

Windows Server 2012 RC 之 Hyper-V 3.0 PowerShell 命令详解 (04)

今天,我们接着对名词部分是VM的命令来一个巡礼。接下来要出场的是Move-VM,Move-VM的作用是将虚拟机从一台Hyper-V主机移动到另一台主机。如果已经玩过Hyper-V 3.0的朋友一定会被Hyper-V3.0中的移动功能所折服。就我个人而言,因为有时需要将虚拟机存储从SSD移动到西数黑盘上,这个功能是真心实用,向导也是简洁明了。

image

只是大家如果要使用PowerShell来完成移动任务的时候要注意,向导中的两种移动类型是由两个命令支持,分别是Move-VM和Move-VMStorage,今天先来谈谈Move-VM。

Move-VM一共有四个参数集,首先来看最简单的一个。这里还是以08R2-CNSHTSTSVR01这台机器作为示例来演示,我们来看效果:

image

上次已经说过,08R2-CNSHTSTSVR01这是一台没有安装操作系统的虚拟机,因此移动速度很快,我没有截取到包含进度显示的截图,大家可以自己试一试。同时需要注意一点,如果在移动虚拟机的时候要同时移动存储的话必须指定-IncludeStorage参数。同时默认情况下,虚拟机的配置文件和虚拟磁盘是按照目标主机上的缺省设置来配置。因为我的测试环境中是将VHD和配置文件放在不同目录,所以会关注这一点。

接下来,我们来看看新建虚拟机的命令,New-VM。其实在本系列文章的开始,我已经给出三个参数集中一个参数集的使用例子了。这里在使用Show-Command来看下这三个参数集。

image

毫无疑问,上次给出的例子对应“Existing VHD”这个参数集,“No VHD”和“New VHD”也是非常好理解的。这里我就点到为止了,因为还是希望大家多多探索这些基础命令。

New-VM之后是Remove-VM。看到这里,应该有很多朋友都知道怎么用Remove-VM了,一是指定Name参数,而是通过Get-VM得到VM对象,然后通过管道传递给Remove-VM即可。

接下来是Rename-VM。Rename-VM的参数集构成和Remove-VM类似,运行后的结果也是没有任何悬念。

image

接下来的命令是Repair-VM,从目前的帮助信息中,我暂时找不到一个比较好的例子来说明这个命令的作用,因此暂时先放一放。

接下来的一些列命令,是和虚拟机的启动,停止,重启以及暂停运行有关的。Restart-VM自然是用来重启虚拟机,支持管道和输入虚拟机名。接下来的Resume-VM和Suspend-VM则分别用来恢复和挂起虚拟机,使用方法和之前的类似,就不在多做介绍了。同理,Start-VM和Stop-VM则分别用来启动和停止虚拟机,Stop-VM在默认情况下是告诉虚拟机内的操作性系统执行关闭操作,即所谓的Shutdown。如果需要执行硬关机操作则需要指定-Turnoff参数,当然Stop-VM也可以指定-Save参数来保存虚拟机状态,这和Save-VM的作用类似,目前不清楚这项设计是因为RC还没有从Stop-VM中移除这个参数,还是一种冗余设置。

最后我们再来看看Set-VM命令。不用多少,Set-VM是用来更改VM设置的命令,但是在继续介绍之前,请大家记住Set-VM不能更改VM的所有设置。目前可以更改的设置有当Hyper-V主机启动时虚拟机所采取的行动,启动演示,以及当Hyper-V主机关闭时虚拟机所采取的动作。然后是处理器和内存的设置,下面就来看看演示的截图。

image

至此,花了一定的篇幅来和大家分享了名词部分是VM的所用命令,从下次开始,将为大家介绍名词部分是VHD的命令,敬请期待。

发表于 作者 ghjconan | 0 评论

Windows Server 2012 RC 之 Hyper-V 3.0 PowerShell 命令详解 (03)

今天我们继续来过一下和VM有关的命令。根据第一篇文章给出的名词是VM的命令列表,接下来就轮到这些命令中的老大哥Get-VM登场了。

Get-VM用起来很简单,虽然有三个参数集,但实际上常用的参数集应该只有一个,也就是使用虚拟机名来获得虚拟机对象的那个参数集。同时如果需要在多台Hyper-V主机上获得对象,我们还需指定ComputerName参数。具体命令执行效果如下:

image

在刚才这个例子中,我在testserver和cnshhypervsvr02这两台机器上各有一台名为08R2-CNSHTSTSVR01的虚拟机,因此呈现了截图中的效果。那么假设我Name参数中指定了两台Hyper-V主机中各一台虚拟机名称时会发生什么情况呢?我们试试就知道了:

image

嗯,会报错。好了,接下来我再意识流一把,怎么样来确定一台虚拟机是否在一台Hyper-V主机上存在呢,也就是自定义所谓的Test-VM命令,默认模块中是没有这个命令的。我们可以自己编写这个函数,代码如下:

Function Test-VM
{
 [cmdletbinding()]
 Param
 (
  [Parameter(Mandatory=$true,Position=1)]
  [string[]]$Name,
  [Parameter(Mandatory=$true,Position=2)]
  [string[]]$ComputerName
 )
 Process
 {
  $results = @()
  foreach ($cName in $ComputerName) {
  foreach ($vName in $Name) {
  $result = New-Object System.Management.Automation.PSObject
  Try
  {
   $vm = Get-VM -ComputerName $cName -Name $vName -ErrorAction Stop
   if ($vm -ne $null) {
    $Existence = $true
   } else {
    $Existence = $false
   }
  }
  Catch
  {
   #Display an error message
  }
   $result | Add-Member -NotePropertyName ComputerName -NotePropertyValue $cName
   $result | Add-Member -NotePropertyName Name -NotePropertyValue $vName
   $result | Add-Member -NotePropertyName Existence -NotePropertyValue $Existence
   $results += $result
  }
 }
 return $results
}

结果也不赖:

image

接下来我们要看的是Measure-VM这个命令。该命令的作用是产生虚拟机的处理器,内存,网络以及存储方面的使用率报表。在使用这个命令之前,必须运行Enable-VMResourceMetering命令启用虚拟机的资源使用记录。这里还需要注意点,默认情况下,Enable-VMResourceMetering需要用户输入虚拟机名,来针对一台或者多台虚拟机启用资源使用记录。大家觉得敲名字烦的话,可以使用Get-VM找到想要设置的虚拟机,然后通过管道传递给Enable-VMResourceMetering即可,命令很简单,Get-VM -Name 08R2-CNSHA* | Enable-VMResourceMetering。完成之后就可以运行Measure-VMResourceMetering来看下报告。

image

结果还是不错的,这里有个参数需要大家注意,MeteringDuration,也就是所谓的使用记录时间。因为资源使用的评估需要一定时间,大家可以根据这个值来判断使用记录是否可以作为资源使用基线。如果需要重置的话,则需要运行Reset-VMResourceMetering,而如果因为种种原因需要禁用资源使用记录的话则可以运行Disable-VMResourceMetering,还是可以通过管道进行批量禁用。

image

本次的介绍就到此结束了,主要过了下Get-VM以及名词部分是VMResourceMetering的命令,接下来还用更多精彩的内容,敬请期待。

(更新完成)

发表于 作者 ghjconan | 1 评论

Windows Server 2012 RC 之 Hyper-V 3.0 PowerShell 命令详解 (02)

承接上回,上次我从Hyper-V中的核心名词虚拟机(VM)入手,带领大家迅速看了下和虚拟机快照(VMSnapshot)有关的 命令。今天我们要继续来看下名词部分是VM的命令。

今天首先要介绍的是动词部分以C开始的Compare-VM命令,也就是上篇我说道可能初看看不出个所以然的命令。当然看了帮助之后,“Compares a virtual machine and a virtual machine host for compatibility, returning a compatibility report.”,各位应该就能理解这个命令的作用了,原来是将一台虚拟机和一台虚拟机主机比较,然后产生兼容性报表。这里在我的测试环境中,为了领略下System Center 2012的风采,另一台测试机安装的是Windows Server 2008 R2,当运行该命令后会产生相应的报错:

image

这说明当前RC版本中的的Compare-VM不支持Hyper-V 2.0,这里我也好奇兼容性报告是怎么样的,于是利用Windows to go,重新在另一台机器上安装了Windows Server 2012 RC。然后得到的结果如下:

image

这里大家需要注意,在运行Compare-VM之前,需要使用图形界面或者Enable-VMMigration来启用Hyper-V的Migration功能,而要启用Migration功能,Hyper-V主机必须加入域环境。我的做法是将Hyper-V主机加入这台主机上承载的虚拟机域控中。

接下来要介绍的是Import-VM和Export-VM这组命令,显而易见这两个命令是用来导入和导出虚拟机的。除了在日常的测试中,快速分发牛人配置好的虚拟机环境之外,在Windows Server Server 2012中,克隆域控制器也会使用到Export-VM和Import-VM命令。

Export-VM相对比较简单,只要指定虚拟机名和路径即可,导入的时候则需要参数的组合。

image

Import-VM的参数组合(准确的说是参数集),一共分为三种。第一种是使用兼容性报告。第二种参数相对较少,但是有一个关键的参数Register,该参数的作用是根据提供的路径在Hyper-V中注册相应的虚拟机,而不是将虚拟机复制到默认文件夹。注意指定路径时,一定要使用虚拟机的配置文件(.xml格式的文件)。同时该配置文件也会被Hyper-V独占,也就是当删除该虚拟机时,该配置文件将被删除。因此一旦导入虚拟机后,应当视相应的文件夹为虚拟机所使用的文件夹,而非导出的虚拟机文件夹。

image

第三种参数集则相对比较复杂,但是执行的效果正好与第二种相反,关键参数是GenerateNewID和Copy,其它参数都是可选参数,可以按需指定,执行后的效果就是虚拟机文件将被复制到对应的默认文件夹。

image

因此第三种参数集正是我们分发实验用的虚拟机模板时应当采用的正确方法,在08R2的时候,可能有部分朋友被导出和导入界面迷惑过,那么相信这次就会清楚了。

如果大家光看我说的内容,觉得有点模棱两可的话,最简单的方法就是新建一台没有安装操作系统的虚拟机,然后执行刚才说的导入和导出操作。因为虚拟机没有安装任何操作系统,磁盘文件的大小处于最小值,方便我们迅速验证命令的结果。

本次关于Compare-VM,Import-VM以及Export-VM的介绍就到此结束了,敬请期待下次的介绍。

注意:本文所描述的是正在开发中的一款产品。

(更新结束)

发表于 作者 ghjconan | 0 评论

Windows Server 2012 RC 之 Hyper-V 3.0 PowerShell 命令详解 (01)

大家好,今天我们就来详细看看Windows Server 2012 RC中Hyper-V 3.0提供了哪些PowerShell命令来方便我们进行管理。上篇文章有朋友批评我官味太重,那我们这次就回归技术,不过我还是提醒大家有些事情还是请大家考虑下,不要真到那一天后再来后悔。

在详细介绍具体命令之前,提醒大家一下。在Windows PowerShell 3.0中增加了Update-Help命令,各位可以随时执行该命令获得最新的帮助信息。目前Windows部门下的各个产品组都在对帮助文档进行更新。当然有部分模块的帮助还没有就位,还请各位耐心等待。

image

然后还是老规矩,查下Hyper-V 3.0的PowerShell命令有多少,(Get-Command -Module Hyper-V).Count一下就可以搞定,最后得到数量是164。好吧,人不疯狂枉少年不是,难道我要把这些命令都记下来?当然不是,我还是那句话,一点要知道你准备操作的对象是什么,对应的英文单词是什么,剩下的交给PowerShell的Tab键补完。如果你真的能背下来呢,我觉得你很伟大,但真的是没必要。

image

今天要和大家看的就是Hyper-V中的核心对象,虚拟机(VM)。接下来就让我看看具体有哪些动词和VM搭配。名词很多,有些大家很熟悉,比如New,Get,Remove;有些很好理解,比如Checkpoint,Import,Export;有些则第一眼看上去有点迷茫,比如Compare,Measure。没关系。这正是我要去解答,无论各位是否接触过Hyper-V 2.0,本系列文章还是会做一个全景式覆盖。同时这里正好提一点,有些我认为简单的命令就不在单独用文字列出了,我还是希望大家多敲敲键盘,培养下和PowerShell的感情。

image

首当其冲的是Checkpoint-VM,命令本身很好理解,就是给虚拟机做快照。该命令的语法如下:

SYNTAX
    Checkpoint-VM [-Name] <String[]> [[-SnapshotName] <String>] [-AsJob [<SwitchParameter>]] [-ComputerName
    <String[]>] [-Passthru [<SwitchParameter>]] [<CommonParameters>]

    Checkpoint-VM [-VM] <VirtualMachine[]> [[-SnapshotName] <String>] [-AsJob [<SwitchParameter>]] [-Passthru
    [<SwitchParameter>]] [<CommonParameters>]

根据语法,我们可以同时输入多台虚拟机的名称,然后对这些虚拟机创建快照。同时又可以使用Get-VM将得到的虚拟机对象通过管道传递给Checkpoint-VM来创建快照,这里的截图展示的是第二个例子。

image

好了,快照很快就创建完成了,但是怎么样删除快照呢?各位包括我都没在之前的列表中看到类似Remove-Checkpoint的命令啊。那是因为快照的对应的名词是Snapshot,而在Module中对应的名词有VM前缀,因此要管理虚拟机快照的,我们需要使用Export-VMSnapshot,Get-VMSnapshot,Remove-VMSnapshot,Rename-VMSnapshot和Restore-VMSnapshot。至于为什么不用New-VMSnapshot,我也不太清楚,所以上connect.microsoft.com问了下,目前等待答案中。

这五个cmdlets中最容易理解的就是Restore-VMSnapshot,也就是所谓的快照回滚,在Hyper-V 2.0中经常被推荐在测试环境中使用。而Get-VMSnapshot也很容易理解,得到快照对象,想必有支持输入计算机名的参数,当然也可以用Get-VM将得到的虚拟机对象传递给Get-VMSnapshot,然后再传递给Rename-VMSnapshot或者Remove-VMSnapshot。

image

最后来说说,Export-VMSnapshot,很简单就是导出快照。

image

今天的内容就到此结束了,可能有点意识流,想到什么就说什么,一下子从名词VM跳到VMSnapshot。但是和大家分享下我自己的观点,如果你对一件事产生疑问,那么在最短时间内搞懂它,对这件事的记忆就越深刻。

注意:本文描述的是正在开发中的一款产品。

(更新完成)

发表于 作者 ghjconan | 1 评论

Windows Server 2012 RC 介绍 (08) – 搭建基于Hyper-V 3.0 的测试平台

大家好,正如大家所知,Windows Server 2012 RC已于昨日正式发布,做为Geek一份子的我,在下载完成后就迫不及待的将我工作和家中的测试机升级到Windows Server 2012 RC,享受Hyper-V 3.0带来的便利。

在正文开始之前,谈谈我今天为什么选择搭建测试平台这个话题。正如我在之前招聘广告中所说的,五年的时光匆匆而过,大家可能都知道,在中国,对IT人士而言,五年可能是他作为技术专家整个生涯中一半的时间。因此不知不觉中,上一辈IT专业人士的接力棒已经传到我们这一代手中。像我这样的85后可能是无比幸运的一代,不用为Windows NT 4.0 和 Windows Server 2000去烦恼,当Windows Server 2003交付到我们手中时已经是非常健壮的一个系统了,同时我们也享受到了上一辈IT专业人士在Webcast上的谆谆教诲。

时光荏苒,摆在新一代IT专业人士面前的命题是如此巨大,如何建设私有云,如何将提高IT服务质量,如何满足审计要求等等。我个人认为接下来的几年将是IT专业人士命运的分水岭。对中小企业来说,私有云的投资成本是一笔可观的数字,在经营还没有走上正轨时,贸然投资私有云必然不是一个明智的选择。而Office 365的落地正在加速,这将是未来中小企业的不二选择。当然在中国质疑的声音很大,中国的市场对Office 365的接受度会因为国情而有各式各样的问题。但是现实情况是,苹果的AppStore已经在开始培养国人购买正版软件的意识了,毕竟繁琐的越狱步骤不是每个人都能接受的。回归段首的论点,为什么我说IT专业人士的分水岭即将到来。很简单,当越来越多的中小企业开始享受公共云带来的服务时,这些企业中的IT人员职位数量必然会被削减。对企业家来说这可能仅仅是财务报表上数字上的变化,但是对一个个体来说这就是命运的变化。有的IT专业人士将会直上云端,而有的则将离去。物尽天择,适者生存,这是自然规则,我们谁都违背不了。

当然,各位朋友也不用被我吓着,现在毕竟还是变革前的黎明,到变革真正成功还需要一段时间,对已经工作的朋友现在就要开始跟上变革的节奏了,而对还没有毕业的孩子们,请你们提前做好准备吧。那么在准备阶段我们需要准备哪些方面的知识呢?还是从云的基础,虚拟化开始说起吧。结合我自己的专长和喜好,我选择了Hyper-V 3.0作为接下来一段时间的讨论话题,当然Windows PowerShell自然不会缺少。关于Windows PowerShell 3.0本身的介绍还需要等一段时间,等文档完善后,自然会更新的。现在着重介绍Windows Server 2012 RC本身的功能。

搭建基于Hyper-V 3.0的测试平台,无外乎以下几步。

1. 安装Windows Server 2012 RC
2. 启用Hyper-V 3.0
3. 配置测试网络
4. 部署虚拟机
5. 开始测试

第一步,对很多朋友来说不是问题,因为微软的开发人员在Windows的安装向导上下了苦功夫,将安装体验优化到现有水平上的极致,大家只要配置一台内存和硬盘足够大以及支持Hyper-V的PC机即可。之前我们可能需要使用其他工具来查看当前计算机是否支持Hyper-V 3.0,现在在系统信息中已经贴心的增加了这一功能。因为我已经启用了Hyper-V,所以截图中提示不会显示信息,大家可以在没有启用Hyper-V之前看看这里会显示什么。

image

说到这个,前段时间Asuka和我说他配了一台32G内存, 2T硬盘的机器,我只能望着我那台坏了一根海盗船内存,西数1T黑盘刚修好的机器叹气啊,哪位老大还是赞助我一台吧。当然这是玩笑,要不是硬盘还贵,我肯定再配一台机器,现在只能用SSD来爽一把。

第二步,启用Hyper-V 3.0。这其实也不难,大家用崭新的服务器管理器(Server Manager)就能完成,当然大家也可以用Windows PowerShell来启用,假设你要在多台机器上启用Hyper-V的话。

image

第三步,配置测试网络。这一步可能之前有部分朋友会感到困扰,因为使用VMWare Workstation的关系。但实际上利用Hyper-V的三种网络,在配合Windows自身的路由和远程访问功能就能搭建出比较完善的网络模型了。接下来我会为大家分享几张截图并加以说明。当然这些内容在Windows Server 2008 R2上也可以使用。

image

首先添加虚拟交换机。因为是家中的测试机,所以192.168.1.0/24是无线路由器所在网络,因此连接类型是External。然后我们再新建一个供测试用的类型为Internal的虚拟交换机,创建的时候使用一个容易辨识的名称,到这里其实都很简单。接下来是一个技巧的问题,我们需要打开网络连接控制面板,找到刚才创建出来的虚拟交换机,然后设置IP地址,注意这里不需要指定网关,网关仅需在物理网卡上设置即可。

image

到此,如果你已经创建了虚拟机,开启了远程桌面,并将虚拟机中的网卡网关地址指向Hyper-V主机上对应的网卡地址,那么你就可以通过远程桌面来管理虚拟机中的操作系统了。唯一的问题是部分朋友可能会需要时不时加载ISO,那在Hyper-V 3.0中,我们可以通过PowerShell来解决,这当然是后话,以后涉及到的时候会说明的。

不过我们的网络配置工作还没有完成,虽然通过以上设置,可以使得虚拟机和Hyper-V宿主机之间进行通讯,但是此时的虚拟机是无法连接Internet,这当然会让我们不爽,因为虚拟机的操作系统如果是试用版的话还需要联网激活,来享受180天的测试时间。因此我们需要安装一台承担路由和远程访问(RRAS)的虚拟机。这台服务器的配置也不复杂,仅需要添加类型外部和内部两块网卡,然后在RRAS中配置下NAT就行。这里需要注意的是同样只要外网网卡设置网关地址即可,同时内网网卡地址,为了方便起见,建议配制成 192.168.X.254。

image

随后我们可以在域控制器上安装DHCP服务,并设置好DNS转发器,然后将DHCP选项中的路由器(网关)地址设置指向RRAS这台机器的内网网卡地址即可,这样每一台新建好的虚拟机只要是使用同一个虚拟交换机就能上网了。

这里也推荐大家可以在Hyper-V宿主机上启用DNS服务器角色,并配置条件转发器将从宿主机上发起的针对corp.contoso.com的查询转发到虚拟机,这样做的好处是你使用远程桌面的时候可以使用FQDN进行连接,否则只能使用IP,这需要在虚拟机模板的远程桌面选项中关闭NLA。同时不建议大家在Hyper-V宿主机上启用RRAS角色,因为你可能会在RRAS配置好NAT之后继续添加虚拟交换机,如果需要该虚拟交换机也能上Internet,则必须重新配置NAT。

最后请大家注意,以上测试环境配置仅适用于家庭网络,在办公网络中启用该设置请联系网络管理员及系统管理员。

第四步,部署虚拟机。建议大家在Hyper-V中安装的第一台不同操作系统的虚拟机都应作为虚拟机模板使用。方法也很简单,使用sysprep即可。这里需要提醒的一点是sysprep新增一个/mode参数,大家可以找找相关的资料看看。作为虚拟机模板的虚拟机在sysprep完毕后,可以从管理控制台中删除,然后将vhd文件设置为只读即可。

image

随后Windows PowerShell就在此时闪亮登场了,由于Hyper-V 3.0有对应的PowerShell模块,使得我们自定义脚本变得如此简单,以下只是一个示例脚本,主要是创建虚拟机,大家可以在这个基础上扩展,来创造满足自己需要的脚本。

Function New-MyTestServerVM
{
    [cmdletbinding()]
    Param
    (
        [Parameter(Mandatory=$true,Position=1)]
        [string]$VMName,
        [Parameter(Mandatory=$true,Position=2)]
        [string]$SwitchName
    )
    Process
    {
        $vhd = New-VHD -ComputerName "TestServer" -Path "e:\vhds\WIN8-$VMName.vhdx" -ParentPath "e:\VHDs\Windows Server 2012 RC Base.vhdx" -Differencing
        New-VM -ComputerName "TestServer" -Name "WIN8-$VMName" -VHDPath $($vhd.Path) -MemoryStartupBytes 512MB -SwitchName $SwitchName
    }
}

第五步,开始测试。有了这样的一个环境,相信很多测试的可以按步就班的开展了,接下来就是各位自己发挥的时间了,敬请享受吧!

最后以狄更斯的双城开篇记作为结尾,来和开篇的叙述呼应吧。

“这是最好的时代,这是最坏的时代,这是智慧的时代,这是愚蠢的时代;这是信仰的时期,这是怀疑的时期;这是光明的季节,这是黑暗的季节;这是希望之春,这是失望之冬;人们面前有着各样事物,人们面前一无所有;人们正在直登天堂;人们正在直下地狱。”

注意:本文描述的是正在开发中的一款产品,如果将来有所变动,造成本文不在适用的话,请以正式版为准。

(更新完成)

发表于 作者 ghjconan | 2 评论

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

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

image

嗯,不错,有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}

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

image

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

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

image

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

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

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

发表于 作者 ghjconan | 0 评论

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。

image

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

DHCP策略配置概览

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

image

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

image

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

image

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

image

image

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看下复制结果,结果如下:

image

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

image

这里大家可以看到速度明显不如第一次快了。这个实验的目的主要就是为了说明,在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。

image

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

发表于 作者 ghjconan | 1 评论

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),这一点当我们在建立多条策略之后就可以看到,如下图所示:

image

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

当客户端将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命令,敬请期待。

(上篇更新完成)

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

发表于 作者 ghjconan | 0 评论

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

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

image

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

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

image

接下来就是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中的强制退出效果。

image

image

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

image

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

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

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

image

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

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

image

第五点,如果维护任务需要长时间运行,请使用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中的其它新功能。

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

发表于 作者 ghjconan | 0 评论

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端的设置,和以前相比没有太多变化。

image

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

image

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

image

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

image

image

其结果还是一样的,我们可以在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授权规则。

image

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

image

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

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

image

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

Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI

image

该项设置也是控制谁能使用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

image

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

image

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

image

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

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

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

(中篇更新完成)

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

发表于 作者 ghjconan | 0 评论

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都可以访问。

image

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项来进行安装。

image

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

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

image

(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文档来简要描述整个配置过程。

image

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

image

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

image

配置授权规则及站点安全

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

image

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

image

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

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

image

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

image

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

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

image

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

image

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

(上篇更新完成)

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

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

发表于 作者 ghjconan | 0 评论

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中了。

clip_image0011

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

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

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

clip_image002[1]

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

clip_image003[1]

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

clip_image004

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

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

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

clip_image005

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

clip_image006

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

clip_image007

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

clip_image008

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

clip_image009

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

clip_image010

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

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

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

clip_image011

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

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

clip_image012

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

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

clip_image013

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

clip_image014

这毫无疑问改善了部署体验,写到这里,我也暂时无法猜测后台是直接通过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时具体讨论,我现在能说的就一个字,爽!)

clip_image015

完成之后,我们就运行以下命令来安装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有关。以下就是命令运行结果:

clip_image016

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

clip_image017

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

clip_image018

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

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

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

发表于 作者 ghjconan | 22 评论
归档在:

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

创建同步规则

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

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

clip_image001

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

clip_image002

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

clip_image003

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

clip_image004

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

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

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

clip_image005

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

clip_image006

启用同步规则资源调配

在创建完管理代理,管理代理运行模式,同步规则之后,大家是不是会基于看下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”。

clip_image007

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

clip_image008

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

clip_image009

初始化FIM同步服务

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

clip_image010

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

clip_image011

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

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

clip_image012

确认数据导出状态

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

clip_image013

调整属性流优先级

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

clip_image014

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

clip_image015

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

clip_image016

测试入站复制

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

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

从外部系统(数据文件)中导入用户

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

clip_image017

在Metaverse中创建(Projection)对象

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

clip_image018

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

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

clip_image019

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

clip_image020

验证用户状态

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

clip_image021

clip_image022

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

发表于 作者 ghjconan | 2 评论
归档在:
更多内容 下一页 »