locked
OSD Successresult and abortresult RRS feed

  • Question

  • Hi all!

    Don't know if this should go in the sequencing forum or the client forum...here I go...

    Wondering if anyone been playing around with the successresult and abort result elements in OSD files. I'm having some trouble getting it to run. I'm running App-V 4.6 on RDS on Win2008R2.

    I need to run a vbs script before the application starts to check if execution is allowed based on computer names. I'm exiting my script with wscript.quit 0 or wscript.quit 1 but it seems that the app-v client doesn't care about it and go ahead and launch the application anyway or more likely I'm doing something wrong...

    This is an excerpt from my OSD file...

    <DEPENDENCY>
     <CLIENTVERSION VERSION="4.5.0.0"/>
                    <SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="FALSE" WAIT="TRUE" TIMEOUT="0" SUCCESSRESULT="0" ABORTRESULT="1">
                          <HREF>wscript.exe "\\path\script.vbs"</HREF>
                    </SCRIPT>
    </DEPENDENCY>

    the script looks like this...

    Set WshShell = WScript.CreateObject("WScript.Shell")
    clientName = WshShell.ExpandEnvironmentStrings("%computername%")

    if lcase(clientName) = "mycomputer" then
     msgbox "Not allowed on this computer",vbCritical
            wscript.quit 1
    End if
    wscript.echo "Moving on"
    wscript.quit 0

    I know the script executes properly since I get the correct msgboxes / echoes.
    If I run the script in a *.cmd file and then check %errorlevel% I will see my returncode...

    Do I miss something? Could it be that wscript.quit x doesn't return a real exit code but rather an error code? Isn't <href> supported with abortresult / successresult?

    I've mostly looked at this article...

    http://support.microsoft.com/kb/930973/en-us

    • Edited by Jonnw Thursday, March 11, 2010 3:58 PM Typo
    Thursday, March 11, 2010 3:57 PM

Answers

  • This has been confirmed as a bug!

    • Marked as answer by Jonnw Wednesday, March 24, 2010 3:45 PM
    Wednesday, March 24, 2010 3:45 PM

All replies

  • Hello,

    See this reference;
    http://www.tmurgent.com/osd_illustrated.aspx

    The returned value has to be 32-bit apparently, can't tell you what that means as I haven't scripted to much in a 64-bit environment.

    /Znack
    Thursday, March 11, 2010 4:51 PM
  • Thanks for your reply Znack. I'll test it on 32-bit tomorrow morning.

    Does anyone have any idea if the point of those tags are to acctually be able to abort the application launch? Am I barking up the wrong tree.

    Thursday, March 11, 2010 7:32 PM
  • I don't think this is related to your issue, but Microsoft will tell you that using both SUCCESSRESULT and ABORTRESULT will cause "undocumened behavior".  Meaning only use one or the other ot the results are unknown.

    In your case, the client shouldn't be confused (whereas if the script returned a "2", what should it do?), but it is a good practice to only use one or the other.
    • Proposed as answer by Asaf Magen Wednesday, September 19, 2012 8:41 AM
    • Unproposed as answer by Asaf Magen Wednesday, September 19, 2012 8:41 AM
    Thursday, March 11, 2010 11:56 PM
    Moderator
  • Hi!

    I'm leaning more towards this is a x64 issue somehow or possibly a client version issue. If I run the same script on my 4.5 client version on Win2003 x86 it runs just fine and behavs as expected. I've tried going with only abortresult or only successresult but it doesn't seem to matter. The logfile in verbose mode doesn't out any differences either. Tried running both wscript and cscript as *32 and by using %systemroot%\sysnative to get x64 version but no difference there either.

    I will test the 4.6 client for Win32 to see how it behaves.
    Friday, March 12, 2010 9:56 AM
  • Have tested 4.6 Win32/x86 client now. Doesn't work there either, seems both x86 and x64 4.6 client doesn't work with abortresult or successresult. Previous versions seems to work as expected but I haven't got around to test all versions.

    Time to invoke Microsoft to get their oppinion.
    Friday, March 12, 2010 11:24 AM
  • This has been confirmed as a bug!

    • Marked as answer by Jonnw Wednesday, March 24, 2010 3:45 PM
    Wednesday, March 24, 2010 3:45 PM
  • any update regarding this issue?
    Thursday, September 13, 2012 12:16 PM