Categories Tutorials

Can I have your attention: Add PowerShell on-screen alerts to your scripts

Most of the time, PowerShell scripts that are designed to automate some sort of task convey the task status in one of two ways. Either the script displays a message on screen or it writes information to some sort of log file. Both of these approaches are widely used and are perfectly valid. Even so, they are not ideally suited to every situation.

Imagine for a moment that you have configured the Windows Task Scheduler to automatically run a specific PowerShell script once a week. The script’s purpose is irrelevant to this discussion, but let’s assume that the script does something important. Because the script is running automatically on a scheduled basis, writing the script’s output to the PowerShell console isn’t going to be effective. After all, there probably isn’t going to be someone looking at the screen when the script runs. That being the case, the script is most likely to write its output and any other relevant information to a log file.

Getting attention with PowerShell on-screen alerts

This approach works fine in nominal situations, but imagine what would happen if the script encountered a problem. Because the IT staff is likely to be busy with other things, they are likely to assume that the script is working just like it always has, and therefore ignore the log file. What the script really needs is a way of getting someone’s attention in real-time.

There are several different ways of accomplishing this. One option, for example, is to design the script to send email alerts whenever necessary. A simpler option, however, is to generate PowerShell on-screen alerts by using popup messages. Let me show you how it’s done.

Unfortunately, there is no native PowerShell cmdlet for generating popup messages. Several years back, Windows included a command named Net Send, which could be used to display popup messages on a user’s screen. Unfortunately, Microsoft has removed the Net Send command for whatever reason. Even so, there is an alternative command that you can use if you want to display a popup message on a networked computer. The command is called msg. Unfortunately, the msg command is designed primarily for use in Terminal Services environments, so getting it to do exactly what you want can sometimes require a bit of trial and error.

At its simplest, the msg command requires you to provide two parameters — the message recipient’s name and the message that you want to send. To show you how this works, I will send a message to myself. My username is Brien, so the command that I am using is:

Msg Brien This is a test.

You can see the command and the resulting popup message in the screenshot below.


Although this is a really simple example, it clearly illustrates the fact that even though msg.exe is not a native PowerShell cmdlet, it is possible to use it to send messages from within PowerShell. Hopefully, you are already thinking of ways in which your PowerShell scripts might benefit from this capability.

Using PowerShell variables

As previously noted, the msg command can accept several different parameters. So far I have shown you how to send a message to a specific user, but there are also parameters that can be used to direct messages to other computers or to a particular session. Regardless of which parameters you decide to use, you do not have to hard code the parameters within your script. Even though msg is not a native PowerShell cmdlet, you can use PowerShell variables to supply the various parameters. This can be immensely helpful when building complex scripts because it frees you from having to hard code messages and message recipients.

Let’s take a look at how this works by building onto my previous example. Rather than manually specifying the recipient name and the message, let’s write them to variables and then reference those variables from within the msg command. Here is what such an operation might look like:

$User = “Brien”
$Message = “This message was generated by PowerShell”
Msg $User $Message

You can see these commands and the resulting popup message in the figure below.


If you do decide to use the msg command in a PowerShell script, then there are a few additional command-line switches that you may find helpful. One such switch is /W. The /W switch forces the script to wait for user acknowledgment before continuing. Suppose for a moment that a script was designed to shut down a user’s computer. You might generate a popup message telling the user that their computer will shut down when they click OK. Regardless of what the message says, using the /W switch causes the script to pause until the user clicks OK.

Similarly, you can use the /Time switch to specify how long a message will remain displayed on a recipient’s screen. Some admins like to use the /W switch in conjunction with the /Time switch. The idea is that if the user does not click OK within a reasonable amount of time, the script will automatically continue.

Finally, it’s important to know how to send a message to a user on another computer. When you simply specify a user name as I have been doing, the msg command assumes that the user is logged onto the same machine that you are currently using. If you want to redirect a message to another system, then use the /Server: switch, followed by the computer name. Since you may not know which users are logged into which computers, you can use an asterisk in place of a user name. This will cause the message to be sent to every user on the specified system.

PowerShell on-screen alerts: Where to find full documentation

The msg command can be really handy for alerting users to impending administrative actions or for alerting admins to a condition that requires their attention. You can find the full command documentation here.

Featured image: Shutterstock

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Share
Published by
Brien Posey

Recent Posts

IFA 2019: All the top smartphone announcements and unveilings

IFA 2019, this year’s version of the annual consumer electronics trade show, did not disappoint. Is one of these smartphones…

10 mins ago

Outlook connectivity: Troubleshooting and solving common issues

IT professionals all dread getting this fevered message from employees and clients: “I’m having Outlook connectivity issues!” Here’s what you…

5 hours ago

Using tags with Azure runbook automation to control your costs

Here’s a script designed to start and stop virtual machines based on tags associated at the resource group level. It…

8 hours ago

Software-defined perimeter solutions: Why this is the future of security

Traditional VPNs are showing their age in the modern cloud-powered workplace. That’s why software-defined perimeter solutions are in your future.

3 days ago

Why you need to check your virtualization host’s NUMA configuration

Should you disallow NUMA spanning in your Hyper-V architecture? There are two sides to this story, and you’ll get both…

3 days ago

Getting started with Visual Studio Code and integrating with Azure DevOps

Coding may not be the No. 1 job duty for cloud admins, but it is often a part of the…

3 days ago