使用脚本程序管理Windows网络(9)

使用脚本程序管理Windows网络(9)
2010年11月19日
　　使用脚本程序管理Windows网络 第九部分：理解远程脚本
　　在这一系列中将学习如何使用远程脚本来管理Windows网络的脚本编写基本知识，原文发表于WindowsNetworking.com。
　　让我们回顾一下目前我们所了解到的关于使用WMI的远程脚本：
　　在这个系列文章的第六部分“远程脚本初探”一文中，我们尝试修改我们的ChangeIPAddress.vbs脚本，以便我们可以通过它来远程修改计算机的IP地址。通过这个方法我们了解到，我们需要使用“分组策略（Group Policy）”来激活目标计算机上的Windows防火墙的“远程管理例外”，否则脚本将无法工作。虽然最终我们让脚本工作了，但它超时了并且还返回了一个错误。
　　然后，在第七部分“修复神秘的错误”，我们发现可以在脚本中添加“On Error Resume Next”语句来绕过错误。但是，脚本仍然超时或者是用了很长的时间来完成运行。我向某个脚本高手请教了这个问题，我们对这个错误得到一个初步的解释，但是为了看看问题是否是普遍性的，我们创建了一个新的脚本ChangeGateway.vbs ，并且当我们远程运行此脚本时，它正常工作了。
　　最后，在第八部分“使用Network Monitor 3.0脚本修复远程脚本故障”，我们的一个读者提出一个简单的可能导致错误的原因：更改远程计算机的IP地址中断了计算机连接，从而导致脚本运行出错并最终超时退出。这听起来很合理，所以，当我们运行脚本时，我们尝试使用Network Monitor 3.0来监测当我们运行脚本会发生什么情况，同时我们确信我们的网络跟踪分析证实这位读者的观点是正确的。
　　然而，是时候是该回顾一下了。在我们继续更深入地之前，我们应该先学习的一些远程脚本的技术细节。不断地尝试是一件很好的事，但是有时候缺乏足够的知识积累我们就会很容易碰壁了。而学习这些基本知识往往可以帮助我们避免（或绕过去或者跳过去）碰壁。现在就让我们开始吧。
　　两种类型的远程脚本
　　确实有两种远程脚本。第一种是当我们在计算机A运行脚本时，脚本以计算机B为目标并在B上执行一些操作。之前我们使用了脚本ChangeIPAddress.vbs来尝试远程脚本，我们是将脚本中的这一行：
　　strComputer = "."
　　修改成：
　　strComputer = "xp2"
　　如果我们使用上面的第一行，并在计算机A上运行脚本 ，脚本以计算机A为目标（本地计算机或“.”）并修改了计算机A的IP地址。然而，如果我们使用上面的第二行，并在计算机A上运行脚本，脚本将以计算机B为目标（NetBIOS名为“xp2”的计算机）并修改了计算机B的IP地址。
　　但是，这里还有第二种远程脚本，它是这样运行的：我是登录到计算机A上的管理员，同时，我想使用一个脚本对计算机B上进行一些操作。但是，我想直接在计算机B上运行脚本，而不是在计算机A上运行脚本并计算机B作为脚本的操作目标。因此，我必须将我计算机A上的脚本转移到计算机B上并且在计算机B上运行脚本。如何才能做到这一点？如果我有一个Active Directory环境，那么我可以在远程计算机上尝试将脚本作为一个登录脚本运行。在接下来的文章中我们会研究如何做到这一点，但现在我们只要知道有这两种类型的远程脚本：
　　●在本地计算机上运行脚本，目标指向另一台远程计算机
　　●直接在远程计算机上运行脚本
　　让我们总结一下这2种远程脚本方法之间的区别：
　　●第一种远程脚本需要连接到远程计算机，然后运行脚本。
　　●第二类远程脚本需要部署脚本到远程计算机，然后运行脚本。
　　知道它们的区别了吗？
　　理解远程脚本连接
　　现在我们把重点放在第一类型的远程脚本（这在前面的几章中我们所尝试的做法）。一个脚本在本地计算机上运行的然后连接到远程计算机并对它运行操作，这意味着什么呢？这意味着三件事：
　　●网络连接
　　●用户身份
　　●适当的权限
　　网络连接
　　对于要在远程计算机上进行了一些操作的脚本，首先脚本需要与远程计算机建立网络连接。有哪些问题可能会阻止网络连接呢？
　　首先，可能会有一个域名解析问题。如果我们的脚本不能将远程计算机的主机名或FQDN（Fully-Qualified Domain Name，完整域名）解析为有效的IP地址，那么远程脚本将会运行失败。
　　第二，可能会有一个防火墙问题。我们在前一篇文章中看到，为了让我们的WMI脚本在远程计算机运行，我们必须打开远程计算机上的Windows防火墙的远程管理例外。如果你现在打开控制面板上的Windows防火墙，并选择“例外”选项卡，你将无法找到一个用来打开防火墙例外的“远程管理”的复选框。这其中的原因当然是，“控制面板”主要是提供给家庭用户来配置防火墙的。在一个Active Directory启用的业务环境下，首选的管理Windows防火墙的方式是使用“分组策略（Group Policy）”。我们在较早前的文章已经提到，我们需要配置的分组策略设置是这样的：
　　Computer Configuration\Administrative 
　　Templates\Network\NetworkConnections\Windows Firewall\Domain 
　　Profile\Windows Firewall: Allow inbound remote administration exception
　　●当你将这个策略指向一台远程计算机时，它会打开计算机上的两个TCP端口： 445和135 ：
　　TCP端口445是Server Message Block (SMB)流量进入的端口，如果远程计算机上的防火墙关闭了这个端口，那么不仅你无法使用WMI连接它，而且你也无法使用标准的MMC控制台工具来连接它，如Computer Management。所以当端口关闭时，如果你尝试运行脚本操作远程的计算机，你可能会收到隐藏的错误，如“System error 53 has occurred. The network path was not found.”等等。
　　●TCP端口135是Distributed COM (DCOM)流量进入的端口。更具体地说，端口135是DCOM Service Control Manager (SCM )的一个监听端口，它提供了基于RPC的服务用于初始化COM对象等。
　　概括而言，如果想要从本地计算机运行WMI查询可以成功地使用RCP封装连接到在远程计算机上的WMI服务，并且可以在远程计算机上成功实例化DCOM对象，TCP端口135和445都必须在远程计算机上的防火墙上打开。
　　用户身份
　　当你运行一个脚本操作远程计算机时，同时该脚本能够与远程计算机建立网络连接，那么该脚本就能够在远程计算机上执行相应的操作。但是，所执行的操作成功与否取决于在远程计算机上运行该脚本的用户身份。所以举例说，如果我使用普通域用户帐户登录到计算机A上。然后，我运行脚本ChangeIPAddress.vbs操作远程计算机B。脚本使用RPC连接到计算机B的WMI服务上 ，然后它尝试修改计算机B的IP地址。但是结果脚本失败了。这是为什么？那么，到底是谁在远程计算机上尝试执行这个行动呢？是你――而你是一个本地计算机的域用户，当你在默认情况下运行该脚本时，它借用了你的身份，即脚本试图使用你的身份（你的域用户帐户）来执行操作。所以，当脚本试图改变远程计算机的IP地址时，实际上是你，一个域用户，在试图这样执行这个操作。这样做当然会失败，因为修改一个IP地址要求有本地管理员权限。
　　所以，如果你在计算机A上，以一个域用户登录，同时你还想要用你的脚本来改变计算机B的IP地址。你应该怎么做呢？
　　其实，你可以硬编码地将远程计算机的本地管理员帐户的密码直接写到我们的脚本中去。换言之，在我们的ChangeIPAddress.vbs脚本上，我们可以这样将：
　　Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
　　替换成：
　　strUser = "Administrator" strPassword = "Pa$$w0rd" Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2"， strUser， strPassword)
　　问题是，这是不安全的――在你的脚本上，所有的人都可以从脚本中看到以文本方式记录的远程计算机的本地管理员帐户的密码！
　　如何删掉上面两行代码，然后在脚本运行时，以命令参数传递的形式给变量strUser和strPassword赋值，是否可行呢？显然这是优于硬编码这些值到脚本上的方法，但是如果有任何人运行网络监测器（如Network Monitor 3.0 ），那么他们可以发现这些本应保密的认证信息，于是你可能又危害了你的远程计算机。
　　那么如果我们使用runas /user:Administrator cmd.exe运行命令提示符，然后在没有指定其他任何验证的情况下，在命令提示符上运行该脚本，又是否可行呢？这可能是你在需要确保脚本有适当的运行身份（通常是本地管理员的目标计算机）时的远程脚本运行的最好解决方案，尽管这个是有一点麻烦的。当然，你也可以简单地作为一个域管理员帐户登录到工作站，并只需打开一个命令提示符运行该脚本。
　　适当的权限
　　现在情况是这样，你正在计算机A上运行你的脚本，而该脚本准备在远程计算机B上执行一些操作。脚本已经和计算机B上的WMI服务建立了网络连接，并且该脚本正以其适当的身份（通常是本地管理员）在计算机B上尝试执行它的操作。那么在这个时候，到底还有什么可能会导致脚本运行失败呢？权限不够！如果脚本正在执行一些由ACL（比如修改文件系统对象或者在Active Directory创建一个对象或者激活DCOM对象）控制的操作，而如果你（脚本所使用的你的身份）没有合适的权限来执行这一行动，该脚本将失败。不幸的是，对于远程脚本来说，这往往是最难的一部分，因为在Windows平台上有NTFS权限、DCOM权限，以及大量的其他类型的权限。另外，你可能有正确的权限组，但是没有特定的权限，如执行一些操作的权限。例如，假设你要使用脚本来清除远程计算机上事件日志，但你的身份缺乏关于该远程计算机的SeSecurityPrivilege。结果会怎么样？你的脚本将失败。
　　对于远程脚本，还有很多需要学习的，不是吗？在我们的下一篇文章中，我们将继续对这个问题进行阐述。