We’'re looking into deploying Spark in association with a Wildfire server to several thousand desktop machines within our company.
In doing this, we would like to lock down the client in a few ways so that it cannot be misused by our agents, and we can verify it will be used for for our intended business purposes only.
I’'ve been looking around for a few days and have not come up with any methods that would allow us to restrict access or lock down certain features.
We would like to remove the ability to connect to any servers other than our own (IM client side), to also disable other client side features such as file transfer, checking for updates, editing their profile, traffic window and etc.
If this question has been documented elsewhere, I apologize for my ignorance and inability to properly search.
I’'d have a suggestion which would prevent the client from connecting to an undesired server. If you install some forewall in your systems (like the free version of ZoneAlarm for instance) you could set up your local wildfire as being a “trusted” address and restrict the wildfire client to only be allowed to connect to trusted sites. That would prevent it from connecting to any server which was not registered in your firewall as being “trusted”.
If we are to bring this into spark, one way would be to allow one not to display the “server” textbox for login through some previous setup. That could be a useful feature.
Deploying spark via an install file or group policy would be great.
I’'m playing with Wildfire and Spark at the moment and having problems with users logging in - for some reason it keeps coming up with my details (I installed the client on each machine using “run as…” as the users have no install rights).
In addition to locking the client down, I think it would be very helpful to be able to define the client settings such as server/port/ssl type in the spark manager plugin so that when clients are installed, from the URL provided, they will get the correct settings initially and only have to enter thier username and password.
I’'m not sure what the capabilities of the install4j package are, but true silent install would be dependent on if the .exe can accept not only command line options, but use strings from command line parameters. Also, as far as I can tell, the default .xml file is hard-coded into the executable. This would need to be changed unless you wanted the installer to compile the program on the fly.
Option level control would be dependant on the same as above.
Group policy templates would be very difficult to implement. Currently custom group policy templates use the registry to store settings. Spark uses xml files stored in the users’’ home folders. To as teh developers to change this is cruel, as teh registry is windows dependant and Microsoft is currently moving in an anti-registry direction anyway(see Vista). Your best bet here would be to change settings using a logon/start-up script.
As far as locking things down, that would certianly be a nice feature. I would venture to guess it would mean making the users’’ settings.xml file read-only and having Spark properly be able to handle not being able to write to it.
I’'m not sure they mean configure it via Group Policy settings. Rather, it would be nice if it was in an msi installer package so that it could be deployed and configured at the same time using the msi package and passing in the correct config options.
Group Policy management would enable settings to be changed once Spark had already been installed - I can see this being useful with the plugin features as organisations may add plugins at a later stage.
I too would like these features, I am contemplating rolling a Wildfire / Spark instal out across 1500 users but I do not want my users to be able to transfer files. We have other methods for that. The connection to other Jabber servers is not so much of an issue, we have a firewall.
I have seen the reply about writing a sparkPlug to disable fille transfers, but a way to centrally manage and deploy SparkPlugs would be very useful.