We have about 2600 users on our AD domain - our CIO wants all these users to be easily available to everyone on their rosters (Spark 2.5.8). I’m wary of creating a LDAP shared group with that many users as I have seen on these pages that performance can suffer badly with too many contacts on the roster - would that be fair comment? Our server is unstressed at the moment but I don’t want to take any chances as I’ve had severe CPU / performance problems with LDAP queries in the past.
So the alternative is just departmental rosters and use of the search bar in Spark - which I’m more happy with. However, the CIO (again) doesn’t think that’s sufficient as someone could add a user as a contact, and that user (if they didn’t use Spark already and had not yet registered) would not necessarily know that he or she’d been added. Make sense?! I’ve looked through the Registration and Subscription properties via the plugins in Openfire 3.5.2 and I can’t see anything that would notify a user in this way.
Any views as to whether I can achieve this somehow, or even whether I’m being overly paranoid with a 2600 user roster? 
Nick
The subscription plugin controls how or if people are notified when somebody adds them to a roster. I have mine set to auto accept local subscriptions. I would think you would see a significant slowdown of spark launch times and increase in memory needed by the server if you shared the entire AD user list as one group. Additionally you will have an issue with doing this as AD limits the results of any one LDAP query to 1000 results. You excede this by 1600. This means when open fire tries to get the list of members for the group with all users in it, it will only find the first 1000 accounts. This can be changed in your Domain controllers but could lead to instability. Your better bet is to server out smaller groups. I server out 28 smaller groups based on team (departments) and office location. This leads to some duplication but works well.
I had through some accident approx. 1000 users on my contact list. This is not practicable, it took more than one minute until the complete list was loaded. (using Psi, not Spark) Also it would be really confusing to have everyone on the list. I assume everyone will talk to the people of his own department at most. But all this people are spread though the whole roster. Thats really waste of working hours.
You should create a shared group for each department and let your users add additional contacts they need to talk to. Also it does make sence if you have also MultiUserChatrooms for each department. If a person from department A needs to talk to someone of department B, but does not know exactly who is responsible, he can ask in that chatroom.
Thanks Todd & Coolcat, you’ve confirmed my gut feelings on the size of the shared groups. We will stick with the original plan.
Re: the subscription service - as far as I can see the notifications via the subscription plugin will only work if the person being added is a. an existing Spark user, and b. the service is not set to auto accept local subscriptions. I’m talking about somebody being added who is not yet a Spark user, AND Openfire is set to accept local subscriptions. So in my case I would need a notification method other than an Openfire IM - it would need to be an email notification using a variable based on the JID, or an LDAP query to pull out the SMTP address. And I’m really sure that Openfire doesn’t do that out of the box…