How to Restart, Reset, Shutdown, Poweroff VMs with PowerCLI

Posted on by Sahan Fernando

It’s been a while… been a while since I blogged and I’m ashamed to say been a while since I scripted! But there is nothing like a crisis to bring out the scripting guns when we had to restart a 100 odd virtual machines which were hung. Which made me realize that while I had the script already made, I hadn’t made a post about it. So here it is, and hope it would be useful for you as it was for me!

In all of these commands I will use -Confirm:$False at the end. Confirm:$false is used to disregard the Confirmation prompt that PowerCLI gives out. It’s an optional parameter that is useful if you’re executing this for bulk VMs

Restart VMs with PowerCLI

The command to gracefully restart a VM from the Guest OS – which is to say to send a restart command to the guest operating system and let it do its thing – is the following :

Restart-VMGuest -VM <VM_name> -Confirm:$False

This command is useful if you prefer to let the OS gracefully restart itself after, say, a memory or CPU upgrade.

*VM Tools is required for this command to work because the vCenter API has to communicate with the OS for the command to execute.

It is the same as pressing the “Restart Guest OS” button on the vCenter

Reset VMs with PowerCLI

The command to reset a VM – which is pretty much like pressing the physical reset button to restart the system – is the following :

Restart-VM -VM <VM_name> -Confirm:$False

This command is useful if the VM is hung or unresponsive and resetting it is the only option you have left.

It is the same as pressing the Reset button on the vCenter

Shutdown VMs with PowerCLI

The command to gracefully shutdown a VM from the Guest OS – which is to say to send a shutdown command to the guest operating system and let it do its thing – is the following :

Shutdown-VMGuest -VM <VM_name> -Confirm:$False

This command is useful if you prefer to let the OS gracefully shut itself down during, for example, a downtime.

*VM Tools is required for this command to work because the vCenter API has to communicate with the OS for the command to execute.

It’s the same as pressing the “Shut Down Guest OS” button on the vCenter

Power Off VMs with PowerCLI

The command to forcefully power off a VM – which is pretty much like yanking the power cable off a server (or less violently powering off by pressing the power button) – is the following :

Stop-VM -VM <VM_name> -Confirm:$False

This command is useful you want the VMs shut down as quickly as possibly or if its unresponsive.

It’s the same as pressing the “Power Off” button on the vCenter

Putting it all together to a script for executing on bulk VMs

The above commands are to execute on one VM, lets see how we can use them to create a full fledged script.

Long term followers of the blog will know that I like to put the list of VMs for the script to be executed on in a text file and import the list via the text file to the script – read all about it here. The reason I do this is that it’s easier to change the VM list later on which increases the reusability of the script.

Lets see how we can put together a script to reset a list of VMs which I assume is contained in a text file called “vmlist.txt”

$vm_list = Get-Content "vmlist.txt" #txt file with the vm list
$vcenter = "<vcenter_name>"


Connect-VIServer $vcenter 

foreach ($vm in $vm_list){

Restart-VM -VM <VM_name> -Confirm:$False #<replace this with any of the above commands to suit your need>
}

Disconnect-VIServer -Confirm:$false

To change between restart, reset, shutdown or power off – change the line Restart-VM… with the command you want.

That is it! As easy as that!

It makes me feel validated & boosts my ego if you share, comment if you found this useful (no pressure 😉  ). Social media links are below!

And as always, Happy scripting!

How to get the Operating System (OS) of Virtual machines with PowerCLI

Posted on by Sahan Fernando

There have been numerous occasions where we were required to gather the list of VMs in the vCenter along with their OS, for audits, for support, to plan patching, etc… But its not always that easy.

The vCenter gets the OS details of the VM with the aid of VM Tools in the virtual machine. But what if the VM is powered off or doesn’t have tools installed? Then the OS is left as blank! But there is a workaround, we can fetch the OS info the VM was configured with – since that information is stored in the vCenter itself, we don’t have to rely on the VM tools running inside the VM to get this information.

