#207684 - 2013-09-04 10:21 PM
Messaging to the console session when running as a diff user
|
Tsguy
Getting the hang of it
Registered: 2010-01-18
Posts: 67
Loc: Oregon
|
Hello again all,
I have a software deployment that's using a combination of Kix scripts and CMD scripts. The scripts won't be executed under the user's context; they will be executed on the machines via an SMS type solution (PDQdeploy in this case).
One thing I wanted to most have in this project is a few popup messages for users telling them to leave their machines alone while the installs occur.
The Messagebox feature of kix, works in the logged in user context, so that won't work in my case.
I have found that using the following within the CMD scripts, will display a message on the user's machine regardless of what session type they are in (console / rdp)
msg * "This is a message I want to display"
I was using this rather liberally within several CMD files for software installations, and if you manually run the CMD files, or call them individually via PDQdeploy, they give the popup's I'm looking for even when running under a different user session.
But I'm now trying to use a Kix script which places RUN calls to my software installation CMD's. The CMD scripts are doing everything correctly, except for messaging. The previously displaying MSG popups (when running the CMD's manually) don't display at all or even provide any errors.
I've now tried a number of different ways to try and call out MSG.exe from both within the base Kix script as well as within the called CMD scripts, and none seem to get the results I want.
I want popup's that can appear on the console session (regardless of the user that's executing the popup call). They don't need anything other than an OK button and the message I want to provide.
I have tried the following out of kix, and so far not gotten anywhere.
shell '%compspec% /c msg.exe /server:127.0.0.1 * "this is a test message"'
DIM $MSG
$MSG = 'c:\windows\system32\msg.exe /server:127.0.0.1 * "this is a test message"'
RUN $MSG
Am I barking up a wrong tree on this, is there another way to tackle this problem? I looked at sendmessage as well, but it also didn't seem to display.
thanks for any advice,
Lan
|
Top
|
|
|
|
#207685 - 2013-09-04 10:37 PM
Re: Messaging to the console session when running as a diff user
[Re: Tsguy]
|
Jochen
KiX Supporter
Registered: 2000-03-17
Posts: 6380
Loc: Stuttgart, Germany
|
Hi there .. I guess you try something what is intrinsic in KiXtart
MessageBox( )
Action:
Displays a standard dialog box in Windows.
Syntax:
MESSAGEBOX ("message", "title", style, time-out)
Parameters:
Message
The message to display in the dialog box.
Title
The title of the dialog box.
Style (optional)
Optional numeric expression that is the sum of values specifying the number
and type of buttons to display, the icon style to use, the identity of the
default button, and the modality. The following table illustrates the values
used and the meaning of each group of values.
Buttons to display
Value
Meaning
0
Display OK button only.
1
Display OK and Cancel buttons.
2
Display Abort, Retry, and Ignore buttons.
3
Display Yes, No, and Cancel buttons.
4
Display Yes and No buttons.
5
Display Retry and Cancel buttons.
Icon to display
Value
Meaning
16
Stop symbol
32
Question mark
48
Exclamation mark
64
Information symbol
Default button
Value
Meaning
0
First button is default.
256
Second button is default.
512
Third button is default.
Modality
Value
Meaning
0
Application-modal. The user must respond to the message box
before continuing work in the application.
4096
System-modal. All applications are suspended until the user responds
to the message box.
When adding numbers to create a final value for the argument type,
use only one number from each group. If style is omitted, a default value
of 0 is assumed.
Time-out (optional)
Optional numeric expression representing the number of seconds after which
to close the dialog box.
Note: The time-out feature only works if the MESSAGEBOX dialog box is the
active window for the duration of the time-out. If the user switches away
from KiXtart and activates another application, the MESSAGEBOX dialog box
is not closed.
Remarks:
MESSAGEBOX displays a maximum of 1024 characters in application-modal
dialog boxes. Longer messages are truncated after the 1024th character.
Message strings longer than 255 characters with no intervening spaces
are truncated after the 255th character. For system-modal dialog boxes,
the number of characters you can display depends on screen resolution
and number of lines in the message.
MESSAGEBOX breaks lines automatically at the right edge of the dialog box.
If you want to set line breaks yourself, place a linefeed (ANSI character 10)
before the first character of the text that is to begin each new line.
Returns:
The value returned by MESSAGEBOX indicates which button was selected,
as shown in the following table.
Value
Meaning
-1
User did not respond to the dialog box within the specified time-out period.
1
OK button selected.
2
Cancel button selected.
3
Abort button selected.
4
Retry button selected.
5
Ignore button selected.
6
Yes button selected.
7
No button selected.
If the dialog box contains a Cancel button, pressing ESC has the same
effect as choosing Cancel.
Example:
$Selection = MessageBox("Do you want to continue ?", "KiXtart", 36)
If $Selection = 6
? "Yes selected, continuing...."
Endif
Edited by Jochen (2013-09-04 10:40 PM) Edit Reason: broken the loooong lines
_________________________
|
Top
|
|
|
|
#207689 - 2013-09-04 11:01 PM
Re: Messaging to the console session when running as a diff user
[Re: Jochen]
|
Tsguy
Getting the hang of it
Registered: 2010-01-18
Posts: 67
Loc: Oregon
|
Yes, I have an so far no go.
I am currently testing the following within the called CMD's, and on first pass, it looks like this may be closer to what I want.
@echo off
cls
Set TempWS=%LocalAppData%\TempWS.vbs
:: Create a temporary WSHscript
Echo Set wshShell = CreateObject( "WScript.Shell" ) > %TempWS%
Echo wshShell.Popup "Software is being upgraded on your workstation." ^& vbCrLf ^& _ >> %TempWS%
Echo "Please leave your machine alone." ^& vbCrLf ^& _ >> %TempWS%
Echo "Your computer will be rebooted once this is complete.", 60, _ >> %TempWS%
Echo "IT Admins are upgrading your machine", 64 >> %TempWS%
Wscript.exe %TempWS%
Del %TempWS%
exit
Refrenced code originally from this lovely site - http://www.robvanderwoude.com/usermessages.php
Will be putting this through end to end test shortly.
Lan
|
Top
|
|
|
|
#207694 - 2013-09-05 12:08 AM
Re: Messaging to the console session when running as a diff user
[Re: Tsguy]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
Here's what's happening, right? Kix Script RUNs a CMD file, then loops waiting for a flag file to be created by the CMD file... when the CMD finishes, the Kix script continues.
Now - you need to send one or more status messages from the CMD script to the logged-in user.
The Kix and CMD file are started with elevated rights, and likely running in the "hidden desktop" context. The user can't see the output.
How is the Kix script being initiated? Does the user login process trigger this in some way?
Basically, you need some process in the User's context to display messages. If the CMD script can run something likeEcho [MESSAGE]>C:\temp\SMessage.ini
Echo HEADER=Status Message >>C:\temp\SMessage.ini
Echo BODY=Do not interrupt the installation or I will send 440 volts to your keyboard! >>C:\temp\SMessage.ini you can use a Kix script to display it. This creates an ini file every time a new message is to be displayed, and assumes that the display process can find and display messages faster than the CMD can generate them.
The Kix "monitor & report" script would be run during the login process, again started by a RUN 'KIX32.EXE MandR.Kix' from your Kix login script. On the crazy notion that you don't use Kix for login scripts, you could use a START Kix32.exe MandR.kix in your bat file.
The MandR.kix would be something like this:; do var inits, etc...
$Tag = 1
If Exist('C:\temp\InstallIsDone.flag') ; cmd script is done - exit!
$Tag = 0
EndIf
While $Tag
If Exist('C:\Temp\SMessage.ini') ; new message - display it
$Header = ReadProfileString('C:\Temp\SMessage.ini', 'MESSAGE', 'Header')
$Message = ReadProfileString('C:\Temp\SMessage.ini', 'MESSAGE', 'Body')
Del 'C:\Temp\SMessage.ini' ; delete first, then display & wait
$Rc = MessageBox($Message, $Header, 0, 10) ; display message & wait up to 10 seconds for OK
EndIf
If Exist('C:\temp\InstallIsDone.flag') ; cmd script is done - exit!
$Tag = 0
EndIf
Sleep 5 ; wait for new message or end of install
Loop
; installation is complete, you are free to use your computer again...
'Done!' @CRLF Basically, the CMD script is writing to a file that a Kix script in the user session can read/remove. The Kix script also looks for the presence of the flag file so it knows when to exit. It also checks for the flag file at startup so it never runs the loop after the initial installation is completed.
Glenn
PS - just basic testing was done and it worked as shown, but you should add variable declarations and other nice things..
_________________________
Actually I am a Rocket Scientist!
|
Top
|
|
|
|
#207697 - 2013-09-05 12:51 AM
Re: Messaging to the console session when running as a diff user
[Re: Glenn Barnas]
|
Tsguy
Getting the hang of it
Registered: 2010-01-18
Posts: 67
Loc: Oregon
|
Glenn,
You are right on the money with what's going on. Kix script, calling to CMD's that are trying to provide simple status messages and are completely hidden from the user.
I am one of the "crazys" who is not using kix as a login script at this point. And in this scripts case, it may end up being called during login, but I want it to execute the same whether called from login vs pushed via a deployment solution.
Just prior to seeing your post, I was able to resolve my problem with the use of Psexec.
Code added into the called CMD files:
Pushd "\\networkserver\networkshare"
psexec /accepteula -i -s msg.exe /TIME:60 * "Office 2010 is being installed to your computer, this can take a while to complete. Your computer will reboot once the upgrade is finished."
popd
Psexec defaults to executing on the local system, when flagged with -i (interactive session) and -s (system account session), it displays the MSG's I want.
I am tempted to potentially take this a step further and have psexec call to a kix script instead so that I can utilize the much more customizable messagebox features.
BTW - ty very very much for the suggestions and insight.
/peace
lan
|
Top
|
|
|
|
#207698 - 2013-09-05 01:38 AM
Re: Messaging to the console session when running as a diff user
[Re: Tsguy]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
|
Top
|
|
|
|
#207701 - 2013-09-05 06:47 AM
Re: Messaging to the console session when running as a diff user
[Re: Glenn Barnas]
|
Tsguy
Getting the hang of it
Registered: 2010-01-18
Posts: 67
Loc: Oregon
|
Just a final follow up on this, I was able to get the message boxes working the way I wanted.
The launching logic - BaseCMD - launches Kix script, which runs Install CMDs.. Install CMDs use Psexec / Kix message boxes for popup alerts to the console user throughout the installs.
Psexec is particular about wanting to work off PATH variables, or hard local paths. In my case, I went the simple route of copying my message box kix scripts to the local machine so that the PSexec calls would work.
Sample CMD:
Pushd "\\networkserver\networkshare"
Xcopy Notice.kix C:\temp /q /y
psexec /accepteula -i -s Kix32.exe "C:\temp\Notice.kix"
popd
Sample Notice.kix:
SetConsole('HIDE')
$MessageHeader = ' ***IT Administration is applying software upgrades to your computer*** '
MessageBox ("$MessageHeader"," Cool Nifty Software is being installed / upgraded... ",0,60)
exit
I have a few more tests to run before I'll say it's golden, but it's looking much better now.
Kix rox
|
Top
|
|
|
|
#209752 - 2014-12-24 12:39 AM
Re: Messaging to the console session when running as a diff user
[Re: Tsguy]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
This came to haunt me today - like a ghost of Christmas-coding past.. I have come up with a solution will work well for this install process, as well as my workstation management system's maintenance needs.
I am pushing out a procedure to do daily maintenance on various workstations, using a centralized network management tool. The procedure can invoke a process on the target system in either the currently logged-on user context or the SYSTEM context. It needs to run in the SYSTEM context to have the correct rights.
I needed to be able to A) inform the user that maintenance was starting, and B) allow the user to defer the maintenance (and any possible reboot) by 30 minutes. This implied two-way communication.
I started with the PSExec process above, but on Windows 7, the screen would flash, blink, and turn grey, followed by an ominous message that another process was attempting to communicate from the great beyond (or at least another session). Only after approving communication did the KiXtart MessageBox appear. This was not smooth, slick, and comforting to the user in any manner! If they did not allow the communication, they would not be alerted to the maintenance or reboot process and might lose work.
I needed a method to run in the user context, yet generate messages from the SYSTEM context.. what to do??
Well, in a nutshell, I created a user process that was invoked as the logged on user (run & continue method) just prior to the SYSTEM context maintenance script. For logon-based installs, the user process could be started by the login script, and would wait up to several hours for the SYSTEM process to start.
The user-context script basically needed to - Wait for a file that contained the parameters for the MessageBox function
- Determine when a new message appeared in the message file
- Sleep a reasonable amount of time when the file was present, and just a little longer between checks when it wasn't. (I used 10 and 20 seconds, which worked well and caused little impact.)
- Wait a specific amount of time for the message file to show up. Since the management system runs at noon to collect data and schedules the invasive maintenance for 7pm, I allowed the process to wait up to 8 hours for this file to appear.
The SYSTEM writes the parameters of the message to the file, then reads an INDEX value from the message file (message.ini), increments it by one and writes the value back. Writing the index value last insures that the most current message data is written before the INDEX value changes. The SYSTEM process then waits 10 seconds (for good measure) plus 20 seconds (the worst-case time it takes for the user-message process to detect a new message, plus the timeout value of the MessageBox function. So - for a 5 minute timeout (300 seconds), the delay is 330 seconds.
The user process wakes up after the 10-20 second sleep, reads the INDEX value and compares it with the previous value. If it's larger, a new message is present. It reads the message, title, status, and timeout values and pops them into a MessageBox function. The result of this function is then written to a different file (since the user probably won't have write access to the SYSTEM generated message file). I use RESPONSE.INI, with a RESPONSE section and a Value parameter.
The SYSTEM process, after sleeping, reads the response, deletes the response file, and processes the response.
There's a special value - 9999 - that when written by the SYSTEM process is used to inform the User process that it is no longer required. The user process terminates.
If the SYSTEM process needs the user process to remain, but knows it won't be needed for a while, it simply deletes the message file. The user process doubles its sleep interval from 10 to 20 seconds until the message file re-appears or the max runtime value is exceeded.
I used WKix32.exe to call the user process with the -I parameter. It works very well - there's no flash or stutter - the MessageBox simply appears. The overhead of the user process is so low that when monitoring the active processes, it never shows any utilization.
I'll be posting the code for the user process and the mechanics of calling it from the SYSTEM process in the Script Vault in the next day or so, maybe right after the Ghost of Christmas Presents makes its appearance.
Merry Christmas to all, and to all - bug free code!!
Scrooge McCoder (er.. Glenn)
_________________________
Actually I am a Rocket Scientist!
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(Allen)
and 466 anonymous users online.
|
|
|