Still Writing Scripts for Managing Endpoints/End-User Machines? There is a Better Way!

When IT Administrators started using scripts to perform day to day administration tasks for managing endpoints, it was a saviour for many. Scripting is a powerful tool that can quickly automate repeatable tasks. It is highly efficient with limited data structures and variables also making it very easy to learn. Even a user with very little exposure to code can quickly learn and start using them. This is the reason why you see scripting being widely adopted for all kinds of system administration tasks. But IT Administrators grow so habituated to using scripts to simplify work that they do not realise when the scripts spiral up to a whole new level of complexity and volume. It can often come to a point where the scripts go so out of control that IT Teams have no visibility into the fleet of laptops and desktops. It is only when scripts are extensively used that their shortcomings tend to surface. Scripting was hardly meant to be a scalable solution.

As organizations grow and expand, the need to automate managing endpoints becomes more real than ever. But letting your scripts do the automation comes with its own set of problems.

Different Scripts for Different Platforms:

Scripts have to be written in PowerShell for Windows and Bash or AppleScript for macOS devices. If your fleet has endpoints with different operating systems, scripts need to be written separately for each operating system making scripting repetitive and difficult to manage.

Script Management and Maintenance:

Scripts can be lengthy and difficult to write and comprehend. Additionally, there may be many scripts running for various purposes on an ad hoc basis or through MDMs.  In such cases, scripts tend to be become “tribal knowledge” and in most cases, only the script author knows what scripts they’ve written. If somebody leaves the organization, the knowledge is often lost and it’s hard for the rest of the team to decipher the scripts and make changes to them.

• Lack of Script Validation and Change Management Capabilities
  Testing out scripts before deploying to the fleet and ensuring that the scripts behave as expected is important to ensure that the configuration changes applied do not corrupt end user devices. There is no process in place to validate if changes made to the scripts are well vetted and tested. Rolling back changes also becomes cumbersome when there are no standards followed to maintain the scripts. An inadequately written script may result in the accidental deletion of data or other unintended consequences. The cost of incurring such damages and the potential loss of time and resources spent in resolving those issues could be enormous.

Script Compatibility with New Builds:

There is no guarantee that scripts written today would work on your fleet in the future. With software and operating systems being constantly updated, IT teams end up spending time updating the scripts so that they run on the fleet seamlessly.

Audit Trail:

If a script scheduled to run on a device is not successful in applying a configuration, there is no way to determine that. Scripts do not have good auditing capabilities, making it hard to track all the changes made to the fleet.

Setting the Scope for Running Scripts on Endpoints:

Some scripts need to be run at a user level and some need to be run at a system level on the end user devices. Differentiating the two and running the script with the right permission becomes a barrier to efficiently deploying the scripts.

Customized Scripts Could be Error-Prone:

When IT Administrators get burdened with more and more ad hoc requests, they tend to run custom scripts through the terminal to quickly fix issues. These customized scripts written to cater to ad hoc requests could be forgotten. When problems arise as a consequence of one of those scripts, debugging and finding the root cause of such problems becomes a hassle.

Is there a better way to achieve what the IT administrator initially set out to do with scripting?

There is a way to perform customized configurations and automate managing your endpoints:

• Tools with Idempotency capabilities, i.e. if the system is not at the desired state, a configuration change is made to make it so; but if it is already at that state, no state change is made.
• Code Abstractions take care of underlying tasks needed to achieve the specified configuration.
• Peer Reviewable Code and Adoption of SDLC Process - Fleet state is represented with code, which is peer-reviewed, and changes can be tested before deployment.

A configuration management tool like Chef not only makes it easy to configure your endpoint state as code compared to writing complex and lengthy scripts, but its “code-first” approach also helps setup an SDLC process ensuring that changes are well vetted and tested before pushing to production. It makes the overall cost of change less expensive and increases IT team productivity. With Chef, it is even possible to perform compliance checks by specifying your compliance policies as code.

Let us look at a small example of what it looks like to configure a setting on your endpoint using Chef, compared to configuring the same setting with a script.

Powershell Script to set a Windows laptop to a defined Power Level:

$DiskTimeout = 1200
$StandByTimeout = 1200
$HibernateTimeout = 1200
$dup = powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61
$guid = $dup.Split(‘ ‘)[3]
powercfg /changename “$($guid)” “developer power scheme”
powercfg /setactive “$($guid)”
powercfg /change monitor-timeout-ac $MonitorTimeout
powercfg /change disk-timeout-ac $DiskTimeout
powercfg /change standby-timeout-ac $StandByTimeout
powercfg /change hibernate-timeout-ac $HibernateTimeout

VS

Chef recipe using a resource to do the same

windows_power_management 'Set the Device to a defined power level'

do

power_scheme_label 'Unrestricted'
power_level 'ultimate'
monitor_timeout 15
disk_timeout 0
standby_timeout 0
hibernate_timeout 0
action :set

end

For configuring a device with Chef, all you must do is call the resource and pass the parameters that you want to set. All the needed underlying tasks are taken care of. Chef resources are not only more readable but even allow you to easily customize configurations with a single resource for different users and machines dynamically. This is especially useful when managing a large fleet of end user devices.

An MDM/UEM is useful for performing core device management tasks like Enrollments, Remote Wipe/Lock, etc. But using code as an alternative to scripting is an efficient way to get around MDM/UEM capabilities that are basic or missing in the MDM GUI. Chef's agent-based approach allows pulling configuration information from the Chef server periodically, thereby ensuring that machines stay in the desired state even when end users accidentally change a configuration.

JOIN OUR WEBINAR TO LEARN MORE

We will discuss more of what Chef can do to transform your organization’s endpoint management strategy in a webinar on October 27, 2021, at 10:00 AM PT.

Chaithra Mailankody, Associate Product Manager, and, Sudeep Charles, Senior Manager, Product Marketing, at Chef, will present current trends and issues in scripting and how Chef Desktop, which focuses on codifying your fleet instead, can help you avoid them. We will also have a Q&A session where a panel will answer all your questions.

If the content of this blog interests you, you should definitely attend the webinar and see how Chef can meet your IT fleet management objectives.

BOOK YOUR SPOT NOW