搭建对接私有环境AD的WorkSpaces桌面服务 – PCMAN的技术博客

本文介绍了如何搭建一个与现有AD对接集成的Workspaces并具备网络访问限制能力的实验环境。其中操作交互较多时间较长，建议预先了解VPC、Subnet、路由表、CloudFormation、Windows Server与微软Active Directory的基础知识，分步实验。

一、背景

Workspaces是AWS在2019底在中国区域最新发布的云桌面服务。Workspaces是基于PCoIP远程协议的高质量的企业级云桌面服务，具备面向企业客户的一系列特性，支持域对接、策略管理、桌面保护、复杂的VPC网络对接等。

体验WorkSpaces非常简单，开通此服务的前置条件是需要AD服务；可以使用AWS托管的Director服务，同时也可以复用企业在自己的IDC或者其他云上部署的AD环境。我们接下来的POC演示部分包含搭建AD环境，并用WorkSpaces和此AD环境进行对接。

本文档描写了如何搭建这样一个实验环境，基于AWS宁夏区域已经上线的Workspaces功能进行撰写。其中AD域将放在AWS北京区域模拟用户私有数据中心场景。

二、架构

本次实验的架构图如下所示。

在本架构中，右侧是客户私有数据中心，通过专线或VPN互联。左侧是AWS区域，在VPC内又分别划分了Public Subnet和Private Subnet，后续我们将通过CloudFormation实现这个架构。

三、搭建AD域

本文档中，以一个AWS北京区域的EC2模拟客户私有环境内的域控制器。这个EC2位于和Workspaces不同的区域，隶属不同的VPC，有不同的CIDR网段。后续实验中，我们将通过VPC Peering，将两个Region打通，配置路由和安全规则组，并以这个方式，模拟生产环境中的DX专线或VPN。

1、搭建AD环境

搭建AD环境可以选择在北京区域的默认VPC上，直接创建EC2实例即可。也可以使用本文提供的CloudFormation来自动创建整个环境。本文将使用CloudFormation。

如果是在默认VPC上手工创建EC2，那么在AD系统版本的选择上推荐Windows Server 2016 Data Center Edition。请注意不要选择Core版本，Core版本只包含Powershell窗口，不包含GUI图形界面。如下截图。

本实验推荐采用CloudFormation方式，将创建独立的VPC，不影响默认VPC下的应用。进入CloudFormation界面，选择从S3加载，并使用如下脚本：

https://s3.cn-northwest-1.amazonaws.com.cn/workspaces-workshop/ad-vpc.yml

操作过程如下截图。输入地址后点击Next继续。

设置CloudFormation的名称，并选择Windows Server要使用的登录密钥。注意，密钥需要事先在本Region内生成好，才可以从这里的下拉框中选中。如下截图。

在接下来的CloudFormation向导的两个步骤都不需要修改参数，直接点击Next下一步即可完成创建。

最后切换到CloudFormation的Output界面，可以看到新的VPC和Windows Server已经创建完成。

2、安装AD组件

连接到创建好的Windows Server 2016上，从开始菜单中，找到“Server Manager”，点击图标继续。

在服务器管理界面上，选择“Dashboard”，点击“Add roles and features”。如下截图。

在Wizard向导的第一步，跳过提示，点击下一步继续。如下截图。

在向导第二部，选择“installation Type”位置，选择“Role-based or feature-based installation”。点击下一步继续。

在选择“Server Selection”的步骤，选择“Select a server from server pool”，并选择本机。请通过IP地址确认当前配置的是本机。

在选择“Server Roles”界面，点击“Active Directory Domain Services”，如下图。

点击后，页面会自动弹出提示，提示依存性关系需要部署更多组件。这一步不需要修改选项，点击“Add Features”继续。

添加组件成功，不需要再选择其他组件了，点击下一步继续。

现在页面来到Features界面，保持默认值不变，点击下一步继续。

在“AD DS”步骤，没有可以设置的选项，点击下一步继续。

在“Confirmation”界面，点击“Install”开始安装。

安装进行中，这里需要等待5分钟左右，如下截图。

安装完成，提示需要后续配置操作，这里可以点击close关闭窗口，并进行后续配置。如下截图。

至此这个步骤完成，进入后续配置步骤。

3、配置域控制器

