Agent comands will run at the endpoint on next check in, which is based upon your policy polling cycle. Lower the polling cycle to 15 minutes. If you have remote access to the endpoint (or test machine), you can tell the agent to call home by selecting "Refresh Configuration" in the WR system tray menu.

 

To see if a command has run or been executed, look a the Log tab and Command Log. It'll show status of commands and the endpoints response.

---

@ wrote:

Agent comands will run at the endpoint on next check in, which is based upon your policy polling cycle. Lower the polling cycle to 15 minutes. If you have remote access to the endpoint (or test machine), you can tell the agent to call home by selecting "Refresh Configuration" in the WR system tray menu.

 

To see if a command has run or been executed, look a the Log tab and Command Log. It'll show status of commands and the endpoints response.

Hi coscooper and thanks for your answer.

Yes, my policy cycle is the minimum, i.e. 15 minutes.

In order to verify if command has been executed I enter the submenu of Agent commands called "View commands for selected endpoints". Indeed my commands are shown as executed.

However, I am connecting remotely to the other endpoint to verify if the application I wanted to start has indeed started but this is not the case. I also send a command to my own endpoint and still nothing happens although at "View commands for selected endpoints" it is shown as executed.

What I have read around the forums is that the command runs at System context instead of User context, whatever that means. See message #8 here: Agent Commands - Advanced - Run a DOS Command - Examples of various commands?

 

So, my question is still the same. How will I be able to start an application remotely on another endpoint by using the agent?

---

Ah hah! Now I understand what you're trying to do, not just when it runs at the agent level, but how to configure it to work.

 

Basically anything you can do in a command line on a windows OS you can do in our DOS command line. Which means, you'll have to have the syntax formatted properly and application you want to launch formatted properly, otherwise it does nothing.

 

An example is our own installer has command switches to do various things during an installation.

 

"c:{dir where the installer is locatedwsasme.exe/key=xxxx-xxxx-xxxx-xxxx-xxxx/silent/lang=ru" The action within the quotes will launch the installer and tell it to install silently, no GUI will pop up, use the entered keycode and install the language as Russian. (Probably not exactly something you want to do, but it's an example)

 

Another example: If you'd like to tell our agent to scan a dir you can, (there of course are built-in agent commands in our management console), but the same thing can be done with DOS command.

 

"C:Program FilesWebrootWRSA.exe" -scan="c:Documents and SettingsAdministratorDesktop" > this will scan all of the files on the Administrators desktop.

 

So, you can't just send a request to launch an application without declaring it's location and any supporting switches it has builtin.

 

Lastly, you can also declare any builtin system command. https://technet.microsoft.com/en-us/library/bb490890.aspx

 

Example:

 

DEL c:program datawrdata *.db

 

The above will delete all of the inactive DB files in our log storage area, but of course, this can be dangerous if applied to the wrong dir, so use it wisely. 8-)

 

Hope this helps.

---

I have been trying this recently myself. I am familiar with this functionality from using other products that allow remote sending of DOS Commands. First issue is that usually you are not able to run a program that has an interactive GUI. Another issue usually is that the commands will execute under the same user account that the Windows service is running as. So even if launching an interactive app was possible it would not display on the users screen because it is running under a different account other than the one the user at the console is running on.

 

With all that being said, I tested this functionality and have been unable to get any commands to work. I tried all of the following commands individually and made sure there was valid related filename that matched the command when necessary.

 

echo "This is a test" > c: est folder estfile.txt   

ren "c: est folder estfile.txt" test.txt

del  "c: est folder est.txt"

 

All commands show that they have executed but I have no evidence of any of the changes I would see if they truly did execute. I even changed the service account to be the same as the user account I am logging in and rebooted and tried again and still no change. I am not sure what is going on but it certainly seems like it is not working.

---

well, I am sure I am sending the right command.

For example, I opened DOS prompt locally and run the command: "C:Program FilesMicrosoft OfficeOffice14EXCEL.EXE"

including the quotes.

The result was as expected and excel application was started (see image below):

 

?

However, this is not the case when I send the same command using the webroot Agent.

What should I do to make this happen? Do I have to include a special switch or parameter when sending the DOS command using the Agent?

---

All - stay tuned. This command has somehow decide to not work any more and we're trying to determine specifically where the variation happens and/or if it's between OS's. I tested in my test network and Windows 7 isn't nor Windows 10 is responding. I've submitted it as a defect.

 

I would encourage you guys to submit a support ticket as well so we have enough ticket metrics to help push the defect to get resolved.

 

Webroot Business Customer Support

---

I got the following answer from support:

 

Support wrote:

Hello.

 

Thank you for contacting Webroot support.

 

If I was to be honest this way of opening an app remotely does not work very well and is usually only used for Webroot based DOS commands provided by support.

 

It can be heavily dependent on local and network permissions on the selected machines and if that machine is in behind a Firewall then this may also caused communication issues if the following URLs are not bypassed.

 

===========================================================================================

 

*.webrootcloudav.com

Agent communication and updates

(Please note: Some firewalls do not support double dotted subdomain names with a single wildcard mask (i.e. g1.p4.webrootcloudav.com being represented by *.webrootcloudav.com) so some environments might require either *.p4.webrootcloudav.com or *.*.webrootcloudav.com)

 

*.webroot.com

Agent messaging

 

*.s3.amazonaws.com

Agent file downloading and uploading

 

WSAWebFilteringPortal.elasticbeanstalk.com

Required for agent Web Filtering, elasticbeanstalk is an amazon AWS domain

 

*.webrootanywhere.com

Management portal and support ticket logs upload

 

If you require further assistance or have any questions, please send us a reply.

 

Thank you,

Derrick,

Webroot SecureAnywhere Business Support

 

Does anybody know how to set the Windows Firewall for bypassing the above URLs?

---

All - so, after some internal email threads with a variety of support and dev folks here at Webroot, I've learned a thing or two about DOS commands with regards to our agent. They are limited and controlled through code, not carte' blanc ability as any command line tool locally. There's code in place to limit their ability.

 

So, there may be some confusion on what they're used for and basically the original intent was for them to be used ONLY for our support teams to invoke specific commands the agent will respect to perform a specific function.

 

Net-net, DO NOT RELY on them to act as an option to run a command line utlity outside of the WSAB agent.

 

Hope that helps.

---

Well, then I guess this is totally misleading and confusing since this appears to be a very limited (webroot oriented commands only) DOS command line for the agent and FAQ does not explain any of these limitations.

Is this so limited for security reasons? Can it stay limited as it is by default but let the user decide if unlimited (i.e. normal) DOS commands can be given?

---