Why is OOF an OOF and not an OOO?
Here's an interesting historical question - when we say Out of Office, why does it sometimes get shortened to ‘OOF’? Shouldn’t it be ‘OOO’? Inside Microsoft, ‘OOF’ means not just the message which says you’re Out of Office, but it has grown to mean the act of being Out of the Office too - so you’ll get people putting sticky notes on their door saying ‘OOF Thurs & Fri’ or even people verbally saying things like, "Oh, Kevin’s OOF on vacation for the rest of the week’. I suppose that sounds better than "Oh, Kevin’s OOO on vacation ..." OOF was a command used in the days of Microsoft’s Xenix mail system, which set a user as ‘Out of Facility’ - ie Out of the Office. The usage of the term ‘OOF’ just stuck, as did the term ‘Little r’ (e.g. on an email sent to a distribution list, "Who wants to go to the cinema tonight? Little ‘r’ if you’re interested", meaning reply just to me) - as preserved in Outlook with CTRL+R for Reply, and CTRL+SHIFT+R (aka Big R) for Reply All. Ewan DaltonExchange Server: The Road Ahead
We’re approaching the one-year anniversary of the release of Exchange Server 2013. This is traditionally the time when people start asking questions like: When is Service Pack 1 coming? What’s the timeline for the next Exchange Server release? What are you cooking up for the next version of Exchange? This time around, we’re also hearing a few customers ask: Will there be another version of Exchange Server? We hope the answer to that question is obvious, but we wanted to go on record to make sure no one is confused. Here are the facts: The Exchange engineering team is hard at work developing the next version of Exchange. We expect the next on-premises version to be released according to our traditional release cadence (2-3 years after the previous version). Microsoft has no plans to stop delivering on-premises releases of Exchange. It’s true that customers are shifting their Exchange deployments from on-premises to the cloud, and it’s true that we are investing heavily in Office 365. We’re fans of Office 365 because we’ve seen that when customers run email in our cloud, they save money, they get larger mailboxes, and they get faster access to our latest innovations. IT admins spend less time maintaining servers and more time lighting up features that make users happy. Running Office 365 also brings us real-world experience that helps us build a better on-premises product. While we are enthusiastic about the cloud, we also understand that our customers will transition to the cloud at their own pace. Many customers will remain on-premises or in hybrid deployments for the foreseeable future, and we want to keep delivering our newest and best features to them. Fortunately, our development process allows us to do that. We have a single code base that serves both cloud and on-premises customers, so we can deliver innovation to both groups. Our development strategy continues to focus on Office 365 as the initial platform where we roll out new features. This approach allows us to introduce and test new features at scale before including relevant functionality into on-premises updates. The benefits of the strategy can be seen in Exchange 2013, where features such as Managed Availability are directly based on work done to automate and improve our datacenter operations. If you want clues about what’s coming in the next version of Exchange Server, keep an eye on what’s happening in Office 365. It’s an exciting time for messaging and collaboration. Today’s technology trends— cloud, mobile devices, social computing, machine learning—all have the opportunity to make email more useful and powerful. We’ve got some great stuff cooking, and we’re committed to bringing innovation to all of our customers, whether they choose to deploy Exchange in the cloud or on-premises. The Exchange product team and our customers have a 17+ year history of successfully navigating changes in IT architecture and management together. We look forward to continuing that tradition with you. Perry Clarke Corporate Vice President Microsoft ExchangeMEC Check: Are You Registered?
Just 8 ½ weeks until the Microsoft Exchange Conference 2014 kicks off in Austin, Texas! We’re putting the finishing touches on sessions, speakers, content, parties, and all of those wonderful and quirky touches that make MEC different from any other conference. If you haven’t registered yet, now is the time, because hotels are filling up fast and your chance to win rock star treatment ends on Feb 10. Here are the key things to know about MEC 2014: When March 31st to April 2nd Where Austin, Texas, the live music capital of the world. Who A diverse group of folks who all share a passion for Exchange. We’ll have an all-star lineup of executive speakers, joined by planeloads of people from the Exchange engineering team, plus MVPs, partners, and customers from across the globe. What We have 100 unique sessions planned, including new formats like Experts Unplugged sessions where you can hear experts give unscripted answers to your toughest questions, and a Future Look @ session series where upcoming Exchange features will be disclosed in detail for the first time. Why Whether you are a MEC veteran or a first-timer, it’s the best possible way to take your Exchange skills, knowledge, and connections to the next level. Want more details? Check out www.iammec.com or watch some of the MEC 2012 keynote to get a taste of the type of experience you can only get at MEC. After you register, be sure to join the conversation on Twitter by following @MEConf and using the #iammec hashtag. We’ll see you in Austin! The Exchange TeamUpdated Exchange Public Folder Guidance
The last time we talked about the future of Exchange Public Folders, was in Terry Myerson's blog post titled, "Exchange 12 and Public Folders". The main theme of this blog focused on the statement that Public Folders are being "de-emphasized". While Exchange 2007 is supported for 10 years from release, those new to public folders were encouraged to look at SharePoint. Since this blog was written, there has been a broad range of questions and speculation about this topic, and we felt it was time to update our guidance regarding Exchange Public Folders. General Guidance Since Terry's blog post, there seems to be much confusion over the use of the word "de-emphasized". Many people have interpreted this guidance as "Public Folders are dead, and we need to migrate to SharePoint now!" This is not true. Our updated guidance is centered around the major scenarios in which Exchange Public Folders are used today. Depending on each scenario, the strengths of each server and known issues, you should find our guidance more specific to your environment. For this reason, Microsoft will continue to support Public Folders in the next major release of Exchange Server, after Exchange 2007. This means Public Folders will have full support for 10 years from release of the next major release of Exchange Server. Moreover, Microsoft will continue to invest heavily in SharePoint, which has focused platforms to support discussions, team calendaring and collaboration in Windows SharePoint Services (WSS) and more mature enterprise content management with enterprise search in Microsoft Office SharePoint Server (MOSS). Guidance by Scenario By looking at the primary scenarios where Public Folders are used, we hope to provide more clarity for your organization, allowing you to invest properly in your IT infrastructure. For each scenario, we are providing specific guidance to help you decide whether Exchange Public Folders or SharePoint is the right option. Scenario Use PF's Currently? New to PF's? Document Sharing SharePoint may be better option SharePoint is better option Calendar Sharing No need to move Use either* Contact Sharing No need to move Use either* Discussion Forums No need to move Use either* Distribution Group Archive No need to move Use either* Custom Applications SharePoint may be better option SharePoint may be better option** Organizational Forms No need to move Use InfoPath * Depending on scope of scenario, use Exchange PF's or SharePoint ** Depending on the scope of the application use Exchange Web Services and/or SharePoint While this table is focused on Exchange PF's and SharePoint, another alternative direction may be to build a custom SQL Server application to replace Exchange Public Folder use case scenarios. Strengths of Servers It is helpful to understand why we are providing the scenario guidance, in the previous section. Feedback from customers has indicated they feel a strong push to migrate from Public Folders to SharePoint, today. This general feeling does not take into account, the complexities of the migration. You should first understand the strengths of Exchange Public Folders and SharePoint. SharePoint Team Workspaces - SharePoint helps teams communicate and collaborate by providing easy access to people, documents and information. Documentation Management - PF's were not designed for document sharing and collaboration. SharePoint provides versioning and other document management features, such as check-in and check-out functionality, and automatic notifications of content changes. Workflow Applications - SharePoint provides many application templates that provide customer scenarios for building workflow on the SharePoint platform, to address specific business processes or sets of tasks. Exchange Server Public Folders Outlook integration - Public Folders are fully integrated into Outlook and Outlook Web Access. Replication - Exchange Public Folders have a true multi-master replication architecture, allowing the PF hierarchy and content to be replicated to other servers in the organization for efficiency and fault tolerance. Important Factors to Consider Exchange Public Folders will be supported for 10 years from the release of the next major release of Exchange Server. There is no emphasis here to push you off of Public Folders. If you do decide you are going to migrate your Exchange Public Folders to SharePoint, please consider the following during this process: Public Folder Hierarchy - The volume and organization of your current PF hierarchy, will have an impact on the amount of time it will take to plan the migration properly. A small number of PF's, or nicely organized into business/project groups, will be relatively easy to plan. Having an extremely large number of PF's, or very disorganized, will require a significant manual identification effort. In either case, owners of PF's will likely look at a different organizational structure of content in SharePoint. Public Folder Content - The volume and type of content in your Public Folders will impact how you approach the migration. 1. There are certain considerations in SharePoint content storage which may become an issue if migrating Public Folders with a very large amount of content. Therefore, it is important to plan your SharePoint content storage accordingly. 2. The type of content in a Public Folder will impact what type of list is created in SharePoint. Public Folder used for team calendaring or contact sharing can be moved into similar lists, within SharePoint. 3. Compound documents (i.e. messages with attachments) should be considered. In SharePoint, a document library is a list of individual items. This is not a problem if you export the Exchange items as .msg files, but if you want to split the item into multiple pieces you need to devise a strategy to "keep" these items together. Public Folder Permissions - Most likely, owners of Exchange Public Folders will want the permissions on that PF to follow over to the newly created SharePoint list. If leveraging a 3rd Party migration tool, ensure the permissions are factored into the migration process. If manually migrating Public Folders over to SharePoint, PFDavAdmin (free Microsoft download) can help export the permissions on each PF (but, doesn't help import those permissions into SharePoint). Public Folder Names - SharePoint has some restrictions on filenames, lengths, and size, as well as character restrictions. These restrictions will affect Public Folders being migrated, as well as documents within those Public Folders. If leveraging a 3rd Party migration tool, ensure this is factored into the migration process. Mail-enabled SharePoint Document Library's - While these libraries can store any document type, e-mail sent to mail-enabled document libraries usually show up in .eml format (Outlook Express format). If you try to open the .eml file from the document library, it will open using the web browser and will only contain the message body (no header or attachment). You can create your own application to convert to .msg format, or you can search on the web and find any number of .eml to .msg converter utilities. Public Folder Replication - Exchange Server allows for replication of content of Public Folders to additional Exchange Servers. SharePoint does not have this multi-master replication architecture. If replication of content is important, post migration, then you should investigate 3rd Party replication technologies. There are many advantages with moving to SharePoint for your collaboration, content management and business process needs. In contrast, not all Public Folder usage scenarios are best served by SharePoint. Consider the strengths of each server, and the factors listed above, when making this decision. A very realistic option for moving to SharePoint, is to deploy SharePoint in your organization today. Begin integrating it into your organizations workflow, and slowly reduce your reliance on Exchange Public Folders. As we've already said, Exchange Public Folders will be fully supported for 10 years from the release of the next version of Exchange Server. Migration Tools The only "free" migration tool to help customers migrate content to SharePoint, is a community-based tool, created by Kimmo Forss. Customers interested in migrating their Exchange Public Folders to SharePoint should also investigate 3rd Party migration tools, which work to address the considerations listed above. PF migration tools are available from: Quest Software Casahl Tzunami Information Works AvePoint - Jim LuceyAnnouncing 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. Wireless carriers may also join the program to include the Exchange brand to identify compliant devices for end-users. See Exchange ActiveSync Protocol for a list of current EAS licensees. This qualification program includes a test plan defined by Microsoft and a third-party lab to qualify implementations by handset makers. Qualifying clients must use EAS v14 or later, and implement the following features and management policies. Information on these and other EAS features can be found in Exchange documentation on TechNet: Direct Push email, contacts & calendar Accept, Decline & Tentatively Accept meetings Rich formatted email (HTML) Reply/Forward state on email GAL Lookup Autodiscover ABQ strings (device type and device model) provided Remote Wipe Password Required Minimum Password Length Timeout without User Input Number of Failed Attempts 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. We have a healthy pipeline of mobile device manufacturers ready to join the program and plan to announce additional participants in the coming months. Over time, the program will evolve to require additional features and management policies. We hope this program is a first step in helping you manage mobile email devices in your enterprise. For more info on managing your organization’s EAS devices, check out the previous post: Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list. Greg Smiley Senior Product Manager Exchange Product ManagementMicrosoft Exchange Labs
What is Exchange Labs? As part of Microsoft's software + services strategy, we are enhancing the way we build, test and deliver Exchange. On October 1, 2007, we announced Exchange Labs, a new program for testing the next version of Exchange in high-scale services environments. Who can use Exchange Labs? The initial rollout of Exchange Labs is designed for select schools and universities as part of http://get.live.com/edu. Windows Live @ edu "powered by Exchange Labs", allows these select academic institutions to easily connect students and alumni with e-mail, and integrate these users with existing on-premises Exchange Server deployments that support faculty and staff. If you are a school, and interested in Exchange Labs for your organization, please see Getting Started with Exchange Labs. What features are enabled with Exchange Labs today? For end-users we have: Windows Live ID authentication, that can be used with Messenger, Spaces, and all of the other Windows Live services Support for the complete Outlook experience: Microsoft Office Outlook, Outlook Web Access, Outlook Mobile Support for the broadest set of 3 rd party clients with POP, IMAP, and Exchange Activesync support 5 GB of mailbox quotas Security with SSL enabled all of the time Shared address books and calendars For school administrators we have: Provisioning and administration tools to manage student and alumni accounts Ability to integrate on-premises Exchange deployment for faculty and staff, with hosted Exchange Labs for students and alumni As always, I look forward to feedback from our community on this new program. Thank you for choosing Exchange, Terry General Manager, ExchangeThe SDE career path at Microsoft
In Microsoft, there are a number of standard job titles. The most important one is SDE – Software Development Engineer. The rest can be considered the supporting cast (one requirement of being an SDE is to be so supremely confident that such a statement as the previous one can be made without actually laughing out loud while doing so). The life of an SDE at Microsoft is as close to heaven as a computer geek can get. Chocolate donuts for breakfast, a quick bite in the cafeteria for lunch, any fast food at all for dinner, and before, in between and after is glorious coding. Of course, other things intervene occasionally – like annoying testers who keep insisting the code actually works, or program managers who insist the code actually be useful to someone (honestly, I don’t know where they find these people), or bosses who insist on “talking”, sometimes even in the form of meetings. These are unfortunately necessary evils and an SDE will tolerate them and, on occasion, even indulge them from time to time. There is a cloud on the horizon in many SDE’s careers however, and it’s called management. At Microsoft, there aren’t a whole lot of real managers, they are mostly technical people who at one time or another did real work and then – probably due to chemical imbalances in the brain brought on by a diet of donuts, cafeteria and fast food – suddenly “stepped up” to the management plate. It’s pretty insidious. One day you’re a happy go lucky developer enjoying work to its legal limit and with masses of extremely marketable skills, and then your boss suggests that maybe you should take on a report or two. Just junior people, you understand, to see how you like it. Zap. Six months later you have a team of 15 and you can’t write a line of code to save your life anymore (but you can create a mean Powerpoint presentation). Microsoft does have an alternative career path for SDE’s (and the other, lesser, disciplines) which enables an IC (individual contributor) to remain an IC but continue to progress in that role. While the ultimate destination of a manager is a VP, the equivalent IC role for an SDE is a DE (Distinguished Engineer). DE is quite a bit harder to attain then VP, actually. An intermediate IC role is usually some kind of architect. I know some people who have followed this path successfully, but it is a bit of a harder road to hoe. In my case, I’ve taken the Bilbo Baggins approach (“There and Back Again”). Prior to 1998, I had spent 13 years as an IC (not all at Microsoft, although I wish I had joined the company in ’85). I then took on two reports. Then six. Then, after Exchange 2000 shipped, I took on a team of fifteen. Then suddenly I had seventy developers working for me. I even attained the exalted level of PUM (Product Unit Manager). Those were the dark times. I forgot how to code. I forgot how to debug. I pretty much forgot how to think. I finally snapped out of it and ever since I’ve been striving once more for IC status. I currently am down to a team of five, but I’m not likely to get much lower than that any time soon. No matter. I’m coding again and once more feel like a contributing member of the team rather than a roadblock on the way to success. And those chocolate donuts are yummy. - Jon AvnerOutlook REST API beta and Outlook REST API v2.0 Deprecation Notice
Today we are announcing the deprecation of the Outlook REST API beta and Outlook REST API v2.0 and that they will be decommissioned on November 30, 2022. Once past this date, the services will be retired, and developers may no longer access them.Microsoft Ignite 2020 - One Week Away!
In about a week from today Microsoft Ignite 2020 gets underway. It’s quite a bit different this year but the one thing you can be certain of is we have lots of new and interesting content for you to enjoy. This post is to highlight the Exchange, Outlook and Bookings sessions we have created and curated for your viewing pleasure. The links won’t be live until the event starts, but we wanted to give you a peek into what to expect.
