I am trying to hack together an automated Icon Cache delete, and everything is working fine when I initiate the scripts manually. In PowerShell I use TaskKill to kill Explorer.exe, Sleep for 10 seconds so the icon cache DB files are no longer in use, then delete them and restart Explorer.exe with Start-Process. I am also using a VBScript to launch the PowerShell script as I want this to happen transparently to the user.
The final implementation involves running everything by way of the Run key in the Windows registry. That triggers my script that has a mechanism for running this only once, but for every user who logs on to the machine.
The problem SEEMS to be that killing Explorer.exe also kills the script that was launched via Run, so it never has a chance to write to the registry in Current User that this task has completed. Thus Explorer.exe is restarted on every single logon, which is not desirable.
Is this a known interaction between Explorer.exe and things launched via the Run key? Or might there be something else going on?
Related
I accidentally screwed up my darktable configuration, so I reloaded it from scratch. To avoid losing all my recorded changes I have done to my pictures, I wrote a powershell backup script for the darktable database. I want to launch this script from the windows task scheduler when ever I launch darktable. I have found the event id which indicates in the security log of a new process has occurred which I should be able to use to automatically launch my backup script from task scheduler. I want to add code to the script to check the services to see if darktable is actually running and only perform the backup if it is. Anyone know how I can identify this?
If I run the following command in my session...
(Get-Process -Id $pid).CloseMainWindow()
I am able to gracefully shut down a process (no modal windows or other popups arise).
If, however, the pid is in another user's session on the same machine (running RDS), the process does not close, and CloseMainWindow() returns FALSE (it returns TRUE if it's running in my own session). It also works if I run the powershell from the other user's session.
I specifically need a way to gracefully shut down the program as the program has a few important cleanup actions required to keep its database in order. So stop-process or process.kill() will not work.
After lengthy research, it does not seem possible to do this. There is, however, a solution which met at least some of my requirements.
You can create a Windows Scheduled Task which is triggered on session disconnect. This allows you to run a cleanup job as the user, rather than as the administrator, which allows programs to exit gracefully.
It has two major drawbacks....
It is called even if the user just has a minor network interruption (so you have to build a wait() function in the script to sleep for a bit and then check if it is still disconnected - not a clean solution.
It isn't called during a log-off event. For that you need to use a logoff script triggered by GPO.
Hope this helps someone in the future.
What I have: I have Windows 7 on my home PC.
What I'm trying to do: I'm trying to keep TeamViewer running at home so I can always get to my home computer. The other day it got completely messed up and would not let me connect but everything else on the PC was just fine.
Items I've looked at:
I looked at this thread and it does not seem to apply to what I need:
Is it possible to start Teamviewer, to accept connections, from commandline?
... but it does not appear to be what I'm looking for.
I have looked at this:
https://serverfault.com/questions/48600/how-can-i-automatically-restart-a-windows-service-if-it-crashes
... and to test the script at the above URL, I stopped a service on my computer and pointed the above vbs script to that service and the vbs script will not restart that service, so that's not working.
What's happening:
From time to time on my home computer, TeamViewer hangs or gets messed up in some way and I cannot connect to my home computer. The last time this happened, the TeamViewer UI was still running but there was a little red dot next to the tray icon and the id numbers and password were blank in the UI so I had to right click and kill it and restart the computer and all was OK.
What I'd like to do:
Is there a way I can run some kind of script or something that will completely kill all TeamViewer processes and services and restart it completely? I'd like to schedule this type of activity once an hour so I can be assured of pretty much always being able to get into my home computer or else just wait an hour and it should be back up and available?
I have 20 years in IT with networking background, databases, GUI development, website development, hardware and software installation but no experience in brain surgery. I've given it a good try but am now asking for some help.
Thanks.
I think that task scheduler, taskkill and batch script is your friend here.
create a batch file to stop any current team viewer process and then restart it.
crate a batch file something like:
taskkill /IM TeamViewer.exe
start "" "C:\Program Files (x86)\TeamViewer\TeamViewer.exe"
(substitute the path to TeamViewer.exe on your own machine).
Then create an hourly scheduled task to run the script using the highest privileges (using Windows Task Scheduler).
Lookup taskkill for more info on killing tasks from the command line.
Just to add that you'll have to have the PC in a associated in your teamviewer account in a group (e.g. My Computers) and use the same account to connect - otherwise the password change on restart will prevent you connecting (you won't know the new password).
I am looking for a way to run a job on a schedule and also alert the user to that running job. Specifically, I am using PowerShell to manage a computer lab scenario, and between sessions I want to refresh the environment, clean off the desktop, reset shortcuts pinned to the task bar for the next session, etc. But I want to warn anyone sitting at the machine that this is about to happen. However, my scripts that use Balloontips very successfully as regular scripts don't work as scheduled jobs. They run, and I have verified they run as the user in question, by creating a Scheduled Job that rights a text file to the user desktop. But Balloon Tips don't actually appear. Is there some secret to getting this to work, or is this a form of "interaction" that a scheduled job just can't do?
I also tried an alternative approach, launching the browser with a web page warning of the impending cleanup. That also didn't work. Suggesting some limits to what can be done as a Scheduled Job.
I would much rather go the very "integrated with the OS" route of the balloon tips, but for the life of me it seems like that just isn't an option. So, any other suggestions for providing user info by way of a scheduled job?
Since this runs in Session 0 where GUI interaction doesn't exist you must resort to some other mechanism.
You say this happens between sessions. You could show your ballon via another "notification script" that is executed from within your ScheduledJob. You have options here. For example:
Add entry to registry Run key that will self delete on run. Shows popup when user logs in (session change ? ). Entry executes posh script which parameters you could craft, i.e. (powershell -File notify.ps1 -ArgumentList "Operation bla bla..")
Add ScheduledTask that doesn't run in Session 0 (regular task). You need to do that only once. Every next time you run this job to show notification to the user from within main script via schtasks run or ScheduledTasks module depending on your system.
Add a ScheduledTask that check periodically EventLog for the input of your main script. The task would start on logon and subscribe to event log notifications. I don't like this as the script must run non-stop.
How can I prevent a user from killing powershell process which ends the action of the script. and how can I restart powershell by a piece of code to resume its action?
If the script is being run under the users account, you can't stop them from being able to kill the process.
To get around this, you could have the script run as another user (as a service, or invoking as another user) which will launch the Powershell session under their credentials, in which case only admins will be able to kill the process.
Speaking from experience here:
In our environment we run SCCM, we have several powershell scripts that open a verbose window to let the user know that something is running. This script is running as SYSTEM. The user can still close the window even if they're not a member of the administrators group.
To get around crucial scripts that can't be closed I would suggest running the script silently, so that way it runs without the user even knowing. Or, if you indeed need a GUI, use VB.NET / C# to create a form and use the form closing event to prevent the user from closing it until you're well and ready.