返回到“Dashboard”界面，在右上角找到带叹号表示的小旗子，点击后出现下拉框，选择“Post-deployment Configuration”里边的“Promote this server to a domain controller”，开始域控制器的配置。如下截图。

进入Wizard后，在第一个步骤“Deployment Configuration”，选择“Add a new forest”，然后输入域要使用的域名，例如本次实验使用那个“mywp01.com”。实验使用的域名是内部使用，不需要考虑是否在Internet上是真实有效的。如下截图。

进入“Domain Controller Options”页面，保持页面上方的选项不需要修改，在下方输入管理员密码。注意密码需要考虑复杂度，包含大小写、数字、特殊字符。如下截图。

在“DNS Options”设置界面，保持选项不变，点击“Next”继续。如下截图。

在“Addtional Options”中，保持默认的NetBIOS名字不变，点击“Next”继续。如下截图。

在“Path”界面，保持目录选项不变，直接点击“Next”下一步继续。如下截图。

在“Review Options”界面，点击“Next”下一步继续。如下截图。

在“Prerequisites Check”界面中，保持选项不变，点击“Install”。如下截图。

在“Installation”界面中，可查看到安装进度。安装程序可能会给出一些提示，这里可以不用干预。配置过程可能需要5-10分钟。

部署完成后，系统会自动重启。

4、配置DNS

在重启完成后，我们重新连接到远程桌面。这个时候，可以不使用domain用户登录，也可以继续使用原先的administrator用户名和密码的登录方式。

连接到RDP后，点击“Windows Administrative Tools”。如下截图。

在管理工具中，找到“DNS”，如下截图。

进入DNS后，点击左侧的当前服务器名单，展开菜单，选择“Forward Lookup Zone”，正向解析，在点击开创建域时候配置的域名“mywp01.com”，用鼠标右键点击，然后选择“Other New Records”。如下截图。

在弹出的的“Resource Record Type”界面中，向下滚动，找到“Service Location”，即SRV记录。点击“Create Record”按钮。如下截图。

添加第一个记录，Service地方填写 ldap，协议填写 tcp，端口填写389，Priority和Weight留空保持默认不需要填写。Host Offering of this service填写为 mywp01.com 也就是根域的名字。填写过程需要手工输入，不要从下拉框中选取。完成后点击OK继续。如下截图。

接下来输入第二个域名。Service地方填写 kerberos，协议填写 tcp，端口填写88，Priority和Weight留空保持默认不需要填写。Host Offering of this service填写为 mywp01.com 也就是根域的名字。填写过程需要手工输入，不要从下拉框中选取。完成后点击OK继续。如下截图。

提交完成后，界面会返回添加域名类型的界面。点击Done退回到DNS管理界面。

配置完成后，还需要重新加载设置。用右键点击根域，然后在弹出菜单中，选择Reload。如下截图。

在是否要重新加载配置的页面，选择Yes。如果是生产环境，此选项也不会中断当前解析服务。重新加载不等于重启Service，因此无需担心。

至此域控制器上的配置工作完成。

四、搭建Workspaces的VPC环境

前文模拟了用户私有数据中心的AD搭建，现在将控制台切换到AWS宁夏区域，进行创建WorkSpaces的准备工作。

1、创建VPC

根据前文所描述的Workspaces网络架构，这里需要创建一个新的VPC，包含Public Subnet，Private Subnet、一个EIP、一个EC2实例用于NAT Instance做网络出口测试，以及跳板机。

配置过程，通过CloudFormation进行。进入宁夏区域的CloudFormation界面，点击创建stack。

选择S3 URL，并填写如下地址。注意：本模版只对宁夏有效。如果需要在海外使用，请将这个文件从宁夏S3上下载到您的笔记本本地，然后上传到您要进行实验的海外区域的S3上，再通过S3调用。

https://s3.cn-northwest-1.amazonaws.com.cn/workspaces-workshop/workspaces-vpc.yml

如下截图。点击下一步继续。

在参数输入界面，名字输入CloudFormation的名字，可任意输入。然后从下拉框中找到本区域的EC2登录密钥。这个密钥需要提前在本区域生成好。选好后点击下一步继续。如下截图。

在下一个配置界面，无需操作，页面翻动到最下方，点击Next继续。如下截图。

