Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Task Server Task and Batch Variables

Created: 20 Mar 2013 | 8 comments

Is there a way to have a task server task use custom dos variables in a batch task? The example below works fine as a client task but does not work in a "Run Script on Task Server" task. %this% is empty when it should return "that".

SET This=That
ECHO %this%

Operating Systems:

Comments 8 CommentsJump to latest comment

Thomas Baird's picture

I'm guessing this isn't the real question you have - but there's something you're trying to do that isn't specified here.

First, it "seems" to me that this should work.  You may want to call support to see why it doesn't as it could be a defect... I don't know.

Second, there may be a better way to accomplish what you want.

Just a thought.  If you share what you're trying to do, maybe we can help find a work-around / another way.

Thomas Baird
Enthusiast for making things better!


Mistral's picture

True ... just tried.

Not even

echo %time%

works as Task Server Script.

Thomas Baird's picture

Looking into the limitations of task server scripts.  Thanks for sharing.

Thomas Baird
Enthusiast for making things better!


noodleNT's picture

Thanks guys.... here is what we were doing and why it became an issue.

We are starting a hardware migration and we are using PCT to move the users data and settings to the new hardware. However we have multiple sites and our IT Department is mostly in our DC office. Our Help Desk will be building new computers in our DC office for users in our remote office and we needed a way to move the data between sites. So I built a tokenized script that starts a PCT capture and saves the data to the local site's task server. We then needed a way for the restore job to "Hunt Down" where that users PCT data was saved and copy it to the local site server that the new computer is connected to. For performance sake we wanted the "Hunt and Copy" task to be a task server task since the data is really moving from one site server to another.

We worked around this issue by building a VBS Task Server script and hardcoding our taskservers into an array variable since you don't need to use the % to call a variable.


Sub sDelete_Files(FromPath, CompGuid)
 'On error resume next
 set oFolder=FSO.getfolder(FromPath)
 FOR EACH oFile IN oFolder.files
  If Instr(1,oFile.Name,CompGuid,1) THEN
                       wscript.echo "Deleting: " & oFile.Name'oFile.delete
  End IF
End Sub 
Function fCheckForFile(filePath)
    If FSO.FileExists(filePath) = False Then
       fCheckForFile = 0
  fCheckForFile = 1
 End If
End Function 

' ---------------------------Main ------------------------------------------------------------------------ 
Dim FSO    'File System Object
Dim FromPath  'Personality Upload Task Server
Dim ToPath   'Current Task Server
Dim CompGuid  'Computer GUID
Dim PersonalityEXE 'Personality .exe full file name

Dim aTaskServerArray(4)
 aTaskServerArray(0) = "\\\Personality\"
 aTaskServerArray(1) = "\\\Personality\"
 aTaskServerArray(2) = "\\\Personality\"
 aTaskServerArray(3) = "\\\Personality\"
 aTaskServerArray(4) = "\\\Personality\"

Set args = WScript.Arguments
CompGuid=Replace(ToPath, Chr(34), "")
'wscript.echo "ToPath: " & ToPath
ToPath = "\\" & ToPath & "\Personality\"

CompGuid = "%OwnerGuid%"
CompGuid=Replace(CompGuid, Chr(34), "")
PersonalityEXE = CompGuid & ".EXE"

Set FSO = CreateObject("scripting.filesystemobject")

'Does Personality capture exist on current task server?
PersonalityEXEOnCurrentTaskServer = fCheckForFile(ToPath & PersonalityEXE)
'If so, we're done. If not, find it.
IF PersonalityEXEOnCurrentTaskServer = 0 THEN
 FOR x = 0 TO ubound(aTaskServerArray)
  PersonalityEXEOnCurrentTaskServer = fCheckForFile(aTaskServerArray(x) & PersonalityEXE)
  IF PersonalityEXEOnCurrentTaskServer = 1 THEN FromPath=aTaskServerArray(x) 'When found, save the original upload path in FromPath
 IF Len(FromPath) < 2 Then Wscript.Quit(2) 'If an original upload was not detected anywhere, exit with error 2
 'wscript.echo FromPath & CompGuid & " ToPath: " & ToPath
 Call sCopy_Files(FromPath, CompGuid, ToPath)

'check for personality.exe file.
PersonalityEXEOnCurrentTaskServer = fCheckForFile(ToPath & PersonalityEXE)
IF PersonalityEXEOnCurrentTaskServer = 0 THEN
 Wscript.Quit(3) 'Exit 3 if desired file does not exist on NEW task server.
 Call sDelete_Files(FromPath, CompGuid)'Delete files from original server.

Thomas Baird's picture

Cool guys.  I know what's happening, but I don't know why yet.

echo %time% >> c:\temp\time.txt

If you put that in a server script task, you'll get "Echo is on" in the output.  Send that to a client PC, and you'll get the time.
As I wrote to the task team about this, it occurred to me the difference, because I couldn't figure out why the text file had "Echo is on" in it, instead of the time.  Yeah, the script ran.
What happened, is that %time% was interpreted as a token, and "replaced" with nothing, because there was no matching task token for that variable.  This is exactly the same format we use for task tokens, and because it's not defined as an actual token, it was stripped.  The resulting text looks like this:
echo >> c:\temp\time.txt
and guess what?  That will give you "Echo is on" as well.
So we know what's going on, just not why.  And yes, I'm asking if that's a known limitation or not.  You might want to open a case on this to track the result, but I'll try to keep up with it here too.

Thomas Baird
Enthusiast for making things better!


Mistral's picture

Yeah, that's obvious.

The questions is, why there are two different token handlings:

- Client task: unknown token -> don't touch (keep the environment variable)

- Task Server task: unknown token -> replace (with "nothing" - wreck the environment variable)

Thomas Baird's picture

Yup.  I'm asking.  Trust me.

Thomas Baird
Enthusiast for making things better!


Thomas Baird's picture

OK folks - here's the news for all watching this:  We have a defect logged, AND it is "fixed" and should be out in the V4 Rollup, which is expected in about a week.

Having said that, I'll believe it when I personally test it, but still, that's the official news, so here's hoping that in a week or so we can all sigh and feel good about these tasks.  :D

Thomas Baird
Enthusiast for making things better!