Link to home
Start Free TrialLog in
Avatar of edz_pgt
edz_pgtFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Server 2016 scheduled task won't run

Scheduled task won't run unless logged in on Windows Server 2016. I've researched this for several hours and I'm getting nowhere. This is calling a VBS script which runs just fine if you either run it manually, or set the scheduled task to run only when the user is logged in.

The user is a domain admin. I also tried activating the default administrator account and it also fails in the same way when using this account, too.

I've tried calling the script via a batch file.
I've ensured that the START IN folder is specified and that it has a trailing backslash.

I've also tried calling this as C:\windows\syswow64\cscript - with a variable of the path to the vbscript, and using the syswow folder as the START IN folder.

I'm at a loss to know what to try next. There's possibly a typo somewhere along the line, but the scheduled task does run if it's set to run only when I'm logged in - I would hope that this proves the parameters to be correct.

For information, the script calls a program called Snapshot.exe and this creates a volume shadow copy vss type backup to a folder. This will eventually be a network resource but I've reconfigured it to be a local drive location temporarily so that there's no confusion over network credentials.

Any ideas please?
Avatar of McKnife
McKnife
Flag of Germany image

We schedule snapshots by drive snapshot ourselves (is it drive snapshot for you) and it works. Share your task, batch and error, please.
Avatar of edz_pgt

ASKER

Hi McKnife,

Yes, it's Drive Snaphot. We've got loads of these out there and several on servers. The possible difference here is it being Server 2016 as this is the first one we've done, as far as I'm aware.

We've got a massive script that we usually use, but I've stripped most of it out in an effort to narrow down what might be causing this issue. So, the script that I'm running as a test right now is this:

'**Start Encode**
Dim strCurrDay
strCurrDay = Day(Now)
Dim strCurrMonth
strCurrMonth = Month(Now)
Dim strCurrYear
strCurrYear = Year(Now)
Dim strHshFilename
Dim strRptFilename
Dim strSNAFilename
Dim strMessage
Dim strBckupType
Dim strOutcome
Dim strSpaceEmail
Dim strShortPathLog
Dim strShortPathBackup
Dim objFolder
Dim objRprtFile
Dim objFiles
Dim objFile
Dim strHyphenPos
Dim strDelFullFile
Dim strDelDiffFile
Dim dtOldestDate
Dim strOldestFile
Dim intCountHshFiles
Dim BackupFolderExists
set objFso = CreateObject("Scripting.FileSystemObject")
set WshShell = Wscript.CreateObject("WScript.Shell")
strShortPathLog = objFso.GetFolder("E:\Backup").ShortPath


strShortPathBackup = objFso.GetFolder("E:\Backup\Test").ShortPath
strHshFilename = strShortPathBackup & "\C-" & strCurrYear & "-" & strCurrMonth & ".hsh"
strRptFilename = strShortPathLog & "\C-" & strCurrYear & "-" & strCurrMonth & "-" & strCurrDay & "-Backup-Report.log"
strSNAFilename = strShortPathBackup & "\C-" & strCurrYear & "-" & strCurrMonth & "-" & strCurrDay & ".SNA"
Return = WshShell.Run(strShortPathLog & "\snapshot.exe -PW=m32268m6xGC239a -T -W -L4400 C: " & strSNAFilename & " --LogFile:" & strRptFilename, , True)

Open in new window


User generated image
Any help is appreciated!
Share the task, batch (whole batch) and error, please. You gave me parts of the task, parts of the batch and no error.

You could see that it just works (not DS's fault, not server 2016's fault), by using this task:
snapshot c: e:\test.sna

Open in new window

without using vbscript or any arguments/ start in drives.
Execute that as system and that's all.
Avatar of edz_pgt

ASKER

Actually, I did do this previously but in a batch file, not a vbs file. It worked no problem at all.
So, that would sugged it's something to do with the code in the vb script - but it works no problem when it's run manually.
Well, we still need the error as seen on the history tab of task scheduler, and we need the task details (executor, elevated or not...).
Avatar of edz_pgt

ASKER

OK - I've minimised the script down to this which I've tested works fine when run manually.

set objFso = CreateObject("Scripting.FileSystemObject")
set WshShell = Wscript.CreateObject("WScript.Shell")
Return = WshShell.Run("E:\Backup\snapshot.exe C: E:\backup\test\cdrive.sna")

Open in new window


The scheduled task never actually finishes, so I need to terminate it each time. The last log before termination is this:
Task Scheduler launched "{27371fdd-a3f9-4f1b-ac43-77b7f6d2967c}"  instance of task "\Snapshot2"  for user "myadminaccount" .

The task is set to run whether the user is logged in or not.
The user account is set to myadminaccount.
Run with highest priviliges is checked.
Configured for Vista/Server 2008.
Try the system account instead. If that fails, we will easily be able to diagnose that. (Please note, the system account can be used to write to network shares as well).
Avatar of edz_pgt