在Review界面，无需操作，页面翻动到最下方，点击Next继续。如下截图。

等待数分钟后，创建完成。

CloudFormation创建完成后，我们可通过Output标签页看到输出的VPC和Subnet信息。同时，也会输出用于NAT Gateway以及跳板机的登录信息。

2、设置VPC Peering模拟接入远程的域环境

为了模拟远程的AD接入，我们为Workspaces所在的VPC和域所在的VPC创建Peering。

进入Workspaces所在的AWS Region的VPC界面，点击“Peering Connections”，点击“Create Peering Connection”。如下截图。

在VPC Peering界面中，选择发起方的VPC。注意如果本区域有多个VPC，请注意选择CloudFormation生成的为Workspaces专用的VPC。如下截图。

在远程另一端，选择本次实验模拟域控制器的VPC，这个VPC是在另一个账号名下，并输入VPC ID。请注意账号是纯数字，数字之间不要输入分段的连字符（不带减号）。如下截图。

提交VPC Peering请求成功。如下截图。

现在可在Workspaces所在的区域中看到VPC Peering是等待批准阶段。如下截图。

现在来到域控制器所在的Region上，进入VPC界面，进入Peering Connections界面。找到远程发起的VPC Peering Request，点击Action，点击Accept Request。如下截图。

在弹出的确认窗口中，点击确认。如下截图。

接受Peering成功，点击编辑路由表，前往VPC模块下的路由表界面，编辑路由。如下截图。

在路由表界面，当前模拟AD域的这个环境使用的是默认VPC，因此就选择默认VPC的路由表，点击编辑路由。

在代表企业私有数据中心域控制器这一侧，输入 IP地址 10.1.101.0/24 的网段，然后从Target中选择Peering Connection，然后选择刚才建立的VPC Peering。前边实验中，通过Cloudformation建立好的VPC的网段是10.1.0.0/16，其中包含了Public Subnet和Private Subnet。Public Subnet按传统数据中心的理解就是DMZ区域，Private是放置桌面的内网区域。因此，对接AD时候，从企业内网我们就赋予去往Private Subnet的路由，而Public Subnet是不赋予任何路由的。由此实现了精细的网络权限管控。如下截图。

接下来输入第二个Private Subnet的路由，然后点击Save routes完成。

现在回到要使用Workspaces的宁夏区域，在VPC模块的Peering Connections界面中，刷新页面，可以看到Peering是已经成功的绿色的Active状态。如下截图。

现在进入宁夏区域的VPC界面，找到路由表。CloudFormation为Workspaces创建的Private Subnet私有子网的名字就叫做“Workspaces”，点击这个路由表，编辑之。如下截图。

在编辑路由界面，填写上从Private Subnet回到域控制器方向的路由，即172.31.0.0/15，目标Target选择Peering。如下截图。

至此VPC Peering配置完成了。

以上实验，我们创建了Workspaces要运行的网络环境，以及打通了模拟用户AD的另一个VPC。

五、设置AD Connector对接到Domain

Workspaces在国内支持两种AD方式：1）托管的微软AD，2）对接现有AD。AWS海外区域还支持轻量级的Simple AD服务，但在国内区域暂时没有提供。本实验模拟的是域客户现有AD对接。因此，现在要在客户现有AD的域控制器上进行配置。

1、设置委托

使用管理员Administrator账号登录到前文创建的AD域控制上，登录时候不需要选域登录，就直接输入账号即可。登录后点击开始，找到Windows Adminitrative Tools，点击进入。

找到User and Computers，双击打开。如下截图。

在打开的界面中，找到刚才创建的域，展开菜单，在最下方找到“Users”，用鼠标邮件点击“Users”，在弹出菜单里边选择“New”，然后选择“Group”。如下截图。

在弹出的对话框中，Group Name位置填写“Connectors”，在Group Scope选项中选择Global，在Group type选择“Security”。点击即OK继续。如下截图。

点击OK继续后，创建Group完成。窗口回到User and Computers菜单。用鼠标邮件点击根域，然后选择“Delegation of Control”。如下截图。

在弹出的向导界面，点击Next。

在Select users and groups界面，现在清单中是空白的。点击Add，添加一个新的组。

在输入框中输入刚才创建的组名“Connectors”，然后点击OK继续。

