Recently, one of my customers reached out to me stating they were having trouble delivering emails due to SPF failures. While it’s not uncommon for SPF checks to fail (you don’t want to know how many organizations struggle implementing SPF records correctly!), I was a little surprised. After all, the customer had successfully implemented SPF records for quite some time now, and rarely ran into issues with it. In fact, they are quite the example for some of my other customers as their SPF policy is set to a hard failure. Needless to say: a lot of effort went into it, to ensure their SPF records were correct/up-to-date/etc. However, that's not the point here. What follows is an overview of what we've discovered during our troubleshooting. To me, it revealed some interesting routing logic in EOP –some of which is barely (not) documented.
ENow Software's Exchange blog built by Microsoft MVPs for IT/Sys Admins.
Michael Van Horenbeeck MVP, MCSM
Michael Van Horenbeeck is a Microsoft Certified Solutions Master (MCSM) and Exchange Server MVP from Belgium, with a strong focus on Microsoft Exchange, Office 365, Active Directory, and a bit of Lync. Michael has been active in the industry for about 12 years and developed a love for Exchange back in 2000. He is a frequent blogger and a member of the Belgian Unified Communications User Group Pro-Exchange. Besides writing about technology, Michael is a regular contributor to The UC Architects podcast and speaker at various conferences around the world. You can follow Michael via twitter (@mvanhorenbeeck) or his blog michaelvh.wordpress.com.
Over the past two weeks, Microsoft has made a range of announcements around updates and new releases of Office, Office 365 and Exchange. The fact that Microsoft announces updates is hardly surprising. By now you should be used to the never-ending cascade of new features that are constantly dropped onto the market. A good way to keep track of what’s to come is the Office 365 Roadmap website.
Earlier this week, Tony Redmond wrote about Jeffrey Snover – also known as the godfather of PowerShell – being promoted to Technical Fellow at Microsoft; one of the highest achievable ranks.
Given that Jeffrey is considered to be the founding father of PowerShell, that does not really come as a surprise, as PowerShell has changed the way we work and interact with systems. And this does not only apply to large-scale environments or cloud solutions like Office 365.
A few days ago, Microsoft released the public preview of Exchange 2016 to the world. For many messaging professionals, this is usually an exciting time. But is it really? I remember when Exchange 2007 'hit the market.' I spent quite a few long days and nights discovering the new features and dramatically changed architecture. Pretty much the same happened when Microsoft unleashed Exchange 2010. The newly minted Database Availability Group kept many people – including myself – fascinated and busy for a long time. One of my fondest memories about that time was a hefty, yet in hindsight very funny, discussion that followed a technical presentation at my former employer.
On June 16 2015, Microsoft released Cumulative Update 9 for Exchange Server 2013 along with Update Rollup 10 for Exchange Server 2010 and Update Rollup 17 (yes, that many already) for Exchange Server 2007.
Unfortunately for some, Update Rollup 9 looks like it's going to be another uneventful update —provided that no post-installation issues arise. Except for changing where Sent Items are stored when a message is sent as or on behalf of a Shared Mailbox, Microsoft reported no new features or changes in existing functionality. That is not too surprising, given that Exchange Server 2013 is now in its third year.
Yesterday, Microsoft issued its monthly security bulletin. This time around, the bulletin also includes a fix for a vulnerability that affects only Exchange 2013 environments.
When designing for a migration to Exchange Server 2013, chances are you’ll have to deal with public folders. Given that Exchange 2013 has been around for a while, you might think such a task would be a proverbial walk in the park. Of course, if you are looking at a cookie-cutter environment, you might be right. However, in every design there are elements specific to the customer that require a different approach.
More specifically, consider the scenario in which you have public folders — possibly lots of them. For the sake of this article, let’s assume you have about 500GB worth in public folders spread over several thousand public folders across one or more replicas. For some customers, these numbers are much more than they have. For other customers, 500GB in public folders might just be a fraction of what they have to deal with. Regardless of your situation, public folders raise a rather interesting question: How do you plan for (a migration of) public folders to Exchange 2013?
On March 17th, Microsoft released Cumulative Update 8 for Exchange Server 2013. By now, we're all used to the idea that cumulative updates and not only Service Packs have also become a vehicle to introduce new features into Exchange. Hence, it is no surprise that CU8 comes with a bunch of new features and improvements alongside a myriad of bug fixes.
It has been since Cumulative Update 5 that Microsoft introduced new "hybrid" features. So you can imagine how pleased I was to learn that CU8 contained a rather important improvement with regards to hybrid deployments.
Before we dive into the feature itself, let me give some background information on the problem the feature will help to solve. A hybrid deployment is often deployed to allow the so-called "hybrid mailbox moves", sometimes you'll also see them referenced as "MRS moves" or "remote mailbox moves". Regardless of what name you use, in my opinion these mailbox moves offer significant value over other migration methods. The simple reason being that hybrid mailbox moves are more resilient, more flexible and almost transparent to the end user. In a staged- or cutover migration, once a mailbox is moved, Outlook's offline cache (.OST file) has to be recreated. While you might think this is not really a problem, try and imagine how that would feel like for an organization that has limited bandwidth but has several hundred gigabyte worth of mailbox data. In such scenario, if you can avoid having to download the data which you just have 'uploaded' to Office 365, then that is something you would want to look into.
Update 02/13/2014. By popular demand: added a “Lost modified on:” field which display the date on which one of the settings on the virtual directory was last modified.
Update 02/12/2014. Added some new features to the script. If you add -ADPropertiesOnly when calling the script, it will now only query the ADProperties which processes a whole lot faster in distributed environments. The script now also automatically creates a Remote PowerShell session if it cannot find an active one to use. It will connect to the server you specify with the -ComputerName parameter. If you choose not to specify the parameter, the script will create a remote PowerShell session to the localhost. Thirdly, there’s now also a -Filter parameter which allows you to filter the server(s) for which you want the see the results.
The following command would query all CAS’es in the environment which have “02″ in their name and return the ADproperties for the different virtual directories:
As described in the Office 365 CON 2014 Virtual Conference sessions, “Stairway to heaven – Best practices for Hybrid Deployments”, it is very important that you validate your on-premises environment before getting started with the hybrid bits.
The reason why this is so important has to do with the many interactions between Office 365 [the cloud] and your on-premises environment. Let’s take a look at what components are at stake here.
First there is the directory synchronization [DirSync]. DirSync is the cornerstone for hybrid deployments as it ensures that objects are correctly synchronized between your on-premises environment and Office 365 and it ensures the behavior is consistent across both environments. It is also the enabler for easily onboarding and off-boarding mailboxes to/from Exchange online. Assuming that you will start your hybrid deployment by setting up DirSync, you will need to make sure that you on-premises Active Directory is in a healthy state. By “healthy” I’m not only referring to as replicating properly. Office 365 – Windows Azure AD – expects certain object values. It does – for instance – not accept malformed object attributes whereas on-premises Active Directories do in certain cases. Although DirSync reporting will automatically send you an e-mail report when one or more objects have synchronization issues, it’s always better to make sure you don’t run into these issues in the first place. Another requirement is to make sure that you on-premises User Principal Names [UPNs] match a domain in Office 365. This is particularly important when setting up Identity Federation [ADFS] afterwards.