Vista - VBscript in 2008 Server Task Scheduler will not run

We have a script that we use that exports SharePoint data and then copies it
to a share on another server. This works fine on the 2003 Server we had it
on before.

If I run the script from the commmand line on the new 2008 server it works
fine. In the settings we are signed on with an admin account.

The new server we migrated to is 2008 x64.

We have another 2008 32 bit server that has a similar script and it is
working without incident.

We are not sure which is the right script executable to use. In the
System32 there is both a cscript.exe and a wscript.exe and there is also a
cscript.exe and wscript.exe in the SysWow64.

We have tried several combinations to get this t o run.

The only error we get in task scheduled is either invalid file or invalid
directory.

Since it runs from the command prompt we are wondering about why we would
get that.

If we run it using the RUN command in the 2008 scheduler it hangs.

I am hoping someone has run into this and solved it.

I'm stuck.

Here is the script (sorry its a bit long)

Dim mToday
Dim mPath
dim sTemp
dim command1
dim commandparm
dim command2
dim inline
dim i
dim oExec
dim input
dim inputData
dim cmdstring
dim Dest
dim mFirst
dim mSecond
dim emailsendto
dim emailsubject
dim emailbody
dim emailfrom
dim emailsender
dim freespace
Const HARD_DISK = 3
Const CCS_DISK = 4
Const GB = 1073741824

set objShell = CreateObject("Wscript.shell")
Set oWmg = GetObject("winmgmts:")
set objFS = CreateObject("Scripting.FileSystemObject")
if objFS.FileExists("DailyBackup.log") Then
objFS.DeleteFile("DailyBackup.log")
WScript.Sleep 1000
End If
set objLog = objFS.CreateTextFile("DailyBackup.log",8, true)



objlog.writeline(now() &vbTab& "Start: Daily Backup ")
mToday = Day(Now())

