How to force "Idle Enabled" in spark from server side?

I want to force all users’s spark client to be idle enabled.

We don’t want our users to appear online when they are not on their PC. Many users here are disabling the “Idle Enabled” inside their spark and now they appear to be online all the time…even at night!

Is there a way to force the idle disabled checkbox grayed out or dissapear?

I want to be able to do this from the server side OR some group policy setting. We have a Microsoft active directory environment here. This is a microsoft shop.

Thanks in advance for all tips!

Uh-Oh… a week has passed around 50 views too but no replies.

Does that mean this is not do-able or does it mean this has been answered before ?

there is no server side way of controlling this via openfire. you would need to compile a custom build of spark or modify the spark settings at login via a script.

Hmmm…Ok

So there is nothing we can do from the server side…but from the client side:

  1. modifying the spark.properties file at logon will do the trick. But most people in my company never logon daily. They just lock their workstation and go home everyday. Hence the logon script will not be effective.

Furthermore, the logon script leaves the option to change the idle setting wide open. Users will simply change that setting after logon!

  1. A custom build seems too much work and I dont even know how to do that.

Is there a quick way to do it?

any tips are helpful.

Also, will a sparkplug help instead of modifying sourcecode?

http://www.igniterealtime.org/builds/sparkplug_kit/docs/latest/sparkplug_dev_gui de.html

If you have the coding knowhow you could write a plugin that will allow you to modify this property. For example the client control plugin for openfire controls many functions of spark. maybe you could modify this plugin since it is now opensource.

I know this is not the answer you were hoping for. But what if you include it in the Acceptable Use policy for the company?

We included a lot of things users were doing and were not supposed to be doing in the policy, and create a category in our ticket system (to report users) where we write up users doing things that are not supposed to. It doesn’t stop the problem in the short term, but it does in the long term. When we starting letting go of users our Director of sales without mentioning the issues or the name, said in a company wide meeting, we know when you do things you are not supposed to, and one of the people we let go recently had over 50 incidents recorded, and anything that is against the policy is recorded.

Granted, the person was let go for other reasons, but had 50 incidents. What this did do, is reduce the amount of incidents we are catching. We have TVs here, and people were connecting cable or Antennas to watch TV, instead of the digital signage that is supposed to be playing.

Social engineering sometimes does wonders. Removing the access is usually the best option, but when not available, amend that policy, distribute changes and get users in line