When it comes to sizing a typical on-premises Exchange Server deployment, Microsoft has really gone out of their way to provide all the information you need. Along with the Mailbox Role Requirements Calculator, I believe Microsoft’s guidance to be one of the most complete in the industry—–leaving little to the imagination and with clear guidance on what you should and shouldn’t do.
In the world of hybrid headaches, directory synchronization is the root of all evil. While there's nothing wrong with using directory synchronization (I'm a big fan), most of the issues and questions I encounter when dealing with hybrid issues are a direct result of not understanding directory synchronization and how the process works.
Topics: Azure active directory
A little over two years ago, I wrote about an issue I encountered with a KEMP load balancer and how Microsoft performs hybrid mailbox moves. More specifically, the issue evolved around a seemingly different interpretation between KEMP and Microsoft regarding the implementation of the expect 100-continue header. As I noted then, the workaround was to configure the KEMP load balancer to ignore the 100-Continue rules as described in RFC 2616.
A while ago, my good friend Bhargav Shukla reached out to me informing me that KEMP had tracked and solved the problem I described back then. As it turns out, Microsoft had based their interpretation of the expect 100-Continue header on RFC 7231 which superseded RFC 2616. I believe KEMP based itself on the latter, ultimately leading to the issue I described. This illustrates that it’s not always easy to keep up with the fast pace in the tech industry…
Consider the following scenario: you are about to implement directory synchronization for Office 365. You have multiple Active Directory sites across several, geographically dispersed, locations all over the world. Unsurprisingly, some of these locations have better connectivity than others and you might not want AAD Connect to connect to Domain Controllers in locations with a slow or high latency connection at the risk of slowing down the entire process.
When Azure AD Connect connects to a new forest, it uses DNS to locate domain controllers it needs to connect to. Without additional configuration, it is very difficult to control or know exactly which Domain Controllers AAD Connect will connect to. I believe that within the domain it is installed in, AAD Connect will try and connect to Domain Controllers within the same site first –but I’m still waiting on getting that confirmed. Even if that is true, that would not necessarily be the case for remote forests as there is no way for AAD Connect to know which site in the remote forest is closest.
Once AAD Connect is installed, you will find that it is relatively easy to define a (static) list of Domain Controllers that AAD Connect should connect to.
Over the past few years, Microsoft has made many attempts to do away with public folders. If you have had the pleasure to work or are still working with Exchange 2007 and Exchange 2010, I’m sure you’ll remember the many rumors about Public Folders being deprecated in “vNext”. Yet, they still exist today in Exchange 2016 –although not in exactly the same form as in earlier versions of Exchange. Not only do they still exist, but Public Folders are still widely used! It’s not unheard of that a company has several million public folders representing terabytes worth of data.
Many administrators reacted surprised when Microsoft first announced “Modern Public Folders” back when Exchange 2013 was introduced to the world. Modern Public Folders offer the same exact user functionality as traditional public folders, but align with Microsoft’s efforts to improve high availability using Database Availability Groups. Traditional Public Folders, which were stored in separate Public Folder databases, did not fit into that paradigm. Even more so, because of that architecture with separate databases and no real HA story, Microsoft could not really support Public Folders in Office 365. To be honest, I am almost certain that Microsoft made the changes to the Public Folder architecture so that they would be able to offer them in Office 365. The fact that on-premises customers can now take advantage of those advancements is an added bonus.
Directory-Based Edge Blocking (DBEB) is a feature in Exchange Online Protection which automatically blocks email messages sent to recipients that do not exist in the Office 365 tenant. By default, DBEB is enabled for every domain in the tenant.
…that Mailscape 365 includes latency trending reports which allow you to monitor and report on connection latency and end user transaction times?
In Windows 10, Microsoft introduced “Windows Hello” which – to keep things simple – offers the ability to use biometrics to unlock a computer instead of using a regular password. Windows Hello was demoed fairly early on in the Windows 10 development cycle, and there was lots of excitement in the tech press about it, but the fact that you can use biometrics for authentication purposes is not really new; especially in building access control where biometrics havealready been used for many years to verify someone’s identity before granting access to certain areas of a building. Given this, you might wonder what is so special about Windows Hello. The answer lies in the combination of Hello with another feature.
Along with Hello, Microsoft introduced another new feature that didn’t get as much attention: Microsoft Passport. The simplest way to think of Passport is as a replacement for reusable passwords. While Hello can be used to unlock a credential, Passport lets you replace traditional passwords with much stronger cryptographic credentials.
Passwords are, because of the way people use them, inherently insecure. In recent years, researches have suggested that moving from regular passwords to passphrases could help solve the problem of short (even if complex) and insecure passwords. The following xkcd cartoon clearly illustrates that point:
Topics: Office 365
A few weeks ago, Microsoft released Exchange 2016 to the public. By now, some of you will have had the chance to play with the latest member in the Exchange Server family and perhaps have formed an opinion on whether it’s something you are willing to consider upgrading to now, or after few more Cumulative Updates have been released.