Office 365 Multi-Geo Part03 (Configuring)

This is the part 03 of this article series where we will be going through the technical part of enabling Multi-Geo in Office 365.

Support_Wrench_Cog_Tools_Repair_Fix_Gear-512

Part 1: Get Started

Part 2: Planning and recommendation

Part 3: Configuration

Let’s ensure that we have the following in place before get started.

  1. Office 365 Multi-geo capability is added to the tenant. As the introductory article stated, this capability is a user-level service plan that is optional for you to add. If you have worked closely with your account team this might be all set to go by now.
  2. Test users created and are ready to use.

If you have enabled the Multi-geo, a new tab call “Geo Location Tab” should now appear under the settings in SharePoint and OneDrive admin panels.

To add new geo locations, open the SharePoint admin center –>
Navigate to the Geo locations tab. Click Add location –> Select the location that you want to add, and then click Next –>
Type the domain that you want to use with the geo location, and then click Add –> click Close.

Every new location that you add here are called “satellite locations

3

If everything went well, you will receive an email notification in few hours after provisioning. It could take up to 72 hours which is up to the size of your tenant.

As the new geo location appears in blue on the map on the Geo locations tab in the OneDrive admin center, you can proceed to set users’ preferred data location to that geo location. Usually a new satellite location comes with the default settings, it gives you the freedom of localizing as per your compliance needs.

After you enabling the satellite locations, it is recommended to set the preferred Data Location (PDL) for every user in the directory. In Azure AD there are two types of identities as Cloud and Synchronized. You have to follow the right instructions to deal with each of them when it comes to setting PDL.

Setting PDL for cloud only users (Azure Users)

User objects that are not synchronized from a local AD are the cloud ones. You have to use Microsoft Azure AD PowerShell to set this configuration for such users. This procedure needs Azure AD Module for Windows PowerShell

  1. Launch Microsoft Azure Active Directory Module for Windows PowerShell

Run the following line and enter the Admin Credentials for your Office 365 tenant.

Connect-MsolService

2. Now let’s run the next line to set the PDL for a specific user.

Set-MsolUser -userprincipalName manoj@mantoso.onmicrosoft.com -PreferredDatalocation AUS

3. To find out if this has executed properly, you can use the following command. It should return the new PDL value.

(Get-MsolUser -userprincipalName manoj@mantoso.onmicrosoft.com).PreferredDatalocation

Notes: During the new user creation process, its recommended that you include setting PDL command at the end of the workflow, so that you do not have to do it as a separate task.

User with no OneDrive provisioned yet, better be wait for at least 24 hours in order to allow the change to propagate in the backend. This ensures that  OneDrive sites are provisioned in the correct PDL for such users.

Setting PDL for Synchronized users (Hybrid Users)

Setting the preferred data location for Hybrid users is a bit lengthy process and is well explained in this post.

Search Experience in a Multi-Geo Setup

Every geo location acts as a Search Index (you must be familiar with this term if you are a SharePoint guy) in a Multi-Geo setup. When there is a search query, the results are usually returned as a merged result out of all indexes, which means all these satellite locations we added are works together behind the scenes towards one goal.

9

Following search clients are supported in Multi-Geo

  • OneDrive for Business
  • Delve
  • The SharePoint home page
  • The Search Center
  • Custom search applications that use the SharePoint Search API

Consult this detailed article to understand and configure the search experience in a Multi-Geo setup.

End user experience validation

Validation is utmost important before you roll out the change widely across the organization. Following are some key scenarios for you to try out using test users before make it to everyone.

OneDrive Portal

Click on to OneDrive from the Office 365 App Launcher. You should be directed to the defined geo location automatically, and it will now begin to provision the service in that PDL. After provisioning, try to upload and download some files and ensure everything works as expected.

OneDrive App

Use a mobile device to login to the OneDrive App using the test account that you used to upload the files and verify if the files are available in the mobile and you have to the control to perform actions on those files.

OneDrive Client

Use a laptop or a desktop to verify if the OneDrive Sync client works are expected. You can download the latest client by heading on to the OneDrive Library and click “Sync”. this will prompt you to download the client automatically if it doesn’t exists in the particular device.

Office Integration

Open up Word or Excel and check if your OneDrive location appears there. Try to save a file to OneDrive from there and ensure they are synchronized across your devices.

Sharing Experience

Despite any of these changes we did, you should be able to share a OneDrive file seamlessly (based on your compliance settings). To verify, try to share a file from OneDrive and confirm that the people picker allows you to add any user within the organization regardless of their location.

Advertisement

Office 365 Multi-Geo Part02 (Planning and recommendations)

Multi Geo capability is a little complex topic to wrap up in a single article as Office 365 is a diverse platform with multiple set of business tool offerings. Eventually, Multi-geo configuration can affect to most of these workloads at highest level. That’s where the whole article was split in to 4 stages in order to give you a better and comfortable reading experience with necessary breaks.

Part 1: Get Started

Part 2: Planning and recommendation

