Before speaking to a customer, it is often helpful to understand what technology they may have deployed.

By checking for the existence of DNS records in Public DNS, you can get a good idea on the email system and whether they have an Office 365 tenant established, whether they use ADFS and whether Lync or Skype have been deployed.

Peter Schmidt (MVP) authored a script on the Technet script gallery called Get-Office365DNSRecords.ps1. I enhanced the script to include more error checking and to check for common ADFS records.

For example, when checking Microsoft.com you find lots of Microsoft technology deployed.

However, when checking Google.com, you can see they have not been an adopter of Microsoft technology.  Hmm… wonder why.

Reports

In addition to the on-screen information, this script also outputs two files: results.txt and report.csv. The text file contains the DNS records that were found and the CSV file contains a formatted report of each service that was found for each domain name checked.

Download

Download from the Script Center on TechNet here
Tips:

– Remember to set the execution policy to allow unsigned PowerShell scripts, and that has to be done in an elevated PowerShell session.

– You may need to unblock the script (see this article for more information on how to unblock)

In my last blog post, I wrote about how the new workload specific role feature in Office 365 grants too much administrative ability when you simply want to restrict access to VIP mailboxes.

In this blog post, I will describe how you can create management “Scopes” to define boundaries so that external helpdesk organizations will not have the ability to manage your executives.

“Exclusive scopes are a special type of explicit management scope that can be associated with management role assignments. Exclusive scopes are designed to enable situations where you have a group of highly valuable objects, such as a CEO mailbox, and you want to tightly control who has access to manage those objects…
This behavior is similar to how a deny access control entry (ACE) on an Active Directory access control list (ACL) functions.”

This example creates an exclusive recipient filter-based scope that matches any user with “Executives” in the AD department field (this has to be run in a remote powershell session against Exchange Online):

New-ManagementScope “Executive Users Exclusive Scope” -RecipientRestrictionFilter { Department -Eq “Executives” } –Exclusive

or based on Job Tile

New-ManagementScope “Executive Users Exclusive Scope” -RecipientRestrictionFilter { Title –like “*Executive*” } –Exclusive

