Using --backEnd / run as a service

[B00ze]

Good day.

I've been playing around with various ways to keep VD running when I need it in XP, so here are a few things of interest.
EDIT: Read the replies for a solution to really running VD as a service...

A few notes regarding --backEnd (see https://vitamind.fogbugz.com/default.asp?video.1.156.3):

- It's case-sensitive, "BackEnd" wont work.
- It's needed to run the Agent silently; somehow it's clueless as to its default storage location.
- You cannot use --backEnd to relocate VD storage; if you do, some files will still end-up in the default location.
- If you want to move the VD storage, use a junction/link. This is the only way to point several users to the same database.
- The "Video" (rather than the "Agent") program also has a backEnd option (this gives interesting results, like 5x the video process).
- IMPORTANT: If you start the Agent at a time not covered by a rule, the Agent quits ---> SEE NOTE (*) <---

Solution #1 - Using Task Scheduler

You can use Task Scheduler (and a slew of tasks) to run the VD Agent at various times; waking-up the computer from StandBy along the way if you want to, and killing the Agent with --quit at specific times if you want the PC to go to StandBy again later. Use the same user for all tasks, so the VD database is always at the same place. If you intend to browse the database while logged as various other users, use Junctions in everyone's profiles and point the database to a shared location that everyone has access to.

So to simulate running VD as a service between 8am and 5pm for instance, you could:

- Use task scheduler to start the Agent on system startup (using --backEnd).
- Create another task to start the Agent at 8am (required if you dont have 24h rules).
- Create another task to start the Agent on logon (for when you switch users, see caveat below).
- Create another task to stop the Agent at 5pm with --quit.

The only thing missing is starting the Agent on logoff; task scheduler does not have this option. Instead, you could use group policy to add a logoff script and START the Agent inside the script (make sure you "CD" to VD's install folder when you start it or it will fail to open cameras, and use junctions and move the VD datastore to some shared location if you have multiple users on the PC) ---> SEE REPLY BELOW, THIS DOES NOT WORK <---

Caveat to running VD with task scheduler: I'm not quite sure why (because it works when the Agent runs under LocalService) but while the Agent is running under a specific user (as started with Task Scheduler), then if you run the "Video" frontEnd under another user, it will be unable to "connect" to your cameras. You can review recorded video just fine, but you can't watch live camera feeds.

NOTE (*)

When I first started testing this solution, I noticed that if I started the Agent with --backEnd outside of a time that was covered by an active RULE in VD, then the Agent would run and quit a few seconds later, never spawning its 3 child processes. I tested this several times, and this was the behaviour. So long as I was using Task Scheduler to start VD, it was no issue (in fact it was somewhat useful). So if your VD Agent exibits this behaviour, and if you want to truly run VD as a service (see below) then you will need a 24h rule or VD will not always start.

Then a few days later, this behaviour stopped, and my Agent was happily starting and spawning 3 copies of itself even if no RULE was active at that time. This is how it currently behaves. I have no idea what has changed to make it behave as such, but it is the behaviour you need to be able to run it as a service even if you do not have 24/7 rules in VD.

Regards,

[B00ze]

Good day.

So I tried spawning the VD agent in a logoff script, but that's not working. The process runs under the user that's logging off, so as soon as the script ends, the process is killed (logical; registry needs to be unloaded etc). I think using TaskScheduler is still the simplest way to get the VD agent running most of the time, and this has the benefit that your computer will not go to standby so long as the task is running (and you can ask TaskScheduler to WakeUp the PC in the AM and run VD, and schedule another task in the evening to --quit VD and allow the PC to go back to sleep; this is really nice).

Using SC to install as a Service?

So I tried installing the Agent as a service using SC.exe. This required creating a Junction to my VD database under the LocalService user profile (Google-up HardLinksShellExtension for a visual tool you can use to make junctions). So here's the command to install the service (do NOT try this, it does not work as expected; it's shown here so you understand where the junction needs to be):

sc create VitamindAgent binPath= "E:\Apps\WinXp\Security\VitaminD\Vitamin D Agent.exe --backEnd \"C:\Documents and Settings\LocalService\Local Settings\Application Data\Vitamin D Video\"" start= auto DisplayName= "Vitamin D Agent"

So while this does work, and starting the service does start the Agent (and it spawns its 3 children), the Service Manager expects the Agent to answer some message(s) upon startup, which the Agent does not do. So after a while waiting for an answer, Service Manager kills that initial Agent process and you are left with 3 parent-less processes. Time to reboot and look for for another solution...

[B00ze]

Good day.

So I started looking at srvany.exe to wrap VD in a service, but this is an old tool and I am not sure it works under Win 7. Enter NSSM, the Non-Sucking Service Manager, an open-source Service Wrapper available in 32/64bits, which you can find at http://nssm.cc/.

Solution #2 - Using NSSM to run VD as a Service

First you need to get this tool and copy it somewhere, preferably in your PATH (I dumped it in C:\Windows).

Then you need to remember that services, unless specified otherwise, run under the LocalService user, so you need a VD database under this user's profile folder. The way to do this is to create a junction under LocalService's user profile folder and point this to a shared location, or to your own user's VD database folder. You need this. You can't logon as LocalService yourself to change things in VD, and when you run the VD "Video" frontEnd to view your recorded video, it needs to be accessing the same database that LocalService is using.

Then it's just a matter of running NSSM in a command window to install the service: NSSM install "Vitamin D Agent". NSSM will pop a window; browse to the "Vitamin D Agent.exe" as the Application to run, and use --backEnd "C:\Documents and Settings\LocalService\Local Settings\Application Data\Vitamin D Video" in the Options box.

The beauty of this is: The "Video" frontEnd *WILL* connect to cameras running under LocalService, so there is no caveat like when using TaskScheduler, and stopping the service will neatly kill all the Agent processes, so you won't have a bunch of parent-less processes running wild if you stop your new service.

So there you have it, VD as a Service.

Regards,

[ryan]

This is great! Thanks so much for sharing!

[saintjohnny]

Running as a service would be cool but until you are able to implement that feature, in the meantime it would be just as useful for me to be able to put VDV in the startup folder and the first time it starts up with the computer, it doesn't launch the actual GUI, it just sits hidden as if one were to "close" the program without disarming the cameras. Is it easy to do this? I know programatically it would be for you to do so, but I wasn't sure about work-arounds in the meantime?

One scenario being that on a shared 2 in 1 home/work computer/security computer, one will likely want VDV running all day but if an associate (or child at home) reboots the computer and then after it is finished rebooting and VDV pops up and the associate (or kid) "closes" vitamin D, the program will still be running in the back ground which is great, BUT if they don't just close it and they actually click around and change settings or disarm a camera that wouldn't be good. I may end up running it as a service as documented on this post, or find another work around but I wanted to ask you if you knew an easy way to do so? Thanks!

This is great! Thanks so much for sharing!

[headingwest]

HI,

Is there someone technical who can help me with this bit please:

create a junction under LocalService's user profile folder and point this to a shared location, or to your own user's VD database folder.

So, how do I create a junction?

thank you.