Page 1 of 1 1
Topic Options
#149541 - 2005-10-08 06:40 AM Scheduled tasks running as Admin needs to "interact" with desktop
Redfoxdn Offline
Fresh Scripter

Registered: 2005-09-09
Posts: 8
Loc: Missouri
How can a Scheduled Task-ed KIX script, running as a local Admin, interact with the currently logged on user (i.e. The Desktop - who only has USER rights) on the SAME machine?

Here is my environment/problem:
I have a script that is scheduled to START 15 minutes AFTER the computer is turned on; every so often it checks to see if there is a file to copy from a specifiec UNC path (a remote PC) and It then executes a script/program to perform an action on that file.

This main script is running as user who has been give LOCAL admin rights on the current PC. Assume OS is NT4.0, W2K or XP with WMI installed.

Somehow I want to present a messagebox (or the like) to the Desktop, letting the know to close out of all application or that a particular application needs to be closed... Remember the desktop user only has User Rights (no Admin rights.)

From what I've been reading, the Scheduled Tasks, when created with WMI, has a option like that might support this, BUT then the script HAS to run as LOCALSYSTEM and cannot connect to the network - which is a REQUIREMENT for me... or is that a limitation that only applies to a full pledged service?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_scheduledjob.asp
InteractWithDesktop
Data type: boolean
Access type: Read-only

Specified job is interactive, which means that a user can give input to a scheduled job while it is executing.

I've thought of an elaborate scheme involving WMI and passing asynchronious/semi-synchronious messages back and forth between a scrip running as a user and the scheduled task, but that gets REALLy complicated very quickly...

Any other suggestions/ideas would be helpful.

I am familiar with JT.exe but that does NOT have the InteractWithDesktop option...

Also hear of schtasks.exe but it doesn't work on some OS version and I don't want to use a hacked version...

Sincerely, David.

Top
#149542 - 2005-10-08 01:31 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Use NET SEND instead of MessageBox().
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#149543 - 2005-10-08 01:49 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22334
Loc: OK
net send?
why not sendMessage() ?
_________________________
!

download KiXnet

Top
#149544 - 2005-10-08 02:04 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
or that
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#149545 - 2005-10-08 02:35 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
I have been able to get a GPO Startup script which runs in the security context of localsystem to interact with the desktop. It can also access the netlogon share but getting it to access any other share is another matter. Startup scripts will timeout so cannot stay in memory forever.

Why does your task have to connect to a network share? You could have a central admin script push whatever files the task needs to the local disk.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#149546 - 2005-10-09 05:11 AM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Redfoxdn Offline
Fresh Scripter

Registered: 2005-09-09
Posts: 8
Loc: Missouri
The packages are "pulled" by the "Install" Agent script running on the client workstation. That's one reason why it needs NETWORK access. INI files in a central UNC share would describe what packages to pull down. The resulting LOG files would also need to be placed back to the UNC share.

I don't want to rely on the net send message for several reasons: The way it FINDS the user is using WINS (which still relies on NetBIOS - yuck), which as many of you, has LOTS of problems displaying the message to the CORRECT desktop, IF a user is logged on multiple workstations! Which could happen in our environment - Desktop user + W2K/NT 4.0 Terminal Server sessions
http://support.microsoft.com/default.aspx?scid=KB;EN-US;168893&

I also would like to be able to RECEIVE a response BACK from the user; I.e. User clicked on "Wait for 5 more minutes" type option.

POSSIBLE SOLUTION:
To avoid such a complicated messaging requirement AND remove the requirement for RECEIVING responses from users, how about if the Agent script just Notified the user to logoff BEFORE the workstation Agent starts the package installation. Then there is no way the user could be the cause of a file in use issue... Also, if the package sees that file is STILL in use, (trying to patch a running service maybe?) _IT_ could reboot right away without having to wait for the user to logoff. One problem would be if the user logs BACK on before the package install is complete... But we could just place a "one-way" prompt that "all packages are done you may now log back in" type message on the console (where the CTRL-ALT-DEL) is displayed.

