My Technical Life

When I recently found out about the Entourage for EWS (Exchange Web Services) Beta I was very excited.  With all the trouble we’ve had supporting Entourage for years a change to EWS instead of WebDAV is very welcome.  Needless to say I jumped in on the Beta.

For the last 10 minutes I’ve been staring at the Beta license agreement, and that combined with the fact that I can’t find anyone else posting reviews online leads me to believe I can’t really go into detail here.  However, I will say that overall I am very impressed with what has been brought to the table.  Not only is it syncing everything it should have from the beginning but it is syncing much more quickly.  I look forward to being able to bring this to all of the Mac users at clients with Microsoft Exchange 2007.

Now, Therein lies the problem.  Many of our clients have held off on upgrading to Exchange 2007 due to the investment in new hardware required to do so.  Many of our smaller clients have run Exchange 2003 for years on a shared server with one or more other roles.  With Exchange 2007 they are faced with putting in a dedicated 64-bit server just for Exchange.

For a church, particularly a smaller church, they really have to step back and question if it makes sense to do it at all.  Some will choose to continue using Exchange 2003 until well beyond the end of support from Microsoft.  Unfortunately most will eventually have to make a move that improves performance and functionality.  Email storage has become a commodity and large mailboxes are completely impractical on Exchange 2003.

Those faced with the decision to move on will likely look into Exchange alternatives.  Ironically, prior to the EWS Beta we had found that many of these worked better with Entourage than Exchange 2003/2007 did.  There are many Exchange alternatives out there (Kerio Mail Server, Zimbra, etc.) which will work with your existing Outlook, Entourage and Mobile clients.

Another option that cannot be ignored is Google Apps.  Google extends the Educational Edition for free to all non-profit organizations.  With the synchronization apps released for Blackberry and Windows Mobile we are getting over the mobility shortcomings that have made me reluctant to recommend this solution.  The gCal plug-in will synchronize your calendars down to Outlook, and the Mac Calendar can sync via CalDAV, but syncing your contacts is still a manual process.  Additionally, Google apps does not have any equivalent of Tasks or Memos.  You must rely on third party solutions (Remember the Milk, Toodledo, Things, etc) for the Tasks functionality.  Of course Google has made it pretty obvious from the beginning that they would much rather you use the web interface than a local client.  This became a viable option this week when Google released their Offline Access functionality.

In addition to being a Microsoft Certified Partner, Solerant is a reseller for Kerio and Google Apps.  Clearly it is in our best interest to ensure that we are recommending the best solution to each customer individually and not forcing a one-size-fits-all approach on our customers.  Personally, I feel that while the majority of our customers in the past 8 years have gon with Exchange we will likely see a significant growth in Kerio and Google Apps in 2009.

I just received the official case summary from Microsoft.  I thought I would publish it here for the benefit of anyone using old man Google to solve this problem.

—————-
Symptoms
=-=-=-=-=-=-=
When a large number of items is put into the inbox, calendar, contacts, etc., Exchange Active Sync (EAS) or Entourage Client Sync will fail.

Errors
=-=-=-=-=-=-=
The errors can vary from the standard “TIMEOUT” errors to 0×85010014.  In a DAV trace, to summarize, you will see I/O consistently “PENDING” and 0 bytes read from file.  This ‘file’ is the streaming file.

More Information
=-=-=-=-=-=-=-=-=-=-=
EAS and Entourage request mail from IIS/DAV.  DAV requests the mail from the STORE.  If the store needs to package a large amount of items, it will package them using a STREAM file.  IIS/DAV reads from this stream file.  IIS/DAV returns the information to EAS/Entourage.

Problem
=-=-=-=-=-=
IIS/DAV uses Kernel32::ReadFile() to read from the stream.  A 3rd party kernel driver (FAMv4.sys) intercepts these calls to ReadFile() and returns bad data.  This causes our ‘read’ thread to go into a perpetual ‘PENDING’ state.  For every “PENDING” returned, a POLLING thread is spawned, causing performance problems for the W3WP.exe ExchangeAppPool as well.

