About SDCLIENT based communications

Version 8

    Verified Product Versions

    Endpoint Manager 9.6Endpoint Manager 2016.xEndpoint Manager 2017.x

    Table of Contents:


    I - Introduction:


    SDCLIENT.EXE is traditionally something that is made use of as part of downloading/installing packages - and very few folks actually actively use it themselves. There is quite a bit of capability available to SDCLIENT however which can be made use of in various ingenious ways to solve certain complicated business requirements.


    For instance - Laptop clients present a particular set of challenges in certain environments, as their usage scenario includes inconvenient things (for Ivanti EPM admins) such as "plugging in for 2 minutes to update e-mail and then disconnecting" - which is not sufficient time to run either Inventory or Vulnerability scans, for instance.


    And not everyone may have / may make use of a Ivanti EPM Cloud Service Appliance (CSA). As a result, the requirement is set to be able to have accurate reporting of a client's status in as far as possible - or at least keep track of them in some shape or form so that a modicum of reportability about "when was the last time we saw this guy" exists.


    Having a CSA would solve this particular problem, but there are many other ways in which SDCLIENT-based messaging could be useful.


    II - Overview Of A Real-world Example:


    The challenge faced with the 'roaming laptops without a CSA' is to ensure communication to the Core to have some sort of updates/tracking of messages to be able to keep track of the clients' last status as well as having a date/time-reference to do this. In essence, we would expect 4 different messages from clients, separated into 2 groups:


    INVENTORY scans:

    1 - STARTING inventory scan => Date / time

    2 - FINISHING  inventory scan => Date / time


    - and -


    1 - STARTING vulnerability scan => Date / time

    2 - FINISHED vulnerability scan => Date / time



    Possibilities may include then passing on exit/error-codes and what not - the error message is pretty customizable.


    The date/time is needed to get an idea as to:

    • When the device last connected to the network (Local Scheduler could pick this up via a DHCP IP change, for instance)
    • When the device last STARTED a scan (to deal with and track even with the "2-minute e-mail update" type of connections)
    • When the device last reported COMPLETING a scan (which is a very different thing altogether)


    We might run into situations where - say - the last attempted inventory scan started on January 14th, 2012, but the last COMPLETED inventory scan was only on March 28th, 2010. So in this way, we can at least keep track of when the devices were last on the network and when they actually last completed their relevant jobs.



    III - Client To Core Comms:


    In order to have clients send messages to the Core, we can make use of the software distribution client, which has just this functionality and customize it a little to suit our purposes. The net result is that the client-communication is easy (we use existing technology from the LANDESK Software Distribution client), minimal (the message overhead is minuscule for each message) and robust (SDCLIENT has had over a decade of refinement and stability improvements).


    The basic command-line that needs to be run looks like this:





    So a "real" example would look like so (assuming a 32-bit OS, a TASKID of 68 and a message of "Starting Inventory Scanner - 13/05/2012 08:57:34") the command line would look like so:


    "C:\Program Files\LANDESK\LDClient\sdclient.exe" /taskid=68 /msg="Starting Inventory Scanner - 13/05/2012 08:57:34"



    For a 64-bit OS, the command line would need to be altered to accommodate the correct Program Files directory like so:

    "C:\Program Files (x86)\LANDESK\LDClient\sdclient.exe" /taskid=68 /msg="Starting Inventory Scanner - 13/05/2012 08:57:34"



    A note on TASKID:

    The TASKID is not randomly picked. I will explain further below (in section V - Core Server requirements) how to create and identify the relevant TaskID's required for this. A short explanation, for now, is that the Core Server requires having a task (which has a taskid as a unique identifier) to which the client can send the message/update to. If there is no such task / a wrong taskid is used, then the message will effectively be ignored (since there's no task to update).


    A note on characters:

    Since the message is sent in an XML format, be mindful that certain characters COULD break your message. For English-speaking countries, the - ' - (single quote) is a particularly common problem to stumble over. If you stick to default characters (a-z, A-Z, 0-9) and avoid certain special characters, you should be fine. Simple upshot is - test your intended strings!


    III.A - Additional complications -- specifying Cores:


    It's possible (should it be required) to even specify the Core to which this message should be sent. The default behavior (used above) is to send the message to the Core from which the Ivanti EPM agent has been installed. Should it prove to be necessary, it is possible to specify an alternate Core Server to send a message(s) by use of the following command-line parameter:

    /core={NAME OR IP-ADDRESS}



    So, for instance, if we were to use the previous example, and wanted to send it to the Core Server IP "", then the command-line would look like so:

    "C:\Program Files\LANDESK\LDClient\sdclient.exe" /taskid=68 /msg="Starting Inventory Scanner - 13/05/2012 08:57:34" /core=




    IV - The Local Scheduler:


    There are two basic ways to generate the command line for the Local Scheduler.


    IV.1 - Option 1 for generating the Local Scheduler Task:

    The first is to use the document here - DOC-2338 - and generate the Local Scheduler command-line from the ground up. Key points here are:

    • Remember to reference/use a unique Local_Scheduler_Task_ID so that you can update the command-line easily should it be needed for your clients.
    • Be careful to test this on a disposable box first, as it's very easy to forget a time filter, etc.
    • Be careful not to configure your task in such a way that it'll never run. Think filters through carefully. The Local Scheduler runs tasks as configured, not necessarily as intended.
    • Be sure to go through your task's logic carefully. The Local Scheduler operates "as configured", not necessarily "as intended".


    IV.2 - Option 2 for generating the Local Scheduler Task:

    The second is to use the 32-bit Console GUI for this task, and create the local scheduler task and copy the relevant command-line out of the resulting script-file. To do this, the following steps should be followed. All screenshots are taken from a LANDESK Management Suite 9.0 SP3 Core Server (but the same system works in exactly the same way in LANDESK Management Suite 9.6):


    IV.2.A - Load up the Ivanti EPM Windows Console


    IV.2.B - Go to TOOLS => Distribution => Manage Scripts



    IV.2.C - Right-click on the RIGHT-HAND PANE and select "NEW LOCAL SCHEDULER SCRIPT"



    IV.2.D - Enter a sensible name for your Local Scheduler task and click the "ADD" button to commence configuring the task's options:



    IV.2.E - You are then greeted by the following screen, which permits you to configure the task as you need it.

    The task's options are split into 4 general sections:



    IV.2.F - Here is an example of a configured task, with certain choices being explained in relation to their associated color:



    IV.2.F.1 - General / Event start-up options:

        => This set of options gives "general" filters when the task should run. In this particular instance I recommend enabling "on IP change" filter, as connecting to a network forces an IP change (from to a valid IP, if nothing less).


    IV.2.F.2 - Start and other time options:

        => This set of options is all about start time and time-based filters. The start time is rarely relevant - it is just used as a "make sure you start AFTER this date/time"-option. For most local scheduler tasks (especially recurring ones), it's only significant that this shouldn't be a value that's set months in the future. This must check off as "having passed" for the task to start.



    The LANDESK Local Scheduler will ONLY start a task when *ALL* associated filters are valid.


    This is a very important detail, as it *IS* possible to set up filters in such a way that a task will never run. Remember to double-check your logic carefully - the Local Scheduler will do as it is configured by users, not necessarily "as intended".





    IV.2.F.3 - Run-filters:

        => This is useful to ensure that tasks only run when certain network conditions or machine states (i.e. "no screen saver is running" // "user must be logged in") apply in order to run the task


    IV.2.F.4 - Random delay options:

        => This permits a minimum / maximum random delay to be configured for a task. In this particular scenario, this is an undesired and thus unneeded option.


    IV.2.F.5 - Command line & Command line parameters:

        => Here one configures the actual path to the executable (be it binary, batch-file or whatever) along with (optionally) additional command line parameters for the executable.


    Important note about user context:

    Be mindful that by default, the Local Scheduler will always run a task as "LOCAL SYSTEM", which may affect certain user-context sensitive events.



    When you're done configuring the task, click the SAVE button.


    IV.2.G - You're now returned to the following screen, with your single 'command' being saved.



    You could add now additional commands (all associated with this one task), if desired, but in this case, it's better to save the task. It's easier to modify tasks individually in bite-sized chunks, in case future updates/changes may be required. Resultantly, click the "SAVE" button after reviewing the selections made.



    IV.2.H - Now that we've returned to the "MANAGE SCRIPTS" tool, right-click on your newly generated Local Scheduler script, and choose "ADVANCED EDIT".



    IV.2.I - You will be greeted with a raw-text version of the command-line as the Ivanti EPM processes would work through it.

    This is quite humanly readable (and can be easily converted into an actual command-line), all that needs to be done is to replace certain character placeholders with double-quotes. These strings are given below in a CODE-section so that Jive doesn't eat them / interpret them as formatting.



    - and -




    These are used/processed by different parts of LANDESK when sending remote command-lines. Since we're just after a command-line to run on the clients (after the LANDESK agent is installed), we can substitute these for actual "-s so that the command line can be correctly interpreted by the Windows command-line interface.


    Original command-line example:



    After throwing away the first REMEXEC command-line (which just deletes all pre-existing local Scheduler tasks with an identifier between 1001 and 2000) and replacing the "-s where appropriate (reformatted to fit the window somewhat better):



    IV.2.J - And now you're essentially done.

    We would still advise re-checking / going through the Local Scheduler command-line parameters document to make sure you understand what the task is doing / what filters are configured, and to verify that everything is indeed as it is supposed to be.


    The Local Scheduler command-line parameters can be found in this community document - DOC-2328 .


    If everything checks out, then running this command will create the local scheduler task as configured. In practical terms, you will want to run this after installing the Ivanti agent binary, essentially as a post-configuration job.


    V - Core Server-side Requirements:


    There's just a little work that needs to be done on the Core Server(s). By and large, it amounts to:

    1 - Create the needed tasks (so we have TASKID's to give to the clients)

    2 - Ensure all devices to be monitored are part of the task


    A few screenshots in the next sections will provide a visual reference. These screenshots have been taken from a LANDESK 9.0 SP3 Core - but conceptually work exactly the same for LANDESK Management Suite 9.6:


    V.1 - Creating the 'dummy' tasks:


    V.1.A - Load up the LANDESK Windows Console


    V.1.B - Go to TOOLS => Distribution => Manage Scripts



    V.1.C - Once in "Manage Scripts", enter your desired SCRIPTS-section

    Go to either "MY SCRIPTS" (if this is meant to be private for this user) or "PUBLIC SCRIPTS", if this is meant to be visible to multiple / all users, and right-click on the right-hand pane, and select "NEW CUSTOM SCRIPT".



    V.1.D - Enter a (sensible) script name in the Wizard-window that'll come up.

    This isn't requried as such, as the actual task can be renamed itself, but just makes life easier



    V.1.E - Save the script "as is", leaving it empty bar the default text we provide.

    This means you're saving a blank script that won't do anything (so - should "worst come to the worst", the Core will be sending NIL-commands to clients).



    NOTE: You could equally work with creating a dummy package/delivery method-based scheduled task, but for sake of simplicity, the script-based approach is utilized here.

    V.1.F - After saving the script in step 5, you will now be able to see the script in your "MANAGE SCRIPTS" window.




    V.1.G - Right-click on the desired/created script, and select "SCHEDULE".



    V.1.H - If it wasn't open before, the "SCHEDULED TASKS" tool will now be opened.

    You will be moved to it automatically as the active tool, with your task created as chosen.




    This is the screen where you pick up the TASKID that you'll use in the client's command line. Each scheduled task has a unique numerical identifier. You may have to scroll sideways a bit for the TASK ID to be displayed (I've cropped the different tab-sections somewhat to fit this into 1 screenshot). Make sure you use the correct TASK ID relevant to the Inventory and/or Vulnerability scanner tasks. If you get this wrong, clients will be updating incorrect / non-existing tasks' statuses.


    V.1.H - The Core is now ready to receive messages/updates from clients for the created task.




    V.2 - Ensuring all (relevant) devices are part of the tasks:

    In a "normal" scheduled task (that is, a task which gets sent from Cores to Clients to execute), we could use a straightforward LANDESK Query. Something like (in Pseudo-code) "DEVICE ID EXISTS" or "DEVICE ID EXISTS and TYPE=LAPTOP" (if this will be on a 'mixed' Core which manages other devices as well)


    However, this is not possible, because this task doesn't actually run as such, all it needs to do is "just be there". As a result, because it can't be scheduled to run, we cannot simply have an Ivanti EPM query (which would be resolved every 2 hours by default) assigned to the task. All devices need to be part of the task (that is - be manually dragged in).


    This might be simpler to do if a custom group of devices is created to cover all Laptop devices (in case this is a 'mixed' Core), so that it's easy to check "all Laptop devices" versus the number of devices in the scheduled tasks and (if needed) just drag the entire set of devices again into the tasks, adding the missing ones in the process.


    As a result, I would suggest that - unless a dedicated Core is set up purely for handling laptop clients - that a private or public device group be created (based on whether this is meant for a single user or a group of users).


    This way, you can easily compare the number of devices in the group (by opening the device group and clicking into the right-hand pane, the bottom-left section of the 32-bit Console will show the selected/total number of devices in the group), like so:

    9 _NumbersOfDevices_In_DeviceGroup.JPG


    As mentioned previously, since we're unable to use dynamic resolution/groups/queries for the scheduled task (as we only resolve those once the task is about to start / the configured query resolution interval for active tasks), it will be necessary to compare the number of devices in the custom group with the number of devices in the scheduled task(s). This number can be cleaned in one of two ways:


    Option 1 - the quick overview (a graphical representation) - this becomes visible when you select the task in "SCHEDULED TASKS":

    10_1 _NumbersOfDevices_In_Task.JPG


    Option 2 - The detailed overview - to see this, open up the task in "SCHEDULED TASKS", click on the "ALL DEVICES" sub-branch and then left-click into the right-hand pane. Again, the windows console will show you the selected / total count of devices in the relevant section at the complete bottom left of the 32-bit Console window:

    10_2 _NumbersOfDevices_In_Task.JPG


    VI - Reporting & Monitoring The Devices:


    There are two ways to do conclusive reporting, which essentially both involve querying the database. One can either use Ivanti EPM reporting (for LANDESK 9.0) and talk to the DB that way or directly write SQL to extract the desired information.


    Tables and data-columns that will be relevant for this reporting:



    Table NameColumn NameNote / Explanation
    LD_TASKLD_TASK_IDNThis is the primary identifier for any task. This is the same "TASKID" that is used client-side
    LD_TASKTASK_NAMEThe "human readable" way to get the LD_TASK_IDN that you're after based on task name

    LD_TASK_MACHINE is the cartesian product marrying devices (identified by COMPUTER_IDN)

    to tasks (identified by LD_TASK_IDN). In plain text, it is the list of EVERY device associated to EVERY task.


    COMPUTER_IDN is the unique identifier for devices in the Ivanti EPM database -- this is used to help identify

    devices in the COMPUTER table, where hostnames and so on make COMPUTER_IDN's  "human readable"


    This is the custom-text that clients send via the "/msg=xxx" command-line switch. Remember that this is a

    STRING value, so be wary of this when attempting mathematical operations on date/time.

    COMPUTERCOMPUTER_IDNThe Unique identifier for each device as it is referenced in the Ivanti EPM database.
    COMPUTERDEVICENAMEOne of the more human-friendly ways of identifying devices -- useful for associating with / to COMPUTER_IDN's.




    A possible alternative would've been for instance to 'just' make use of custom data to be reported as part of the inventory scan.


    In this particular situation, that would've been a catch-22 situation, since it could not be guaranteed that an inventory scan would have time to complete, so a process that was indeed very rapid and did not take a lot of time had to be come up with.


    VIII - Common gotchas:


    This section covers common areas that can trip up efforts to make use of this functionality.


    VIII.A - Forgetting to add devices to your dummy task

    • A client *MUST* be part of a task for it to be able to display any sort of custom message.
    • Use static additions of clients to the task. Queries do not do well, since you'll never really "start" the task (as it's purely a recipient of messages), so queries will never be resolved!


    VIII.B - Not getting the Local Scheduler log right

    This is primarily a testing/validation effort - to make sure that the exact conditions that you intend are indeed reflected by the configuration of the local scheduler task.


    It's possible to configure conditions in such a way that they'll never actually come to pass, potentially. Like any logic, it should be thought through carefully & validated to ensure it behaves as intended.


    IX - Conclusion:


    The information provided in this article should suffice in explaining the functioning of and requirements for client-side messaging updates to Ivanti EPM Core Servers.


    Also - this is not 'new' functionality as such - this capability reaches back at least to LANDESK Management Suite 9.0 (should it be relevant), for which this article originally was written for.