This is in the $_.ExtensionData.Config.GuestFullName parameter in Get-VM

One Liner to get the list of all VMs and OS info in the vCenter

Get-VM | Select @{Label = "VM Name" ; Expression = {$_.Name} },@{Label = "Guest OS" ; Expression = {$_.ExtensionData.Config.GuestFullName} }| Export-CSV "vm_os_info.csv"

Its as simple as that. You will get a csv with two columns as “VM Name” and “Guest OS” with all the information in the vCenter wrapped in a neat little bow.

Hope this short and sweet post was useful to you!

It makes me feel validated & helps me out a lot if you share or leave a comment if you found this useful (no pressure 😉 ). Social media links are below!

And as always, Happy scripting!

How to check EVC Status of a Host Cluster with PowerCLI

Posted on by Sahan Fernando

Consider this part 2 of my vSphere Health Check with PowerCLI series. It’s taken its sweet time, I know, but hey – better late than never eh? 😉 Part 1 is found here (Checking for hosts with alarms disabled) .

In this post we’ll discuss how to check the EVC mode of each host cluster in the vCenter. EVC (Enhanced vMotion Capability) is a feature that is a form of standardization of vMotion compatibility in hosts in the cluster according to CPU generation. It sets a minimum feature set offered by CPUs in the cluster so that all hosts presents identical features so that things don’t go haywire when VMs migrate between them. Anyway this is not a lesson on EVC (if you want more info, refer the KB article), this is a lesson on checking on the EVC mode on a cluster by PowerCLI

We will first check whether EVC is enabled in the first place, and if its enabled, which EVC mode its enabled to. While this seems like a lot of complexity – its actually only a few lines of code.

Checking if EVC is enabled

EVCmode information is encapsulated in the Get-Cluster module. So let’s access Get-Cluster and check on the EVCmode parameter. If this EVC mode returns a null value then EVC is not enabled in that cluster. If EVC mode is enabled then it would return the EVC Mode (like Intel “Haswell”, Intel “Skylake”, Intel “Cascade Lake” etc…). Lets see how it comes in to play

$cluster = $Get-Cluster <cluster_name>
    
if($null -eq $cluster.EVCMode){
        $evc_status = "Status : Disabled"
    }

else{
        $evc_mode = $cluster.EVCMode

        $evc_status = "Status : Enabled EVC Mode : $evc_mode"

    }

One-Liner

Lets see how we can use the above principle to get a one-liner to export a csv with the EVC mode results

Get-Cluster |  Select @{N='Cluster';E={$_.Name}},@{N='EVC Mode';E={if($null -eq $_.EVCMode){"EVC not enabled"} else{$_.EVCMode}}} | Export-Csv 'cluster_evc.csv'

And that’s it! Its as simple as that!

It makes me feel validated & helps me out a lot if you share, comment if you found this useful (no pressure 😉 ). Social media links are below!

And as always, Happy scripting!

How to enable ESXi host alarms on the vCenter with PowerCLI (& how to automate it)

Posted on by Sahan Fernando

In a previous write-up I discussed how to check the Alarm status of ESX hosts in a cluster. Let’s take it a step further and check how we can enable the alarms on an ESX host in order to automate it – so that alarms will be enabled on ESX hosts for eternity, as a healthy environment should! No longer shall we be in doubt whether we forgot to enable alarms in a ESX host after working on it! This is actually very simple! Lets get to it!

Here I will be talking about enabling alarms on all hosts in the vCenter (not on a particular cluster). You can put this script on a task scheduler to keep it running on a schedule so that Alarms will be enabled periodically throughout the day.

Step 1: Getting the list of ESX hosts whose alarms are disabled

$alarm_disabled_hosts = Get-VMHost | Where-Object {$_.extensiondata.AlarmActionsEnabled -eq $false}