Resolution
=-=-=-=-=-=-=
Open REGEDIT.exe
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Look for FAMv4 under the Services Key.
Set the “Startup” value to 4 so that it disables the FAMv4 service.
Open a cmd prompt.
Type NET STOP FAMV4.  This stops the FAMv4 service.
Sync your EAS or Entourage clients without issue.

More Information about FAMv4
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FAMv4 stands for File Access Manager and it is made by Vision Works Solutions Incorporated.  Their website is http://www.vwsolutions.com/.  It is essentially an open file utility that allows backup programs to backup open files.  You can find out more about how it works from http://www.vwsolutions.com/FAM/howitworks.aspx. It works with several backup programs and since it is ‘hidden’ in the registry and not listed in services.msc, it is probably licensed by other backup companies as their open file backup solution.

We ask that our customers contact Vision Works Solutions at 1.888.310.6706 or the customer’s individual backup solution to obtain a fix for FAMv4.sys.

In the corporate world most organizations have a pretty clear definition of what devices are allowed to communicate directly to their Exchange servers.  Usually this is limited entirely to devices that the company provides.  From a support perspective this makes life easy, but is clearly unpopular.  In Church IT, as in Small Business, this is very unlikely to be the case.  Most mobile devices are owned by individuals, even if they are required to do one’s job.

Solerant has recommended for years that it’s customers limit mobile devices to those that can access over Activesync or use Blackberry devices with a Blackberry Enterprise Server so that users can have full sync’ing capability.  While some organizations chose to use Blackberry or other devices without a BES, those devices were capable of obtaining their mail through OWA.  We intentionally avoided enabling/opening POP3 due to negative experiences with supporting POP3 as well as the security uncertainty it brings.  While we did enable and open IMAP in organizations with Mac users, we did not often use this for mobile devices.

This policy of support was received well by the majority of our customers because, in general, most people had no desire to carry a device around with their email on it.  When the original iPhone launched we had a sudden increase in users that wanted to be connected.  As organizations requested it we set up IMAP w/SSL and alternative SMTP submit ports for them to use with their new gadgets.  While this created some severe support headaches for a while from users that expected full wireless sync comparable to the Blackberry or Treo they just tossed aside, it waned pretty much immediately as users really only needed to send/receive email to be happy.

With the upcoming release of the iPhone Firmware 2.0 as well as the iPhone 3G full Activesync is being brought to the table.  Many organizations may be faced with implementing Activesync for the first time to support their users, while many others may have to prepare for a sudden onslaught of requests to switch to iPhones instead of their aging Windows Mobile, Palm, or Blackberry devices.  This may be significantly compounded by the more affordable pricing of the 3G iPhone.

How will this affect your individual churches?  I have some examples below and I would love to hear some feedback from others on this topic.

• User/executive demand to implement Microsoft Exchange or an alternative that supports Activesync in organizations that have otherwise not had it to date.
• Pressure to standardize on the iPhone 3G as a mobile device of choice.
• Increased mobile device support demands on IT Staff due to the influx of personal iPhones into the organization from people who would have never otherwise needed/wanted mobile email.

Thoughts?

There aren’t a whole lot of details floating around about Apple’s implementation of ActiveSync on the iPhone yet, but I stumbled across an article from last week that I missed on the Exchange Team Blog that had a few surprise details.

Obviously, we have been working together for a while on their implementation. What can we say today? They are doing Direct Push and most of the Exchange 2003 SP2 policies (including remote wipe). They are doing email, calendar and contacts sync, and global address lists. While previously you could get you Exchange mail on an iPhone via IMAP, getting contacts and calendar required a tethered sync through iTunes. Doing it wirelessly will be much better (IMHO).

Particularly noteworthy, Apple will implement a couple key Exchange 2007 EAS features.

1. Autodiscover – This means those of you running Exchange 2007 can now make it super easy for your users to configure their iPhones to sync with Exchange. Here’s what you do as an admin. All the iPhone user does is enter his/her email address and password. Pretty cool.
2. HTML Mail – See your mail in its full HTML glory. Obviously the iPhone shows mail in HTML format today, so it’s safe to assume your Exchange mail will retain its HTML formatting on the iPhone as well.

I don’t have a lot more to say about the iPhone. Perhaps after I’m worked with it a bit I’ll share some more thoughts.

More of the Article can be found here.