In last week’s cloud software release, we pushed out a subtle new capability that should pack a big punch for our customers. CenturyLink Cloud is constantly looking for ways to engineer a better server management experience for our IaaS customers, and we think that this a great example of that focus. In this blog post, I’ll describe this new feature, show you where to access it, and when you will want to use it.

What is it?

In a nutshell, users can now easily execute arbitrary script commands when creating or managing servers in our cloud. Windows users can choose between PowerShell and Windows Command scripts, while Linux users may use SSH scripts. Both the Command and SSH scripts execute directly on the target machine(s) whereas PowerShell scripts take advantage of the “remote PowerShell” capability.

Where do I access it?

We expose this capability in the two most relevant places. First, blueprint designers can include the Script activity when orchestrating new server environments

When this Script task package is added to a blueprint, the blueprint designer is asked to choose both the target server and execution mode (PowerShell/Command/SSH), and then enter the actual script statement. In the “Script” textbox, the user inputs a single statement or multiple statements.

While this Script task is a very helpful component of the server provisioning process, we think that it’s even more valuable later on when administrators have to manage collections of servers. As a reminder, CenturyLink Cloud cloud servers are organized into “Groups” which are more than just superficial containers. Rather, groups empower administrators to manage sets of servers as a single unit and perform bulk actions against those servers. So, it made perfect sense to also add the Script task here so that administrators could quickly run commands against any or all of the servers in a given group.

When would I use it?

Can’t you already upload customer-specific scripts to your CenturyLink Cloud script library today? Sure you can, but we wanted to support even greater agility and allow administrators to run quick, arbitrary commands without going through the traditional “write-upload-approve-select” workflow process.  Imagine being able to quickly and reliably perform the following operations across an entire stack of servers at once: turn off/on machine services, restart web applications, delete log files, open a firewall port, or update Windows registry values. I’m sure that you could come up with countless more examples of actions that can be performed with a single script statement.

Example #1 – Enabling Services Across Servers

Let’s walk through an example. Assume that we have a set of servers that perform other functions until they are needed to act as web servers. These Windows servers, which have Microsoft’s IIS web server software already installed, have both their IIS website disabled as well as their World Wide Web Publishing Service turned off (and thus aren’t listening for HTTP requests). As expected, trying to serve up a web page on this machine results in an error.

What if an administrator wants to rapidly turn on the WWW Service and the “Default Web Site” on the server? They could go server by server and manually turn things on. However, that’s time-consuming and error prone. Instead, what if they had a quick PowerShell script that takes care of all that?

To get started, I click on the Group Tasks button and choose Execute Script. In the prompt that follows, I select the Script package and apply the following multi-statement PowerShell command (Start-Service “W3SVC”; import-module webadministration; Start-WebSite -Name “Default Web Site”).

On the next prompt, I’m asked which of the group’s servers to apply this to.

That’s all there is to it! The corresponding blueprint finishes executing the script against both machines in just 12 seconds. I should now be able to access the website on either of these two servers.

I confirmed that this was the case by logging into my pair of server and seeing that my WWW service was running and website was available.

Example #2 – Executing Server-side Scripts

In another case, assume that each server has a set of scripts available on one of its storage drives. One of those scripts edits a log file whenever a new version of the software application gets installed in the server farm. After performing a software update across the server group, our administrator wants to trigger this server-side batch file.

First off, notice that I have a Windows Command script (WriteLog.bat) installed on the server. This batch file simply writes a new entry in the server’s log file (see below).

Next, I create a new Group Task, select the Script package, set the script type as Command, and input the local batch file to execute.

Almost immediately, the Windows Command executes the local batch script and updates the log file.


CenturyLink Cloud Blueprints and Group Management are engineered to make server administration work at scale. This new Script task helps ensure that quick actions can be consistently and reliably executed across a vast number of machines. While we still encourage customers to upload (complex) scripts that need to be used over and over again, we hope that this new feature offers a nice alternative for simple actions!