This was discussed in the previous post, so I won’t discuss this at length. Its a pretty self evident line anyway 😉 With Get-VMHost called raw and bare naked like that we loop through all hosts piped to the where-object clause which checks for the AlarmActionsEnabled extension data.

Step 2: Enable them alarms!

The Service Instance in charge of handling alarms in the vCenter is the Alarm manager. So lets get a view of that manager entity to call on its management capabilities. 

$alarmMgr = Get-View AlarmManager

Now that we have called on the Alarm Manager to the $alarmMgr variable, we can also call on EnableAlarmActions to enable alarms from our list of hosts whose alarms are disabled

$alarmMgr.EnableAlarmActions(<host_name>.Extensiondata.MoRef,$true)

Above line enables the alarms on the host that we specify

Let’s see how we can put all this together in one full script:

Connect-VIServer <vCenter>

$alarm_disabled_hosts = Get-VMHost | Where-Object {$_.extensiondata.AlarmActionsEnabled -eq $false}

$alarmMgr = Get-View AlarmManager


ForEach ($hosts in $alarm_disabled_hosts){

    $alarmMgr.EnableAlarmActions($hosts.Extensiondata.MoRef,$true)
    
}

This would enable alarms on all ESX hosts whose alarms are currently disabled.

Extra Credit : Skip hosts in maintenance mode

If the host is in maintenance mode, chances are that you are working on some error on the host and you will have to keep those alarms disabled. So for extra credit let’s see how we can modify the script to skip the hosts in maintenance mode:

Connect-VIServer <vCenter>

$alarmMgr = Get-View AlarmManager


ForEach ($hosts in $alarm_disabled_hosts){

    if ($hosts.ConnectionState -eq "Maintenance"){
        Write-Host "$hosts in maintenance mode, alarms will remain disabled"
    }

    else{
        Write-Host "Enabling alarms in $hosts"
        $alarmMgr.EnableAlarmActions($hosts.Extensiondata.MoRef,$true)
    }

}

And thats it! Keep this running on a schedule and you can be sure your environment has constant monitoring enabled.

If you found this useful, it helps me out if you share, comment or just generally spread the word (no pressure 😉 ). Social media links are below!

And as always, Happy scripting!

How to check ESX host version and build number with PowerCLI

Posted on by Sahan Fernando

Are you planning an ESXi upgrade? or in the middle of a cluster ESXi upgrade and couldn’t track which ones you upgraded and which ones you didn’t? (which is what happened to me 😉 )

So I made a script that would output the build number and version number of ESXi hosts in a cluster

The One-liner

If you’re in a pinch and you just need to check the status of hosts with minimal effort, you can use this one-liner

Get-Cluster "<cluster_name>" | Get-VMHost | Select @{Label = "Host"; Expression = {$_.Name}} , @{Label = "ESX Version"; Expression = {$_.version}}, @{Label = "ESX Build" ; Expression = {$_.build}}

Keep in mind that you need to be logged in to the vCenter with PowerCLI before executing this (obviously). This will ouput something like this:

Explanation:
The mechanism behind this is quite simple. Get-VMHost cmdlet contains parameters called “build” and “version” built in to it. What we are simply doing is outputting the values of those specific parameters.

Script to Output to a CSV

Need something fancier to share with your team or your superiors? Let’s see how we can expand from the one-liner to a proper script that is expandable and versatile that can output to a csv.

$vcenter = "<vcenter_name>"

$cluster_name = "<cluster_name>"

Connect-VIServer $vcenter 

Get-Cluster $cluster_name | Get-VMHost | Select @{Label = "Host"; Expression = {$_.Name}} , @{Label = "ESX Version"; Expression = {$_.version}}, @{Label = "ESX Build" ; Expression = {$_.build}} | Export-csv "cluster_host_build_info.csv"


Disconnect-VIServer -Confirm:$false

