I am looking to put together a list of other companies/large organizations that are using Wildfire to help support the case for an installation at my company.
I am not looking to publicize this list. If you are sucessfully using this and have a minute, could you please PM me and let me know. I’'m looking for Organization name and number of users.
thanks,
jason
to help support the case for an installation at my
company.
dont understand that, could you explain that more precisely?
meaning, he needs data to support his cause/reasoning to have a corporate IM solution implemented… he’'s looking for a couple of companies that can give him their deployment solution (case studies othewise) information to help.
unfortantely, i can not help as i am still testing with ~50 users across multiple sites… but this solution is better than allowing MSN/AOL/Yahoo/Google IM’'s to used at your office.
Yes, i’'m simply looking for names of organizations that are testing this out and planned (or current) deployments…
jason
Ok So, will you be satisfied with mine 80 (planning ~150) users at local intranet? Probably this wount qualify as a large organization.
Yes, I also use Wildfire in my company’'s LAN with around 150 users.
Here my experience.
I install wildfire for my local entities as a purpose of Internal Instant messaging systems ( increasing the communication )
The good points for me are :
The price ( open source)
The easyness of installation ( one day maximum to set it up, with ldap support and share group roasters )
The possibility to connect you own applications on XMPP
The comunity
The variety of client you can choose from
The professinal paying support if the IM become a critical application.
I will conclude by saying, that due to the price of deployement, tell your managment to give it a try, anyway a try won’'t cost anything.
Users are really fond of IM, and if you have blocked external IM, they will love you for installing that software on the LAN.
Running Wildfire 2.5 on LAN using Spark 1.0.4 as the client, still in test - pre-mass deployment phase. 20 internal users. After we work some minor issues out, plan to deploying to over 300 external clients across the USA (Branch/Franchise Offices).
Synergy Financial Management Corp. - Mortgage Broker/Wholesale Bank
Here is my roadmap if it helps:
Server install and local test (1 internal user, me, and one external user) to ensure connectivity. (about a week). 2) Deploy localhost version to LAN, receive feedback and make note son needede adjustments based on users needs. (2 weeks live)
switch over to LDAP (MS-AD on server 2k box in a 2k3 mixed domain). Work out AD-LDAP issues. (2 weeks including live time). {in process, working on AD groups interation, maybe 2 weeks or more}
Start deployment/access to external office managers only. Test machine loads adn bandwidth usage. Adjust as needed {next step, will allow 1 month (4 weeks) to receive feedback on usability and adjust as needed}.
Full Deployment (hopefully by April/May 2000).
Kinda basic and drawn out, but not only am I the IT sys/net admin, but I am also the Phone/Fax Guy, Printer repair, Graphic Artist, Lightbulb changer, and "fix my “WinWall”/“Rhapsody” guy.
Hope it helps
Riv.
but not only am I the IT
sys/net admin, but I am also the Phone/Fax Guy,
Printer repair, Graphic Artist, Lightbulb changer,
and "fix my “WinWall”/“Rhapsody” guy.
sound familiar
btw, April/May 2000, probably a typo
I have it deployed using LDAP/AD to authenticate over 150users, we are a development shop and use it on the secure private network as well as on private LAN. We use it for builds notification and all. It works wonderfully to allow departments to communicate quickly and efficiently
loonybin88
Well, I can’'t reveal publicly who my company is (mainly because we are trying very hard to play nice with our IT guys who are married to a M$ Live Communications Server roadmap), but I help run a fairly large installation:
Wildfire 2.4.4 - 6782 registered users (as of a minute ago - I wrote a query to pull that information out for us, since we use LDAP, and want to know the actual # of users who’'ve logged in, not just how many users LDAP has in it)
We installed the fine stats plugin from Ryan and Larry at http://version2software.com, which has provided us with some great data - the plugin has only been up for about 12 days, but we are averaging around 2150 online users around the clock (we are large multi-national org), and have processed over 2 million messages for our server (225,000 messages for our conference domain) in that time period.
Bottom line for our user base - they come to us (an engineering organization) from all areas of the company - our server isn’‘t ‘‘the corporate standard’’, but it works one heck of a lot better and is more reliable than the M$ Exchange-based IM system (creaky, old, and very unreliable). We started out literally from the ground up (my group put the server up initially), but have grown through word of mouth and by continuing to provide a great alternative to a broken system that corporate doesn’‘t want to admit doesn’'t work.
So, my advice to you would be along the lines of these other posts - do a small pilot, and see what happens. If you don’'t already have an existing IM solution, I think you will be very pleased with the quality of Wildfire, and the great support that the community and developers here give. Not to mention that you can get commercial support if that is what is required.
Good luck!
guyma,
can you give us a hint of your hardware settings.
thanks
Sure…
Rack mounted Dell PowerEdge 2850 (Dual processor Xeon™ CPU 3.00GHz)
8GB RAM
278GB of disk (we are attached to a SAN array for most of that)
OS: Red Hat Enterprise Linux 3
Wildfire is configured to run with an external DB (PostgreSQL 7.3.10-RH) - this DB is shared with other apps (see below).
Note that this machine isn’'t only running Wildfire - we also run an internal version of Sourceforge.net for a collaborative development environment, so this is sized appropriately for a mixed load. We are already beginning to plan for migration of the Wildfire installation to its own dedicated machine if our user base continues to increase, but right now we are running comfortably within the capabilities of this machine.
We are an IT firm, providing outsourced IT solutions for our clients.
We have deployed a local server, and servers at several of our larger clients. The client servers all connect to our internal server, and we have groups named for each client with their employees in them. The clients have their local users, as well as groups for users at any remote offices they may have (as such, we have deployed the server to all client sites for those clients we have done this for).
We found options like MSN Messenger, Yahoo Messenger, and other public solutions weren’‘t reasonable solutions. Users spent far too much time chatting with friends and family at work. It’‘s very difficult to control the impact on productivity of public messaging solutions. As a result, we have blocked all public messaging solutions at the firewall with advanced packet filtering (port blocking alone isn’‘t enough - most public solutions will just keep changing ports until they eventually end up on port 80, and then you’'re stuck). We also had to block the web-based clients for the public solutions (meebo, for example, and several others). We have blocked XMPP traffic from internal clients to the outside world, too, to stop users from using public Jabber servers. XMPP traffic to/from the Internet is allowed to/from the internal server only. We have also used the firewalls to control connectivity in server to server situations via static IPs, further protecting the network. In many cases, client servers communicate with remote sites via VPNs for even greater security. In short, we have things locked down very tightly to avoid user producitivy problems.
Granted, this doesn’‘t stop staff from chatting with other staff about non-work related issues, but that happens anyway via e-mail or the phone, or worse - people get up from their desk and socialize in person if they can. You can’‘t stop all producivity waste in all situations - you just hope the solution in question does more good than bad. In the case of internal corporate IM, clients have found tremendous productivity gains and few losses, so it’'s been very well received.
With a local IM server, however, it’‘s easy to control who can connect, who has accounts, etc. We have denied the ability for users to set up their own accounts, so we (or the client’‘s local IT staff) have absolute control over the server’'s security.
At this time, we have several clients with remote offices spread across Canada and the US, and they’‘re finding the ability to quickly communicate with users anywhere in the organization without having to resort to the phone or slower e-mail communication has increased the speed and efficiency of their companies. The ability for them to see who is at their desk through the use of online/away status helps them locate people quickly, too (rather than e-mailing and waiting, or calling and if they’‘re not at their desk, having them paged - those methods are slow). Also, most of these clients have users that travel between offices. Users don’‘t need to know where a person is physically - they can just IM them, and the message will find it’‘s way to the user wherever they’'re logged in.
We’'re currently in the process of deploying mobile clients on devices such as Blackberries and Microsoft Mobile smart phones. At the moment, we have a few of the upper level executives and several sales people of about 5 firms using the feature as a test. So far, they love the ability to reach staff from anywhere, anytime and vise versa.
At the moment, we have been using PSI as the desktop client, and IM+ for the mobile client (too bad there’‘s no version of PSI available for mobile clients. IM+ isn’‘t a free option, but it works). PSI has been easy to install, and we’‘ve found it works well with roaming profiles on Windows systems (PSI’‘s configuration file lives in the user’'s Documents and Settings/Username folder, so it travels with the profile properly). PSI has been extremely stable for us so far, as has Wildfire (especially the new 1.5.0 release - server to server works flawlessly now - we used to have to restart servers now and then to fix connectivity problems with server to server in the previous release).
One quick note about Windows Mobile based users - if the device goes to sleep (they all do, to save battery life), the IM client will disconnect and users will not receive messages from remote users. Blackberries don’‘t have that problem. Something to keep in mind. Hopefully a client will come along that will either do some kind of keep-alive scenario to keep the connection open. If not, the talk about a SMS message being sent to offline users in a future version of Wildfire may help relax the problem (there is a small email on away plugin developed by a community user that can send e-mails to an SMS account, but it’'s an “all users or no users on a given server” solution at this time).
If you end up deploying mobile clients with IM+, or using different desktop clients, make sure you set the resource names to match on all clients if you want users to be forced to sign out of their desktop clients when they connect from a different client. We ran into that early on, and it provided for some fun for the users until we noticed the problem (a user can be signed in more than once with different resource names - it was confusing for users!)
In total, we probably have over 600 people using Wildfire at various sites, all of them connecting between sites and/or back to our local server. We’‘re quite satisfied with the solution - especially in terms of cost (Microsoft Live Communication Server is exremely expensive, if all you’‘re going to use are the IM capabilities). We’‘re so impressed that we’‘re looking at some of Jive Software’'s other solutions, such as the knowledge base and forum products.
It’‘s free to try it, so why not? If a small roll out to a group of users that are most likely to benefit from an IM solution is successful, go all the way with it. When trying to get a new idea approved, it’‘s import to target users that are a mix of technology savy users, management users, and users at a remote site (if applicable) if possible. That way, you have some people who will catch on quickly and say good things about the solution (as well as help out other people who aren’'t so quick to pick up on new concepts), some people who have pull in the organization to get a full roll out authorized, and some people who will benefit greatly from faster communication with other staff (who will also say good things). Make sure the test subjects get plenty of help and some instruction on how to use the system (a web page with basic help on the corporate intranet website is a good idea - or an e-mail with the same type of information - or both).
Good luck!