ASKER

Looks like its not running as system, either.
That was something I tried earlier in the process and I did have some luck with it but that was just a simple batch file command line and the network shares failed. Doesnt appear to run the vbs script though - even with a local destination.
Ok, download psexec.exe and run
psexec -s -I cmd

Open in new window

The command windows which then appears runs as system account and you can test your script visibly as system.
Avatar of edz_pgt

ASKER

Thanks McKnife.
I've downloaded that, opened an elevated command prompt, run the command you suggested, and it works just fine.

So, it seems it's not the script. It must be something to do with the scheduled task - but I just can't see it.
I'm sure this is going to be one of those 'Doh!' moments but, I'm hoping it comes sometime soon!
That was just the analysis. I'll use your task now, hang on.
Avatar of edz_pgt

ASKER

Thanks - much appreciated!
Works at once.
I'll provide the task as xml file so that you can import it:
testbackup.xml
Avatar of edz_pgt

ASKER

Many thanks - I've compared the two tasks side by side by exporting mine to XML. I've noticed a handful of differences so I'll test those out.

Can you just confirm - are you using Server 2016 please?
Yes, I can confirm that, server 2016, 1607.
Avatar of edz_pgt

ASKER

Well, I don't get it.
This task is virtually identical and still doesn't run.
(I've replaced the domain as it was to desciptive of the client that this server belongs to.)
Snapshot3.xml
Avatar of edz_pgt

ASKER

I've just noticed I'm geting some events in the event log.
I have a string of ID:513

I'll have a google.....
Ok, one more thing: I always use the 64 bit version of drive snapshot, just in case you don't.
Avatar of edz_pgt

ASKER

That's interesting - I was warned off the 64 bit version!
I might give that a try. Thanks.
Warned? Now that's interesting for me. Why were you warned? We are using the x64 version since it came out (5-10 years?) and never a problem. It offers higher performance than the x86 one, lately I compared it on the same system I got 7 GB/minute with the x86 one and 11 GB/minute using x64.
Avatar of edz_pgt

ASKER

When I was first introduced to Snapshot about 5 years ago, I assumed that I needed to 64bit and I struggled to get it to work. I just remember someone (but I can't remember who!) telling me not to use that one and to use the 32bit instead. I have absolutely no idea why!

Anyway, it didn't make any difference - it still doesn't work. It looks like I've managed to fix the error in the event log, but it's not fixed my issue.


I don't suppose it make a difference, but it's worth mentioning that this is a virtual machine. You're not aware of any reason why this would have an impact?
Avatar of edz_pgt

ASKER

For completeness, I wonder if you'd mind downloading the very latest 32-bit snapshot.exe and seeing if your scheduled task still runs with that please?
Works with 32 bit. Works with your snapshot3.xml task and inside a virtual machine. So clearly, you are doing something that you are not sharing or your system has a defect.
Avatar of edz_pgt

ASKER

Yup - I appreciate everything you've done to try and help.
I've created new scheduled tasks and I've also imported yours. Nothing appears to work.

So frustrating!
ASKER CERTIFIED SOLUTION
Avatar of McKnife
McKnife
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Ah, it's simply this:
User generated imageUNblock it and there you go.
Avatar of edz_pgt

ASKER

Interesting.
However, neither the 32 bit or the 64bit exe files have that check mark.

So, you may well be right about the splash screen type box though. You think we can supress that prompt?
Avatar of edz_pgt

ASKER

OMG! - You are an absolute star!
I was actually in the process of rebuilding a vm as a last ditch attempt to resolve this!
If it's unblocked, it's unblocked... then it's something else for you.
Did you verify if the drive snapshot process (snapshot.exe) even appears in task manager?
If it does, it could very well be that the vss mechanism does not get a lock on the drive because of a database being mounted, for example.
Aha... :-)
So what solved it?
Avatar of edz_pgt

ASKER

So, I've used psexec and run it as:
cscript vbscript.vbs
Then, un-checked that box on the UAC prompt and continued.
Crashed the Snapshot task
Started it again and it didn't offer to UAC prompt.
Crashed Snapshot again.
Started the scheduled task (as system) and it ran.

Just need to bring my original script back in again and see if I can get it working to that shared folder.

I'll come back and confirm in a bit.
Avatar of edz_pgt

ASKER

OK - so, I can run the script from psexec and it works just fine and saves to a UNC path on the network. However, running it from the scheduled task, it says it can't find the destination.

Any ideas?
Avatar of edz_pgt

ASKER

Actually - I've just discovered it now works on the admin account so the System account isn't actually necessary.
Woohoo!!
Avatar of edz_pgt

ASKER

Thanks so much, McKnife - your help was invaluable and all at a weekend, too!
You are welcome.