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
More PowerShell Basics articles
- Managing your users’ cached credentials with PowerShell
- Quick tip: Saving PowerShell cmdlet output to the clipboard
- Check mailbox auditing status in Exchange Online with PowerShell
- Automating Active Directory tasks with PowerShell
- Quick take: Using PowerShell split method for Azure scripts