WSUS20部署.docx
《WSUS20部署.docx》由会员分享，可在线阅读，更多相关《WSUS20部署.docx（30页珍藏版）》请在冰豆网上搜索。
WSUS20部署
WSUS2.0部署
（一）
目前在企业内网中，90%以上的桌面操作系统以及大部分的服务器都使用了微软公司的产品。
微软产品素以界面友好，功能强大而著称，但同时也以补丁泛滥而令管理员头疼。
微软为弥补产品安全，提供了各种各样的ServicePack，Hotfix…..这些补丁解决的问题五花八门，种类繁多，管理员都有应接不暇的感觉，更别提普通用户了。
但补丁又确实很重要，补丁对应着严重的安全隐患和性能缺陷，我们决不能掩耳盗铃，置之不理。
那该怎么处理这个问题呢？
其实微软从Win98之后就在操作系统中内置了WindowsUpdate组件，这个组件可以使用Http或Https自动连接到微软的更新网站去下载所需要的补丁并自动安装。
哦，那如此说来，补丁管理问题已经解决，只要大家打开系统中的WindowsUpdate岂不就OK了？
好，本次课程到此结束！
回家洗洗睡了。
且慢，且慢，且听我细细道来，那WindowsUpdate对家庭用户来说甚好，没啥问题，但对企业用户来说就未必合适了。
其一，带宽问题。
假设某企业500名用户，每人需下载20M补丁，全公司可就至少需要10G的带宽！
这可不是个小数目。
想像一下公司员工都去微软下载WindowsXPSP3（349M）所引发的网络大塞车的壮观场景吧！
其二，安全问题。
并非所有的补丁都适合在当前环境使用。
就以当年的WindowsXPServicePack2为例，此补丁打上之后，与当时的很多应用程序都会产生冲突，解决办法是只能换用新版本的应用程序。
如果管理员综合权衡安全和灵活因素，就未必会在生产环境第一时间部署这个补丁。
而用户就不管那么多了，跟着感觉走，直接装上再说！
后果可就想而知了，很有可能会因为这个补丁的安装影响工作效率。
因此，综合来看，用WindowsUpdate组件连接到微软的更新网站更适合家庭用户或小型公司，对中大型企业来看并不适合。
基于上述原因，微软为企业用户提供了WSUS（WindowsServerUpdateServices）作为解决方案。
WSUS解决问题的思路很简单，管理员利用WSUS服务器从微软的更新网站下载补丁，然后再发布给内网用户。
这样既能降低网络带宽流量，将补丁下载的数据量降为最低；又能让补丁置于管理员的控制之下，管理员经过审核后，同意发放补丁，用户才可以安装补丁。
那有人要问了，万一用户使用原先操作系统中自带的WindowsUpdate组件直接连到微软去更新是不是就可以绕过管理员的审核了呢？
答案是否定的，因为一旦WSUS服务器启动了，系统中自带的WindwosUpdate就被禁用了！
哇，好厉害的釜底抽薪哦！
还有一个好消息，WSUS不但有这些优点，还是一个完全免费的产品！
听到这里，你是不是已经有些按捺不住内心的冲动，准备好好地体验一把了。
Comeon，Followme！
让我们一起体验一下WSUS管理补丁的独特魅力。
WSUS常用的部署拓扑有以下三种，现简介如下：
A 单服务器拓扑。
如下图所示，单服务器拓扑是使用最广泛的WSUS拓扑。
单服务器拓扑利用一个WSUS服务器从微软的更新网站下载补丁，然后负责将补丁发给内网用户。
单服务器拓扑是大多数中小公司的最佳选择。
（图1）
B链式拓扑。
如下图所示，链式拓扑定义了上游服务器和下游服务器，上游服务器可以直接连接到微软的更新网站，下游服务器则只能从上游服务器下载更新。
这种拓扑在总公司/分公司的管理模型中比较常见。
考虑到性能因素，链式拓扑很少超过三层。
（图2）
C分离式拓扑。
如下图所示，分离式拓扑指的是在一个与互联网隔离的网络内，WSUS服务器无法从微软网站进行补丁更新，因此只能先用一个能连接互联网的WSUS服务器下载所需要的补丁，然后将下载的补丁导出成数据。
隔离网络内的WSUS服务器通过导入数据来间接完成补丁的下载。
这种拓扑常用于部队，公安等专用网络。
（图3）
WSUS目前常用的是WSUS2.0和WSUS3.0这两个版本。
这两个版本的前身SUS1.0由于只能支持有限的操作系统补丁管理，已经基本被淘汰了。
WSUS2.0和3.0都可以支持微软的全系列产品，我们在后续文章中将陆续介绍WSUS2.0和3.0的部署，管理以及排错技巧。
今天我们从WSUS2.0＋SP1开始介绍。
介绍一下今天的实验拓扑，如下图所示，Florence是域的域控制器，Berlin是wsus服务器，perth是测试用的工作站。
三台计算机都安装了Win2003中文企业版。
（图4）
一安装前的准备工作
要在Berlin上安装WSUS2.0SP1，需满足下列条件。
1）IIS6.0
由于WSUS客户机和服务器之间通过Http或Https传递数据，因此WSUS服务器必然需要IIS的支持。
我们在Berlin上依次点击控制面板－添加或删除程序－添加/删除Windows组件－应用程序服务器，在应用程序服务器中选择安装Internet信息服务（IIS），如下图所示.（图5）
2）BITS20
BITS可以支持后台传输，数据压缩，断点续传等高级功能。
WSUS2.0SP1需要BITS2.0的支持，从
注：
Win2003SP1不需要安装此补丁。
（图6）
3）.NetFramework1.1SP1
WSUS2.0SP1还需要.NetFramework1.1SP1的支持。
从Framework1.1SP1forWin2003，启动安装程序，安装过程非常简单，如下图所示，在此不再赘述。
注：
Win2003SP1不需要安装此补丁。
（图7）
4）磁盘空间
WSUS2.0SP1要求系统分区至少应有1G的剩余空间，WSUS的更新文件需要至少6G空间，WSUS的元文件至少需要2G空间。
解释一下，更新文件是我们安装补丁时所需要的二进制文件，元文件则负责提供更新文件的信息，例如这个补丁修补了哪些漏洞，适用于哪些版本，需要哪些安装条件等等。
更新文件存储在目录中，元文件存储在数据库中。
建议将WSUS数据安装在非系统分区，并且至少准备8G剩余空间，用虚拟机作实验的朋友尤其作注意这点！
5）数据库
WSUS的后台数据库可以是SQL2000，MSDE或WMSDE。
WSUS安装时自带了WMSDE，MSDE是大家很熟悉的数据库桌面引擎，MSDE和WMSDE的区别在于MSDE有最大不能超过2G的限制，而WMSDE没有。
MSDE和WMSDE都没有提供管理工具，如果你需要管理工具，可以考虑安装SQL2000+SP3作为WSUS的后台数据库，也可以在WMSDE或MSDE的基础上加装一个SQL2000管理工具。
建议如无特殊需求，使用WSUS自带的WMSDE数据库即可。
二安装WSUS2.0+SP1
作好安装前的准备工作后，我们就可以进行WSUS2.0的安装了。
如下图所示，启动WSUS2.0SP1的安装程序后出现了安装向导。
（图8）
接受软件许可协议，下一步。
（图9）
设置存储WSUS更新文件的目录为E:
\WSUS，更新文件至少需要6G磁盘空间。
（图10）
WSUS后台数据库选用自带的WMSDE，设置数据库的存储目录为E:
\WSUS。
（图11）
选择WSUS是利用IIS的默认网站发布补丁还是新建一个网站进行补丁发放。
建议如果有可能，尽量选择80端口的默认网站。
因为考虑到以后的应用，默认网站兼容性还是要好一些。
（图12）
安装向导询问WSUS是否从镜像服务器继承设置，我们准备把Berlin作为一个独立的WSUS服务器进行管理，不从任何WSUS服务器继承设置。
（图13）
安装向导收集数据完毕，点击"下一步"开始安装.（图14）
经过一段时间的等待，安装终于完成。
（图15）
三配置WSUS2.0
WSUS2.0安装完成后，我们需要先对WSUS进行一些基本的设置，例如WSUS可以下载哪些微软产品的补丁？
哪种语言的补丁等等。
我们在浏览器中输入Http:
//berlin/wsusadmin启动WSUS的管理界面，如下图所示，我们点击右上角的"选项"（图16）
如下图所示，选择"同步选项"（图17）
如下图所示，我们可以设置补丁所涉及的微软产品以及补丁分类。
在产品和分类中，点击红圈处的"更改"，准备对补丁所涉及的微软产品进行设置。
（图18）
如下图所示，由于我们实验环境中所有的操作系统都是Win2003，因此我们只选择了"Windowsserver2003，DatacenterEdition"，这样WSUS就只会下载Win2003操作系统的相关补丁。
值得注意的是，现在WSUS20.只能支持操作系统相关补丁，但WSUS2.0开始工作后，就会连接到微软更新网站对自身组件进行更新，更新完毕后WSUS就可以支持微软的全系列产品了。
（图19）
接下来设置WSUS的补丁分类，如下图所示，WSUS默认只下载"安全更新"和"关键更新程序"类的补丁，这两类补丁这是在工作中使用最多的。
（图20）
设置完补丁的产品和分类后，我们来设置一下更新文件存储的位置以及更新的语言版本，如下图所示，点击红圈处的"高级"进行设置。
（图21）
如下图所示，我们选择将更新文件存储到WSUS服务器。
如果企业访问互联网的带宽很充足，也可以选择不在本地存储更新，只在WSUS保留元文件，用户需要更新文件时仍然去微软网站下载。
我们在语言设置中选择仅下载简体中文版本的补丁。
（图22）
四同步WSUS2.0
对WSUS进行简单的设置后，我们就可以让WSUS服务器去微软网站同步了，同步可以让WSUS服务器获知到底有多少补丁可以下载。
WSUS默认设置是手工同步的方式，如下图所示，点击"立即同步"，WSUS服务器就开始工作了。
第一次同步微软更新网站的时间比较长，从几十分钟到几个小时不等，之后的同步采用增量方式，所需要的时间就会少很多。
（图23）
如下图所示，WSUS正在同步中（图24）
同步完成，点击WSUS管理页面中的更新。
如下图所示，我们可以看到WSUS已经统计出了补丁的数量以及每个补丁的详细信息。
（图25）
WSUS同步成功后，如何将补丁分发给内网的客户机？
如何对补丁进行审核管理？
如何对客户机进行分组管理？
这些问题我们都将在后续文章中一一介绍。
WSUS2.0部署
（二）
在上一篇文章中（WSUS2.0＋SP1部署实战（图）），我们完成了WSUS2.0SP1的部署，本文我们就来介绍如何利用WSUS进行补丁分发。
WSUS的实验拓扑如下图所示，Florence是域控制器，Berlin是WSUS服务器，Perth是工作站。
WSUS服务器]已经在同步选项中对产品及类别进行了设置，也已完成了同步。
我们接下来就要利用这个环境进行补丁分发。
（图1）
完成补丁分发，需要注意以下三点：
一WSUS分组管理
二组策略或注册表设置
三WSUS更新批准
下面分别介绍具体内容
一WSUS分组管理
分组管理可以把WSUS客户机放入不同的组中进行管理，每个组可以有不同的补丁管理策略，这些对于管理工作的细化很有好处。
举个简单的例子，微软已经发布了WindowxXPSP3，但这个补丁安装后的效果如何管理员却没有把握。
这时管理员可以创建一个测试组，仅允许测试组的计算机安装WindowsXPSP3，如果效果不错就向全体用户推广，如果效果不佳就停止部署。
因此我们有必要先进行计算机组的设置。
在浏览器中输入http:
//berlin/wsusadmin，打开WSUS服务器的管理页面，在管理页面中点击"计算机"，如下图所示，WSUS安装时默认创建了两个组，一个是"所有计算机"组，一个是"未指定的计算机"组。
默认情况下每个WSUS的客户机都会属于这两个组。
（图2）
我们准备创建两个组，一个名为ITET，一个名为TEST。
ITET组用于普通的客户机，TEST组用于测试补丁的客户机。
点击上图中的"创建计算机组"，弹出对话框要求我们输入组名，如下图所示，我们为计算机组命名为ITET。
这样我们就创建出了一个计算机组，然后用同样的方法再创建一个名为"TEST"的计算机组。
（图3）
计算机组创建完成后，如何将客户机加入到指定的组中？
WSUS提供了两种方法供管理员选择，我们可以在WSUS的管理页面中点击"选项"，如下图所示，点击"计算机选项"（图4）
在计算机选项中我们看到有两种选择，一种是用组策略或注册表决定客户机加入哪个计算机组，一种是在WSUS服务器的管理页面中用移动计算机的方法将客户机加入计算机组。
如果客户机数量较少，移动计算机的操作是比较简单的；但如果客户机数量较多，显然还是组策略更有效率。
在此我们选择利用组策略或注册表进行设置，点击"保存设置"让更改生效。
（图5）
二组策略或注册表设置
到目前为止，我们部署了WSUS服务器，创建了计算机组。
但客户机如何知道哪台计算机是自己需要的WSUS服务器，客户机应该加入哪个计算机组呢？
这些设置可以通过组策略或注册表来完成（其实两者是一样的，组策略不过是提供了一个友好的修改注册表的界面）。
1）用组策略设置
如果在域环境下，用组策略是效率最高的方法。
我们只要部署一个域级别的组策略，就可以轻松完成WSUS设置。
在域控制器Florence上依次点击开始－程序－管理工具－ActiveDirectory用户和计算机，右键点击域，选择属性。
在属性中切换到组策略标签，如下图所示，选择默认组策略"DefaultDomainPolicy"，点击编辑按钮。
（图6）
在组策略编辑器中展开计算机配置－管理模板－Windows组件－WindowsUpdate，如下图所示，在此我们可以进行WSUS相关策略的设置（图7）
编辑"配置自动更新"策略，如下图所示，在此策略中我们选择启用自动更新，并且将自动更新模式配置为自动下载并通知安装，在此模式下客户机会自动下载补丁但在安装补丁前会通知用户。
（图8）
编辑"指定IntranetMicrosoft更新服务位置"策略，如下图所示，在此策略中可以设定WSUS更新服务器和统计服务器。
Intranet更新服务器提供补丁下载，Intranet统计服务器提供报表统计，在此例中我们用一台服务器同时提供这两种服务。
我们描述服务器可以使用Netbios名称，完全合格域名或IP。
（图9）
编辑"允许客户端目标设置"策略，如下图所示，在此策略中我们可以设置客户机加入的WSUS计算机组，我们将计算机的目标组设置为刚创建的"ITET"（图10）
完成上述设置后，基本已经可以满足WSUS实验需求，其他策略我们就不一一列举了。
2）用注册表设置
如果部署环境是在工作组中，那么就没有域环境这么方便了。
虽然我们可以编辑每台计算机的本地安全策略，但这么做对一名管理员的耐心是一个极大的考验。
在这种情况下，管理员一般会采用导入/导入注册表的方法来进行设置。
具体是这样的，先在一台模板计算机上编辑好本机的组策略，设置方法如前文介绍。
然后用regedit打开模板计算机的注册表，定位到HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate，如下图所示，我们看到注册表中已经设好了WSUS服务器的名称，计算机加入的目标组等参数。
我们现在要做的就是把这些注册表设置导出成文件，然后在其他的计算机上进行导入操作。
我们在WindowsUpdate上点击右键，选择"导出"（图11）
如下图所示，我们选择将Windowsupdate分支导出成文件，文件名为C:
\WSUS.REG。
（图12）
然后我们只需将WSUS.REG文件利用电子邮件或文件服务器分发给其他用户，每个用户双击此注册表文件进行导入操作即可。
三WSUS更新审批
完成了前面的设置，接下来就该进行实质性的操作，我们要在WSUS服务器上分发补丁了！
上篇博文中我们对WSUS服务器进行的同步设置中规定了WSUS只能涉足Win2003平台下的安全更新和关键更新，这些更新必须经过WSUS服务器批准安装才能分发到客户机上。
下面我们来看看到目前为止哪些更新被批准安装了，打开WSUS服务器的管理页面，点击页面上方的"更新"，如下图所示，在左侧视图中对"产品和分类"选择"关键和安全更新"，对"批准"选择"安装"，在"已同步"处选择"任何时间"，这时右侧面板中显示被批准安装的更新只有两个。
一个是Windowsinstall3.1，一个是Bits2.0和Http5.1，这两个更新是WSUS客户端所必须的，肯定会被批准安装。
问题是那其他的更新为什么没被批准呢？
原来WSUS服务器对安全更新和关键更新默认只批准检测，不批准安装。
现在我们来批准安装一些更新。
（图13）
1）手工批准更新
在WSUS服务器的管理页面中选择更新中，在左侧视图中对"批准"选择"仅检测"，如下图所示，这时右侧面板中显示共有301个更新，每个更新前的图标是灰色的，代表此更新没有被批准安装。
我们选择所有更新，点击左上角的"更改批准"（图14）
如下图所示，我们对所有更新都批准安装。
其实有些补丁并不适合当前环境，例如有一些64位的补丁，但实验环境下我们就不仔细筛选了。
从下图中还可以看到，对每个组可以采取不同的管理策略，例如有的组批准安装，有的组只批准检测，管理起来非常灵活。
这也是我们设置计算机组的意义所在。
（图15）
将更新的状态从批准检测更改为批准安装后，WSUS开始对补丁状态进行更改，如下图所示。
（图16）
如下图所示，状态更改完成，每个更新前的图标变成了绿色箭头，这代表此更新被批准安装，现正在下载中，但还没有下载完毕。
如果下载完成，图标会变为蓝色桶状。
（图17）
2）自动批准安装
如果觉得手工批准安装太麻烦，我们可以让WSUS自动批准。
打开WSUS的管理页面，在选项中点击"自动批准选项"，如下图所示（图18）
如下图所示，我们选择对安全更新程序和关键更新程序批准安装，这样以后只要WSUS服务器发现微软的更新网站有了新的安全更新或关键更新，WSUS就会自动批准进行检测，进行安装！
（图19）
好了，WSUS服务器端的设置已经基本完成，让我们去客户机上看一下吧。
首先在客户机上可以运行gpupdate/force来加速组策略的生效，否则域成员服务器或工作站等候组策略生效可能最多需要90分钟。
然后可以运行wuauclt/detectnow，这样客户机可以立即连接到WSUS服务器而不需要等待20分钟的延时，过程如下图所示。
（图20）
等待一段时间后，客户机的右下角出现提示，告诉我们有一些更新需要安装，如下图所示，哈哈，WSUS开始工作了。
（图21）
如下图所示，客户机从WSUS服务器上下载了四个更新，我们点击安装（图22）
安装过程如下图所示（图23）
客户机如果想知道到底安装了哪些更新，可以输入命令systeminfo，如下图所示，客户机安装补丁的数量和名称都已经列出来了。
（图24）
管理员如果想了解补丁的部署情况，就可以使用WSUS强大的报表功能。
管理员可以打开WSUS的管理页面，选择报告，如下图所示，点击"计算机的状态"（图25）
如下图所示，在左侧的视图中我们选择查看ITET计算机组已安装补丁的报表，点击应用。
（图26）
如下图所示，WSUS显示了ITET组内每台计算机所安装补丁的统计信息。
（图27）
如果想查看详情，可以点击计算机名左侧的＋号，如下图所示，WSUS显示了perth所安装的6个更新的详细信息。
WSUS的报告功能还有很多用法，在此我们就不一一列举了。
（图28）
有一点大家要注意，在上一篇博文中我们看到WSUS2.0刚安装完时只能支持操作系统的更新，功能是比较简陋的。
好在WSUS服务器工作后，首先对自身组件进行更新，现在它已经可以支持微软的全系列产品了，我们再次查看同步选项中的更新产品，如下图所示，是不是吓了你一大跳？
这变化也太大了吧。
如果你有一些微软的其他产品也需要更新，不要犹豫，赶紧去更改WSUS的同步选项吧！
（图29）
至此，我们完成了WSUS服务器的补丁分发，在下一篇文章中，我们会介绍如何部署WSUS的下游服务器。
升级会员 