msg.exe in Scheduled task with %time% variable not resolved

Question

_{Friday, September 28, 2018 8:23 AM}

I need to have scheduled task that pops up at certain time.

If I run from msg from logged in user command prompt

msg.exe * "Hello %username%, It is Thursday %time: =%, please restart your %computerName% any time between 4:30 - 5:30 pm today"

it works as expected, all variables resolving fine

GPO created USER scheduled task works almost OK, but %time% variable is not correctly resolved

Anybody has any idea how to get the time displaying as actual time?

Seb

All replies (23)

_{Friday, September 28, 2018 7:05 PM ✅Answered}

Then change the scheduled task to invoke cmd.exe and have it execute msg.exe using the /c switch.

In the arguments field put:

/c msg.exe * "Your message"

You may need quotes around the entire msg.exe and its parameters. You'll just have to play with it.   

_{Friday, September 28, 2018 2:24 PM}

Use "%time%" instead of "%time: =%"

The ":" is to specify a substring, but I have never seen "=" used in that manner.

Ex:  echo %date:~12,2%%date:~4,2%%date:~7,2%

_{Friday, September 28, 2018 5:19 PM}

You see, one learns all the time

A very simple way is to just replace the leading space with zero:
echo %TIME: =0%
 outputs:
09:18:53,45

No, %time% does NOT work either

In the output still it is presented as %time%

_{Friday, September 28, 2018 9:32 PM}

And that "will" work because...?

_{Monday, October 1, 2018 1:17 AM}

It will work because %time% is a dynamic variable that is provided by cmd.exe. In a command prompt run "set /?".

If Command Extensions are enabled, then there are several dynamic
environment variables that can be expanded but which don't show up in
the list of variables displayed by SET.  These variable values are
computed dynamically each time the value of the variable is expanded.
If the user explicitly defines a variable with one of these names, then
that definition will override the dynamic one described below:

%CD% - expands to the current directory string.

%DATE% - expands to current date using same format as DATE command.

%TIME% - expands to current time using same format as TIME command.

%RANDOM% - expands to a random decimal number between 0 and 32767.

%ERRORLEVEL% - expands to the current ERRORLEVEL value

%CMDEXTVERSION% - expands to the current Command Processor Extensions
    version number.

_{Monday, October 1, 2018 8:13 AM}

Thanks. That indeed work

_{Friday, October 19, 2018 5:40 PM}

Well, it almost worked...

Sadly GPO created scheduled task, created actual task by resolving the %username% & "hard coding" it into text

Which is fine for one-to-one machines, but a complet rubbish for shared machines... as for another user logged at this time is no longer that %username%

How to make it resolve at RUNTIME?

_{Saturday, October 20, 2018 4:47 PM}

I don't have msg.exe to test with but I think that this should work.

Change cmd.exe to powershell.exe. For the command use this:

$t = """Hello {0}, It is {1}, please restart your {2} any time between 4:30 - 5:30 pm today""" -f $env:username,(get-date).ToString('F'),$env:ComputerName;msg.exe * """$t"""

_{Wednesday, October 24, 2018 7:07 PM}

Thanks, msg.exe is standard Windows executable from Vista onwards

_{Wednesday, October 24, 2018 10:23 PM}

Msg.exe is not included in Windows 10 Home. 

_{Friday, November 2, 2018 9:22 PM}

But it is in install.wim ...

_{Thursday, November 8, 2018 4:53 PM}

Most odd, works fine on my test machine, does not work on another machine that is exactly the same version (OS & PS)

Anybody any idea why that could be?

_{Thursday, November 8, 2018 9:27 PM}

Different msg.exe's??? In a command prompt run "where.exe msg.exe". Then do a dir command and see if the files are different. 

Looks like the "*" should come before the /time switch. Try:  msg.exe * /time:360 """$t"""

_{Friday, November 9, 2018 11:33 AM}

Good try, but...not

Exactly the same msg.exe & location of * makes no difference to the error

So all the same, yet different behaviour!

Seb

_{Friday, November 9, 2018 12:44 PM}

It has to be the quotes. Add in "$t" so that you can see the message.

...$env:ComputerName***;$t***;msg.exe * /time...

Then copy and paste that text and run msg.exe yourself. 

_{Friday, November 9, 2018 2:05 PM}

I only updated by making the wording longer and added /time:360 parameter

If it never worked it would be at least something, but it works fine on my test machine.

_{Friday, November 9, 2018 3:10 PM}

Sorry, I changed my reply. Echo out the $t contents. 

...$env:ComputerName***;$t***;msg.exe * /time...

Run msg.exe by itself with the $t output. Try it on both the working and failing machines. 

_{Saturday, November 10, 2018 2:20 PM}

It is to do with message text LENGTH on failing machines

It needs to be < 256

But in fact I believe it can be 262

Shorten the text & it works.

I wonder why it works on my test machine, I must have made some change that I no longer remember what...!?

_{Saturday, November 10, 2018 3:18 PM}

Hmmm, this used to be a problem on older versions of Windows, but I thought that was more or less fixed.

Create a test.bat file with 1 line it:

   @echo %1

Then run:

    test.bat "Your long message"

Does the entire text show? If it's truncated then you must have a system wide problem. Have you determined the max length? Is it a "2 to the Nth" number? Ie: 512, 1024, 2048....

Is Windows 32 or 64 bit?

Is msg.exe a 32 bit program? Open a 32 bit command prompt (c:\windows\SysWOW64\cmd.exe) and try the bat file there. 

Sorry, I'm kind of guessing at this point... 

_{Saturday, November 10, 2018 3:42 PM}

More thoughts.... Try removing the quotes from the message..

   msg * /time:3600 This is a long message

Msg accepts stdin. In the Powershell script try:

  $t |msg * /time:3600 

_{Thursday, November 15, 2018 7:45 PM}

I just settled on shorter text of the message. Works perfectly fine, thanks

removal of quotes made no difference

_{Friday, November 16, 2018 1:51 AM}

Hi,

Thanks for your update and rely.

If you have any questions or requirements, please feel free to contact us.

Thanks again for your understanding and support.

Best Regards,

Otto Wang

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Monday, November 19, 2018 6:07 PM}

And WHY are you replying? You were not in this conversation so ....... off

Seb