CMD in the system tray icon


We are looking for more information on how to utilize the CMD command on the system tray icon. We looked at the documentation, but there is not much in the way of syntax instructions. Can someone offer some assistance? Thank you.

Here are some simple examples

Something more complex, this will clear the print queue. Has to be single line commands.
powershell “Stop-Service spooler -Force; $files = Get-ChildItem -Path $env:SystemRoot\System32\spool\PRINTERS -Force; $files | Remove-Item -Force; Start-Service spooler;[System.Reflection.Assembly]::LoadWithPartialName(‘System.Windows.Forms’);[System.Windows.Forms.Messagebox]::Show(‘Print queue cleared!’)”

1 Like

Have you had any luck using CMD to call a PowerShell script stored on the local PC? We are trying to do something slightly more robust than a single line.

Should be able to run it the same as I have in my example. powershell path/to/ps1, unless Syncro interferes in anyway.

It’s not powershell, and it is certainly not more robust than a single line, but I push a batch file out on every Syncro deployment that runs “shutdown /a”. (The Syncro Tray CMD entry didn’t seem to like the forward slash, IIRC.) My Syncro Tray CMD menu item runs that file to allow the user an easy way to to cancel a pending reboot if needed.

I would expect your powershell item to function similarly. It should be easy enough to test, especially now that we have policy inheritance.

Here’s a one-line/multi-line command that kills Teams, clears its cache, and restarts it. Very popular and solves 90% of the Teams issues with one click.

I don’t see any reason why you couldn’t call a local PS1 file using the same method.

powershell.exe -command "Get-Process Teams | stop-process -force; Start-Sleep -Milliseconds 1500; Remove-Item -path $env:APPDATA'\Microsoft\teams\Cache\*'; Remove-Item -path $env:APPDATA'\Microsoft\teams\blob_storage\*'; Remove-Item -path $env:APPDATA'\Microsoft\teams\databases\*'; Remove-Item -path $env:APPDATA'\Microsoft\teams\GPUcache\*'; Remove-Item -path $env:APPDATA'\Microsoft\teams\IndexedDB\*' -recurse; Remove-Item -path $env:APPDATA'\Microsoft\teams\Local Storage\*' -recurse; Remove-Item -path $env:APPDATA'\Microsoft\teams\tmp\*'; Start-Sleep -Milliseconds 1500; Start-Process -FilePath $env:LOCALAPPDATA'\Microsoft\Teams\Update.exe' -ArgumentList '-processStart Teams.exe'"

I use shutdown -r -t 0 in my menu and it works fine. I may have run into the / issue so I changed it.

It appears that dashes can be used in place of slashes, though I didn’t find any official Microsoft documentation about it in a couple of quick web searches.

I suppose that means I could update my “abort shutdown” tray option and drop the superfluous batch file from my onboarding process. If it tests as expected, I’ll be making this improvement to my current process.

1 Like

Dashes were around before slashes. I know XP were dashes and I believe after that they changed to slashes, but the dashes have always worked.

Keep in mind commands run as the user, so you can’t have it do anything admin-related if they don’t have admin permissions. If you’re wanting to run another script already existing on the machine, you can easily put that script in place by attaching it as a required file in of your regularly running scripts, then you know it will always be available.

1 Like

I actually haven’t had any Teams calls, but… Stolen!

1 Like

Actually, I think Windows had forward slashes as a holdover from DOS, where you only rarely had dash-switches. I know I had to use cd /d D: for example but cd -d D: would not work.
In fact, that is still the case today with Command Prompt and Windows 11

But Unix used / to be the directory separator. (you can still see this in Linux today) and used dashes as the switches.

At some point - commands started getting ported from Unix to Dos and vice-versa, so programs started learning to take shutdown /a or shutdown -a either one.

I think that with POSIX continuing to emerge as a common framework, and Microsoft’s increased adoption of Open-source (and it’s often posix-style practices) Microsoft has shifted over time to just defaulting to having dashes, but usually keeping backwards compatibility for slashes when possible.

Think of this like you are pasting a command something in a Run prompt.
Often this ends up meaning “any thing you could make a one-liner”

Windows-R > cleanmgr.exe - and it pops up the clean temporary files UI

switch that out for other commands like logoff.exe - and it will log the user off from that tray icon.

you may not be able to run something to run a non EXE command directly - like ifconfig or Get-Process but you may be able to use a command processor like cmd.exe /k ipconfig (/k means 'run this and remain. /c means run this and then close. see cmd /? for more details)
or powershell.exe -noprofile -command "Start-Process Outlook.exe"

On top of that, you can even do some trickier configurations, like they did above separating the multiple separate commands in PowerShell by a Semicolon.

Here is another example I whipped up.
powershell.exe -command "$procs = get-process | where {-not [string]::IsNullOrWhiteSpace($_.MainWindowTitle)}; $selectedProc = $procs | select -Property processname,MainwindowTitle,ID | Out-GridView -Title "Select a Process to terminate" -OutputMode Single; Write-Host -ForegroundColor Cyan "You selected to kill: $($selectedProc.MainWindowTitle)."; Stop-process $selectedProc.Id -Confirm -Verbose"

Spread out it would be (I made this deliberately to show off the command chaining, not the most efficient PowerShell pipeline way)

$procs = get-process | where {-not [string]::IsNullOrWhiteSpace($_.MainWindowTitle)};
$selectedProc = $procs | select -Property processname,MainwindowTitle,ID | Out-GridView -Title "Select a Process to terminate"  -OutputMode Single;
Write-Host -ForegroundColor Cyan "You selected to kill: $($selectedProc.MainWindowTitle).";
Stop-process $selectedProc.Id -Confirm -Verbose

This will find the processes they can see with Window Titles (to find visible Windows, and avoid background processes like svchost.exe or similar), show a Clickable Window to let them select a process to kill, and then confirms they wanted to kill that process, all of which could run from a user session.

1 Like

Would be quite cool if Syncro made us a sticky thread of useful (shared) tray commands/scripts. I have a handful as well.


This will only run commands as System not as the end user right? Is there any way to run CMD as the user instead of System from the tray?

Maybe using GitHub - KelvinTegelaar/RunAsUser: a PowerShell module that allows you to impersonate the currently logged on user, while running PowerShell.exe as system. but I don’t know if it would fit as a one-liner, so you’d need to have the tray item run a local script that you either create via a syncro script or add as a required file to another script so syncro will put it on the machine for you.

1 Like