Sccm Patch Deployment Best Practices
This article introduces and discusses some of the best practices for installing and deploying hotfix rollup packs for XenApp and Presentation Server. Citrix periodically releases hotfix rollup packs that might include bug fixes, security fixes, and enhancements for all currently supported XenApp versions. Citrix recommends that you install the latest hotfix rollup pack to get the best out of XenApp in terms of performance, security, and overall user experience. For a major XenApp release, Citrix supports the most recent Hotfix Rollup Pack (HRP).
In addition, Citrix supports the Hotfix Rollup Pack released prior to the most recent hotfix rollup pack for 12 months provided the requests are commercially viable. However, public hotfixes for security vulnerabilities are provided only for the most recent hotfix rollup pack. For example, Hotfix Rollup Pack 02 for Citrix XenApp 6.0 for Microsoft Windows Server 2008 R2 was released on and is the most recently released hotfix rollup pack for Citrix XenApp 6.0 for Microsoft Windows Server 2008 R2.
The hotfix rollup pack released prior to Hotfix Rollup Pack 02 was Hotfix Rollup Pack 01. In addition to supporting Hotfix Rollup Pack 02, Citrix will continue to support Hotfix Rollup Pack 01 until at which time Hotfix Rollup Pack 01 is considered End of Life. Considerations Prior to Installation Citrix recommends that you thoroughly evaluate hotfix rollup packs on a test server or farm. Ensure that you cover some testing comparable to the tasks of an everyday user, as well as some administrator oriented tasks. Examine the readme that accompanies the hotfix rollup pack. Readmes provide necessary information on the prerequisites and known installation issues. Common installation prerequisites might include an updated version of the license server, a particular redistributable (such as Java or.Net Framework), and so on.
The readmes are kept up to date even after the hotfix rollup pack is released to the web. On occasion, installing a hotfix rollup pack can invalidate certain hotfixes. This happens when some of the fixes included in a hotfix are not included in the hotfix rollup pack. For a list of invalidated hotfixes and their replacements, see the Hotfix Rollup Pack readme. You can obtain or request the corresponding replacement hotfix for any invalidated hotfixes by contacting support. Make note of the release dates of different hotfix rollup packs and components (such as plug-ins, consoles, and so on) and attempt to install these in the order they were released.
Sccm Patch Deployment Best Practices
You can find the release dates on the download page of each hotfix rollup pack or component. For example, the XenApp 5 for Windows Server 2003 components were released before Hotfix Rollup Pack 3; therefore, it is recommended to install the components first, followed by Hotfix Rollup Pack 3.
Because hotfix rollup packs are cumulative, there is no need to install earlier hotfix rollup packs. The latest hotfix rollup pack includes the fixes from all the previously released hotfix rollup packs for that product. Order of Deployment The order of hotfix rollup pack deployment is very important, especially in large or complex farm configurations. Before installing a hotfix rollup pack:. Ensure that there are no existing connections on the servers where the update is being run. Ensure that the Independent Management Service is running.
Back up the data store database After a deployment, always ensure that all servers in the farm are updated to the same hotfix rollup pack level. Citrix recommends the following order of deployment:. Zone data collector. Backup zone data collectors.
Database connection server (Applies only to Resource Manager for XenApp 5 for Microsoft Windows Server 2003). Primary farm metric server (Applies only to Resource Manager for XenApp 5 for Microsoft Windows Server 2003). Backup farm metric server (Applies only to Resource Manager for XenApp 5 for Microsoft Windows Server 2003). Member servers The hotfix rollup pack installs and updates only servers that have core XenApp (mps.msi) and/or XenApp Advanced Configuration (cmc.msi) installed.
Common Install and Uninstall Methods There are many installation methods currently used by customers. Some of the most common installation methods include the following:. Double-clicking the hotfix rollup pack installer file. Command line installation by using the msiexec or cpatch commands. Active Directory deployment by using a batch file.
Installation Manager. Deployment through System Center Configuration Manager(SCCM) Installing hotfix rollup packs over an ICA session is not supported but you can install while logged in as an administrator over a remote desktop session. Also, administrative image and slipstreaming of the hotfix rollup packs is not supported.
Uninstalling hotfix rollup packs is supported. The same methods used for installing are supported for uninstalling. After uninstalling, all files are restored to the previous patch level.
In certain situations, uninstalling a hotfix rollup pack prompts for the original source CD location; this happens when the offline plug-in, Streaming Profiler, Single sign-on, and the Access Management or Delivery Services Consoles are installed on the same server as the hotfix rollup pack. In these situations, it is recommended to always run a reinstall or repair on the components after you uninstall the hotfix rollup pack to restore the correct files.
Conclusion These best practices help mitigate some of the installation issues you might experience. Testing a hotfix rollup pack thoroughly before deploying it in a production environment, while taking into consideration the information contained in the readme, is your primary task to a successful deployment. Taking into consideration a role based order of deployment and common installation methods also helps the process. Additional Resources For additional information related to common issues, features, and installation guidelines, refer to the following Knowledge Center articles: CTX117362 - CTX106174 - CTX105646 - CTX119922.
For System Center 2012 Configuration Manager SP1 and later: When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. By sharing the same database you can significantly mitigate the client and network performance impact that can occur when clients switch to a new software update point. When a client switches to a new software update point that shares a database with the old software update point, a delta scan still occurs, but this scan is much smaller than it would be if the WSUS server had its own database. When you install WSUS 3.0, you can specify whether to use the default Internet Information Services (IIS) website or create a new custom WSUS 3.0 website. As a best practice, select Create a Windows Server Update Services 3.0 Web site so that IIS hosts the WSUS 3.0 services in a dedicated website instead of sharing the same website with other Configuration Manager site systems or other software applications.
When you use a custom website for WSUS 3.0, WSUS configures port 8530 for HTTP and port 8531 for HTTPS. You must specify these port settings when you create the software update point for the site.
When you install WSUS 3.0, select the Store updates locally setting. When this setting is selected, the license terms that are associated with software updates are downloaded during the synchronization process and stored on the local hard drive for the WSUS server. When this setting is not selected, client computers might fail to scan for software updates compliance for software updates that have license terms. When you install the software update point, WSUS Synchronization Manager verifies that this setting is enabled every 60 minutes, by default.
There is a limit of 1000 software updates for a software update deployment. When you create an automatic deployment rule, you specify whether to use an existing update group or create a new update group each time the rule runs. When you specify criteria in an automatic deployment rule that results in multiple software updates and the rule runs on a recurring schedule, specify to create a new software update group each time the rule runs. This will prevent the deployment from surpassing the limit of 1000 software updates per deployment. Always use an existing software update group when you use an automatic deployment rule to deploy Endpoint Protection definition updates on a frequent basis. Otherwise, potentially hundreds of software update groups will be created over time. Typically, definition update publishers will set definition updates to expire when they are superseded by four newer updates.
Therefore, the software update group that is created by the automatic deployment rule will never contain more than four definition updates for the publisher: one active and three superseded.