Another year, another slew of exciting Exchange and Office 365-related news. To give you a glance at top events, insights and conversations of 2016, we've compiled a list of our favorite blog posts of the year. Browse through these posts, and let us know others you'd add to the list!
One of the most important aspects of moving to a cloud solution like Office 365 is to provide a way for users to authenticate to their cloud resources. Organizations typically want to reduce administrative overhead and user confusion by managing only one directory, be it the on-premises directory (AD) or the cloud directory (Azure AD).
Ignite ended about a month ago, and it’s time to start exploring some of the new features and services that were introduced in Atlanta. In this article, we will take a look at Azure Information Protection, the next chapter in Microsoft’s data protection story.
Since the introduction of Office 365, and even before that with the ironically named “BPOS,” Microsoft has had several different solutions for cloud identity management. These solutions have ranged from bad to confusing. The solutions that have been easy to use have lacked good functionality, and the solutions with enterprise functionality have been difficult and costly to deploy.
Without any big announcements, a preview version of the Azure AD PowerShell module was released last week. In this article, we will go over the release in a bit more detail and cover some of the changes in comparison with the MSOnline module.
Azure Rights Management Service (RMS) is an information protection solution, the cloud-based version of AD RMS. The service has been rapidly evolving in the past few months, introducing features such as: the Tracking portal, which gives users the ability to audit the consumption of their protected content and revoke access if needed; full multi-factor authentication support across all RMS clients; the RMS protection tool, which provides PowerShell cmdlets to bulk (un)protect files and replaces the AD RMS Bulk Protection Tool; the Azure RMS usage logs; and more.
A few weeks ago, I wrote a blog post here covering how to deploy Azure Active Directory Connect 1.1. Due to popular demand, today I'm going to circle back and review some of the advanced configurations of AAD Connect as well as some troubleshooting tips to cover you in case you run into a hitch with your AAD Connect deployment.
Active Directory Synchronization for Office 365 and Azure has been a vital, but fairly straight forward, part of Office 365 migrations for almost 5 years now. DirSync was updated to Azure Active Directory Sync, and AAD Sync was updated to Azure Active Directory Connect. In this blog post, I’m going to cover everything you need to know about deploying the newest version of AAD Connect.
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.
On December 3, Microsoft had an outage that affected their Office 365 service for customers in most of Europe. More precisely, the outage was actually in Azure Active Directory.