Thanks to everyone who attended the SCCM GURU event I presented, if you missed it you can catch it on the replay – link
Here are my answers to questions raised during the session.
Q: Is the patch management service on ConfigMgr for only Windows/IE patches, for all Microsoft products (e.g. Office), or for all products Microsoft and non-Microsoft?
A: The Software Update feature in ConfigMgr is capable of installing patches for any product supported by the Windows Update catalog. You can also extend the software update catalog using the System Center Custom Updates Publisher tool to deploy 3rd party update catalogs (like Adobe, Dell, etc.) or even manually defined updates.
Q: On the SUM Deployment policy, what mechanism did you use to cause the updates to download or was it only to get the advertisements?
Q: If you have a Software Update Deployment become mandatory before your maintenance window begins, patches will be cached outside of the maintenance window? Is that correct?
A: When a SUM Deployment policy is past deadline the ConfigMgr agent will automatically background download the applicable updates.
We want servers to background download the updates all the time so our SUM Deployment policy is always set past the deadline and an unreachable (20+ years in the future) collection level maintenance window on the ‘All Systems’ collection keeps machines from installing updates before the advertisements start the patching task sequence.
Read more details in one of my previous blog posts:
Q: If Bit Locker has been implemented in the environment, does this add to the complexity of rolling out patches? Can some patches corrupt Bit Locker?
A: I don’t think Bit Locker adds any complexity to patch deployments and I’m not aware of any corruption with patches.
Q: Is the only way to do multi-pass patching to use Task Sequences?
A: Outside of creating a custom script, the task sequence engine presents the easiest and most predictable way to do multi-pass patching.
The main reason we use multi-pass patching is to install patches that result from a baseline upgrade, like a service pack. For example, if a machine is running Office 2010 RTM and we authorize SP1 – the first patching pass would detect and install SP1 and the second pass would detect and install any post-SP1 security patches that now are required on the machine as a result of the service pack upgrade.
Q: Where would I find the “Patch Now” PowerShell stuff?
Q: Would you suggest using your “patch now” PowerShell stuff for a zero-day exploit or an out of band patch?
A: I’ve written two previous blog entries on the subject of initiating task sequences (which we use for patching – link) on-demand:
I am finishing up a blog post with an updated version of this code that is wrapped in a PowerShell module; check back with my blog soon!
As far as use in a zero-day exploit the on-demand scripts prove very useful for our server owners as they can determine their compliance or patch their machines as soon as the ConfigMgr packages are ready to go.
Q: Where is this health check script?
A: The health check script isn’t something I’ve blogged about yet; the script itself run a pretty basic set of checks against a list of machines that are not reached (no agent installed) or not healthy (hardware inventory or update scan). The real “magic” of the check script is that it logs to our SQL database allowing us to collect data on machines where we have no agent, e.g., is the machine responding to a ping request? Are there free space issues on the OS drive? Can we connect to WMI? Any errors in the ccmsetup log? And so on…
The check script is also constantly updated as we identify fixes for common issues they get integrated into the check script to either auto-fix or at the very least report on them.
I’ll consider this topic for a future blog post.
Q: Seems we overcomplicate. Why not just run on auto updates on systems?
A: In the datacenter space we need to be predictable about downtimes for servers, e.g. maintenance windows. We also need the ability to in-line software deployments alongside security updates, run multiple security update install passes, dynamic targeting, handle any reboots, pre/post patching scripts and the list goes on…
If the main goal is just patching and rebooting machines then automatic updates or Windows Server Update Services (WSUS) is a decent tool for the job. ConfigMgr is much more than just a patching tool, and while the method may seem overly complicated ConfigMgr allows us to deliver a much more robust service offering.
Q: Can you talk about the disaster recovery plans for your ConfigMgr Infrastructure?
A: Our current disaster recovery plan includes warm-standby virtual servers shadowing each of our Site Servers. The standby servers are running a blank OS install (no SQL or ConfigMgr installed) with the same drive letter/size configuration as the server they shadow; each morning they replicate a copy of the drives used for ConfigMgr backups (which contains a backup of the Site and SQL databases) as well as the live ConfigMgr folder (which contains all the inbox folders, package files, and other data).
If we were to lose a primary site server for example we could pretty quickly rename the standby server to the name of the lost primary site server, install SQL, restore the databases from backup and then install ConfigMgr and restore the Site database and be up and running again.
We have high-availability for the ConfigMgr roles like Management Points and Distribution Points and most of the other ConfigMgr roles require minimal effort to install on another server in the hierarchy in cases of disaster.
Q: How big is the team you work on that runs the ConfigMgr datacenter infrastructure?
A: My immediate team that supports a ConfigMgr for ~25-30k datacenter servers consists of three service engineers (myself included), one service manager and a small (2-3 persons per shift) tiered support team in India.
Q: What are your plans for upgrading to ConfigMgr 2012?
A: We plan to be upgraded to ConfigMgr 2012 within the next three to four months; currently we are deploying a parallel infrastructure of virtual machines running a ConfigMgr 2012 hierarchy. Once that’s complete we will finalize service continuity testing (making sure automation and reporting functions still work) and then begin migrating clients in a phased approach.
Again, thanks for attending the webcast – if you have additional questions please leave them as comments and I’ll get them answered.