I’m chronicling my switch from the Blackberry to Android platform, and the steps I took to adapt. For part 1 in the series, see here.
I’m an IT Manager and a Network Administrator and email is my life. Between my various gigs (and personal life) I have five email addresses, all of which I need instant push on. Most people outside IT don’t see the necessity of push email, however if you’ve ever gotten that urgent helpdesk ticket while out of the office, you can appreciate the difference a near instant response to the user can bring vs. a 15 – 20 minute delay. Email was the primary driver for my switch to a Blackberry, and so for a switch to Android to be feasible, workable email was a must.
I’m a Blackberry addict. Since first getting my hands on an 8703e in 2007 I’ve been more in-touch with my email than I have with anything else in the world. For the last 4 years, through 4 different models, the Blackberry has been cradled to my hip reliably delivering email day and night. That is, until last December.
Like many, in the last year or so I’d been admiring Android devices from afar, taking in their amazing features, open accessibility, and fast web browsing with awe. Yet, I remained strident that I needed email more than anything else, and nothing was better at email than a Blackberry. This was confirmed with an ill-fated attempt at switching to an early Android handset, the Droid Eris, in 2009. It didn’t last long, and I soon went back to my Blackberry. However, in the last 6 months, as the mobile web became more and more useful, my frustration with my Blackberry finally snapped, and in December I upgraded to a Droid 2 Global.
The Droid 2 Global has been a wonderful device for so many things, but I’m just now coming to peace with it as a replacement for my Blackberry. The road was not without bumps, and I even switched back to my Blackberry for about two weeks to try and figure out what was missing from the Droid’s email experience that the Blackberry was providing. Fortunately, that act seemed to do the trick, and as a result I was able to pin down a few crucial areas of concern and address them systematically. Specifically I was looking at:
- Easy and fast email
- Notifications and profiles
- Battery life
- General usability
In the next few days I’ll touch on each of those areas and outline what I’ve done to address them.
Last week I mentioned a bizarre problem that occurred during an Exchange 2000 to 2003 migration for a client. Shortly after posting that little expository, I discovered another.
The customer called to indicate one of his user’s Inbox had been moved to his Deleted Items folder. I had never before seen this, as Outlook prevents users from making such “mistakes” with special folders. I’d heard rumors that previous versions of OWA would allow users to do this, however he insisted that it just appeared this way after the migration. What was really strange was that new email continued to be delivered to this seemingly “deleted” inbox. No attempt to move the folder back to the root of his mailbox would work, and Google turned up little helpful information this time. Deleting the Outlook profile and all of its offline cache goodies proved futile, and I was on the verge exporting his mailbox to a PST file and nuking it, when The Google finally answered.
Turns out some random bloke on a Technet message board had this problem when moving users from Exchange 2003 to 2007, and after some of the same steps I had taken, he had found the solution that worked equally well for me. Moving the user back to the old server, then back AGAIN to the new server put the Inbox back where it belonged. While I don’t understand the root cause of this problem, I’m glad to have solved it without the pains of nuking a mailbox. Just further proves that keeping an old Exchange server around for a few weeks after its migration is a Smart Move.
After a nasty power outage a few weeks ago at Key, I realized that I had never installed APC’s wonderful Network Shutdown tool on our VMware server. The Network Shutdown tool is a service that runs on just about any OS, and communicates with APC’s network-enabled UPSes. When the UPS detects a power failure and reaches a battery life threshold, it will issue a command to each computer running the Network Shutdown tool to, obviously enough, shut down. I’ve installed this on many Linux boxes in the past, so I figured this would be no different.
A quick Google search turned up numerous hits about a VMware specific RPM available from APC for v2.21. A quick search of APC’s website turned up no such thing, and downloading the newest release for Linux didn’t get me very far. During the installation it through an error about VMware not being supported. After some further Google digging, I finally found a direct link to the RPM buried on APC’s FTP site. Installing the RPM worked like a champ, and once I opened up the requisite firewall ports in ESX I was able to access the web interface and get it configured.
To save others the same headaches I encountered, I’ve preserved the RPM file on my site until APC decides to support VMware in new releases again. The file is available below.
APC Network Shutdown v2.21 for VMware
I upgraded my Verizon 8703e to Blackberry OS 4.2 about two weeks ago, one out of the desire for “new stuff”, and two because someone developed a Blackberry companion to KeePass that required 4.2 or newer. It’s a pretty nice upgrade that brings some of the look and feel of the newer Curves and 8800 series to my trusty email warrior. In particular, the newer, brighter Dimension theme, options for a Today-style screen, and a decent media player that finally lets me listen to the WAV files my unified voicemail software delivers to my inbox.
Generally, the upgrade process was smooth, but not without some hiccups, plus I had to do a fair amount of work to get the much-sought-after Today screen working. Just to help others that may experience the same pain, here are the tips and gotcha’s I encountered:
I use the Netgear WG102 access point in a few client sites, mostly small to medium business that use wifi as a secondary form of access. For about $120 you get an 802.11g access point that’s plenum rated and supports PoE, auto-channel and auto-signal strength, VLAN’s, SNMP, multiple SSID’s, and every security feature under the sun (including 802.1x RADIUS auth). What it doesn’t provide is good centralized management or any sort of serious wifi intelligence, which limits them to smaller shops.
Despite this great bounty for only $120, they do have a major weakness – they tend to lock up after about 2 weeks of normal use, which requires a hard power-cycle to resolve. After some Googling, I recently stumbled across a work-around on Netgear’s forums. It seems by setting an SNMP OID to a certain value, you can cause the access point to do a soft reboot. The trick is to schedule such an event on a weekly, or even daily, basis, so that it occurs before the AP has a chance to lock up. The command below works quite well using the Windows task scheduler and the Net-SNMP tool set.
snmpset.exe -v 1 -c private 10.10.10.10 126.96.36.199.4.1.45188.8.131.52.1 integer 1
Just change the community string (in this instance, private) to your R/W community, and of course the IP address to match your AP. I have this running at two locations each rebooting 5 of these AP’s on a weekly basis and so far no lockups.
I migrated a client from SBS/Exchange 2000 to Exchange 2003 this weekend. On the server-side, everything went quite smooth, despite my fears that SBS would really screw with my ability to work with the standard Windows and Exchange tools. Not so much on the client side.
All the clients were running Outlook 2003. Some users were seeing duplicates of many of their system-level folders (Inbox, Calendar, etc). All users were unable to access any folder but their Inbox. Trying to view the calendar, contacts, or even a user-created mail folder would cause Outlook to crash. I suspected it had something to do with offline folder files, although deleting the Outlook profile and it’s associated OST files had no affect. A bit of Googling finally turned up this post at joeware, which pointed to this post in the Microsoft newsgroups, which contained the answer.
After some work, we were able to determine why Outlook 2003 crashes after moving mailboxes off of Exchange 2000 onto Exchange 2003. The fix is to add a registry value â€œGuid-Replid Cachingâ€ under HKLM\System\CurrentControlSet\Services\MSExchangeIS\SERVERNAME. Under each mailbox store we added a REG_DWORD of â€œGuid-Replid Cachingâ€ with a value of 0.
Taking their advice, I made the change, restarted the Exchange IS service, and damn if that didn’t solve the problem.
I had Verizon FIOS installed just over a week ago, and having put it through its paces, I’m giving my thumbs up.
I decided to make the jump from Comcast after debating prices vs. features and picture quality, finally settling on a FIOS package relatively equivalent in both price and features to my current Comcast package. I placed a call to Verizon, and ordered the 5/2 Internet service, the premier package television service, the “movies” add-on, 1 DVR box, and 2 standard boxes. We have three TV’s in our house, and each television requires a box with Verizon. With my order complete, and installation date scheduled (about 2 weeks out), the wait began.
Okay, so it’s been 7 months since I originally wrote about my search for a dual WAN router (or even since I updated this blog… sad). In that time, I did eventually find a solution, but it was a long, painful road. The road began with a look at load balancers, an extremely complex and expensive bunch of boxes designed to do way more than I need (or could afford). Then came the Cisco 1841, but I couldn’t bring myself to spend $2000 on a simple router for a $160 a month cable connection. After that, I was working with a company (who shall remain nameless) to develop their existing load balancer product into a link balancer, but it wasn’t ready for prime time, and I had to pass. So, 4 months past my implementation date, and I was back to square one. The Linux box was looking better and better.
This whole project changed when I happened to check-up on pfSense, a firewall distribution based on FreeBSD. Lo and behold, they had added multiple WAN support over the summer. A quick download and test run later, and I had my winner. It had the raw support for the features that I need, with the polish coming down the pike in the coming months. It was free, since I already had a spare server to put it on. It was configured completely through a web interface, making for easy administration. It was… a done deal.
We went live with the setup before Christmas, and it’s been running flawlessly. Policy-based routing allows me to control which packets go where, and strong NAT/firewall rules make it a breeze to publish services out to the world. I’ve even got it running a fourth interface for a guest VLAN. More on that later…
So, I’ve been trying to find the best way to provide some extra Internet bandwidth at work without breaking the bank. My initial thought was to double up my T, until I realized how much that would cost me per month, and I still wouldn’t come close to the speed of my home cable modem connection. So, I’ve decided to bring in a Comcast business cable modem as our primary “web” connection. We’ll maintain the T for published services, outgoing email, and redundancy. Simple, cheap, great.
With the easy part out of the way, I embarked on a quest to manage two WAN links. Our firewall/gateway is a Microsoft ISA Server, which doesn’t support multiple WAN links. The only ISA add-on that does support multiple WAN links has just been deemed end of life by EMC. Just as well, as it was $3000. So, I began looking for hardware solutions. Thus began the hard part.