输入正确的话，向导返回上一层添加用户的界面，可以看到Connectors这个Group已经被添加到向导中了。点击Next继续。

在“Tasks to Delegate”界面，选择下方的选项“Create a custom task to delegate”。如下截图。

在“Delegate control of”界面，选择第二大项“Only the following objects in the folder”，然后选中“Computer Objects”，然后不要急于Next，而是向下翻滚动条继续添加。

将页面滚动条翻到最下方后，找到“User objects”，选中之。然后在选中下方的“Create selected objects in this folder”和“Delete selected objects in this folder”这两个选项框。然后点击Next继续。

在Permissions界面，选中上方的“General”和“Property-specific”两个选项，在下方选择“Read”和“Write”两个权限。然后点击Next继续。如下截图。

在向导的最后一步，点击“Finish”完成配置。

配置完成，界面将返回“Users and Computers”界面。

2、创建用于对接的服务账号

上一个步骤中，配置了委托所需要的组。现在来配置一个对接账号。

继续使用刚才的“Users and Computers”界面，找到根域，展开菜单找到Users，用鼠标右键点击Users，弹出菜单里选New，然后选User。如下截图。

输入新用户的login ID为aws。其中，姓名部分可以任意输入，对完成实验无影响。如下截图。

输入新创建的AWS的用户的密码，注意密码需要一定复杂度。这个账户是一个服务账户，是用于Workspaces对接到用户自己的域控制器的，不需要日常修改密码。因此可以选中下方的“User cannot change password”和“Password never expires”。这样密码将永不过期。在生产环境中，这样做可能不符合安全策略，那么意味着需要定期更换这个账号，也需要在AWS的Workspaces控制台上，定期更换连接域的账号。如下截图。

点击Finish创建完成。如下截图。

接下来设置用户所属的组。在Users中，找到刚才创建的Group “Connectors”，鼠标左键双击这个组。如下截图。

在Connectors Properties界面，点击第二个标签页“Members”，点击下方的“Add”添加用户。如下截图。

在打开的添加用户界面，空白处输入“aws”，也就是上一步新建的用户的Login ID。这里不需要输入用户对应的Last Name/First Name，只输入Login ID即可检索到，然后点击OK按钮。如下图。

点击OK后系统会自动识别到刚才加的用户。然后点击OK结束这个窗口。如下截图。

至此添加用户完成。

3、开放安全规则组

现在来到域控制器所在的AWS区域，找到这个EC2实例，确认正在使用的安全组，点击编辑。

在安全规则组保持允许RDP远程登录的基础上，开放如下端口。建议只放行Source是内网地址的流量，不要填写0.0.0.0/0的来源。

TCP/UDP 53：DNS
TCP/UDP 88：Kerberos 身份验证
UDP 123：NTP
TCP 135：RPC
UDP 137-138：Netlogon
TCP 139：Netlogon
TCP/UDP 389：LDAP
TCP/UDP 445：SMB
TCP 1025~65535：RPC用高端端口
RDP 3389
ICMP

本次实验如果使用CloudFormation创建AD环境，则EC2实例已经自动设置好了对应的安全规则组，因此可不需要改动即可继续实验。如下截图。

配置完成点击保存。现在准备工作就绪，我们进入Workspaces的AD对接环节。

4、将Workspaces连接到AD

现在一切准备工作就绪，我们开始启动Workspaces到AD的连接配置工作。

进入宁夏区域的Workspaces服务，找到左侧第一项“Directory”，点击“Set up Directory”。如下截图。

在向导的第一步，选择第二个选项“AD Connector”，即创建AD连接器。点击下一步继续。如下截图。

在向导第二步，选择AD连接器的规模和能力，本实验选择左侧的小型的即可。下方的描述可以任意输入。如下截图。

在向导第三步，选择VPC和子网界面，这时候请选择前文通过CloudFormation为VPC建立的专用VPC。子网下拉框中可以看到这个CloudFormation包含的Public Subnet和Private Subnet，选择名为“Workspaces”的子网是所谓的Private Subnet。如下截图。因为在前文限制了路由和安全规则组，只允许私有子网连接到AD，因此下图中的子网选择必须使用CloudFormation创建的名为Workspaces的子网。如下截图。

选择好VPC和子网后，检查一下设定，然后点击下一步继续。