Or based on a custom attribute (you get the idea…

New-ManagementScope “Executive Users Exclusive Scope” -RecipientRestrictionFilter { CustomAttribute5 –eq “VIP” } –Exclusive

The next step is to assign the exclusive management to a group of highly trusted administrators. Anyone not on the list cannot manage the VIP mailboxes.

New-RoleGroup -Name “VIP Mailbox Administrators” -Roles “Mail Recipients”

At this point you can add add users or security groups into the VIP Mailbox Administrators role group.

Finally, this next command glues the RoleGroup to the Exclusive scope filter:

New-ManagementRoleAssignment -Name “VIP Mailbox Administrators” -SecurityGroup “VIP Mailbox Administrators” -Role “Mail Recipients” –ExclusiveRecipientWriteScope “Executive Users Exclusive Scope”

Going a step further…

The above commands lock out an external helpdesk from being able to manage your executives. But what if you want to restrict your external helpdesk even further, so that the actions they take on the rest of your users are limited as well?

You can create a custom role assignment for your external helpdesk that enables them to manage certain things but not others. For example, if you want to give them the ability to manage Archive rules, you would grant them the  “Retention Management” role.

If you want your external helpdesk to manage ActiveSync policies on mailboxes and remotely wipe lost devices, see this article for more information.

In addition to “Retention Management” and the custom ActiveSync role described above, the other fine-grained roles to consider granting to your external helpdesk would be:

– UM Mailboxes (allows external helpdesk to enable voicemail on new mailboxes)

– View-only Recipients

– View-only configuration (this allows the external helpdesk to view non-recipient configuration such as transport config)

– Distribution Groups (this allows the external helpdesk to create distribution groups)

– Legal Hold (this allows the external helpdesk to place a mailbox on Legal Hold)

– Retention Management (this enables the external helpdesk to setup and manage Archives roles)

Note: If you stop here, the external helpdesk does not have enough permission to grant themselves the “full mailbox” permission to read the inbox contents of the VIP mailboxes, or any mailbox for that matter. By default, there is an implicit deny ACL that prevents an Exchange Admin from having full-mailbox access to read the contents of a mailbox. If you want the external access to be able to read the inbox of any end-user, then a nightly scheduled task can explicitly grant full-mailbox permission to all mailboxes except for the 5 VIP users, because there is already an implicit deny for all admins on the 5 VIP mailboxes. I would not recommend doing this as it should be exceptionally rare when a helpdesk user needs to read the contents of someone’s mailbox. You can consider having them escalate to the internal helpdesk when this need occurs and then it can be controlled.

The external helpdesk would manage Exchange by logging in directly to the ECP here:
https://outlook.office365.com/ecp

This is great – but what if you need your external helpdesk to add or remove O365 licenses? No problem – you can grant them the “User Management Role” in the O365 Admin Portal. This is a great role because it does not have any corresponding role mapping in Exchange Online. So you won’t be giving them any additional privs on mailboxes with this role.

The “User Management Role” in the O365 Admin portal is also how you would allow your external helpdesk to create a mailbox. This is because by simply assigning an Exchange Online license to a user – this is the actual step that does the mailbox creation.

One of my colleagues recommends this SaaS provider “delegate365.com” that can also create exclusive management scopes for you without you having to be an Exchange expert to set this all up. For example, you would just have your external helpdesk logon to delegate365.com to access some but not all of your users. They offer a 30 day free trial that you can use to evaluate whether it would meet your specific needs.

Many customers would like to reduce the number of Office 365 Global Admins to a small handful, while granting service specific admin roles to designated administrators.

Workload-specific admin roles began rolling out on June 11th, 2015 and provide more flexibility to organizations that want to structure admin access to Exchange Admin Center, SharePoint Admin Center, and Skype for Business Admin Center. For example, an Exchange admin will no longer require Office 365 global admin rights to manage Exchange Online. You can now give your SharePoint admin the ability to manage SharePoint site collections without giving them rights over your Exchange environment.

I’m going to grant John Doe the Limited Admin role of Exchange Administrator.

In addition to being an Exchange Administrator, John will also have the ability to perform six tasks in the Office 365 Admin portal:

• View organization and user information
• Manage support tickets
• View users and roles
• View user licenses
• View service health and message center posts
• Manage reporting

Limiting Access to Executive Mailboxes

Now, let’s assume a company wants to grant Exchange Administrators access to all mailboxes except a group of VIP users. In this case, you should not grant the user the limited role of Exchange Administrator, because that would give them too much access (Organizational Administration – the highest rights within Exchange). Instead of granting them rights within the Office 365 Admin Portal, you should instead create a role in the Exchange Admin center such as “View-Only Organization Management” and then grant them full mailbox access on all users except for the VIP users. This script could be scheduled to run as a scheduled task so that these limited admins would be granted access to new employees (or you would update the new employee onboarding account creation process to grant these admins full mailbox access to the new employees).

For these limited admins, they will not logon to the Office 365 Admin center (portal.office.com) but instead they will logon directly to the Exchange Online Control Panel at https://outlook.office365.com/ecp

After applying the June update to Office 2016 (Preview) 16.0.4201.1002, my OneNote notebooks would not open. The error message was that there were no accounts associated with an active Office 365 subscription. This was a bogus error because all my other Office Applications worked fine, and it only affected OneNote. I deactivated Office from the Portal, and then re-activated it – with no improvement.

The fix was to go into Control Panel and launch an Office Repair (The Online Option, not the Quick Repair).

Exchange and Exchange Online have had decent mobile management capabilities through ActiveSync policies prior to the March 30th 2015 announcement of new MDM capabilities for Office 365.  For example, using Activesync you could require a pin to unlock a smartphone after a period of inactivity, wipe a device, and a few other options. You could automatically quarantine new devices that attempted to connect to ActiveSync.

This blog post is a review of the newly announced MDM capabilities in O365.

• Conditional Access—You can set up security policies on devices that connect to Office 365 to ensure that Office 365 corporate email and documents can be accessed only on phones and tablets that are managed by your company and are compliant. Behind the scenes, Office 365 leverages Microsoft Intune and the Microsoft Azure Active Directory to deliver this capability. The Conditional Access policies apply to Office applications such as Word, Excel, PowerPoint and other business applications—making management easier for admins while ensuring users can securely work with their preferred productivity applications.
• Device management—You can set and manage security policies such as device-level pin lock and jailbreak detection to help prevent unauthorized users from accessing corporate email and data on a device when it is lost or stolen. Additional settings and rich reporting are also available within the Office 365 admin center so you can gain critical insights about devices accessing your corporate data.
• Selective wipe—You can easily remove Office 365 company data from an employee’s device while leaving their personal data in place. This is an increasingly important requirement as more businesses adopt a “bring your own device” (BYOD) approach to phones and tablets.

Requirements

You can use MDM for Office 365 to manage many types of mobile devices like Windows Phone 8.1, Android version 4+, iOS devices running version 6+.  Management of BlackBerry devices isn’t supported by Mobile Device Management for Office 365, but you can still use the free BlackBerry Business Cloud Services (BBCS) from BlackBerry to manage BlackBerry devices.

To manage mobile devices used by people in your organization, each person must have an applicable Office 365 license and their device must be enrolled in MDM for Office 365.

How it works

The following diagram shows what happens when a user with a new device signs in to an app that supports access control with MDM for Office 365. The user is blocked from accessing Office 365 resources in the app until they enroll their device.

Policies and access rules created in MDM for Office 365 will override Exchange ActiveSync mobile device mailbox policies and device access rules created in the Exchange admin center.

Getting Started

You first need to Activate MDM for your Office 365 Tenant. As of 4/17/2015 – this has not been rolled out to all tenants. You’ll know when your tenant has this capability when you are able to go to Office 365 admin center > Mobile Devices, and then select Get started to kick off the activation process. It may take some time before the service is ready. When it’s done, you’ll see the new Mobile Device Management for Office 365 page.

Update: As of 5/20/15, MDM is starting to appear in Office 365 tenants. Check out Sean McNeil’s blog posts on this topic for a walkthrough:

office365evangelist.com/?p=2487 and office365evangelist.com/?p=2502

Want More?

Microsoft Intune, part of the Microsoft Enterprise Mobility Suite, provides additional capabilities including the ability to restrict the cut, copy, paste and save as functions in the Office Mobile and OneDrive for Business applications.

Intune also provides the ability to provision and manage certificates, Wi-Fi, VPN (device and app-specific), and email profiles automatically for devices that enroll, enabling users to access corporate resources with the appropriate security configurations.

Management Capabilities

The Office 365 MDM management capabilities include the following:

• Wipe an entire device or Selectively wipe Corporate Data while leaving personal data intact
• Block unsupported devices from accessing Exchange email using Exchange ActiveSync
• Configure device policies like mobile device password requirements and security settingsView list of blocked devices
• View what policies have been applied to a device
• Unblock noncompliant or unsupported device for a user or group of users
• Generate detailed report to see devices that are not compliant

Summary

The new Office 365 MDM capabilities allow you to manage the “Office Mobile”, “OneDrive for Business” and Exchange Activesync features by requiring a device to be enrolled and compliant with policies.

References:
Overview built-in Mobile Device Management for Office 365

Choose between Microsoft Intune and Built-in MDM for Office 365

I recently was asked to advise on how cloud identities can be converted to federated identities such that when Azure AD Connect is run for the first time, the on-premises Active Directory takes over as the source of authority. The benefit of doing this is the user would have a single username and password, eliminating the need to have a different password for Office 365 when they already have one for Active Directory. This becomes complicated when an existing tenant exists and users have adopted various things like Teams. In my experience, a license bundle is assigned to the user which includes an Exchange Online license, which then creates a mailbox in the cloud, when the user already has one on-premises.

So how do we merge identities between Active Directory and Azure AD? In some cases, Azure AD will automatically match things (this is known as soft match).  However, when attributes do not line up then what ends up happening is a duplicate account gets created during the first synchronization. This is preventable through a technique known as hard matching, where we force the two objects to merge during the first synchronization.

Azure AD Connect will attempt a soft match if the primary email address attribute exists on both sides AND (the immutable ID matches the ObjectGUID on-premises OR the cloud immutableID is empty) <- see note below for an explanation why this matters. This is best documented on MS KB 2641663 and on Stephanie Kahlam’s blog (here).

However, what if the cloud identity is not enabled for Exchange Online? In that case, there is no primary address for a cloud identity to use for soft matching. For example, if the user was only configured for CRM Online or another O365 service. You could then make the UPN the same on both sides, Azure AD Connect will soft match on UPN too. This is explained in Microsoft documentation (here). This is performed in Windows Azure Powershell for Office 365 with this command:
Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]