Part 3: Configuration

Part 4: Managing and Maintaining

I have gone through the introductory and concept briefing in the part 01 of this article series. Now let’s continue with this 2nd stage which describes planning and recommendations for Office 365 Multi-geo.

Test run – Highly Critical

4

Try out with a test user/s first. Consider having some test users for each use case as shown below and try out the changes with these users before you roll out in production.

  • Have an existing test user who has an active Office365 account with Exchange, SharePoint, OneDrive being used (with available content)
  • Try to add the capability for this user only
  • Move the user to new PDL
  • Move OneDrive content accordingly
  • Test the functionality for Exchange, OneDrive and SharePoint


Initial rollout (pilot run, targeted run) – Critical

5

After you have tested with the above single user, use a small group of people (5 would be ideal) as the pilot run. In most cases this group would be from IT staff as they are well aware of the approach and changes, technically.

every user should have the preferred data location (PDL) defined so that when the new workloads are created (such as those who do not use OneDrive right now perhaps later) they’ll be provisioned in the new PDL. Office365 will use central Location for those users with no PDL defined. The recommendation is, better to set PDL for all users.

Prepare a list of users with their User Principle Name (UPN) and include your Test users, pilot users and other groups batches in order. This will help you in the configuration stage and will make the procedures easily and well tracked.

Considerations for Hybrid Scenarios

Azure AD Connect supports Multi Geo by allowing synchronization of the PreferredDataLocation attribute for user objects from AADC version 1.1.524.0 onwards. However, this may vary for each organization  and if you are fully cloud with no on-premise dependency, please ignore.

The schema of the object type User in the Azure AD Connector is extended to include the PreferredDataLocation attribute. The attribute is of the type, single-valued string.
The schema of the object type Person in the metaverse is extended to include the PreferredDataLocation attribute. The attribute is of the type, single-valued string.

PreferredDataLocation attribute is not synchronized by default. This functionality is currently intended for larger organization (Its eventually the size than the scenario at the moment). You have to plan for an Local AD (on –premise) attribute which will hold the “Office 365 Geo Location” for your hybrid users as there is no PreferredDataLocation attribute by default in on-premise Active Directory. Further, PreferredDataLocation attribute can be managed by PowerShell for Azure Cloud User Objects but not for Synchronized Objects. For synchronized objects (Hybrid), you must make use of AD Connect application.

Before you start on technical configurations, I would highly recommend you to digest these articles and beware of the outcomes:

stay tuned for the part 03 (technical steps)

DISCLAIMER NOTE: This is an enthusiast post and is not sponsored by Microsoft or any other vendor. Please do not copy/duplicate the content of the post unless you are authorized by me to do so.

Azure AD App Only Authentication

In a simple way, App Only authentication is the ideal method if you want to execute  a task by daemon. This allows you to execute some code without the permissions of a user or without an auth token of a user.

As part of a series of articles, idea of this 1st post is to give you an basic  fundamental understanding on creating an Azure AD App and grant permissions for this App to communicate with SPO.

let’s get this started. Simply head on to your Office365 home page and switch to Admin Centers. From the left pane, click on “Azure Active Directory”. From Azure AD, search for “App Registrations” and click “Add new application registration” link.

A new application interface will pop-up for you. Enter a name, Application type and Sign-on URL and click “Create”. Sign-in URL can be any and it also can be amended later to reflect a different one. A future post will discuss this again on what sort of URLs are used here.

image 

Once the app creation done, you will be given with the app ID and other details related to it.

image

Next- Select Settings –> Required permissions and Add

clip_image001

clip_image002

In this case the API going to be SPO. You can choose the right API based on the requirement.

image

Next, hit “Grant Permission” button on the required permissions tab to provide none-tenant admin user access the application.

A self-signed or public (commercial) certificate must be provided now and then update the Azure AD manifest accordingly.

Following PS can be used to provision the certificate but ensure you have installed OfficeDev PnP PowerShell.

$certroot = 'C:\Site Creator'
$certname = "IntelAi-Cert-1"
$password = ConvertTo-SecureString "P@$$w0rd" -AsPlainText -Force
$startdate = Get-Date
$enddate = $startdate.AddYears(4)
makecert.exe -r -pe -n "CN=$certname" -b ($startdate.ToString("MM/dd/yyyy")) -e ($enddate.ToString("MM/dd/yyyy")) -ss my -len 2048
$cert = Get-ChildItem Cert:\CurrentUser\My | ? {$_.Subject -eq "CN=$certname"}
Export-Certificate -Type CERT -FilePath "$certroot\$certname.cer" -Cert $cert -Force
Export-PfxCertificate -FilePath "$certroot\$certname.pfx" -Cert $cert -Password $password -Force

Following line will copy a string to your clipboard

Get-PnPAzureADManifestKeyCredentials -CertPath 'C:\Site Creator\IntelAi-Cert-1.cer' | clip

Following is how the copied string would look like. It has to be added to the manifest file of the Azure AD application.

