There were several different announcements around Office 365 this past week. Most importantly, the Office 365 public beta is wide open…
Office 365 Beta The Office 365 team announced on their blog last week that Office 365 has moved into a full public beta. As a developer, this is a super easy way to get a test Exchange, SharePoint, and Lync environment. From an Exchange perspective, be sure to try out and understand the different plans (small business, enterprise, and kiosk) that offer different types of mailbox access and size.
In another post linked to from this announcement, the Office 365 team is starting a series specifically about helping “small business stand tall”. Exchange, SharePoint, and Lync are the “killer apps” for the enterprise. Now with Office 365, they become accessible in an instant to even a one-person operation. This means, as an ISV, you’ll have entirely new markets for your products that integrate with these services and these new customers will have new demands on pricing and service delivery…
Office 365 Developer Training Kit To help ISVs develop applications for Office 365, the ISV team announced the Developer Training Kit for Office 365. Check it out…
“…The kit includes 7 sessions, over 10 hours of video, and 16 labs as both an offline training kit as well as an online training course on MSDN. Training Units in the Office 365 Developer Kit The Office 365 Developer Training Kit includes the following training units: Developing in the Cloud with Office 365 Developing for SharePoint Online with Sandbox Solutions Building Workflow Solutions for SharePoint Online Developing SharePoint Online Solutions with the Client Object Model. Leveraging Excel and Access Services in SharePoint Online Developing Communication Solutions for Lync Online Developing Messaging Solutions for Exchange Online…”
“…The kit includes 7 sessions, over 10 hours of video, and 16 labs as both an offline training kit as well as an online training course on MSDN.
The Office 365 Developer Training Kit includes the following training units:
Office 365 Marketplace To help ISVs and partners publish their applications and services we also announced an Office 365 Marketplace this week…
“You can join others whose applications are listed in the Office 365 Marketplace. It is the online destination, based on the Pinpoint platform, for customers, partners, and Microsoft field to find the applications, solutions, and services that you offer supporting Office 365… …Who is Marketplace For? Office 365 customers to find high-quality partners/apps for Office 365 Partners/solutions approved by Microsoft Customers Ratings & Reviews Rich search/browse capabilities Microsoft partners to publicize their products and services to customers Customer leads Promotion as ‘best partners’ Customer site analytics Microsoft field to locate and promote local partners and solutions Localized User experience Sub ownership on partner nomination and approval, ‘featured partners’…”
“You can join others whose applications are listed in the Office 365 Marketplace. It is the online destination, based on the Pinpoint platform, for customers, partners, and Microsoft field to find the applications, solutions, and services that you offer supporting Office 365…
…Who is Marketplace For?
Office 365 customers to find high-quality partners/apps for Office 365
Microsoft partners to publicize their products and services to customers
Microsoft field to locate and promote local partners and solutions
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…”
“…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…”
“…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:
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.”
“…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…
The Exchange Developer Roadmap has been discussed by more authoritative sources before leading up to the release of Exchange 2010. I’d like to revisit this roadmap and take it from where Jason left off, going forward into Exchange Online in Office 365. For enterprise customers this is important to understand – if you are upgrading from Exchange 2003 to 2010 or Online then many applications that touch Exchange today will require an upgrade to the “modern” Exchange APIs. For an ISV looking at these API sets will help you understand what APIs you need to leverage to support the versions of Exchange you’re targeting.
When I talk about this roadmap or evolution of Exchange development, I typically do so by grouping the APIs in six categories:
Let’s take a high-level walk through these groups from Exchange 2003 to Exchange 2010 and see how the APIs evolve over time and how they are different between on-premises and online…
Exchange 2003:
Exchange 2007:
Exchange Online (BPOS):
Exchange 2010:
Exchange Online (Office 365):
I’ll get into more detail about this evolution with a discussion of online service descriptions in the coming weeks. I’ll also talk about how the features and APIs available in each version affect product planning for ISVs that want to support Exchange Online as well as Exchange on-premises.
The focus of this week’s roundup in on Microsoft Online Services. Typically when you hear about “the cloud” in a Microsoft developer discussion someone is getting ready to talk about Azure and its various services. However, in my world I think that Office 365 and BPOS are just as important in this discussion. If for nothing else then they offer a different path to get developers to the cloud.
Changing Patterns of Exchange Integration There’s no doubt that BPOS and now Office 365 changed the game not only for IT admins and end-users but for the ISVs that integrate with Exchange. On the Office 365 blog last month we announced that RIM will have a peripheral cloud-based service of their own for Blackberry customers to connect to Exchange Online. This is a significant example of how IT moving core services like Exchange to the cloud is going to change the way developers integrate with them.
Online Service Descriptions We post service descriptions that go into great detail of all the end-user, administrative, and developer features of the different services that make up a particular offering. Later today I will start publishing a series of posts that look deeper into these service descriptions for Exchange Online to extract key information for Exchange developers. The three major service types are Standard, Dedicated, and Federal and we’ll look at each one. For now, here are the links to the service descriptions:
Evolution of Exchange Development Using the service descriptions above my goal over the next few posts will be to illustrate the evolution of Exchange development from Exchange 2003 to 2010 and into Exchange Online with Office 365. Whether because of a phased migration or business requirements, expect to see many hybrid deployments of Exchange in the near future with some mailboxes online and some on-premises. Understanding the API set available in Exchange Online and figuring out how to build applications that can integrate not only with Exchange on-premises but Exchange Online is very important going forward.
Windows Azure Jump Start The changing pattern for developers who work with Exchange is not only going to be the APIs used to connect to Exchange Online but the platforms they use for their applications. If your customer moves all his or her mailboxes out of their datacenter to the cloud you can bet they ask you about getting your application servers out too. Whether the choice is to use Windows Azure or not, understanding the platforms and paradigms of cloud computing are an essential skill. If you are interesting in Windows Azure, I just finished a great series of videos up on Channel 9 called the Windows Azure Jump Start which I highly recommend for doing just that – jump starting your understanding of Azure and its various services.
First of all this is NOT and April fools joke! This blog actually isn’t dead! Recently (almost a year ago) I switched out of my role in support to a consulting based role working with ISV partners. A bulk of my work is still Exchange and Exchange Online related but a good portion of it is also other things like Windows Phone, Azure, SharePoint, and Lync. Because of that the topics on this blog may start going outside the bounds of Exchange and Outlook development but that’s okay, right?
Weekly Roundup? The plan here is to aggregate interesting topics and articles I’ve come across in the week of work. I’m aiming to do this most Fridays in series I’ll call the Weekly Roundup. Mostly short descriptions with links - easy for me and to the point for you.
Microsoft Exchange RPC Extractor Whether you are doing protocol level work with MAPI, using either Outlook or Exchange’s MAPI provider in a service application, or even writing add-ins for Outlook this tool can be very useful for debugging issues or even learning about how your application communicates with Exchange. From the announcement post on the Exchange API-spotting blog:
The Exchange Interoperability Team is excited to announce the initial release of the Microsoft Exchange RPC Extractor (RPX). RPX is a command-line tool that can parse network captures and interpret remote procedure calls (RPCs) made from a client to Microsoft Exchange Server. RPX uses the information provided in the Microsoft Exchange Server protocol documentation to parse RPCs, remote operations (ROPs) and the parameters for each ROP.
Programming with Exchange Online The Exchange team launched an MSDN landing page devoted to development against Exchange Online as part of Office 365 and BPOS. This is a very important topic and it is important to understand what is and isn’t possible (come back next week for more detail on that topic). The landing page is pretty barren right now outside of a link to one article about using EWS with Exchange Online. Come back to their landing page soon for a series of content on Exchange Online.
Exchange Online vs. Exchange 2010 Again more discussion about Exchange Online, specifically comparing features between Exchange Online in Office 365 (which is based on Exchange 2010) and Exchange 2010 running on-premises. The Office 365 blog has a post from Jon Orton discussing some of the differences at a high level. An important link in the article is to the Office 365 Exchange Online Beta Service Description. This is important to read and I will highlight some key parts in a post next week.
Migrating from an Exchange Client Extension (ECE) to an Outlook add-in On the Outlook integration side the move from Exchange on-premises to Exchange Online thankfully has little impact. However, moving from Outlook 2007 to Outlook 2010 is a different story for some folks. In Outlook 2010 we cut support for the old Exchange Client Extension (ECE) interfaces completely. Steve has a follow up post with some great information on how to manage the transition from ECEs to Outlook add-ins.
Outlook, MAPI, and Virtualization Some great information here if you have a MAPI application utilizing Outlook’s provider and your customer is virtualizing Office applications using App-V and Click-to-Run delivery mechanism. The Outlook team has a post describing how to check the registry to see if Outlook is virtualized. If you need to use MFCMAPI on a machine with virtualized Outlook, read Steve’s blog post for tricking it into running along side Outlook in the virtualized environment.
April 1st 2011 Release of MFCMAPI => MFCMAPI.NET Not much more to say just get to Steve’s blog and check out the amazing update for his MFCMAPI tool.
That’s about all for now…