Virtual Desktops are a topic that runs hot and cold through the enterprise space. Many enterprises begin pilots and projects in the space before building a clearly defined plan, and these are the environments that need additional remediation down the road. Before we start in with architecture, getting a firm answer to “Why do we need them?” is critical to a successfully scope, cost, and validate the design. This month we will focus on the security use case which is one of the ‘easy wins’ for virtual end user compute.
In this second installment of a two-part series, we’ll be going over Phase Two, the build out of standard pre- and post-patching automation, and Phase Three, the build out of application-specific pre- and post-patching automation. Click here for Phase One.
Status Report With basic patching and reboots automated, a patching session for application environments without any special pre-patching and post-patching activities was reduced from 20 minutes per server, down to 6 minutes per server.
In this first installment of a two-part series, we’ll be going over Phase One, the build out of the “core” patching and reboot functionality on Ansible.
History Around a year ago, we began working with a customer whose Red Hat Enterprise Linux (RHEL) 6 and 7 OS patching process was being conducted manually. This required highly skilled administrators focused solely on patching. Documentation was eschewed in favor of tribal knowledge and manual command entry at the command line presented moderate to high risk during server patching.
