I need to start up Outlook via Powershell script and schedule it.
The Powershell script is able to start Outlook when its run manually from powershell command prompt.
But when the same script is run via windows task scheduler I only see the process kicking off in background while there is no running instance of Outlook in the front end.
I wanted to know why the app is not launching at the front end.
Check what user the scheduled task is running as, unless it's running as the logged in user you won't see anything.
Outlook will launch, as a background process, but as it will be running as another user (likely system) you won't see the outlook window.
Related
I created a PowerShell script to run locally on my desktop computer. It opens a program (Start-Process), takes a screenshot, and emails that screenshot via an smtp server. This script is called hourly from task scheduler.
Everything works perfectly if I am logged into my computer, but my problem is that if my computer is locked, the screenshot is of the lock screen. Is there a way to log into my local PC via PowerShell so that the screenshot is of the program that is running?
Notes about my setup: My desktop is running windows 10, I am logged in 24/7, but I lock the screen when I leave so that nobody else in the shared office can use my computer
I have a new project at work, for customer, that require me to do an OEM image creation.
The pre
The idea would be deploy OEM image, it will install, and deploy all software, and then shutdown. Once started back up it will prompt users to chose pc name, select Domain to join and regional settings.
I think i can do this by using a powershell script and wrapping it up in an msi and add it to MDT with no silent install switches (so that it prompts users to manually go through the steps)
Now my issue is how do i inject a powershell script as well as ensure that if this scipt has user input required, that it actually prompts the user to input the data (is this even possible with Wix?)
WiX is able to install files, configure Windows settings, interact with SQL Servers, and etc, but you are working with an installer file. It is not possible to receive input from the end user after a system reboot from WiX alone since you can run a PowerShell script while the system is active, but once it restarts, the process will get terminated and has to be restarted. Unless there is some way to schedule the PowerShell script in Windows such as running it from a service created in C#.
Recently we updated our systems to Office 2016. I have a scheduled task that reads information in an MS Access DB and then sends this information to a mail recipient via Outlook. All was fine until the upgrade.
The Scheduled task launches a .bat file which opens MS Access, calls a function, performs a task and then send the the information via email using outlook.
When I run the batch file manually by double clicking on it, it works as intended and sends the email. However, when I run through Task Scheduler it does not work. I know for certain that it opens the MS Access file and can read, but for some reason it fails to send the email. I have lowered all security setting to no avail.
The scheduled task runs with the highest privileges and all was fine before the upgrade.
Does anyone have any suggestions.
Outlook has security settings that will prevent an application from sending e-mail through it programmatically. It will use a popup dialog to ask for permission to send the e-mail. While I have successfully gotten rid of the popup and made Access send through Outlook while Outlook is open (both manually and as a scheduled task), it still fails when Outlook is not already open.
Your best bet, if you have the capability, is to leave Outlook open on the machine that runs the scheduled task. Otherwise you have to try to figure out what combination of policies and registry/outlook settings will make Outlook work the way you want it to.
Edit: My experience is with a windows domain/local exchange server environment.
We upgraded to Office 2016 a few weeks ago, and had been facing the same problem as you. Our batch file runs Access and triggers a macro that exports some data to a text file, and works fine when run manually. However, when run through Task Scheduler, everything seemed to run fine, but the text file was never updated. After trying for weeks with no success, I finally found the reason for the problem, and a solution.
In our case, the problem was that Access 2016 wants to be run as a foreground app. But when running as a Task Scheduler app (with the "run whether user is logged on or not" option checked), it views itself as a background app and therefore won't run. See Jim Dettman's answers here for a bit more on that: https://www.experts-exchange.com/questions/28988837/
Next, I found this post by Microsoft employee Blake Morrison where he discusses the changes in the latest version of Task Scheduler. One of his troubleshooting suggestions worked for us:
Try creating a new task, but select the Configure for: option to be
“Windows Server 2003, Windows XP, or Windows 2000” – this will create
an XP/2003 fashioned task
Unfortunately you probably have to do this as a new task - existing tasks don't seem to allow you to choose this option (it didn't show up in the dropdown menu for my existing task). So my settings for the new task are:
Running as an administrator account
"Run whether user is logged on or not" - checked
"Run with highest privileges" - checked
Configure For: Windows Server 2003, Windows XP, or Windows 2000
If I manually trigger the task, I see a command prompt open, then Access briefly opens and disappears (our macro has a Quit Access command at the end), and then the command prompt disappears. Output to our text file is written as expected. If I schedule it to run while I'm logged out of the machine, obviously I see nothing, but the text file is again written as expected, so I know it worked.
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.