"keyCredentials": [
 {
  "customKeyIdentifier": "5lca+kziogw7T6MB4kUrxseK5m8=",
  "keyId": "84153f1a-90b7-4802-b99a-bb75d4f9a35b",
  "type": "AsymmetricX509Cert",
  "usage": "Verify",
  "value": "MIIDAjCCAe6gAwIBAgIQkawCJU0cWYxH8RamKNuqqTAJBgUrDgMCHQUAMBkx
 }
],

Select your application under app registrations in Azure AD. Replace the “KeyCredentials”:[], section, as shown below.

image

Now this can be tested whether the application has required permissions to connect to the SharePoint Online site. For the ClientID, you need to provide application ID of the app you have created.

$password = ConvertTo-SecureString "P@$$w0rd" -AsPlainText -Force
Connect-PnPOnline -Url https://site.sharepoint.com/ -ClientId 0c01f61e-ba27-4ae7-ab19-174884a949fc -CertificatePath 'C:\Site Creator\Site-Cert-1.pfx' -CertificatePassword $password -Tenant intelai.onmicrosoft.com
$myWeb = Get-PnPWeb
$myWeb.Title

DISCLAIMER NOTE: This is an enthusiast post and is not sponsored by Microsoft or any other vendor.

Azure AD Conditional Access for Office 365 (Exchange and SharePoint Online) Preview Release

Yesterday Microsoft announced one of the most awaited feature for Office 365, “Azure AD Conditional Access Preview” for SharePoint Online and Exchange.

What is Conditional Access and What it is for ?

Security has been one of the key elements in systems for decades but for the present time it needs to be much more comprehensive than ever before with the evolvement of the cloud and mobile era. With the rise of devices used by a person and the ability to access corporate resources from anywhere in the world, there is a massive demand of securing corporate resources. Ultimately the latest strategies of securing corporate resources are defined by the new ways which users are used to accessed them.

Microsoft has taken another big leap of security capabilities with this release today. Azure Active Directory Conditional Access Features Allows you to secure and manage your corporate resources in simple ways in cloud or even on premise. If you want to ensure an stolen user credential or unmanaged device will not harm your corporate resources, Azure AD Conditional Access if made for you.

clip_image001

How is the access Enforced

Generally when a user signs in to a service, Azure Active Directory checks whether the security inputs of this user meets the access requirements you defined. and if the requirements are met, user will be authorized to access the service or application.

The enforcement can be done in two ways. You can define policies to configure the access either way, for users or devices.

  • User based Access (Control who you want to allow access)

User Attributes – User Attributes level can be used to define policies of which users can access organization’s resources.

Group Membership of a User – or either based on the Group/Groups of user which he/she represents in.

Multifactor Authentication (MFA) – Multifactor Authentication can be configured to ensure better security. User has to provide more than one factor (Password) which could be either a PIN or Phone Number. That ensures extra level of security for your organization’s resources.

Sign-in and User Risk – This capability known as “Conditional Access Risk Policies” comes with Azure AD Identity protection. This will allow you to track unusual sign in activities and risk events based on the access trends and implement advance protection. Global and Multi-region companies will benefit a lot with the capability.

  • Device Based Access (Control what you want to allow access)

Enrolled Devices – Using Microsoft Intune, you can use Device Level Access to control only MDM (Mobile Device Management) Enrolled devices are allowed to access resources. Intune is capable to validate if the device is enrolled with MDM. Also device level access will ensure that only the matched devices with the policies (such as force file encryption on a granted device) you have configured are allowed to access. Even you can flush out the content of a device remotely which was stolen or misused using MDM solutions.

The best part is, It’s not just limited to the cloud, you can also use device based access policies to control your on premise resources or even cloud based SaaS or line of business applications.

What does this Preview Brings you?

This release is a much awaited capability for most of the organizations and a huge step on the Access Policy framework. Conditional Access for CRM and Yammer been already there but Specially for SharePoint and exchange, the call has been ringing there for quite long time.

These three conditions are released for SharePoint and Exchange online as preview. Microsoft Recommends to enable these policies alongside risk based conditional access policy available with Azure Identity Protection.

  • Always require MFA
  • Require MFA when not at work
  • Block access when not at work

Conditional Access Policies are supported in Browser based access to Exchange Online, SharePoint Sites and OneDrive and even for Desktop Applications that uses modern authentication mechanisms.

Across the mobile devices, these are the tested desktop and mobile applications connects to Exchange and SharePoint so far by Microsoft.

  • For Windows 10, Windows10 Mobile, Windows 8.1, Windows 7 and Mac
  • Outlook, Word, Excel and PowerPoint in Office 2016
  • Outlook, Word, Excel and PowerPoint in Office 2013 (with modern authentication enabled)
  • OneDrive Sync Client (with modern authentication)

For IOS

  • Outlook Mobile App

Resources:

Detailed Explanation of Azure Ad Conditional Access

Conditional Access Policy Support for Mobile Devices

Original Announcement