What’s different with the one-liner is the pipe to “Export-csv” which will create the CSV file. Please note that this CSV file will be created on the folder where the script is located.

We have also parameterized the vCenter name and Cluster name for better versatility. Pretty neat huh? What – you want more? Let’s see how we can expand this further to match a build level that you want.

Script to check whether a host is in the build level you want

I hear you… You’re in the middle of upgrading an ESX cluster and you want to check which hosts are left to upgrade – while you can judge for yourself from the above script, here’s a small addition to our script above that makes our lives muuuuch easier

$vcenter = "<vCenter_name>"

$cluster_name = "<cluster_name>"
$expected_build = <expected_build_number>

Connect-VIServer $vcenter 

Get-Cluster $cluster_name | Get-VMHost | Select @{Label = "Host"; Expression = {$_.Name}} , @{Label = "ESX Version"; Expression = {$_.version}}, @{Label = "ESX Build" ; Expression = {$_.build}} , @{Label = "Build Match" ; Expression = {if($_.build -eq $expected_build){"Yes"} else{"No"}}} | Export-csv "cluster_host_build_info.csv"


Disconnect-VIServer -Confirm:$false

The only difference is this line

@{Label = "Build Match" ; Expression = {if($_.build -eq $expected_build){"Yes"} else{"No"}}

Where we check with an IF condition whether the ESX host’s build matches our expected build version that we defined in $expected_build variable above. It will return a “Yes” or a “No”.

In the example below $expected_build = 15169789 and the output will be similar to the screenshot

And that is it! Hope this was as useful to you as it was for me!

It makes me feel validated & boosts my ego if you share, comment if you found this useful (no pressure 😉 ). Social media links are below!

And as always, Happy scripting!

Checking Alarm status of ESXi hosts in a cluster with PowerCLI

Posted on by Sahan Fernando

In a time of increased demand in web services, its our duty as Sys Admins to ensure that everything is running smoothly. Before doing any advanced optimization, the first step is ensuring that the environment is running with the correct configurations in place. To this end I dug through to the deepest bits of PowerCLI in the internet and made quite a big script that checks all settings and outputs a report. I will be breaking apart that script piece by piece and make a bit of a series for the benefit of the scripting community so that you won’t have dig as deep as I did 🙂

As the first part of the Configuration Health check series, let’s take a look at how we can check whether vCenter alarms are enabled on a ESXi host. Not only that lets see how we can get a report of which ESXi hosts have alarms disabled on each cluster. (So that you can go ahead and enable them like a good Admin 😉 )

One-Liner

First up we will check how we can check the alarm status of a single ESXi host. Its this same line that we will be expanding to get a report in a cluster. As is any PowerCLI/Powershell information hunt, it is digging up where this information is encapsulated in is the challenge

Get-VMHost <host_name> | $_.extensiondata.AlarmActionsEnabled

Here the One-Liner will return a $True or $False value where $True means Alarms are enabled and $False means that Alarms are disabled.

You can use the following one-liner to get a list of VMs with alarms disabled in the entire vCenter (with cluster name) and export as CSV

Get-VMHost | Where-Object {$_.extensiondata.AlarmActionsEnabled -eq $false} | Select @{N='Host';E={$_.Name}},@{N='Cluster';E={Get-Cluster -VMHost $_.Name}} | Export-Csv 'hosts_with_alarms_disabled.csv'

Let’s see how we can expand this to obtain a comprehensive report on all clusters of your vCenter

Comprehensive Cluster report

$host_alarm_report = @()
$clusters = Get-Cluster

ForEach($cluster in $clusters){
    $details = @()
    $alrm_status = $cluster | Get-VMHost | Where-Object {$_.extensiondata.AlarmActionsEnabled -eq $false} | Select Name

    if($null -ne $alrm_status){
        $alrm_status = $alrm_status.Name -join ","
        
        Write-Host "$cluster Following hosts do not have Alarms Enabled $alrm_status "

    }

    else{
        $alrm_status = "Alarms Enabled on all hosts"
        Write-Host "$cluster $alarm_action_status"
    }

    $details = @{
		Cluster = $cluster.name
		Alarms_disabled_hosts = $alrm_status

	} 

	$host_alarm_report += New-Object PSObject -Property $details | Select Cluster,Alarms_disabled_hosts

}

$host_alarm_report | Export-Csv "vcenter_host_alarm_report.csv"

The above script will give a csv report of all hosts in all clusters whose alarms are disabled. Hosts will be in one row separated by a comma (this is where the -join “,” part came in and will be categorized by Cluster which is why I believe its a more meaningful and comprehensive report even though its a larger script.

And that is it!

It makes me feel validated if you share, comment if you found this useful (no pressure 😉 ). Social media links are below!

And as always, Happy scripting!

Enable and Disable ESXi Host SSH with PowerCLI | VMHostService Cmdlet

Posted on by Sahan Fernando

Maybe you’re upgrading your hosts, maybe you’re trying to run a command on multiple ESXi Hosts, any which way one thing which you will have to do is enable SSH from the vCenter, and disable when you’re done – because annoying as it is, security is important! 😉 It would be especially annoying if you have to do that for dozens of ESXi hosts at a time.

So here I’ll show you guys a simple script you can run to enable and then disable SSH on multiple ESXi hosts so that you can go ahead and do your main task instead of being distracted by side quests!

Enable SSH on ESX host

$host_list = Get-Content "host_list.txt"


Connect-VIServer $vcenter 


foreach($hosts in $host_list){
	Get-VMHostService -VMHost $hosts | Where-Object {$_.Key -eq "TSM-SSH" } | Start-VMHostService -confirm:$false 
}


Disconnect-VIServer * -confirm:$false

If you’ve followed the blog you will know I like to follow the Get-Content method to get a list of things (in this case list of ESXi Hosts) from a simple text file (separated by new lines). You can follow how to use Get-Content here

The real star of the show is this guy right here:

Get-VMHostService -VMHost $hosts | Where-Object {$_.Key -eq "TSM-SSH" } | Start-VMHostService -confirm:$false

We use the Get-VMHostService cmdlet to output the list of services that is available on the ESX host. From there we pipe that list and search for “TSM-SSH” service. Once that is filtered we pipe that service over to the Start-VMHostService cmdlet which will enable SSH on the host. This usually triggers a “Are you sure?” on the shell but since we need things as automated as possible we disable that with -confirm:$false

That’s it! Simples!

Disable SSH on ESX host 

$host_list = Get-Content "host_list.txt"

Connect-VIServer $vcenter 


foreach($hosts in $host_list){
	Get-VMHostService -VMHost $hosts | Where-Object {$_.Key -eq "TSM-SSH" } | Stop-VMHostService -confirm:$false 
}


Disconnect-VIServer * -confirm:$false

This is exactly the same as above except that instead of piping the filtered SSH service to “Start-VMHostService” cmdlet, we pipe it to “Stop-VMHostService” cmdlet. Self explanatory really (works out because I’m lazy to type at this point xD)

And that is it! It makes me feel validated if you like, share, comment if you found this useful (no pressure 😉 )! Social Media Links are below

Happy Scripting!

Getting Snapshot details of Virtual Machines | Get-Snapshot Cmdlet | PowerCLI

Posted on by Sahan Fernando

Are you a vSphere Admin facing complaints of Virtual Machine slowness? Are rogue, stale and abandoned Snapshots infesting your infrastructure? Boy have I got the script for you!

Sorry about the “as seen on TV” intro, but as a vSphere admin sometimes snapshots do get out of hand. Below is a simple little one-liner using Get-Snapshot Cmdlet to get a list of all snapshots in your environment.

The One-Liner

Get-VM | Get-Snapshot | Select @{Label = "VM"; Expression = {$_.VM}}, @{Label = "Snapshot Name";Expression = {$_.Name}}, @{Label = "Created Date"; Expression = {$_.Created}} , @{Label = "Snapshot Size"; Expression = {$_.SizeGB}} | Export-Csv "snapshot_details.csv"

Script breakdown:

The one-liner will output:

  • The virtual machine which has the snapshot
  • The name of the snapshot
  • The date the snapshot was created
  • The size of the snapshot

This one is fairly simple.

Get-VM when executed alone gets the list of all VMs of the vCenter, which is then piped to (executes like a foreach loop on the next command) the Get-Snapshot Cmdlet which gets all the information of a snapshot of that particular VM (like you specified it like this – Get-Snapshot -VM vm_name)

Then we simply select what we want to output. The Get-Snapshot Cmdlet fetches the following data:

To select, simply add a @{Label = “basically the column name”; Expression = {$_.theParameterThatYouWant}} block to the SELECT statement of the one-liner. You can add as many columns like this as you want separated by commas.

And that is it. In a future post maybe I will pursue how to select snapshots that are older than x number of days and things like that. But until that day comes, hope you enjoyed this one and found it to be useful!

Leave a comment, share and follow me on Social Media! Happy Scripting!

Getting the DNS Servers associated with an ESXi Host | PowerCLI | One-Liner

Posted on by Sahan Fernando

We recently had to check for discrepancies in configurations of ESXi hosts in a datacenter. While they should be identical, we have had issues with DNS working on some hosts while some don’t. So I developed a script that outputs the DNS servers configured on every host of the entire vCenter to a CSV file. (Note: This outputs the IPs of the DNS servers)

Its a one-liner so its not difficult to execute, check it out : 

$vcenter = "vcenter_name"

Connect-VIServer $vcenter 

Get-VMHost | Select Name, @{N='DNS Server(s)';E={$_.Extensiondata.Config.Network.DnsConfig.Address -join ' , '}} | Export-Csv 'esx_dns_info.csv'

Code breakdown:

Basically what we are doing is getting the data that is hidden inside the data that is pulled by the Get-VMHost module -in this case it’s under extension data/config/Network/DNSConfig/Address – which fetches the IP’s of these servers.

Why I used the -join ‘,’ is that a single ESXi host may have multiple DNS servers configured for redundancy, but this will not be outputted properly with CSV. So what I’m doing is joining the list of IPs to a single line separated by a comma.

Then finally pipe all that data in to the Export-CSV module that will export it to a CSV file I’ve named “esx_dns_info.csv”

And that is it – simple as that. Hope that was a easy and clear guide to getting the DNS servers associated with an ESX host.

If you liked it, please share the news! Happy Scripting!

Why you as a Sys Admin might be hesitant to script!

Posted on by Sahan Fernando

Scripting is addictive, it is the tool of the lazy and the weapon of the efficient. While some like me are hooked onto scripting, most do not share this passion. In my few years in the industry, I have noticed that while most Systems Engineer’s do leverage scripts, they do not truly take to it. Some would be hesitant to develop a script, some are happy picking up some one liner from the web and being done, while some would opt not to script at all.

In this post I thought to list out some of the reasons I have seen why people don’t script and dispel some of the myths :

1) But මචං (pal) I am not a programmer

This is the most common answer I get when I ask “why don’t you make a script for it?”. While I do come from a background of Software Engineering, in my opinion System’s Engineers do the hardest part of coding – debugging someone else’s code!

If you think about it systems and datacenters today are all software based. Troubleshooting system/infrastructure errors is actually troubleshooting issues in code that someone else has made – which is the toughest thing possible!

If you are able to troubleshoot logically the issues of a code, that means you can definitely write a small piece of code that simplifies your work! It’s just a matter of mindset.

2) Not using coding elements that make life a lot easier