在向导的第四步，组织名称位置是友好显示名称可以任意输入，第二项Directory DNS name需要输入域的完整名称，本实验前文步骤搭建时候使用的是 mywp01.com 的名字。在Directory NetBIOS name位置是选填。DNS IP填写为域控制器的DNS IP。本例子使用了另外一个AWS另外一个Region的服务模拟了私有数据中心的EC2，所以这里填写为EC2的内网IP地址 172.31.18.186。填写IP请注意，CloudFormation创建的实验环境，网段都是固定的，但是IP是DHCP的，请填写为具体实验时候使用的IP。如果是生产环境配置，与企业现有环境对接，一般域控制器是主辅域控两个DNS，这里可以在第二个DNS框中填写第二个DNS的IP。如下截图。

现在将页面向下滚动，继续填写对接到AD使用的服务账号的用户名和密码。服务账号在前文中命名为aws，隶属于AD上的Connectors组。这里就填写用户名aws和对应的密码。然后点击下一步继续。如下截图。

最后一步是review所有配置，点击“Create Directory”继续。如下截图。

系统会进入创建中。这个步骤需要3到5分钟。在Directory的状态变为绿色后，创建完成。如下截图。

接下来要再进行一次注册操作。选中目录，从Action中选择Register。

在弹出窗口中，选择子网，注意选择workspaces对应的private subnet。选择后点击Register注册。如下截图。

注册完成，注册状态这一栏会变为绿色。如下截图。

至此域的对接完成。

六、创建桌面

1、在AD上创建用户

对接到企业自有的AD后，用户管理的工作是通过AD完成的。主要方式如下：

如果用户是一个不存在的新用户，则首先需要在AD上创建这个用户，然后进入Workspaces，扫描并获取这个新创建的用户，然后为之创建桌面。
如果用户是一个存量的用户，已经在AD上有账号，那么就可以直接在Workspaces界面中，通过对接的目录服务将用户名搜索出来，然后继续为之创建桌面。请注意：AD上的用户并不意味着自动在workspaces上创建桌面。

现在我们来创建一个全新的用户。

首先使用RDP登录到域控制器，进入“Users and Compunters”，展开当前根域“mywp01.com”，用鼠标右键点击Users，然后在弹出菜单中选择New，在选择User。

在新建用户界面，输入User Login name为user01，姓名可以任意输入。后续要对接的主要是用User Login name。如下截图。

在输入密码界面，为此用户设置密码。注意密码需要满足复杂度要求。下方的几个选项框都取消不选中。

在设置用户的最后一步，点击Finish完成。如下截图。

如此，就完成了一个新用户的添加过程。

根据实验需要，可以再添加一个用户，User Login name设置为user01，用户姓名可以叫 Li Si 。这里不再重复描述。

2、使用标准模版开机

现在进入宁夏区域，进入Workspaces服务，点击左侧第二个“Workspaces”，在右侧点击“Launch Workspaces”。如下截图。

在向导第一步中，选择刚才对接好的AD域。

第二步，在“Select Users from Directory：mywp01.com”的输入框中，输入用户名的登录账号 user01 ，然后点击右侧的“Search”按钮。如下截图。

在上一步点击搜索按钮后，可以查询出来登录名为user01的用户，通过Name也可以看到他的名字Zhang San，也是我们在AD域上创建账号对应的用户名。现在选中这个用户，点击“Add Selected”，为其创建Workspaces。如下截图。

上一步操作后，可以看到页面下方的选中清单中出来了此用户。同时，页面也提示，一次可以添加20个用户到清单中，一次开通20个桌面。如下截图。

在向导的第三步，选择要使用的规格和软件包。首先点击下方的语言选项，切换镜像为中文版本。然后点击右上角的CPU按钮，可以按CPU大小排序，这样便于检索。我们选择Standard with Windows 10 and Office 2016的版本开通桌面。注意：包含Office2016的镜像比不含Office的镜像版本更贵一些，因为其包含软件授权。如下截图。

将页面滚动到下方，可以设置桌面的磁盘空间。注意用户磁盘只能设定为10GB/50GB等几个固定档位，不能输入这几个数字之外的非标准值。建议保持不变，点击Next继续。如下截图。