In scenarios where neither of those options work, then the only remaining option is to either blow away the cloud account or force the cloud account to use the same Immutable ID as the on-premises AD ObjectGUID (after it is converted into the proper format). This is known as a “hard match.”

In one case, I don’t know why, I had to make the UPN match on both sides, and the hard match too, otherwise I found a duplicate object was getting created in the cloud.

Hard Match “How TO”

To update the immutableID value of the Office365 object to match the on-prem ObjectGUID, you use the get-Aduser powershell command (this is installed on most Domain Controllers and can be installed on member servers). The format of the ObjectGUID must be converted to Base64. You can download the script I use to perform this (here).

Then once you get the ObjectGUID converted, you can run this in Azure AD PowerShell to perform the hard match:
install-module msonline
connect-msolservice
Set-MsolUser -UserPrincipalName [email protected] -ImmutableId RDHiRneDPkiofrZ2nbYu7Q==

Then force Azure AD Connect to run and that should convert the cloud identity to be sourced from on-premises Active Directory.

If the cloud identity ever pre-existed from a previous synced existence (for example, if prior to an ADMT migration, if the account originated from a separate AD forest than where the account exists presently) then soft match will never work – it will throw a bogus error about duplicate proxy addresses in the MIIS GUI. The only solution is to hard match by updating the cloud identity with the new on-prem ObjectGUID (following conversion from the steps above]

