Custom Detection Script Debugging RRS feed


All replies

  • Hi

    Please download the UAG tracing symbols, as well as a document explaining UAG tracing, from here:

    In order for you to trace the custom detection script running on the client machine, enable in Trace.hta on the client machine tracing for the DETECTOR_BASE component.


    Thursday, May 20, 2010 6:17 PM
  • Thanks for the component name. I've got all that working now. Should the name of my custom detection script, i.e. script.vbs, show up in the trace?
    Thursday, May 20, 2010 6:37 PM
  • Hi,

      The script name along with any outputs that you have added should show up in that log.  If they aren't make sure the following is true:

    You are acccessing IAG/UAG from a Windows system

    Your custom detection file eg. "filename.vbs" is placed in the \von\InternalSite\Scripts\CustomUpdate folder

    The [TrunkName] file is in the \von\InternalSite\Inc\CustomUpdate folder and contains the following code pointing to the custom file:

     g_scriptList("/InternalSite/CustomUpdate/filename.vbs") = false

    Make sure that the [TrunkName] is replaced with an exact match with the name of the trunk that you want to use this script on, for example if my trunk was named portal2 the file would be named

    Dan Herzog
    Microsoft CSS IAG/UAG Support

    Friday, May 21, 2010 12:41 AM
  • I had missed the path for the script file and had put it in the wrong folder. Now when I run tracing on the client, I see my custom script listed in the trace file. Unfortunately it's listed with and error.

    [1]18d0.18b4 05/21/2010-08:18:54.335 [detectionengine CDetector::FetchBody Detector.cpp@1759] Info:HttpSendRequest done.
    [1]18d0.18b4 05/21/2010-08:18:54.335 [detectionengine CDetector::FetchBody Detector.cpp@1799] Info:HttpQueryInfo returned status code: 404.
    [1]18d0.18b4 05/21/2010-08:18:54.335 [detectionengine Detector.cpp@1811] Exiting from CDetector::FetchBody FetchBody: completed with status: 0.
    [1]18d0.18b4 05/21/2010-08:18:54.335 [detectionengine CDetector::FetchBodies Detector.cpp@1499] ERROR:<NULL>, /InternalSite/CustomUpdate/ComputerCertificate.vbs
    [1]18d0.18b4 05/21/2010-08:18:54.335 [detectionengine Detector.cpp@1505] Exiting from CDetector::FetchBodies results: 0
    [1]18d0.18b4 05/21/2010-08:18:54.506 [detectionengine Detector.cpp@202] Entering CDetector::FinalRelease

    Since I don't see any debugs from the actual script, I assume this means that the script isn't being run on the client. What else can I do to troubleshoot this?

    Friday, May 21, 2010 1:30 PM
  • It could be that you have a syntax error in your VBS script, or that the script exits on some run-time error.

    If the latter, you can add an On Error Resume Next statement at the very start of the script, which will cause script execution to continue with the statement following the one that caused the error.

    But I'm more inclined to believe that the issue is a VBS syntax error, and these are not that easy to spot. You can start cutting off parts of the script, making it as simple as you can, and see if it runs. If it does, then start adding back, little by little, pieces of code into it, checking that it still runs after every addition.


    Saturday, May 22, 2010 11:16 PM
  • Thanks.

    I figured I could start by basically making the script into a "Hello World" type script. If the only line in it is:

    Whale.DebugEcho "Hello world!"

    should it run and just output that in the trace file?

    Perhaps the better question is where can I find information about writing a detection script that includes references to available functions and proper syntax?

    Monday, May 24, 2010 1:16 PM
  • Yes, such a script should run and you should see its output in the trace file.

    As for a sample script, you could take a look at UAG's default detection script named Detection.vbs and located in the ...\von\InternalSite folder. Or maybe you can get some information from this thread:


    Monday, May 24, 2010 2:21 PM
  • I figured out the reason I was seeing the error in the log file. I had the wrong path in my inc file. I've fixed that and I no longer get that error. However, the script still does not seem to be running. I don't see it listed anywhere in the log file now. Here is my current configuration:

    I've written a script called "helloworld.vbs" and placed it in the von\InternalSite\scripts\CustomUpdate folder. The script contains just the following line:


    Whale.DebugEcho "Hello world"


    I've created a file named "" and put it in the von\InternalSite\inc\CustomUpdate folder. (There is a trunk named "Portal" under HTTPS connections). This file contains the following:


    g_ScriptList("/InternalSite/scripts/CustomUpdate/helloworld.vbs") = false


    I've created the following entry in the URL list under the URL Set tab in the Advanced Trunk Configuration:

    Name: InternalRule_CustomDetection
    Action: Accept
    URL: /internalsite/scripts/customupdate/[a-z0-9]+\.vbs
    Parameters: Reject
    Methods: GET

    When I trace the login of a user, I see the /InternalSite/Detection.vbs script referenced, but no instance of my helloworld.vbs script.

    Any ideas?

    Friday, May 28, 2010 7:18 PM
  • Hi,

    Actually you have a mistake in the name of the rule you added to the URL rule set: the rule name should start with InternalSite_ not InternalRule_ . You can take a look at the UAG Web Monitor and you will probably see a Security Violation entry about the request for InternalSite/scripts/CustomUpdate/helloworld.vbs being blocked.

    But wait, don’t go changing the rule set just yet!

    I assume you probably followed the instructions I gave to S.Kwan on that other Forum thread I mentioned before, but I was a bit wrong there (although those work too) – you do not need to place your custom detection script in the InternalSite/scripts/CustomUpdate, instead place it in InternalSite/CustomUpdate folder. If you do that, then there is no need to amend the default URL rule set. Make sure though that you also change your file to correctly point to the location of your custom detection script:

    g_ScriptList("/InternalSite/CustomUpdate/helloworld.vbs") = false


    Saturday, May 29, 2010 7:20 AM
  • Great! That did the trick. Now my helloworld.vbs script runs. Since that worked, I moved on to my real goal: machine certificate detection. I changed the file to point to my (well it's not really mine, I got it from this thread: Thanks Electrofun!) certificate detection script, ComputerCertificate.vbs. The script ran and I can see the debug information in the trace file. Unfortunately it didn't detect the machine certificate. I compared the call to Whale.System.IsCertValid against Dan Herzog's information in this thread: and they appear to match up.

    My script:

    b=Whale.System.IsCertValid(eCertSystemStore_LOCAL_MACHINE,"My",tempcompname,"CA Name as shown in the Issued By field when double clicking on the machine cert ", False, bRes)

    Results from trace:

    [1]1550.197c 06/01/2010-09:21:17.586 [detectionengine System.cpp@356] Entering CSystem::IsCertValid Store Type=131072, Store Name=My, Subject=client FQDN , Issure=CA Name as shown in the Issued By field when double clicking on the machine cert
    [1]1550.197c 06/01/2010-09:21:17.592 [detectionengine System.cpp@392] Exiting from CSystem::IsCertValid . Found valid cert=0

    I have 2 questions about these results:

    1. Am I using the correct name for the CA?
    2. Does "Found valid cert=0" indicate that UAG found a match or not?
    Tuesday, June 1, 2010 2:41 PM
  • Any ideas?
    Wednesday, June 16, 2010 7:19 PM
  • Hi,

      1) Should be
      2) Cert=0 means nothing was found

    I would try this test again but this time hard code the client machine name into the call, for example would result in the following function,

    Whale.System.IsCertValid ( eCertSystemStore_LOCAL_MACHINE,"My","", "Contoso CA", False,  bRes )

    It should return the machine cert from the client system.  If not make sure that the cert is properly installed and in the "personal" store of the "Local Machine"/"Computer Account" section of the Certificate MMC.  If that still doesn't work to locate the certificate we'll need a bit more detail on the certificate and what's in the Subject or in the SAN of the machine certificate.

    Dan Herzog
    Microsoft CSS IAG/UAG Support


    Thursday, July 1, 2010 7:02 AM
  • I specified the machine name manually but the script still fails to find the certificate. I opened MMC, added the Certificates snap-in, pointed it to Computer Account and then browsed to Personal\Certificates. I have one certificate listed there. On the general tab under "Issued to:" it has my machine's FQDN (The machine name is in all caps, but in my script I used lowercase when I hard coded the name. Is it case sensitive perhaps?) and under "Issued by:" it has the name of the CA that I specified in the script. Looking at the Details tab, I see that there is no "Subject," however, there is a SAN that says, "DNS Name=" and then my machine's FQDN (with the machine name all in caps).
    Friday, July 2, 2010 1:31 PM
  • Hi,

      I don't recal if the check is case sensitive or not, but I belive it is as we are trying to find an exact match.  I would try in your hardcoded script to match the CA name case as well as the certificate name case.  If that still doesn't work we'll need to look more specifically at the cert to make sure there isn't something about the cert that's preventing the detection function from reading the certificate.

    Dan Herzog
    Microsoft CSS IAG/UAG Support

    Friday, July 2, 2010 6:32 PM
  • Try to modify the computer cert template to use/generate the Subject CN from AD. It helpded in my case where I had no Subject CN specified as well.
    Friday, July 2, 2010 10:59 PM
  • I posted an answer to this question last year.

    Have a look at this thread - scroll down to near the end. This should help you.



    Tuesday, October 12, 2010 10:07 AM