在向导第四步，选择桌面的电源管理方式。AlwaysOn将一直开机，适合包月方式购买Workspaces的场景。AutoStop适合按需使用，可设置最小1小时自动关机。然后将页面向下滚动。如下截图。

在向导第四步下半部分，对这一批次开通的桌面设置标签。这个标签将用于系统上多处的标识，其中的好处之一是可以用于区分账单，例如如下的填写方法，Key填写为BU，Value填写为ABC，标示公司集团ABC；第二行DEPT标示部门，Value填写为Dev。以上的Key和Value都可以任意填写，按照实际公司的命名规则即可。如此，当有几十个上百个桌面后，可以分别生成不同Key标签对应的账单，例如某分公司费用总数，或者某部门费用总数。最后点击Next Step。如下截图。

在向导第五步，回顾刚才的设置，不需要做改动，直接点击Launch Workspaces启动。

创建工作大约需要20分钟。需要较长时间的原因是桌面需要执行Sysprep配置，实施系统盘保护，配置Windows的用户数据漫游，将所有桌面、我的文档、用户自行安装软件都将映射到D盘，并且桌面会自动加入公司域。因此配置时间比普通Windows EC2长。请耐心等待。如下截图。

经过大约20分钟，开通完成。页面上将提示用户下载Workspaces客户端软件的地址，以及用户第一次使用的激活码。如下截图。

现在系统管理员可以将这个登录网址和注册码发给使用Workspaces的最终用户了。

3、登录Workspaces

作为Workspaces的最终用户，收到客户端下载地址后，在浏览器中访问。本文将使用Windows10作为客户端为例。

访问 https://clients.amazonworkspaces.awsapps.cn/ 地址。点击其中的Windows客户端下载。

下载完毕后，双击安装。请注意，Workspaces的AWS海外服务版本和国内服务版本客户端不完全一样，在中国区实验以及提供服务，请使用AWS中国区的下载地址。下载完成后，双击开始安装，如下截图。

点击下一步，在安装类型处，选择为本用户安装或者为本机所有人安装都可以。不影响本电脑上使用。点击Next继续。

安装路径可以使用默认路径，点击下一步继续。

安装完成后，桌面上可以看到Workspaces图标，双击启动。登陆窗口会提示收入注册码。这个时候，请按照上文步骤，开通Workspaces之后提示的验证码，输入到界面中，并点击注册按钮继续。如下截图。

接下来，登陆窗口会显示创建Workspaces设置的组织名称，并且要求输入用户名和密码。这里的用户名就是在Active Directory上创建的user01和user02这样的Login Username。输入匹配的密码后，并选中保持登陆状态后，点击登录按钮。如下截图。

密码正确的话，系统会显示正在启动。第一次登陆到一个全新桌面，需要大量初始化工作，花费的时间较长。创建Workspaces时候，如果选择的是AlwaysOn模式，桌面会一直开机，后续每次登陆都会很快。如果选择的是AutoStop模式，那么一段时间系统不使用会自动关机，再次启动时候会有一个稍长的启动时间。

登陆到桌面成功。为了更好的使用体验，可以在查看菜单下，选择全屏幕。

对这个镜像运行测试，打开浏览器，可以看到能正常访问外部网络。

至此创建桌面完成。

七、管理Workspaces

在启动了属于用自己AD域的第一个桌面之后，还有一些必要的配置工作，例如优化镜像，调整为符合公司工作环境需要的软件。

1、预装软件调整并制作镜像

首先我们在第一个启动的桌面上，完成Windows更新，然后才能推送给用户。如果不更新，将有非常大的安全风险。如果创建桌面后由每个用户自行更新，会消耗大量时间。建议由管理员为本企业统一安装镜像。

在本实验中，我们在桌面上安装Acrobat等软件作为公司标准软件包。然后再发起镜像制作。如下截图。

完成补丁后，需要完全重新启动一次，注意重启需要几分钟时间，重启后请确认下连接正常再开始制作镜像。

进入Workspaces界面，找到刚才进行过补丁升级和软件安装的桌面。选中后点击Actions，点击Create Image。注意，只能对启动状态的桌面制作镜像。如下截图。

在制作镜像的确认界面，需要经过Sysprep等步骤，因此耗时较长，需要点击Next继续。如下截图。

在镜像名称配置界面，输入新创建的Image名称，然后点击Create Image继续。