Another tip: if the account was being used heavily for Teams, SharePoint, OneDrive, PowerBI, or other cloud workloads, you may want to only remove the Exchange license, however, that still leaves the MailboxGUID from the account left on the object. The only way to clear that from the cloud user is to connect to Exchange Online PowerShell and run this command:

install-module exchangeonlinemanagement
connect-exchangeonline

Set-User [email protected] –PermanentlyClearPreviousMailboxInfo

In a previous blog post, I wrote about the value of the new Office 365 “Groups.” These are a next generation type of group that replaces the function of a traditional distribution group, and includes the benefits of a security group, along with many other rich collaboration experiences. For example, they offer a shared calendar, shared files via OneDrive, shared OneNote, and a group chat experience in OWA. You can use these groups for Azure AD SSO, and the new March preview of AAD-Connect will dirsync these groups to on-premises.

See: Office 365 “Groups” are next generation distribution lists
and Upgrading Dirsync to Azure Active Directory Connect Public Preview – March 2015 update

I was inspired to write this post after reading my colleague’s post on how to update the primary SMTP address: http://blog.ucparticles.com/2014/11/office-365-groups-how-to-update-primary.html

Basically, when a new “Office 365 Group” is created, it gets stamped with an MyTenant.onmicrosoft.com address, for example: [email protected]

In Keif’s blog post above, he demonstrates how to use Exchange Online remote powershell to update the address to match the vanity domain name, ex: [email protected]. This improves aesthetics and mail routing.

• Obtain a list of existing Office 365 Group mailboxes

  Get-GroupMailbox

• Use the following one-liner to update the primary SMTP address

  Set-GroupMailbox –Identity Name –PrimarySMTPAddress groupname@defaultdomain.com (Insert primary domain here)

Keif also posted a powershell script to read from a CSV file and convert the groups to the new SMTP format. Awesome!

So this solves one part of the conversion, which is to get the groups to use the shorter SMTP domain format.

What about the overall process itself? Let’s say you have 100 distribution groups today and you want to convert them all to Office 365 Groups? How would you go about doing this?

Approach #1 – Create a new O365 Group and then add the existing DL as a ‘member’

Approach #2 – Create a new O365 Group and then delete the old DL. Inform users to start using the new Group.

Approach #3 – Create a new O365 Group, delete the old DL and then update the new O365 Group to use the old DL’s SMTP name, or add it as a secondary proxy alias

There are tradeoffs with each approach, but in general you want to select the approach that prevents NDR’s from occurring, and you want to make sure to automatically subscribe the members of the old DL to the new O365 Group so that they don’t have to manually take any action in order to start receiving new emails from the group. In a future blog post, I will walk through the end to end process.

Update 5/20/2015: If you take approach #3,  I now recommend leaving the primary SMTP address as the onmicrosoft.com address, and adding the old DL as a secondary proxy address. The reason for this is because the new Office 2016 Office Client will not display these Groups if the primary address is not an onmicrosoft.com domain name.

There is a new Azure AD feature that allows you to create O365 groups through the Azure Access Panel. This feature is in Preview (Beta) but this blog post is a walkthrough of this as well as exploring the value of O365 Groups.

You can still create groups in the OWA web Interface as well:

These groups are mighty powerful. Not only can they function as AD security groups (in the Cloud only as they don’t sync down to on-premises (yet), but they also function as email distribution groups and shared calendars. They also provide group chat and file sharing capabilities via a dedicated document library in SharePoint Online. You can also have shared OneNote notebooks with your group! You can also assign Azure AD applications to groups for single sign-on (more on that below).
(Note: for a great whitepaper on these capabilities, click here).

Te

To get started, you have to enable the preview functionality in your Azure AD tenant.

Then scroll down to Group Management and enable the group features

Note: I recommend doing this in your demo environment first so that you can evaluate the functionality before turning it on in production, especially since they are ‘preview’ features.

You will notice that a newly created group from the Access Panel will appear as a “Distribution Group” type.

You can edit the group properties to be able to receive email from outside the organization and you can also subscribe new members so that they are notified when new group conversations occur.