PowerShell for Storage and File System Management (Part 12)

If you would like to read the other parts in this article series please go to:

There is no denying that this has been a really long, and tedious article series, but this is the final part. Throughout this series, I have shown you how to build a script that detects various types of storage health problems, and then sends an E-mail alert in the event that a problem was detected. The funny thing is that even though I have spent a year writing this particular series (one part each month), I never even got to the point of talking about file system level diagnostics. That may be another topic for another series. For right now though, we’ve got work to do. My goal in this article is to show you how to automate the script that we have created.

So why automate the script? Well, having a script that can perform storage health checks is great, but the script is really only practical if it can be run automatically. Otherwise, it will be up to the administrator to remember to run it. In the grand scheme of things, administrators would likely view this as a low priority task that is likely to be overlooked. Once automated however, the script runs by itself without administrative intervention. The administrator is involved only when a problem is discovered.

So with that said, let’s get to work. To the best of my knowledge, there is no such thing as a PowerShell level mechanism for scheduling scripts to run at a predetermined time. However, Windows Task Manager will get the job done nicely. Windows Task Scheduler has been a part of the Windows operating system for many years. There’s just one problem… Windows Task Scheduler was never designed to run PowerShell scripts.

From the operating system’s standpoint, launching a task from Windows Task Manager is essentially the same as launching a task from the server’s Run prompt. To see why this is an issue, try launching a PowerShell script from the Run prompt. If you simply enter the script’s name at the Run prompt, Windows launches Notepad. If you insert ./ in front of the script’s filename then Windows produces an error message saying that it couldn’t find the script. On top of these issues, there are also permissions to consider.

Thankfully, using the Windows Task Scheduler to run a PowerShell script on a scheduled basis is easier than you might expect. To begin the process, open the Server Manager and choose the Task Scheduler option from the Tools menu. When Task Scheduler opens, click on the Create Task link, found in the Actions pane. Upon doing so, Windows will display the Create Task dialog box, which you can see in Figure A.

Figure A: Windows displays the Create Task dialog box.

The first thing that you will need to do in order to create a scheduled task is to enter a name for the task into the Name field. This name can be a friendly name, as it is only used to identify the task and has nothing to do with task execution. While you are at it, it is also a good idea to enter a description of the task. You might for instance explain what the script does, and why it is being scheduled to run.

The next thing that you will need to do is to enter a set of security credentials. This step can be very straightforward (you might even be able to use the defaults), or it can be tricky. The reason why I say this is because the Windows Task Scheduler knows nothing of your PowerShell script. Windows Task Scheduler is simply asking for a set of credentials that can be used to launch the task. So with that in mind, consider how our PowerShell script works. It runs code locally (which is what the Windows Task Scheduler expects), but it also makes calls to remote systems. As such, you are going to have to make sure that your PowerShell script has all of the permissions that it needs.

If all of the remote systems queried by the script exist within the same Active Directory domain as the server on which the script will be initiated, then the process is easy. You can use a domain administrator account, as shown in the figure above, and that account should have the required permissions for each of the remote systems. If however, your script queries systems from other Active Directory forests, or servers that are not domain joined, then things become more difficult. In that sort of situation, you will need to provide Windows Task Scheduler with an account that has permission to launch the script, but you will have to revise the PowerShell script to retrieve alternate credentials that can be used to query remote systems. The good news is that doing so involves using a technique that you have already learned. When I showed you how to generate E-mail alerts, I also showed you how to write code to retrieve stored credentials.

The next step in the process is to configure a task trigger. This is a fancy way of saying that you are going to need to determine when the script should run. Simply go to the Triggers tab and click the New button. Doing so will cause Windows to display the New Trigger dialog box, which will allow you to schedule your script (there are also many other kinds of triggers). You can see what this dialog box looks like in Figure B.

Figure B: You will need to define the schedule for running your script.

The next step is to define an action. In this case, the action is the running of the script. To do so, go to the Actions tab and click the New button. This will cause Windows to display the New Action dialog box. Make sure that the Action is set to Start a Program.

Now, we have to figure out how to launch a PowerShell script. As previously mentioned, simply entering the script name doesn’t work. Rather than entering the script name, enter PowerShell.exe as the program name. You can then enter the –File switch, followed by your path and filename in the Add Arguments field. You can see what this looks like in Figure C.

Figure C: You can specify the PowerShell script as an argument.

If you want to test your scheduled task, or make edits to it, you can locate the task in the console tree’s Task Scheduled Library. The task will be listed using the name that you assigned.


We have now created a script that checks disk health, generates alerts when necessary, and runs automatically. Incidentally, scheduled PowerShell scripts usually close automatically after being run. If you would like to keep the results on screen, then you can use PowerShell’s –NoExit switch. You can retrieve the full syntax for PowerShell.exe by entering powershell.exe /? at the command prompt.

If you would like to read the other parts in this article series please go to:

About The Author

2 thoughts on “PowerShell for Storage and File System Management (Part 12)”

  1. This is my 2nd day into learning Power shell as an Apprentice Network Engineer, and this series of pages has made power shell make sense to me more so than ever before, to the point i’m looking forward to implementing this within my company. Really well written, I was glued to every article.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top