There are many reasons to add automation to your network. In this video, you’ll learn about restarting computers, mapping network drives, application installations, automated backups, and more.
In information technology, we are constantly creating scripts to automate our computing environments. This allows us to perform functions when we’re not at the office and sitting in front of our computer. And this is something that can happen at any time of the day, even when we’re sleeping. We might also use these scripts to monitor systems and make sure that everything is running as expected.
And if this script performs a function that needs to occur many times over and over again, it can occur very quickly in this automated scripting environment. We don’t have to wait for a human being to begin the process, and there’s no errors because no one’s having to type this in interactively at the command line. This means you can create scripts that automate the tasks that occur over and over again, and that frees up your time to perform other job functions.
We might use our scripts to restart machines. We’re obviously not restarting the machine just because we would like it to restart. Instead, we may be performing an application update. And at the end of that update, we need to reboot the machine to have all those changes take effect. Or we may be installing security patches and we have to restart the machine to have those security patches take effect.
And in some environments, they may be working with hardware or software that needs a reset every day. So there may be an automated process every night that goes through those systems and restarts every single one of them. When we log into our computer at work, there’s usually a number of drives that are configured automatically during the startup process.
In our Active Directory video, I took you through the example of creating a script that would map a drive each time someone logged in. This way the moment they log in, they have access to all of the data that they need for the day. We might also use this drive mapping function to allow us access to other types of data. We might want to map a drive that contains files for an application update, we’ll run the update process, and then we’ll remove that drive mapping.
Or we might be moving user data or backing up some of the user data so we may need to map a drive to have somewhere to copy all of that information. If you’ve ever installed software at home, you know that you would connect to a website, you would download the installation file, you would need to run that installation file, answer any prompts that occur during the installation process, and at the end you might have to restart the machine so that application is now available.
That’s the process for a single computer. Now do that for thousands of devices in a work environment. We simply don’t have time to take a flash drive and go to every single machine to install this one application. Most of these setup programs allow us to script the process so there’s no interactive prompts during the installation. Instead, we simply start the installation with a set of predefined answers and it goes through the installation without any type of human intervention.
So our automation script might map an application installation drive, install the application without any of those user prompts, disconnect the map drive, and then automatically restart the system all without us needing to do any type of direct human intervention. A very common form of automation involves backups. We want to create backups every night of all of our user data, and running an automated script is a perfect way to provide this data transfer.
We could certainly perform this function interactively. But it’s very time consuming to wait for all of this data to be transferred across the network to the backup system. Instead, we can have a script wait for this process to complete. And when it’s done, we can clear the connections, restart the machine, and we’re back up and running. We usually have these backups occur when nobody’s at work so we can have that automated process happen in the middle of the night while we’re sleeping, and when we come back to work in the morning the backup process is now complete.
If you’re in charge of a data center, you might have hundreds or even thousands of devices that you need to monitor for uptime and availability. We might want to monitor this system throughout the day to make sure it’s working as expected, and that we’re not having any problems with memory or storage space. Or we might need to perform an inventory of all these systems and get a list of the hardware and software associated with each one of these devices.
And it’s not unusual to create scripts that can go to machines and perform security or vulnerability checks so we know what systems need to be updated and patched. And of course with our operating systems and applications, there’s constant changes and constant patches that need to occur. Operating systems are constantly getting new updates. And occasionally you’ll get a bug fix or a security patch that needs to be installed. Or we might get a new device driver or an updated device driver that needs to be installed on everyone’s machine.
And as new applications are rolled out, we need some type of automated process to get that application installed onto everyone’s desktop. While all those scripts can provide us with a great deal of functionality, we still have to be very careful about what we’re scripting and when we’re scripting this information. And although the scripting provides us with extensive automation, we still have to be very careful with what we’re scripting.
For example, if we’re performing an application rollout, we want to be sure that the executable that we’re sending out is safe and free from any malware. You would not want to script an automated installation function which is effectively installing malware on everyone’s system. You also want to be sure to test all of these scripts before they’re rolled out. You don’t want to deploy a script that makes changes to a registry that then creates problems for other applications on that system.
And it’s true that even having a single character in a script incorrect could create a significant set of problems when the script runs. As with most things in information technology, you should always have a backup. And before you deploy any script in production, it should always go through a testing process.