Hello… I would like to install security and critical windows update for new Windows servers, and i need the servers goes to state “compliance” (patch and reboot for many times). How can i create a baseline and workflow for this?
Thanks for your time, it will be apreciated!
Would you be able to describe a sample use case ?
There are two possible approaches, either baselines or automation plans, so an example might help determine which approach would suit your needs best.
Hi Mairt: For example, after install a new server, proceed to connect to the internet and look for new updates from Windows Update, in a first search would find about 80 patches required for installation, I select all critical and security, I install and then reboot to finish patching. Once the computer restarted, proceed with a new search, install and reboot, repeat these steps until Windows Update indicate that I require no more reboots and server is up to date.
In a second scenario, instead of using Windows Update, use a WSUS server as a repository, which already contain patches tested and approved, so proceed to install all patches figuring as pending and reboot the server… these procedure is repeated the necessary times until server gone up to date.
These cases form patching and subsequent reboots takes a lot of time and manual intervention. How IEM could automate the patching a server until it is updated with a single task and minimal manual intervention?
Thanks for the reply!
Hi Hectorio,
Thanks for this, interesting examples.
I think the multiple restarts probably fits more with automation plan way of working.
An approach would be add the Windows content published with IEM to one or more baselines, with a restart after each one. Join all these together in a plan with restarts as required.
Baselines are covered here
http://www-01.ibm.com/support/knowledgecenter/SS6MER_9.1.0/com.ibm.tivoli.tem.doc_9.1/Platform/Console/c_baselines.html?lang=en
Does that help ?
Cheers,
Martin
Hi Mairt, sorry for delay…
I think i’m resolve this with a single baseline (for every Windows Version) and taking action from it…
In Execution
Now… the problem is… too slow…
when I schedule a Patch (baseline)… its take a long time for downloads and be “Ready” (waiting for time “Starts on”…) for patch apply… In one case, for 70 patchs… take along 36 hours for download…
And in other case, i make a Baseline with only 15 patchs take me 3:30 hours for by ready… For this test… when computers were ready for patch… I cancel the Action and re-eschecule again… and take another 3:30 hours… (Downloading again? Not in cache? Not space in relay server?)
I can look than in every patch time in “Pending Downloads” state takes a long time… and the patch its less than 1MB.
It’s a normal behavior? Maybe a need to make a changes in IEM Confiuguration?
Thanks for your help appreciated.
Hectorio
@hectorio, I do something similar with my Relays (I have a fairly large number of Dedicated Relays) when I build them.
I keep baselines for each Year of patches, so 2012, 2013, 2014, 2015 etc. These baselines are only Relevant on systems I place in a particular OU reserved for Relays. One of the Baselines installs the Relay Service and configures the Relay to not accept Autoselect requests from endpoints. I switch this back to 1 when the Relay is physically deployed.
I then take actions from each of these baselines, with no Expiration Date (a policy), On Failure Retry x3, Reapply whenever relevant, Run all member actions, Post-Action Reboot with 1 minute deadline. each month when I update the Baseline components, I stop and resubmit the Actions. (I LOVE the presets feature in the Take Action dialog!).
I DO NOT select Start Client Downloads before constraints are satisfied. The client doesn’t seem to handle this well with Baselines. When used on a Baseline action, the client seems to want to Pre-Cache ALL the patches in the Baseline rather than just the ones that are Relevant. It seems to work better when I allow the client to download what it needs when it needs it.
I also configure my Relays to use 200GB of Cache space so the patches don’t get pruned out of the cache for a while.
Hi Tim:
In my scenario, I need to schedule the patchs in a time and date coordinated with the users of the systems, which is why we need to do the download previously (Start client downloads…) and put start and end dates. From what I look in the Baseline… it dont takes delay for each patch irrelevant, but it takes a time in each relevant patch. Another thing I look is that the application in Windows Server 2003 systems is faster than in 2008 (not confirmed, maybe would be another circunstances…).
I would say then that when I program a patch with several hours of anticipation… the execution could be relatively quick, but when I need to execute an action immediately, it may take me up to 3 hours (with a baseline containing only up to 15 relevant patches). With WSUS, this action could take not more than 1 hour…
I may need to make some adjustments in IEM and Relay Servers to improve the performance of download and installation… I need to be equal or faster than when programmed patches with WSUS (with a Scheduler Console).
Any suggestions for this, would be appreciated.
Best Regards
Hectorio
Sorry! I read your post incorrectly. I thought you were discussing the process of building “new” servers and applying all the missing patches as quickly as possible. We don’t release a “new” server to Application Owners until they are fully patched, so time to patch them is not critical.
Every Patch Tuesday I create a Baseline with that Month’s Microsoft Fixlets/Tasks. All of them. We handle Linux/UNIX servers differently.
Our Operations Center then uses these Monthly Baselines to deploy the Patches to groups of servers in pre-defined Patch Windows. We usually assume that the Monthly patches will take between 2-4 hours to install, but we advertise 4-6 hours for the installation process. They first push the Baselines to “Test” servers. This helps to pre-stage the patches on the Data Center Relays so when the Baselines are pushed to the Production servers a few nights later, they are already cached and the Production servers can quickly download them and install them.
As I mentioned earlier, we don’t use the Pre-Cache option with Baselines because each server seems to attempt to pre-cache all the patch installers in the baseline, and for most servers, they don’t need all the patches.
In practice, I’ve found that there are very few modern Microsoft patches that will impact the performance of a server before it is rebooted. If any of these come up, we find them when we patch the Test machines. The only time the End Users are directly impacted by patching is while the servers are rebooting and finalizing their patches and this would be the same for WSUS installed patches as for IEM installed patches.
We handle Server Reboots as a separate action with a 30 minute staggered start because we have a large number of servers.
The whole process does take a little longer than if WSUS were doing it, but not much, and we get much better control and reporting of the process using IBM Endpoint Manager.
Tim:
In our environment, there are patched servers and some with many outstanding, with our procedure with and Automator and WSUS, we managed patch in less than four hours to servers that were not inclusive service pack. It is for this reason that we considered almost as “new”.
In WSUS, the configuration was in automatically approval for critical and security updates, after tuesday patch, we install in test servers, and a few days on production servers. In case of problems with a patch simply we decline it in WSUS. On this way, there were no need to keep Baselines and the task of patching was more transparent to the operator.
Furthermore IEM has advantages and we would implement them, the only point we have against is their performance in delivering patches (and create mensually baselines)…
For other side… it will take time to ask permission (convincing ) for deploying patches before maintenance window.
PD: Mensually we patch for 400 servers aprox.
Thanks for your time.
I DO NOT select Start Client Downloads before constraints are satisfied. The client doesn’t seem to handle this well with Baselines. When used on a Baseline action, the client seems to want to Pre-Cache ALL the patches in the Baseline rather than just the ones that are Relevant. It seems to work better when I allow the client to download what it needs when it needs it.
@TimRice is that true? When we pre-cache does it cache all the non-relevant fixlets too?
@BigFixNinja @Aram Please share your inputs too.
Hi there,
Advanced download steps for baselines in plans are handled by the automation plan engine by first creating copy of the original baseline in memory, and that copy then has everything except for the download statements stripped out of it.
So, what I would expect to see if you look at the generated download step, is that all the original relevance of the baseline still applies. So if a particular component is not applicable to a given computer, that computer would not pre-fetch that content.
Cheers,
Paul.
