(Read Post 1: Introduction, Post 2: Useful Cmdlets, Post 3: Organizing Your Code, Post 4: Authoring Cmdlets and Working with REST APIs )
In this week’s installment of Windows Administration with PowerShell, we will be discussing a common administrative task that can be automated with PowerShell. This example will be used as a medium to introduce you to the WMI interface, as well as Automox Custom Policies. Like the RESTful APIs discussed in last weeks post, WMI is another foundational component that PowerShell uses to automate various tasks. So, what exactly is WMI?
Windows Management Instrumentation (WMI)
Microsoft actually has a pretty clear and concise definition of WMI:
“Windows Management Instrumentation (WMI) is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components.”
Essentially, this means you can use WMI to gather a variety of information from your endpoints. Anything from disk usage metrics to information on installed programs is available, all of which can be accessed by PowerShell. WMI separates this information into classes to provide various interfaces for working with data specific to your project. Some examples include:
- Win32_OperatingSystem
- Win32_LogicalDisk
- Win32_Product
How does this help us automate administrative tasks? Well, you can use any of this information as trigger points for performing specific tasks.
Real World Scenario #3: Clearing Temporary Files
Temporary files can grow out of control pretty quickly and are generally something that users do not actively clean up. These files can take up precious storage space on your system drive and are generally the first files that are deleted when trying to save space. Why not automate this process?
Evaluation
The first step in this process is determining a trigger point for automation. In this scenario, we only want temp files to be cleaned up when disk space is running low. You can retrieve disk usage information using the ‘Win32_LogicalDisk’ WMI class as seen below:
In many configurations, there may be more than one hard drive installed. In this scenario, we want to only monitor the system drive and filter the data returned by that drive letter. It is tempting to just filter by the C: drive because it is generally the default system drive, however, keep in mind that not all environments contain default configurations. Luckily, there is another WMI class that can be used to determine what the currently configured system drive is. Using the data returned, we can retrieve only the system drive as shown below:
Now that we have the system drive info, we can determine how much free space is left. You will notice the FreeSpace and Size properties returned in the above output are in byte format. There are a couple options on how to proceed:
- Option 1: Percentage based measurement
- Option 2: Free gigabyte measurement
To follow option one (percentage based measurement), execute the following:
Dividing the FreeSpace property by the Size property is the normal arithmetic operation for determining percentage. Multiplying this result by 100 moves the decimal two places to the right. You can then use [System.Math]::Round to further round the remaining decimals to the desired length. The second parameter provided is the number of decimal places you desire. If you choose option two, (free gigabyte measurement) simply divide the Freespace property by the 1GB constant in PowerShell. Then use the System.Math class again to round to the desired decimal place. To create flexibility for future use, let’s throw both of these options into a cmdlet:
The last evaluation step is to set up your condition. In our case, we want to trigger remediation whenever the free drive space is below 10 percent:
Remediation
Now that we know remediation is required, how exactly do we accomplish that? While there are default temp file locations, every environment is different and there may be additional file locations you wish to clean up. This can be accomplished by creating your own custom cmdlet to delete desired files:
The two paths already configured in the $tempFolders array are default temp file locations for Windows. You can add as many paths as you like into this array to support the needs of your environment.
Running Your Code
Now that you have both evaluation and remediation cmdlets, the next step is to schedule your code to run periodically. Windows provides a native solution for this called Task Scheduler. However, if you are managing more than one endpoint you will need to be able to deploy your solution to all of them. There are ways to do this remotely, assuming you are in an enterprise environment, but these have proved to be cumbersome. Alternatively, you can use an Automox Custom Policy.
Automox Custom Policies
Automox Custom Policies can help you accomplish a variety of administrative tasks across your environment from a central location. In this example, we can paste the code we have already developed directly into the console by making a few minor tweaks:
Notice that the code has been split up into the respective Evaluation and Remediation sections. For the evaluation script, we need to return 1 or 0 to indicate whether or not remediation is required. As you can see from the screenshot above, 1 indicates non-compliance and 0 indicates compliance. If 1 is returned, the remediation code will be executed on the respective endpoint. It’s important to note that we need to invoke the cmdlet we created in the Remediation code. Otherwise, when it is sent to the endpoint nothing will happen.
The last step for creating this policy is to set a custom schedule for it to run. In the screenshot below, we have configured this policy to run every Monday, Tuesday, and Friday.
Once you create a policy, don’t forget to assign it to any server groups you want it to run on!
Next Week
Next week we will continue to talk about WMI usage with PowerShell. Specifically, we will explore how to use WMI to detect the presence of an undesired application and uninstall it. We will also demonstrate how to use Automox Custom Policies to enforce this across your environment.
About Automox
Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes aperture of attack by more than 80% with just half the effort of traditional solutions.
Cloud-based and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and Linux from a single intuitive console. IT and SecOps can quickly gain control and share visibility of on-prem, remote and virtual endpoints without the need to deploy costly infrastructure.
Experience modern, cloud-based patch management today with a 15-day free trial of Automox and start recapturing more than half the time you're currently spending on managing your attack surface. Automox dramatically reduces corporate risk while raising operational efficiency to deliver best-in-class security outcomes, faster and with fewer resources.
