I was at a client site the other week when a colleague named Allen, the help desk manager (and administrator of all company-issued devices), told me they were finally shutting down their BlackBerry server (version 5.0.3). This came as big news since it was running for about 10 years in conjunction with a Verizon Wireless company account for user handhelds. At one point my client was issuing BlackBerries to all users on their corporate Verizon plan but that began fading away with the times.
As IT people, we know all the Monty Python references and analogies (I'm partial to Microsoft Exchange as the Killer Rabbit from "Monty Python and the Holy Grail," myself). "I'm not dead yet" was a refrain commonly applied to this system over the past couple of years. Fingers hovered near the power button on more than one occasion then thought better of it.
"Everyone finally went to BYOD?" I asked.
"Well, mostly," Allen replied. "We let the support on the BlackBerry server lapse since it wasn't mission critical. We still have eleven users on BlackBerries Bold 9650s, however, and these were working just fine for them. These are techies who just needed something basic to serve for pager duty using mail contacts set up with email-to-SMS functionality for system alerts. Also, we had a few employees who didn't want to have to go out and buy their own devices and a couple of folks who have Androids or iPhones but wanted to keep their work email separate from their personal devices."
"Why shut down the BES, in that case?" I asked. "Seems like it was a free solution that worked fine."
"We do in-house vulnerability scans via Qualys as part of our PCI compliance requirements," Allen replied (this organization handles credit card data and is therefore subject to stringent security controls). "The scans picked up a slew of vulnerabilities pertaining to several outdated versions of Java on the BlackBerry server."
Knowing I write about mobility for TechRepublic, Allen provided me with the full list of vulnerabilities:
Continuing his explanation, Allen said, "The BlackBerry server has Java version 1.6.0_45 installed, but the BlackBerry Administration Service and the BAS Native Code Container were using 1.6.0_18. The setup is right in the registry in the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BAS-AS\Parameters" key.
Allen also provided me a screenshot to demonstrate how it works:
"It's possible to update the Java version used by the BES components but there are many moving parts involved with this to get the BlackBerry server to play nicely with it," Allen said. "If something's not right the services won't come up. If a Java patch gets applied and broadsides the server we have to spend time cleaning up these settings. We're trying to get all unnecessary Java instances removed in the company for security reasons, so we finally decided it was time to pull the plug on this box rather than finagle with it through various Java updates and so forth."
A common refrain
As a system administrator it's my opinion that Java is, simply put, an unholy mess right now. For years it was woven into many applications and platforms; after all, the installation tagline reads "Three billion devices run Java." It was like an energy drink being pushed upon marathon runners at every step of their route... until all the bugs and security holes started showing up, causing everyone to declare "Drop those cups! Java is unsafe!" It reminds me of a funny scene from the Eddie Murphy film "Beverly Hills Cop II" where miscreant police officer Axle Foley approaches a house under construction and pretends to be a building inspector, frantically telling the men "Stop working!" as part of a scheme to get them to depart so he can occupy the palatial estate.
However, it's not so easy to just "stop working." Lots of devices depend on Java. My company uses Dell Remote Access Controllers for server access and Citrix Netscalar devices for network load balancing. These are based upon a working Java client (there are non-Java methods available but these have not functioned properly), but getting updated Java versions to work with these devices is frustrating and time-consuming since they often won't cooperate. Sometimes you have to lower security settings, add exceptions, or just disable security checks altogether (hint: not a good idea; this defeats the purpose of being careful!) Browser-based java plugins are notorious for these antics and it's now routine to have to jump between Firefox, Chrome and Internet Explorer to desperately try to get something valid to work. Massive amounts of time get wasted Googling solutions which in the heat of a system outage is about as fun as it sounds. Believe me, there's nothing more frustrating than being blocked from accessing something you have a right - and a dire need - to get at. It's like trying to visit your injured child in the hospital but being told "You can't come in since we don't know who you are" by the staff.
The evolution plan
At any rate, I digress. Oracle will need to figure out its Java problems if it wants people to continue installing and using it, otherwise it will go the way of the BlackBerry server itself. Eliminating Java in this case made sense since Allen's company had viable alternatives.
The plan they devised:
- Allow the 11 employees on the BES to continue using company-owned devices, swapping the BlackBerries for iPhone 4S or Samsung Galaxy smartphones, as provided by Verizon Wireless, which they would retain for voice/data services.
- Set up these new iPhones/Androids with Activesync access to the email environment.
- People on pager duty could continue using their mail contacts for email-to-SMS functionality to receive system alerts; the phone numbers weren't changing.
- Remove all users from the BES as they drop off during the migration process.
- Shut down the BES and decommission the server.
- Remove firewall rules permitting the BES to access Research in Motion (RIM) servers for email forwarding as well as any DNS entries, the AD computer object, server documentation, asset lists and so forth.
Employees who liked the BlackBerry devices were free to keep them for personal use, although they would no longer have a voice or data plan. The BlackBerry Bold actually serves as a pretty good MP3 player and PDF reader (if you have Documents to Go on it). You can put micro-SD cards in it to access files and if you use Wi-Fi connectivity it will run apps like Dropbox or the email client (which can still work via IMAP/POP3 access). In other words, it's not too bad as a backup device just to tool around with. I myself took a spare one to keep in my car to play music through my speakers via an auxiliary cable.
Now, there is one caveat here: if you have an old BlackBerry lying around without a data plan you can't upgrade it to the latest OS via the BlackBerry Desktop Manager program. This program actually checks to see if you have a valid data plan before it will let you proceed, something I consider pretty rude on the part of Research in Motion. So, any outdated operating systems on BlackBerries should be updated to the latest (and presumably final) version before shutting off the service.
The end of the road
Many might question why the BlackBerry server ran as long as it did, but in my view it performed the function it was built for right up until the end and, like a horse put out to pasture, deserved a respectful retirement. My client experienced a smooth and seamless transition from one platform to another and employees were perfectly happy with their replacement devices, which still met their needs and those of the organization itself.
This is a good example of how an IT department can balance services by letting some users do their own thing via BYOD and providing company-owned devices to others with minimalistic requirements... up until security concerns made it an unviable proposition, anyhow.
I don't begrudge security concerns their validity - this subject should be prominent on the mind of every IT administrator and end user; a security breach can shut an organization down. However, the Qualys method - find problems and then recommend solutions or alternatives - is far preferable to some of the ham-handed security methods I've seen from vendors, who just turn off or block things heedless of the consequences, leading to a game of jumping through hoops. I get what they're trying to accomplish, but I favor democracy over totalitarianism, where possible. A grand total of three security prompts while trying to log into a production system using Java is, shall we say, excessive - and it undoubtedly can lead to users just saying "Yeah , yeah, yeah, quit bugging me" and clicking "Allow/Yes" to whatever pops up next time. Good security should be a finely tuned and elegantly controlled dance, not a wild and heedless charge by a herd of stampeding elephants.
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.