set objInput = CreateObject("Scripting.FileSystemObject")
if objInput.FileExists("ShrptBackupSettings.log") Then
set filein = objInput.OpenTextFile("c:\program files\common files\microsoft
shared\web server extensions\12\Bin\shrptbackupsettings.log", 1)
input = Split(filein.ReadAll, vbNewLine)

For each inputData in input
if Instr(1, inputData, "DESTDAILY:") Then
mleft = Instr(1, inputData, ":")
mLen = (inputData)
ServerDest = " " & Mid(inputData, mLeft +1)
mServerStart = Instr(mleft, inputdata, "\\")
if mServerStart > 0 then
mServerEnd = Instr(mServerstart + 2, inputdata, "\")
if mServerEnd > 0 then
strComputer = mid(inputdata, mserverstart +2, (mServerEnd -
(mServerStart + 2)))
if Len(strComputer) > 0 Then
REM Set objWMIService = GetObject("winmgmts:\\" & strComputer)
Set objwMIService =
GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

Set colDisks = objWMIService.ExecQuery _
("SELECT * FROM Win32_LogicalDisk WHERE DriveType = " & HARD_DISK)
For Each objDisk in colDisks
numDiskSpace = objDisk.Size
numFreeSpace = objDisk.FreeSpace
emailbody = emailbody & "Computer Name: " & strComputer & vbcrlf
emailbody = emailbody & "Disk Name: " & objDisk.name & vbcrlf
emailbody = emailbody & "Disk Size: " & Left(numDiskSpace/GB, 4) &
" GB" & vbcrlf
emailbody = emailbody & "Free Space: " & Left(numFreeSpace/GB, 4)
& " GB" & vbcrlf
emailbody = emailbody & Left((numFreeSpace / numDiskSpace) * 100,
4) & "%" & vbcrlf
emailbody = emailbody & "Percent Free: " & Left((numFreeSpace /
numDiskSpace) * 100, 4) & vbcrlf
Next
End if

End IF
End if
End if
if Instr(1, inputData, "SENDTO:") Then
mleft = Instr(1, inputData, ":")
mLen = (inputData)
emailsendto = " " & Mid(inputData, mLeft +1)
End if
if Instr(1, inputData, "SUBJECT:") Then
mleft = Instr(1, inputData, ":")
mLen = (inputData)
emailsubject = " " & Mid(inputData, mLeft +1)
End if
if Instr(1, inputData, "FROM:") Then
mleft = Instr(1, inputData, ":")
mLen = (inputData)
emailfrom = " " & Mid(inputData, mLeft +1)
End if
if Instr(1, inputData, "SENDER:") Then
mleft = Instr(1, inputData, ":")
mLen = (inputData)
emailsender = " " & Mid(inputData, mLeft +1)
End if

IF Instr(1,inputData,"SITE:") Then
mLeft = Instr(1, inputData, ":")
mLen = (inputData)
sitename = Mid(inputData, mLeft + 1)
mHttp = Instr(1, inputdata, "//")
mFirst = instr(mhttp +2, inputdata, "/")
mLen = Len(inputdata)
mSiteNamelen = (mLen - (mFirst + 1))
if mFirst > 0 then
mSecond = Instr(mFirst + 1, sitename, "/")
end If

if mSecond > 0 then
mLen = Len(inputdata - mSecond)
Dest = Right(inputdata, mLen)
else
mSiteLen = Len(mLen - mFirst)
Dest = mid(inputdata, mFirst +1, (mLen -mFirst))
End if
DestSite = Trim(Dest) & ".dat"
objlog.writeline(now() &vbTab& "Creating dailybackup for: " & sitename &
" Daily Folder: " & mToday )
command1parm = " c:\program files\common files\microsoft shared\web
server extensions\12\bin"
command1term = ", 0 , True"
cmdstring = "cmd /k stsadm -o export -url " & sitename & " -filename " &
ServerDest & mToday & "\" & DestSite & " -includeusersecurity -versions 4
-overwrite"

command1 = "cmd /k cd c:\program files\common files\microsoft shared\web
server extensions\12\bin"
objlog.writeline(now() &vbTab& command1 )

Set oExec = objShell.Exec(cmdstring)
objlog.writeline(now() &vbTab& cmdstring)
Do While Not oExec.StdOut.AtEndOfStream
strText = oExec.StdOut.ReadLine()
If Instr(1, strText, "error" ) Then
emailbody = emailbody & "Backup of :" & sitename & ":" & strText &
vbcrlf
Exit Do
End If

Loop

End if
Next
else
REM email the users
MsgBox "ShrptBackupSettings.Log not found cannot continue"
Wscript.quit

End if


objlog.writeline(now() &vbTab& command2 )

REM strWndprs = "select * from Win32_Process where name='cmd.exe'"
REM Set objQResult = oWmg.Execquery(strWndprs)

REM For Each objProcess In objQResult

REM intReturn = objProcess.Terminate(1)

REM Next



set objSendMail = CreateObject("CDO.Message")
set iConf = CreateObject("CDO.Configuration")
set Flds = iConf.Fields
Flds("http://schemas.microsoft.com/cdo/configuration/sendusing") = 1
Flds.Update
set objSendMail.Configuration = iConf

objSendMail.From = emailfrom
objSendMail.Subject = emailsubject
objSendMail.Sender = emailsender
objSendMail.To = emailsendto
objSendMail.TextBody = emailbody
objSendMail.Send


wscript.quit

Chuck, on the 64-bit server, double-check those file paths you have. On
64-bit Windows, 32-bit applications are stored in Program Files (x86)
instead of Program Files. That looks like the issue.

Although you're right to be concerned about whether you should use the 64 or
32-bit WSH host in general, for this situation it won't matter. Use the
64-bit version (which is located in System32 due to historic compatibility
issues) and make sure you're using the cscript.exe console host. If this
doesn't work, there are other issues that may need to be examined; make sure
all of the log files mentioned in the script exist in the locations
specified.

"ChuckT" <ChuckT@xxxxxx> wrote in message
news:2684BED7-BC63-49F3-90A4-D31430114246@xxxxxx

Hi Alex:

Thank you for the help.

Do you need to point directly to the Cscript.exe in 2008 x64?

In 2003 server and 2008 32 bit you can just point the task scheduler command
window to the vbs file and it runs.

In 2008 x64 do I need to point the command window in System32 and then in
the parameters insert the path and name of the vbs file?

I'll try that.

Looks like we could do this also in power shell but it might take a couple
of days to learn that tool well enough to do a script like this one.

Thanks again for the help

Chuck

"Alex K. Angelopoulos" wrote:

Anything that works in the 32-bit version works in the 64-bit version, in
general. That means that yes, pointing directly to the script should work
ok; it will probably default to the 64-bit version of the host IIRC, but
that should be ok. Like I said, I suspect the real issue is the file paths
inside the script file.

Just to confirm that the script host is running ok, you can perform a null
test for comparison. Create a script that does absolutely nothing, just has
a couple of blank lines, and schedule it. You should get no failures. If you
want to confirm it by seeing that yes, it is running, you could insert a
line into the do-nothing script like

WScript.Sleep 120000

That should tell it to sleep for 2 minutes, giving you sufficient time after
a scheduled start to check task manager and confirm that the script is
indeed running.

"ChuckT" <ChuckT@xxxxxx> wrote in message
news:BA6E9F9C-B90D-46AA-848C-2635B1430780@xxxxxx

Thanks Alex. Going back on site today and will ty that. Are you sure that
this does work on x64? Starting to wonder if this is a bug?

"Alex K. Angelopoulos" wrote:

Hi Alex:

I'm back on site and a simple script like this will NOT run:

dim mToday
wscript.sleep 1000
mToday = Day(now())
msgbox "The date value is : " & mToday
wscript.quit


Runs fine when I double click it from the file explorer and says it is
running when I click on it in TASK SCHEDULER but it does not run.

Do you have any thoughts? Is there something special about wscript and
sever 2008? Do I need a self cert or is there some security setting that
needs to be enabled that you are aware of?

Thank you for the help, I really appreciate it.

Chuck

"Alex K. Angelopoulos" wrote:

"ChuckT" <ChuckT@xxxxxx> wrote in message
news:966DC410-8715-47B6-8A4E-3A3ED27CA585@xxxxxxSince I don't have sharepoint running on an x64 system I can't use the same
script, and there _are_ a couple of known issues that you may encounter with
the scheduler - but they're not specific to x64 systems. However, on
re-reading I noticed that you said the scripts were "similar" not
"identical". So you may have indeed run into one of the other issues that
isn't x64-specific.

(1) Navigating to a WSH script and selecting it in the Task Scheduler UI is
sufficient for making it launch successfully on x64 systems, just like i32.
I make regular use of scheduled scripts on mine, and I just did a
confirmation test since I recently installed Win7 x64. Note that this
doesn't confirm anything for 2008x64, but given that the same scheduler core
is used and that there are other common sources of problems for scheduling,
I think we need to examine other possibilities first.

(2) Recheck those file locations against the script as run. In my
experience, when someone is using scripts across 32/64 and they refer to a
Program Files path by literal value, the vast majority of the time the cause
of any error is a bad path specification for x64.

(3) Check the path for the script itself; does it contain spaces? I didn't
consider this originally when I posted, but you could encounter a problem
with the explicit path used internally. I don't know if this applies, but
here's the MSKB ref:
http://support.microsoft.com/kb/951246
Because of general issues with spaces in paths, I generally use a distinct
path without spaces for all scripts, usually c:\apps\scripts - apps is my
general catchall for applications that are copied rather than installed, and
gives me an easily-checked single base path for ensuring security is
maintained.

(4) If these don't show an obvious problem, the next step in my opinion is
determining WHERE it hangs in execution. Although that's difficult to do
without a UI, you can at least have the script log messages at critical
points immediately before and after attempting to start an operation. This
will tell us where the hang occurs, at least. Here's how you can do that,
using your objShell instance and the LogEvent method:

objShell.LogEvent 1, "Beginning script execution"

and so on with appropriate messages. Events will show up in the Application
log as errors (due to the type 1), with the source shown as WSH. The most
likely vulnerable point for breakage if everything else above is ok is
likely to be the actual file copy or file deletion events.