I'm also thinking about using the Computer Startup Script options to install the queued packages, but I'm not sure if there is an equivalent scheduling option that works with NT 4.0 Wks.

We also have the ability to display a Message-Of-The-Day at User Logon (via login scripts), which would serve as a reminder for users to leave the PCs ON but just logout... unfortunatel that may be WAY to much for non-competent users, who end up shutting down the PCs anyway...

Any additional ideas/questions/concerns are welcome!

BTW> the concept is similar to what the "Kixtart Systems Management Server" scripts perform overall. It's just that our DOMAIN users don't have ADMIN rights on the workstations (NT4.0, W2K, XP etc.).... So that's why I have to design the delivery & deployment this way.

It would be nice to be able to use the WSUS system for CUSTOM packages as well... that WOULD solve this problem with ONE exception. This script would be able to handle Windows 95-Windows XP and beyond Operating Systems, where WSUS only supports W2K SP4 and above!

Top
#149547 - 2005-10-09 05:14 AM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Redfoxdn Offline
Fresh Scripter

Registered: 2005-09-09
Posts: 8
Loc: Missouri
What does Kix's Sendmessages rely on? WINS/NetBIOS interface? or some other Win32 API? - named pipes perhaps...?

David

Top
#149548 - 2005-10-09 10:00 AM Re: Scheduled tasks running as Admin needs to "interact" with desktop
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11571
Loc: CA
Not sure what method KiX uses, but NET SEND does support IP as well as NetBIOS.
Top
#149549 - 2005-10-09 03:20 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
I think SendMessage() uses the same APIs as NET SEND. Both can send to the computer name so there would be no problem with ambiguity.

GPOs will NOT work on NT4. Did you miss the memo on NT4 being past EOL?

NT4 TSE YUCK! You are really in the dark ages.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#149550 - 2005-10-09 04:19 PM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Sealeopard Offline
KiX Master
*****

Registered: 2001-04-25
Posts: 11162
Loc: Boston, MA, USA
Quote:


BTW> the concept is similar to what the "Kixtart Systems Management Server" scripts perform overall. It's just that our DOMAIN users don't have ADMIN rights on the workstations (NT4.0, W2K, XP etc.).... So that's why I have to design the delivery & deployment this way.




And thats what the "Kixtart Systems Management Server" was designed for. My users also didn't have local admin privileges. They were given choices to have applications installed, depending on the settings, those applications were then installed at night via the Task Scheduler and reboots were performed automatically. Giving users local admin rights is a security risk.
_________________________
There are two types of vessels, submarines and targets.

Top
#149551 - 2005-10-10 05:18 AM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Redfoxdn Offline
Fresh Scripter

Registered: 2005-09-09
Posts: 8
Loc: Missouri
In our case all workstations are turned off at night... so the overnight installs aren't possible. We haven't quiete decided WHEN exactly we want these to occur yet...

I'm not very impressed with some of the software deployment options offered by GPOs... it's like MS's Ntbackup vs. Veritas/Symantec Backup Exec, has JUST enought teaser features to get the Minimum things done but not much more...

Top
#149552 - 2005-10-10 05:18 AM Re: Scheduled tasks running as Admin needs to "interact" with desktop
Redfoxdn Offline
Fresh Scripter

Registered: 2005-09-09
Posts: 8
Loc: Missouri
I know that NT 4.0 TSE is old... we're migrating to W2003 with TSE in App mode by the end of this year, pending our Business App/DB upgrade. (That was our holdup.)

We have a few NT 4.0 Wks left, but not many... so that may make the NT4.0 compatibility a mute point.

Top
Page 1 of 1 1


Moderator:  Shawn, ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart 
Hop to:
Shout Box

Who's Online
1 registered (Bryce) and 183 anonymous users online.
Newest Members
gkustra, emnipetro, Hirze, thequeen, ameliaryan
17642 Registered Users

Generated in 0.153 seconds in which 0.079 seconds were spent on a total of 12 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org