Scripting can get cumbersome and not save as much time as advertised if you’re not using coding elements. I’ll admit, here is where some coding background would come useful, but they are not difficult to pick up.

Here’s a little example, say you have to power down a bunch of virtual machines in your vCenter, you can do it like this: 

Get-VM VM1 | Shutdown-VMGuest
Get-VM VM2 | Shutdown-VMGuest
Get-VM VM3 | Shutdown-VMGuest

This does get the job done, but its terribly inefficient. Say this list is 100s of VMs, you would be writing 100s of lines to get this done. Would be easier to go to the vCenter and do it manually at that point! And if your application team says “Oops, sorry guys that was the wrong list of virtual machines” well all that effort is down the drain!
Here’s another, more simple way of doing the same thing : 

$vmList = "VM1", "VM2", "VM3"

ForEach ($vm in $vmList){
    Get-VM $vm | Shutdown-VMGuest
}

This is a much more efficient piece of script. If you need to edit the list of VMs all you have to do is edit that one array variable. Your script is only a few lines long and the application team can edit this as much as they want and you don’t have to sweat about it. Also now you have a ready made script that you can use whenever another request like this comes along!

3) Not making scripts for the long term

Okay, this point also directly relates to the last point. One thing we’ve all done when we get a problem we need a script for is find a script/one-liner, execute and be done. But for scripts to be truly time-saving and effective they need to be applicable in the long term. For that you have to be mindful of concepts like code extend-ability and efficiency.

