I am using psexec to run a remote script which does some UI operations on the print objects present in the remote system. To be specific , the API used is SHInvokePrinterCommand() to invoke printer properties of a printer object.
The entire thing works fine when executed with a user logged in(and thus a visible desktop) on windows 7. But when no user is logged in , the procedure is failing to work, the API(SHInvokePrinterCommand) returns successfully but it doesn't seem to do any work. WINDOWS XP under the similar conditions, WORKS FINE.
The observation made me believe that it has something to do with the session and "Window station" architecture that varies within these operating systems.
With some coding in the remote process , I was able to establish that the remote process is started in a non-zero session (session 2) by psexec and the only window station it is attached to is "WinSta0".(I used EnumWindowStations() for that). WinSta0 is the only windows station which receives input from KeyBoard , mouse etc.
With this much observation , I fail to understand what makes the entire thing not work in case of windows 7, with no on logged in. Basically the properties page of printer is not actually getting invoked in this case.
Does the session , that psexec forms , for executing the remote process ,in some way not a "complete" session? Any way to fix this problem?
Any ideas or suggestion are most welcome.
Several things come to mind, mostly related to increased security in Windows Vista & above.
SHInvokePrinterCommand is deprecated in Vista & above.
PSExec runs the script in a service, which in Vista & above no longer have desktop access.
When there's no logged in user, HKEY_CURRENT_USER doesn't exist, and any attempts to read from it will fail.
Related
We have a windows service that gets installed and runs on users system in the background, but on some windows machine user get an error "A device or program has requested your attention" This is specific to Windows 7.
This is because when we are installing the .exe on the user machine using MSI(created with WIX), the installer job I believe runs on Session 0, and when any prompt appears the user is prompted that a program has requested attention and he gets switched to Session 0. Can we suppress messages for installer or exe running in Session 0.
Thanks.
To fix this you will have to determine what UI is shown if the user switches to Session 0, what shows it, and how to remove it.
Services run on Session 0. Before Windows Vista, they could interact with the desktop, so many did. Chances are your service is trying to show some UI. Upon detecting this, Windows is trying to help you out. Fix the service to avoid showing UI, and the message will go away.
It's plausible that this could also occur for a deferred custom action in the system context (as those are invoked by the Windows Installer service), but I've never run into this scenario. If so, the fix is the same: make that action not show any UI.
Michael's correct, but I want to expand on it a little.
The issue isn't primarily about session 0 or services. It is about anything that tries to show a UI that is not part of the interactive user's current session. The main problem is the shatter attack where (for example) something running with the system (or otherwise privileged) account shows UI to the (perhaps limited) interactive user. The window into the privileged process is a security hole. As a result, attempts by an install to run custom actions with the system account (deferred CAs) that show UI are an issue, as are services. Session 0 is really just part of the implementation that is intended to address the security issues.
So yes, address UI attempts from your services and from (primarily deferred) custom actions in the install.
My company has about 50 - 60 machines that we need to manage remotely.
They are set to automatically login but I'd like to perform the following activities:
Capture screenshot (for diagnostic purposes, if something isn't working)
Start/stop/kill processes
Start/stop/kill services
Reboot machine
This seems simple enough but I'd like to get information on the best approach for doing this. My biggest problem is capturing a screenshot "no matter what is going on". For example, if I write a Windows Service, it can't capture the desktop session screen or the login screen.
EDIT: I've prefer to make this a Windows Service so it can run even if the user isn't logged in (i.e. if a problem occurs with the auto-login) but that doesn't seem possible. Furthermore, I'd also like to capture a screen if somebody RDPs in the machine. Basically, I want to know exactly what is going on with each machine and monitor it remotely.
Remote Capture Screen Shots
Boxcutter will do this (I dont know about the login screen though, however in theory if you run it with PSExec below it should)
Start/stop/kill processes & Start/stop/kill services
PSExec, PSList, PSKill, PSService all part of SysInternals will work here
Reboot machine
run shutdown command via PSExec or run shutdown command with -m flag and the PC name you want to shutdown.
PSTools and remote shutdown do require / prefer the machines be on the same Domain as your PC and you must have admin rights to the PC's in question
Before I start, another post for something similar to this request for help is located at Running a process at the Windows 7 Welcome Screen, but the responses were not quite what I believe I am looking for, and the post is over a year old so I thought it best to start a new thread for my needs.
In Windows 7 Ultimate, I am trying to create a script or task scheduler event that will run a Windows "rundll32.exe" process with arguments at the logon, lock, and switch user screens (basically any screen that is waiting for user to log into the machine).
I have tried using the startup script controls in group policy editor as well as creating a task scheduler event, but so far I am unable to get the process to display on the logon screens.
The command line I am using does work while logged into any account at any user level via the "Run.." dialog as well as via CMD prompt, and is only creating a popup that already exists in the Windows OEM Environment.
The hardest part is this: My friend just bought a new laptop. The new laptop came with this specific feature already enabled, but I have no idea what is making it happen and do not have access to the computer to check out gpedit.msc and task scheduler for possible solutions.
There are two reasons why I need this info: 1) I want the feature to work on my own laptop, and 2) my friend would like help disabling it on his as he doesn't like it.
I have been all over Google, posted at Microsoft Answers, and also posted on the laptop manufacturer's user forums. I have found very few pages that refer to the same question as I have, but none have answers that work, and since I have seen and know that this is possible, I am compelled to continue looking.
The laptop that this is currently working on was purchased with a fresh install of Win 7 Ultimate and no manufacturer bloatware/additional software added, so we know that the feature was made to happen by whomever it was that installed the OS and configured it for sale. Therefore I am certain it is just a matter of the right task or script in Windows itself before I see the results I need and then know how to direct my friend to disable his via phone.
The specific call is "rundll32.exe van.dll,RunVAN". In task scheduler I have set this to run as "SYSTEM" and set the triggers for startup, workstation lock, and local disconnect. I have tried using full path to rundll32.exe as well as the bare command. In gpedit startup scripts I have tried full path and bare command. Neither of which for either case is making this popup show on the logon screens.
Any and all help and/or advice on this would be greatly appreciated by both myself and my friend.
dynamic display of images for the credential provider
I would greatly appreciate some help on this one! It may be a tricky one. :)
Problem
I have an VB6 application which is set up as scheduled task. It starts every time, but when executing CreateObject() it fails if a user is not logged on to computer.
I am looking for information on what could cause this. My primary suspicion is that some Windows API fails.
Key points
Behaviour confirmed on Windows 2000, 2003, 2008 and Vista.
The application executes as user X at scheduled time, executed by Windows Task Scheduler.
It executes every time. Application does start!
If user X is logged on via RDP it runs perfectly. (Note that user doesn't need to be connected, only logged on)
If user X is not logged on to computer the application fails.
Failure point
Application fails when using CreateObject() to instantiate a DCOM object which is also part of the application.
The DCOM objects declare .dll-references at startup (globally/on top of .bas-file) and run a small startup function. Failure must be during startup, possibly in one of the .dll-declarations.
Thoughts
After some Googling my initial suspicion was directed at MAPI. From what I could see MAPI required user to be logged on. The application has MAPI references. But even with all MAPI references removed it still does not work.
What is the difference if an user is logged on? Registry mapping? Environment? Explorer.exe is running.
Isn't the user logged on when application executes as the user?
What info would help?
A definitive answer would be truly great.
Any information regarding any VB6 feature/Windows API that could act differently depending on whether user is logged on or not would definitively help.
Similar experiences may lead me in the right direction.
Tips on debugging this.
The VB application possibly needs to get hold on to running services that are only running when a user is logged on.
What is the "Identity" setting of the DCOM component.
C:\WINDOWS\system32\Com\comexp.msc
C:\WINDOWS\system32\Com\comexp.msc
Component Services
My Computer
DCOM Config
The DCOM Object, right click properties
Identity tab
Set it to "This User" and set a user with the required permissions, and then run the app as your self to see if the DCOM component can still work, then try again from the scheduler.
We never found out what caused this.
Instead I made a RDP client which I put in Scheduled Tasks. It logged on a user which had the required app in startup. After some time the RDP client forcefully logged out the user (to prevent runaway apps hanging the system).
Not the perfect solution, but a solution nevertheless.
has your VB6 forms?
because when you run scheduled, it run "as a service", so it can't have forms, or if it have forms an enviroment where to show them.
I don't remember what I have used, but exists generic "run as a service" converter exe to run windowed VB6 projects.
Also perhaps you can easy convert your code to run as a VBScript, and schedule it.
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.