I have a Powershell script that is stored on the server. I then wrapped this script into a package in SCCM. I now have a custom task sequence and I was looking into variables such as SMSRebootMessage and SMSRebootTimeout but I couldn't get it to work. The machines that I'm targeting to test this are not part of any OS upgrade. They are on Windows 7. My goal is to:
Notify user there's an available software (via Software Center notification) | This usually shows up when deploying a TS to a collection so no assistance with this step.
The user's machine then reboots with no other actions.
After reboot the script/package run at Win PE or at startup.
Kindly show steps how I can perform this.
Thank you
Related
There are some questions regarding this topic, but thought I'd ask my about my unique situation...
Background - We are attempting to execute a QTP script via Jenkins. Now, Jenkins is running on a Windows Server, on which we are having some QTP install issues (that topic is for another thread...). As a workaround, I am trying to execute a simple AOM VBScript invoking QTP on a remote client machine (running Windows XP) and execute the test on that machine...
Setup - Just for initial proof-of-concepts, a .VBS file located on a Windows 7 box (the "calling box") has the following command:
Set qtpApp = CreateObject("QuickTest.Application","WinXPMachineName")
Problem - I am getting the following error on the calling box:
ActiveX component can't create object: 'QuickTest.Application'
I have followed the instructions to set up QTP for remote execution on the Windows XP machine. Note that QTP isn't installed on the Window 7 box .
QuickTest Pro must be installed on the local machine (in your case, your Windows 7 computer) even though you'll ultimately launch QTP elsewhere. This is because Set qtApp = CreateObject("QuickTest.Application", "MyServer") summons the local installation of QTP to open. Once the local QTP is open, it should communicate with the remote server and instruct the remote server to begin the test cases.
So, yes, you will need QTP installed on the local machine. (This is not troublesome if you have concurrent aka 'floating' licenses. If you have the seat licenses, that means they are paying for each individual computer that QTP is installed on. If that's the case, I don't know what to recommend.)
An alternate method:
I've been wrestling with remotely-launching QTP test scripts, particularly by launching them through the Windows Task Scheduler (That way, you wouldn't need QTP on the local machine, only on the remote machine). Here are a few questions I've had that hopeful might blaze a trail:
How can I run a QTP test from the command line?
Remotely managing Scheduled Tasks on another computer: Access
Denied
Unable to remotely schedule tasks from the command line
I was using another automation tool than QTP but I faced the same issue.
I was told I had to have the software "QAWP" installed in both machines to be able to run it remotely, but my company was reluctant on buying a second license for just this and wanted another solution 'Cheaper one'. So:
In the test machine have a batch file that executes your tests.
Add a scheduled tasks in windows that calls your batch file.
from any other machine you can start the scheduled tasks using the command:
schtasks /run /s /tn
both launch and remote machines have to be in the same domain and logged in as the same user that you gave access in the DCOM settings
turn off firewall if possible or add qtp to the exceptions
works perfectly for me
Can anyone tell if Set qtApp = CreateObject("QuickTest.Application", "MyServer") works if working with QTP trail version?
I have QTP trail version on two Win7 64bit machine.
When I use the above code to start QTP on my remote machine form vbscript then it works.
But when i try executing it from QTP it fails.
I have the right DCOM settings and all administrative privileges on both machines and my QTP is also running as admin.
So does it only work when I have licence installed?
To add more info to whoever still looking for answer to invoke QTP/UFT in remote machines:
Using VBScript to invoke QTP/UFT tests in remote machine is old school approach. I would suggest you to use Jenkins. It has tons of advantages.
Check here for more details.
When I run the PowerSheel script manually - through a .bat file that executes it with the PowerShell interpreter - it correctly executes an SQL query and creates an Excel file and e-mails it.
If I automate it - run the .bat file that runs the PowerShell file with the interpreter through the Windows job scheduler every night - then the e-mail is sent without the file.
It is difficulty to copy the code here because I made a nice framework many functions deep with lambda-functions and all, but generally:
$ExcelWorkBook.SaveAs($Filename)
$ExcelWorkBook.Close()
$ExcelApp.Quit()
(...)
Sleep -Seconds 500
(...)
$MailMessage.Attachments.Add($Filename)
$SMTP.Send($MailMessage)
I have heard that Excel does not actually support GUI-less automation (windows task scheduler) but that actually worked for me through a different framework.
What can I do to make it work, if cannot how can I generate Excel files from PowerShell in a different way, or how can I just easily generate and e-mail reports in PowerShell?
if you are running windows 2008 or above, then the job is probably executed in session0 (read about session0 isolation at microsoft).
You have to create Desktop-Folders for session0, read more here:
http://social.msdn.microsoft.com/Forums/en/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91
Windows 2008 Server x64
Please make this folder
C:\Windows\SysWOW64\config\systemprofile\Desktop
Windows 2008 Server x86
Please make this folder
C:\Windows\System32\config\systemprofile\Desktop
Then restart machine and try again.
I got it working with GUI-less Excel automation via task scheduler and powershell, done by creating those folders.
#Dan yes I do. CSV is a really poor report format for corporate reporting, no colors, no formatting, nothing. A manager would be insulted to find that in his inbox.
#VonPryz - but manually it works! So you say debug the scheduling?
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.
I have seen references online that state that 'Scheduled Tasks' in Windows are stored in %SystemRoot%\Tasks, which I think usually equates to C:\Windows\Tasks.
However, I observe that while that folder exists on my Windows 7 system, Scheduled tasks doesn't use it.
My system appears to use, C:\Windows\System32\Tasks.
I have studied the Environment variables and there doesn't seem to be anything related to Scheduled Tasks there.
How do I discover which folder is used for Scheduled tasks?
Tasks are saved in filesystem AND registry
Tasks are stored in 3 locations: 1 file system location and 2 registry locations.
File system:
C:\Windows\System32\Tasks
Registry:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
So, you need to delete a corrupted task in these 3 locations.
I want to extend #Jan answer:
It's seems, that Task Scheduler 1.0 API uses C:\Windows\Tasks folder for create and enumerate tasks (this example), while Task Scheduler 2.0 API uses C:\Windows\System32\Tasks to create and enumerate tasks (this example).
It's also seems, that windows console utility schtasks and GUI utility taskschd.msc uses Task Scheduler 2.0 API.
P.S.
I found, that if task placed in C:\Windows\Tasks and have not set AccountInformation, then task won't be displayed in windows console and GUI schedulers. If you set AccountInformation (even "" for SYSTEM account) and set flag TASK_FLAG_RUN_ONLY_IF_LOGGED_ON - task will be displayed in all standard applications.
Solution found here
For Windows 7 and up, scheduled tasks are not run by cmd.exe, but rather by MMC (Microsoft Management Console). %SystemRoot%\Tasks should work on any other Windows version though.
There are multiple issues with the MMC however as on almost every PC in my business the ask scheduler API will not open and has somehow been corrupted. So you cannot edit, delete or otherwise modify tasks that were developed before the API decided not to run anymore. The only way we have found to fix that issue is to totally wipe away a persons profile under the C:\Users\ area and force the system to recreate the log in once the person logs back in. This seems to fix the API issue and it works again, however the tasks are often not visible anymore to that user since the tasks developed are specific to the user and not the machine in Windows 7. The other odd thing is that sometimes, although not with any frequency that can be analyzed, the tasks still run even though the API is corrupted and will not open. The cause of this issue is apparently not known but there are many "fixes" described on various websites, but the user profile deletion and adding anew seems to work every time for at least a little while. The tasks are saved as XML now in WIN 7, so if you do find them in the system32/tasks folder you can delete them, or copy them to a new drive and then import them back into task scheduler. We went with the system scheduler software from Splinterware though since we had the same corruption issue multiple times even with the fix that does not seem to be permanent.
Looks like TaskCache registry data is in ...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
... on my Windows 10 PC (i.e. add Schedule before TaskCache and TaskCache has an upper case C).
On newer versions of Windows (Windows 10 and Windows Server 2016) the tasks you create are located in C:\Windows\Tasks. They will have the extension .job
For example if you create the task "DoWork" it will create the task in
C:\Windows\Tasks\DoWork.job
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.