创建命令已经下发，前文的提示需要需要45分钟左右。现在看这个运行中的桌面转入了暂停状态，镜像制作中进行中，如下截图。

进入左侧菜单的Image目录，可以看到新的镜像正在生成。

等待大约45分钟时间，Image制作完成。现在选中这个完成的Image，选择Create Bundle，创建服务包。

在创建Bundle服务包时候可以重新选择镜像的尺寸，例如只使用浏览器的用户可以运行在1vCPU/2GB或者2vCPU/4GB。运行开发程序的用户可以选择4vCPU以上的幸好。此外，系统盘和数据盘的输入需要注意：

只能输入几个阶梯规格，例如50GB，80GB，100GB等，不支持任意输入；
只能调大不能减小。基于这一版image制作出来的Bundle，只能选择更大的磁盘空间。

因此，如果觉得磁盘空间过大，建议从新创建一个桌面，选择80GB/10GB的最小磁盘尺寸，重新部署软件，然后生成image。这样就获得了系统盘是80GB数量级的小规格Image，再从这个小规格Image生成Bundle即可。

现在继续完成创建Bundle。如下截图。

创建Bundle不需要等待，瞬时课程。因为主要磁盘读写的Image工作已经在上一步完成了。因此从Image到Bundle输入信息即可完成。现在进入Bundle界面，可以从筛选类型中，查看Custom Bundle类型，即可看到定制好的镜像。如下截图。

现在我们为另外一个用户创建一个全新桌面，分配的用户名为user02（与刚才不同），全新建立桌面时候，从Bundle清单中，已经可以看到我们上一步创建的Dev-Type-A这个包，即可正常使用。如下截图。

至此制作镜像和软件包完成。

2、升级镜像

当用户已经运行一段时间后，如果需要批量为用户部署新软件，常用的办法是从AD上下发策略推送，另一种办法是升级用户桌面。

本次实验为了模拟桌面升级，我们将采取如下策略：

在已经上一步已经制作好名为Dev-Type-A的标准镜像（含Acrobat Reader）的基础上，继续安装一些企业要分发的软件（如Draw.io、VScode等）；
并制作新的模版Dev-Type-B；
将已经使用Dev-Type-A模版的用户升级到Dev-Type-A。

首先我们在Dev-Type-A的标准镜像，安装企业管理员希望推送的新的工作软件，我们以下图的Draw.io和VScode为例。

准备完成后，重启user02的桌面，然后重新发起制作image的操作。如下截图。

等待一段时间后，Image完成。

继续为此Image创建Bundle。从Image菜单中，选定新生成好的Image，然后点击Actions，选择Create Bundle。如下截图。

输入名称并选择规格。关于磁盘容量配置的最小限制条件，前文在制作第一版镜像的张杰中已经讲述这里不再重复。如下截图。

创建完成。现在可以从Bundle菜单中同时看见A和B这两个型号了。如下截图。

最后我们执行为user01从Dev-Type-A升级到Dev-Type-B的操作。

从Workspaces清单中，选中user01的桌面，点击Actions，选择Migrate Workspaces。如下截图。

在选择型号界面，从下拉框中选择新制作的 Dev-Type-B，然后点击页面右下角 Migrate Workspaces继续。

执行了迁移之后，可以从Workspacs界面中看到User01的桌面已经是处理中（Pending）的状态。过一会，用户将升级到新版本的桌面。如下截图。

升级完成后，登录到桌面后，可以看到在新版软件包Dev-Type-B中的软件已经可以使用。

制作新版本软件包需要注意的是：

由于Workspaces的系统保护，Windows用户的桌面、我的文档、APPDATA等目录都被漫游映射到D盘，因此当安装软件时候，请务必注意软件安装路径是位于C盘系统盘的。部分安装软件会自己识别漫游，而将自身自动装到D盘。Workspaces不会将位于D盘漫游目录的数据打包到新的镜像中。因此，管理员制作新版镜像时，请务必确认安装路径位于C盘；
制作新版镜像时候，OS级别的一些设置会被替换成Workspaces标准定义，例如桌面墙纸，例如Windows设置是否在桌面显示“我的电脑”等系统图标，这些设置将被复原；
升级现有用户桌面也就意味着更换了全新的系统盘，原先用户自行系统盘上的自行安装的软件将会丢失。因此建议不要过于频繁升级桌面，以免重新初始化环境对用户使用习惯造成影响。

