Weekly Roundup: April 15, 2011 – EAS Logo Program Edition
This roundup is dominated by the Exchange ActiveSync Logo Program announcement as I still have a very Exchange-centric view of the “world”.
Exchange ActiveSync Logo Program The Exchange team announced on their blog this week what they call the “Exchange ActiveSync Logo Program”.
“…You’ve told us that one of your top concerns is the increasing diversity of mobile devices that employees use to access your company resources. While many of these devices use Exchange ActiveSync (EAS) for mobile email, we all know that not all EAS clients are created equal. Exchange ActiveSync policies and features aren’t consistently implemented by licensees, so it can be challenging to find out what’s supported on each device …
…Today, we launched the Exchange ActiveSync Logo Program to establish baseline for EAS functionality in mobile email devices . The program is designed for device manufacturers that license the EAS protocol from Microsoft for use in mobile email clients that connect to Exchange…
…All Windows Phone 7 and Windows Phone 6.5 devices are compliant, as are Nokia devices running Mail for Exchange 3.0.50, including the Nokia E7, and Apple devices running iOS 4, including the iPhone 4, iPhone 3GS, iPad and iPad 2…
…Over time, the program will evolve to require additional features and management policies…”
A parallel announcement with some additional information and quotes from Nokia was made on the Unified Communications Group team blog as well.
“…In the Exchange ActiveSync Logo program, participants agree to implement a predefined set of EAS policies (or more). You can get a full detailed list of the defined features here. Two of the key features required by the Exchange ActiveSync program are remote wipe and support for Allow/Block/Quarantine (ABQ) strings. Remote wipe gives IT administrators the ability to erase data on a device that has been compromised or lost, so company and personal information isn’t at risk. ABQ strings enable IT admins to identify the mobile device type and model trying to connect with Exchange 2010 in order to validate and enforce appropriate access policies. This means no more worrying about rogue or unsupported devices accessing the network…”
There was also information posted to TechNet, detailing what devices meet the bar today and what the requirements are.
“…The table below lists the FY11 requirements for participation in the EAS Logo Program. Exchange Partner Marketing plans to add additional functional requirements over time to address market needs…
…Program Requirements:
- Must be current EAS licensee
- Use EAS v14 or later
- Direct Push email, contacts & calendar
- Accept, Decline & Tentatively Accept meetings
- Rich formatted email (HTML)
- Reply/Forward state on email
- GAL Lookup
- Autodiscover
- ABQ strings provided: device type and device model
- Remote Wipe
- Password Required
- Minimum Password Length
- Timeout without User Input
- Number of Failed Attempts…”
As stated, the goal here is to try identify baseline feature set that the Exchange team feels any EAS device should meet and then give IT Pros the ability to quantify the devices that meet that baseline. This also gives EAS licensees implementing mobile devices a clear target feature set to prioritize in their mobile email client development planning.
Windows Azure PaaS vs. IaaS With everyone talking about “cloud” and various different “*aaS” models, it can hard to cut through and see what is really going on. For ISVs or developers in general, understanding the patterns and paths to different models is important. “Planky” gives a great overview of the difference between platform as a service (PaaS) and infrastructure as a service (IaaS) and where PaaS with application virtualization fits in. The key point for me is at the end of his post:
“…PaaS applications are more difficult to deploy because the apps have to be specifically engineered to work as scale-out, multi-instance entities. IaaS applications can “just be”. So the movement of an existing application to IaaS is simpler…
…It’s a sort of trade-off. You trade ease-of-deployment, but it bites later when you are wedded to the management of the OS and everything in the stack above it, for the life of that application…
…With PaaS, there is initial difficulty in migrating an application to be a good PaaS citizen and that is a one-time piece of work. Once done, you no longer worry about the management of the OS, the middleware, the runtimes etc.”
In summary this resonates with me as a short-view (IaaS) and long-view (PaaS) approach. IaaS allows you to move your application from on-premises to some kind of hosted service infrastructure with minimal code changes – essentially the hardware moves from your datacenter to someone else’s and your code stays the same. So while you get to “the cloud” quicker, you still have to manage the platform stack between your application and the hosted hardware. PaaS moves you up a level and eliminates any need to manage the platform stack – all you care about is your application code. However, PaaS is a rewrite (or at least extensive refactoring) of your application.
Windows Azure Helps Power eBay's iPad Marketplace This is a great example of two key points about Windows Azure. The first being identifying projects to experiment with Azure – a new project evolving new code that may have a great need for scale if it takes off makes a great Azure project. The rewrite for PaaS is not a huge concern because you are writing new code anyway and the great advantage of writing good apps for PaaS (especially in Azure) is the ability to scale out quickly demand spikes at some point. The second key point is that Windows Azure is not only about .NET – eBay uses Java, not .NET – Azure also has support for PHP, Ruby, Python, C++. Read more about interoperability here.
Look at the Windows Azure evidence site for more case studies…