The Best Way to Send Pop-Up Messages to All PCs on a Network in Windows 11
The problem: Microsoft removed the feature and never replaced it
If you have administered a Windows network for more than a decade, you remember net send * Server reboot in 10 minutes. One line, every machine, a pop-up nobody could miss.
That command depended on the Messenger Service, a NetBIOS-based notification system. Spammers discovered that they could blast pop-up ads at any reachable IP range, so Microsoft disabled the service by default in Windows XP SP2 and removed it entirely in Windows Vista and Server 2008. It has never come back.
What replaced it was msg.exe — and this is where most admins lose a day of their life, because msg.exe is not a replacement for net send. It is a Terminal Services utility. Its job is to message users logged into a machine, not machines across a network. In practice that means:
- It targets sessions, not hosts.
msg *means “all sessions on this computer”, not “all computers”. - Remote use requires
AllowRemoteRPCto be set to1in the registry on every target machine. - It needs administrative credentials on each target, and it fails silently on workgroups where credentials don’t match.
- There is no delivery confirmation. A message that never arrived looks identical to one that did.
- The pop-up is a blocking dialog on a single session — no history, no offline queue, no way to know who read it.
The underlying issue is architectural. Windows no longer has a general-purpose, network-wide user notification channel. Everything else you might reach for is a workaround built on top of remote execution, and remote execution is precisely what modern endpoint security is designed to stop.
Four myths that waste an afternoon
Myth 1: “msg.exe is the official net send replacement.”
Microsoft’s own documentation frames msg as a Remote Desktop Services tool. It was never designed for peer-to-peer LAN notification, and it does not behave like net send outside a Terminal Server. Every hour spent scripting around it is spent fighting the tool’s intended purpose.
Myth 2: “I can re-enable the Messenger Service.” The service does not exist in any supported Windows build. Third-party “netsend restore” utilities that claim to bring it back are re-implementations with their own agent — which means you are installing software anyway, just from a less accountable source.
Myth 3: “PsExec plus msg is good enough.”
It works in a lab. In production it requires local admin rights on every endpoint, opens SMB admin shares, and is flagged by virtually every EDR product as lateral-movement behaviour — because that is exactly what ransomware operators use it for. Building your routine alerting on a tool your security team is trying to block is a slow-motion incident ticket.
Myth 4: “We have Teams/Slack, so this is solved.” Cloud collaboration tools solve conversation, not notification. A toast can be muted, the app may not be running on a shop-floor or kiosk PC, delivery depends on an internet link, and shared-login machines have no meaningful identity. If your message is “evacuate bay 3” or “stop entering orders, the ERP is down”, a muted notification in a background app is not an acceptable delivery mechanism.
Comparing the actual options
| Approach | Works across a workgroup | Admin rights on target | Reaches all logged-in users | Delivery confirmation | Flagged by EDR | Ongoing maintenance |
|---|---|---|---|---|---|---|
msg.exe direct |
No (credential mismatch) | Yes | Only sessions on that host | No | Sometimes | Registry edit per PC |
PsExec + msg |
Partially | Yes | Per host | No | Frequently | High |
| PowerShell remoting loop | Yes, if WinRM configured | Yes | Per host | Partial (exit codes) | Sometimes | High — WinRM + host list |
| GPO logon script | Domain only | No | Only at logon | No | No | Medium; wrong timing for urgent alerts |
| Email / distribution list | Yes | No | Only if mail client open | Read receipts, unreliable | No | Low, but not real-time |
| Cloud chat (Teams/Slack) | Yes | No | Only if app running and unmuted | No | No | Low; requires internet |
| Dedicated LAN messenger | Yes | No | Yes, all running clients | Yes, typically | No | Low after deployment |
The pattern is consistent: every native method trades away either reach, reliability, or your security posture. The scripted approaches are free in licence cost and expensive in engineering time, and they degrade every time Microsoft tightens remote execution defaults.
A dedicated LAN messenger inverts the trade. Instead of an administrator remotely forcing a dialog onto a machine — which is inherently a privileged, suspicious action — a small client already running on each endpoint listens for messages over a defined port and displays them. No admin rights at delivery time, no remote code execution, no registry surgery. Tools in this category, such as Softros LAN Messenger, run peer-to-peer over the local network, so there is no server to build and no traffic leaving the LAN.
If you want to try the native route first
Give it a fair test before you buy anything. On two machines in the same subnet:
# On the target machine (elevated), enable remote RPC:
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name AllowRemoteRPC -Value 1
# From the sending machine:
msg * /server:TARGET-PC "Test message"If that fails across a workgroup, or you cannot justify enabling remote RPC fleet-wide, you have your answer.
From practice: a 60-seat manufacturing site
A metal-fabrication plant with roughly 60 Windows endpoints — 45 office PCs and 15 shop-floor terminals on shared logins — needed shift-change and line-stoppage announcements. Their historic net send script died with the Windows 10 rollout.
The interim fix was a PowerShell loop over a host list using Invoke-Command. It worked for four months. Then the security team deployed an EDR agent, the loop started generating alerts, and the host list had drifted out of date because nobody updated it when machines were reimaged.
The replacement was a client-based LAN messenger deployed silently via GPO. Three details mattered more than the feature list:
- Discovery replaced the host list. Clients find each other by broadcast, so a reimaged PC rejoins automatically. The maintenance burden that killed the script simply disappeared.
- Shop-floor terminals were included via a group. Broadcast to a named group hit all 15 terminals regardless of who was logged in.
- Delivery status ended the arguments. “I never got the message” became checkable.
Measured over the following quarter, the IT team logged zero maintenance hours on the messaging system, against roughly two hours a month previously spent patching the script and reconciling host lists. Deployment took one afternoon.
The honest caveat: this only works if the client is actually installed everywhere. If you have unmanaged BYOD machines or a fleet you cannot push software to, a broadcast messenger will not reach them, and no tool in this category will.
FAQ
Does net send work in Windows 11?
No. The command and the underlying Messenger Service were removed in Windows Vista. There is no supported way to restore them.
What is the closest built-in equivalent?
msg.exe, but only for users logged into a machine you specify, and only with AllowRemoteRPC enabled and administrative credentials on the target.
Can I broadcast to a workgroup with no domain? Not reliably with native tools — they depend on matching credentials or domain authentication. Broadcast-based LAN messengers are credential-independent and generally handle workgroups without extra configuration.
Will pop-up messages cross VLANs or subnets?
Not by default. Broadcast discovery stops at the router. You will need to configure remote broadcast addresses in the client, use ip helper-address, or move to a unicast/server model.
Do I need to open firewall ports? Yes. Any messenger needs its TCP/UDP ports allowed inbound on endpoints. Softros, for example, uses ports 19771 and 19880; push the rule via GPO rather than touching machines individually.
Is there a free option? Several exist, but most of the well-known free LAN messengers stopped receiving updates years ago, have unsigned installers, and cannot be configured across subnets. For a handful of PCs on one flat network they are fine; beyond that the maintenance cost outweighs the licence saving.
Can I send messages from a script or scheduler?
Look for command-line support before you buy. Most commercial LAN messengers expose a CLI or API so you can trigger alerts from monitoring systems — which is how you replace the original net send script rather than the original net send habit.
Posted in Technology