至此桌面的软件包升级过程完成。

3、控制网络访问

Workspaces作为企业用户的入口主要作用就是管控，其中一个方面是网络行为的管控。在前文我们对接了企业内网的AD，对企业内网的访问控制可以分别通过如下手段实现：

将Workspaces放在VPC中的Private Subnet里，Workspaces不暴露在公网，没有Public IP也没有EIP；
在Workspaces所在的Subnet上，设置Network ACL规则，限制去往特定地址段的流量；
在Workspaces所在的Subnet对应的RouteTable路由表上，不填写去往特定网段的路由，以阻止其访问；
在企业AD一侧的环境中，通过Network ACL策略拒绝特定网段访问；
其他网络防火墙手段。

以上这些手段可限制Workspaces对内网的访问防伪。

本实验将限制Workspaces对公网的访问。根据前文的架构图可知，我们为Workspaces设计了一个Private Subnet，这个网段的默认路由指向CloudFormation自动创建的NAT Gateway，且NAT Gateway绑定了EIP作为固定IP出口。AWS的NAT Gateway本身上不能添加策略，无法进一步实现上网行为过滤。为了过滤上网流量，我们可以采用如下方法：

替换NAT Gateway为一个商用防火墙的AMI，可通过Marketplace上查找Cisco、Checkpoint、PaloAlto、F5、Fortinet等厂家的防火墙AMI实现；
替换NAT Gateway为一个EC2 NAT Instance，使用Linux软件包括软路由、代理服务器等技术手段，模拟上网行为管理设备。

本实验为技术展示和讲解性质，因此采用第二种方式来模拟上网行为管理能力。真实的生产环境建议使用第一种方式。

当前NAT Instance已经被CloudFormation自动部署好，我们不需要修改其配置即可使用。现在来到Workspaces所在的宁夏区域，进入VPC界面，找到Workspaces所在的Private Subnet子网，编辑其路由表。如下截图。

编辑路由表时候，把这个红色框里边的默认路由对应的NAT实例的条目删除。如下截图。

重新配置一条默认路由，Target选择Instance。如下截图。

然后从Instance的清单中选择本次实验CloudFormation自动建立的EC2实例，也就是CloudFormation中提供提供了Public IP可登录的Linux EC2实例。

保存后完成路由的切换。现在流量就已经通过EC2实例了。在云桌面内测试访问成功。

通过EC2 NAT Instance实例控制去往互联网流量的方法，是管理EC2 NAT Instance的安全规则组。只有放行了的端口，内网的Workspaces才能对外访问。

以如下截图为例，EC2 NAT Instance的安全规则组只放行了80和443，在这个时候，所有Workspaces除了上网以外的流量，都是无法操作的。如希望从Workspaces登录互联网上别的Windows服务器，那么需要要在NAT Instance实例中的安全规则组中加入允许3389端口，并设置源地址内网的IP地址段即可。如下截图。

对于上网行为的管理，本实验采用Squid作为Web代理服务器来模拟商用防火墙效果。我们现在登录到EC2 NAT Instance上设置规则。

进入Workspaces对应的CloudFormation，从Output里边找到ssh入口。如下截图。

通过这个地址登录到Linux，执行sudo -i成为root权限，并编辑 /etc/squid/blacklist.txt文件。这个文件默认为空，需要填写要屏蔽的网址，屏蔽整个网址则可以填写 .域名的形式。如果多个域名，请填写多行。例如填写如下：

.apache.org

然后执行如下命令，重启squid。

systemctl stop squid
systemctl start squid

再去桌面上访问 www.apache.org ，可以发现访问已经被squid拦截。

请注意在这个实验中，Squid默认只拦截Http协议的访问，不拦截Https请求。如果需要Squid对Https作出响应，需要启用SSL Bump功能。经测试，SSLbump的稳定性不足，对于包含大量第三方域名调用的网站支持不佳，因此不建议在商用环境中使用SSLbump过滤SSL流量。因此，在生产环境上进行上网为行为管理，建议使用Marketplace上的商用防火墙AMI来实现管控。

至此搭建并管理Workspaces的整个实验过程完成。