标签: deployment

通过自动安装与驱动器映像进行部署的优缺点是什么？对于 Windows，我知道在克隆驱动器时 SID 生成存在问题。通过映像部署 Linux 是否存在类似问题？

通过 Active Directory / GPO 部署软件包需要哪些步骤？

我管理着一个拥有大约 150 台机器的小型学校网络。我正在寻找一种简单的方法来将软件部署到所有机器上，而无需访问每一台机器。

我已经使用赛门铁克 Ghost 将所有机器都设置为相同，但对于一个应用程序，重新安装整个网络似乎太过分了。

过去，我使用过 Novell 的 ZenWorks，它通过 MSI 安装程序或在安装前后拍摄机器的快照，然后将更改推送到网络上的指定机器。

然而，这一次，我使用的是 Windows 2003 并且预算有限（即没有）。我一直无法了解组策略安装程序，所以也许如果有人能指点我一个好的操作方法，那也将不胜感激。

感谢您的帮助！

如果您同时尝试通过网络安装来安装 500 Linux 系统，那么瓶颈将是 NFS/HTTP/FTP 或任何服务器保存您安装所需的文件。

IMO，这只能通过添加更多安装服务器然后循环它们来解决。

这个问题有没有更好的解决方案？像“P2P Linux安装”之类的东西？

更新：我需要更具体地描述我的情况。目前我正在使用 kickstart+NFS 部署 RHEL。当我尝试同时部署 500 个 RHEL 时，NFS 服务器将有巨大的流量，并且使每个安装过程都变慢。设置更多 NFS 服务器是一种解决方案，但我认为这不是一个好的解决方案。

我们在 IIS 7.5 上遇到了一个问题，我们有一个简单的部署系统，它包含以下内容：

创建一个新的 webroot 的 zip 文件，包含三个文件夹：

Api
Site
Manager

它被解压到一个新文件夹中（假设我们称之为“SITE_REV1”），并包含一个调用以下内容的脚本（每个 webroot 一个）：

C:\Windows\system32\inetsrv\appcmd set vdir "www.site.com/" -physicalPath:"SITE_REV1\Site"

这通常工作，在 9/10 倍。在某些情况下，webroot 似乎已正确更新（如果我检查 IIS 管理器中的基本设置，路径看起来是正确的），但有问题的运行站点实际上指向旧位置。我们设法“修复它”的唯一方法是运行 IIS 重置。仅回收有问题的应用程序池是不够的。

有时似乎甚至有必要重新启动，但我不能 100% 确定这是准确的（并非总是我自己在解决问题）。

我使用 Powershell 和 Web-Administration 模块重写了脚本，希望 appcmd 中存在故障，但发生了同样的问题。

Set-ItemProperty "IIS:\Sites\www.site.com" -Name physicalPath -Value "SITE_REV1\Site"

有没有人经历过这样的事情？有没有人知道发生了什么，我可以尝试做些什么来防止这个问题？执行 IIS 重置对我们来说并不是一个好的选择，因为每次我们尝试在单个站点上部署更改时，这都会影响服务器上的所有站点。

编辑：我们已经确定在 IIS 管理器中启动/停止站点（而不是应用程序池）可以解决错误的物理路径，但是如果我使用 appcmd 停止站点，更改物理路径，然后启动它，我仍然遭受同样的问题。我在一片空白...

在 Windows 2012 服务器上使用 Web 部署，如果部署有一个充满用户生成内容的文件夹，我将其排除在.pubxml文件中发布：

<ExcludeFoldersFromDeployment>somefoldername</ExcludeFoldersFromDeployment>

如果您使用在目标位置删除其他文件选项进行部署，此文件夹中的文件仍会从实时服务器中删除。

<SkipExtraFilesOnServer>False</SkipExtraFilesOnServer>

有什么办法可以让部署过程，包括清理live server的时候，忽略指定的文件夹？我喜欢知道发布过程也会从服务器中删除已删除或修改的文件，但清除用户生成数据的整个文件夹显然是一个问题！

我使用的是 Windows Server 2012 和 Web Deploy 3.5。当我尝试从 Visual Studio 发布时，我得到 404 并建议遵循以下链接

http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE

wmsrv 和远程代理都在运行并正确配置。检查 wmsrv 日志后，一遍又一遍地看到相同的错误：

2013-11-27 18:11:41 10.7.140.235 HEAD /msdeploy.axd site=DevStatsDashboard 8172 - 10.7.141.48 - - 404 7 0 1388

从支持站点http://support.microsoft.com/kb/943891这意味着 HTTP 错误 404.7 – FILE_EXTENSION_DENIED

但是我使用的是 IIS8 并且我允许 .axd 文件

有没有人有什么建议？

我有一台 Windows Server 2008 机器作为我的 DC。今年早些时候，我创建了一个软件安装 GPO 来部署 Adob​​e Flash Player 插件 MSI。我将策略分配给计算机，大约一半运行 Windows XP x86，另一半运行 Windows 7 x64。这一切都像发条一样。

在创建软件安装策略时，我通过在 Orca 中编辑 MSI 禁用了 Flash Player 插件的自动更新功能。我这样做是因为我希望我的所有机器都运行完全相同版本的插件。

现在，一段时间过去了，较新版本的 Flash Player 插件已经发布。是时候推出插件的更新版本了。我已经有了新的 MSI，但我不知道下一步该做什么。

• 我在软件安装 GPO 中看到了升级选项卡，但那里读取的所有内容都将用于更大主程序的附加组件，而不是随时间发布的更新。
• 我读过最好使用新的 MSI 创建新的软件安装策略，撤销旧的 GPO，并分配新的 GPO。我觉得，随着时间的推移，我最终会收到比有效政策更多的撤销政策。
• 我还读到，有些人通过用新的 MSI 替换旧的 MSI 并简单地告诉 GPO 重新部署而取得了成功。这似乎是一种后门方法，只会让我陷入困境。

简而言之，通过组策略推出新版本的正确、最佳实践或首选方式是什么？

我正在寻找一种解决方案来自动化我们应用程序的部署过程之一。在部署开始时，我想以编程方式将指定的服务器设置为维护模式，最后在部署完成后，从 nginx 服务器中删除维护模式标志。

通过维护模式，我的意思是 nginx 应该以 HTTP 响应代码 503 响应所有请求（可能带有自定义页面）。

我知道如何设置服务器块以响应 503 代码（请参阅http://www.cyberciti.biz/faq/custom-nginx-maintenance-page-with-http503/）但问题是如何以编程方式执行此操作并且最有效。

我想到了两个选择：

选项1：在部署过程开始时，将维护文件写入文档根目录，并有条件地检查nginx服务器配置中是否存在维护文件：

server {
    if (-f $document_root/in_maintenance_mode) {
        return 503;
    }
}

此方法包含一定的开销，因为每个请求都会检查文件是否存在。是否可以仅在加载 nginx 配置时检查文件是否存在？

选项 2：部署脚本用维护版本替换整个 nginx 服务器配置文件，并在部署结束时将其换回。如果使用此方法，我担心可能会覆盖维护配置文件的其他自动化进程，例如 puppet。

在 Server 2012 上部署 RDS 时，有两种选择：使用“基于角色或基于功能的安装”选项以“正常”方式安装，或使用“远程桌面服务安装”以“特殊”方式安装？测试时，我选择了基于会话的桌面部署。

究竟有什么区别？我在两台不同的服务器上都试过，没有发现任何显着差异。