Now they might sound like boring, complex terms but the concepts are really simple. When making a script, make sure that if you have to re-use it the parts you have to change are minimal and what you have to change is clear. This is where the use of variables with names that make sense and comments come in to play.
Let’s take an example about increasing the Memory of a virtual machine:

Connect-VIServer vCenter1
Get-VM VM1 | Set-VM -MemoryGB 8

This is perfectly fine and gets the job done… for this Virtual Machine.
Now take a look at this script:

#Set the parameters
$vcenter_name = "vCenter1"
$vm_name = "VM1" #for multiple VMs go as "VM1", "VM2" ...
$memory_amount = 8 

Connect-VIServer $vcenter

ForEach($vm in $vm_name){

    Get-VM $vm | Set-VM -MemoryGB $memory_amount 
}

With few lines of code added we have created a clear, extensible script that you can share with your colleagues and be a hero. We went from a script focused on a particular virtual machine to one that we can easily choose a different vCenter, have multiple VMs, and change the memory amounts easily. By using comments we have ensured that even if you dig this script up a year later, you can easily pick up what to do!

4) Uhh… I had a script for this, but I can’t find it now

Remember when you got that one problem, and you searched the web for a script/one-liner, got it done then forgot about it? Well now it has come up again and now you have to do the same thing again? Or your friend is asking for the script and now you’re the dumdum who can’t find it? Yes, we’ve all been there.

Programmers use a code repository or repo to keep the code, and you as a Sys Admin can do the same thing. It doesn’t have to be as fancy as a GitHub repo (even though it makes life easier with version controls and all), it could very well be a Google drive or even just a well organized folder in your PC! Just ensure that your scripts are stored somewhere which is easily accessible and searchable in the long term.

Your future-self will thank you for it!

In Summation

Just follow these simple tips to make your life easier with scripting:

  • Believe that you are able to script – don’t just dispel it thinking its something that only “some people” can do. All you need is a little practice.
  • Learn a few coding tips and tricks to make a more versatile script.
  • When you’re making a script keep in mind to make a script that you can dig up years later and use it easily. Think of your future-self!
  • Most importantly make sure you have saved your script somewhere that you can easily find!

And that is it! Hope you’ve enjoyed this post and feel like making more scripts that you’ll be proud of!

If you liked/hated this post, want me to share some detailed tips and tricks or elaborate more, please do hit me up in the comments, or on my social media linked below!

Thanks for reading and happy scripting!!!