I have cruise control with Nant running on windows 7 machine .Builds work just fine. But I have a task for which i need to start a batch process which opens up an application window (directX based application) and perform some tasks. But this nant task fails all the time , the very first call for device getdevicecaps fails .this thing works on XP. Please help!
And yes if it helps, I am unable to add any publisher tasks to the cruise control server configuration .
This was not the answer you were looking for.
That's because Windows 7, Vista, and the 2008+ flavors basically shut down the ability to open an interactive window from a service completely. Why? Because opening up a UI and presenting it is a huge security risk -- someone with a lower amount of credentials could in many scenarios do tasks they weren't otherwise allowed to do.
AFAIK, the only way you can get around this is to rewrite the task.
Related
Like some cyber coffee applications that disables the user ability to use any other application but only the ones started inside that cyber admin application panel, I searched the Internet for some way of doing it in Delphi:
Remove the Windows Task bar;
Disable the Alt+Tab function;
Disable the Task Manager;
Be able to do/undo that changes in a configuration panel.
These needs are for keeping users from downloading viruses and making changes to Windows configuration or even play games, if it is the system administrator's preference. The own program would serve as a container for authorized applications to run inside then as if it were a MDI application. That is already working
Of course that the system manager will have the options to disable that or revert.
Is there a way to make those four configurations in run-time with Delphi XE3?
I'm not familiar with Delphi. I'm also not sure if it is possible during run-time. But you could do the following:
Write to the registry to prevent alt-tab see this.
Again write to the registry to disable Task Manager see this.
Sounds like you can disable the task bar too by the registry see this.
On your control panel have options and when they hit save, save and restart the computer.
This is provided that Delphi can write to the registry (I believe C# and C++ can). If not, you could create .reg files and execute those by calling cmd.exe with arguments. This I think will cause some pop-ups though.
Update: You may be able to load in the registry changes without a signing out by killing explorer.exe and then loading it again. This may only load parts of the updated registry though.
I'd suggest booting your hardware into Linux, and then run a Windows virtual machine that is as locked down as possible using the existing kiosk mode security settings in Windows. This VM then runs your MDI application when the VM boots. When the MDI application exists the VM reverts to a snapshot of the known good Windows configuration.
You strip down a Linux OS to include only the bare minimum components needed to host your Windows VM.
I'm assuming your MDI windows will only host applications your organization has written, not arbitrary Windows executables. Otherwise you are asking to re-write Windows itself, which will prove impossible.
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 had to delve into this because the code that worked fine on Windows 2003/XP doesn't on Windows 7. Application launched by the use of CreateProcessAsUser fails with 0xc0000142 error code. The difference between my old code and one available from MSDN at Starting an Interactive Client Process in C++ is that I didn't set up privileges and to Window Station and desktop. I've updated my code according to the example, but I would very much like to understand which change in newer Windows made running processes in interactive Window station a requirement?
At least part of the requirements derive from the change to run interactive processes in a different session from services. This was done so that applications could not run 'shatter' style attacks against privileged services. More information is available here.
This is a Windows 2003 (or later) machine that gets switched on every morning, but no one logs on until some hours later.
I want to use the time in between to run a backup script c:\script\backup.cmd
How can I start this unattended after the machine has come up?
I tried 2 registry keys, but this resulted in the script being run after a user logs on (which is too late):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
In the end I used Windows TaskScheduler, who has such an option, but I was wondering if there is another possibility?
Short answer: GPEDIT.MSC (Start, Run, GPEdit.msc)
Windows 2000 and above [1] offer a computer Startup Scripts collection in the policy editor:
Computer Settings -> Windows Settings -> Scripts (Startup/Shutdown)
There's an equivalent logon script area (i.e. after computer startup, when a user logs on) in the User configuration bit.
Longer:
GPEDIT.MSC is the Group Policy editing console, and runs against the local computer's Local Group Policy store when it's used directly, so it's useful for setting local-only parameters. When using Active Directory, a similar interface is used to edit AD Forest-hosted group policy objects (GPOs), so the same settings are available across a bunch of machines.
The computer startup scripts run in the computer context, i.e. as LocalSystem, as you noted, so they often can't access network drives which require a certain user or group membership to work. When domain-member computers access network resources, they generally (with exceptions) authenticate using their MACHINENAME$ account - which lets you set Share/NTFS permissions to allow a computer to access those resources.
A startup script is a quick and easy way of getting a process running when the machine boots.
The computer startup process will be affected by the time it takes to run the program, though, so you might want to ensure you call it with the START command from a batch file, or specifying not to wait for the executable to complete in whatever script language you use. (the key point there is: run the script asynchronously unless it's critical, or doesn't need to be run asynchronously cos it will always take no time at all. Long boots = unhappy users).
Using a Win32 Service is an alternative option - you can use the SRVANY utility from the Resource Kit to "service-ify" pretty much any executable. VS.Net 2002 and later also let you build a managed service directly.
And Task Scheduler gets much more capable as of Vista/2008, able to run scripts at startup, on idle, and/or when Event Logs are generated or certain other conditions are met: it's pretty cool! Scheduled Tasks has the possible advantage of being able to specify the user account under which the task runs, if that's important to you.
Caveat Scriptor:
http://support.microsoft.com/kb/256320
Run Startup Scripts Asynchronously:
http://msdn.microsoft.com/en-us/library/ms811602.aspx
Vista Task Scheduler (what's new):
http://technet.microsoft.com/en-us/appcompat/aa906020.aspx
[1] Windows XP, 2003, Vista/2008, Windows 7/2008R2, Windows 8/2012, Windows 8.1/2012R2, Windows 10/Windows Server 2016. Everything. But NT4 didn't!
You have already outlined a good solution:
Setup a scheduled task to run at Start Up and allow the job to run when the user isn't logged on.
You can run a script at system startup using group policy gpedit.msc
The way you aleady do this seems fine to me; however if you want an alternative approach then services get started when the machine boots so you could write a service that detects if it's a new day (to allow for reboots) and if it is then run your backup.
If I was doing this as a service I'd use TCL because I know it and like it and it has an extension twapi that allows you to run a script as a service. Other scripting languages may well have similar facilities.
There is, if you're using Active Directory. If you can isolate the computer to its own OU or use WMI filtering, you could assign a GPO which has a startup script for the computer. This would ensure that even if someone went in via safe mode and disabled the Task Scheduler, upon startup and connection to the domain, the script would run.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.