Comparing SharePoint 2016 Boundaries and limitations with SharePoint 2013 & 2010

You can examine new improvements in boundaries and limitation whenever a new SharePoint version is coming which are helpful to figure out the best capacity planning for customers. In this blog post I am going to discussing improvements in boundaries and limitations for SharePoint 2016 and there comparison with earlier versions.

From ignite and further updates SharePoint 2016 seems to be a major update which can handle large amount of data. The maximum content database size is still not announced but it will either 1TB or greater which is atleast 5 times greater than the maximum content DB size of existing SharePoint environments (2010 & 2013) which means content can scale in TBs.

The increase in Content DB size means it will be supporting a larger number of site collections and YES a single content database in SharePoint 2016 can hold 100,000 site collections (it requires a huge round of applause) which is 20 times great then the existing ones.

Below table shows the Limits and boundaries of SharePoint 2016 vs SharePoint 2013 Vs SharePoint 2010:

SharePoint 2016 SharePoint 2013 SharePoint 2010
Content Database Size Content database sizing into TB’s 200 GB in general usage scenarios. 200 GB in general usage scenarios.
Site Collections per Content Database 100,000 site collections per content database 2,000 recommended

5,000 maximum

2,000 recommended

5,000 maximum

List Threshold Increased List Threshold >5,000 5,000 items 5,000 items
MaxFile Size MaxFile Size increases to 10GB and removed character restrictions Default maximum file size is 250 MB which can increase up to 2GB Default maximum file size is 250 MB which can increase up to 2GB
Indexed Items 2x increase in Search scale to 500 million items 100 million per search service application.

10 million per index partition

100 million per search service application.

10 million per index partition

There is still time in release of SharePoint 2016 and with final release we can have clear picture on boundaries and limitation and how much they have been improved.

Upgrade Azure AD Sync to Azure AD Connect

As Azure AD Connect is now generally available to replace AAD Sync for synchronize on prem active directory to Azure Active Directory. Now, It’s time to think about upgrading your existing deployment of Azure AD Sync tool and use the latest and greatest code from Microsoft. With Azure AD Connect we can perform an in-place upgrade from Azure ADSync to Azure AD Connect.

You can download Azure AD Connect tool from Microsoft website. Once you download the Azure AD connect tool, perform the following steps to perform an in place upgrade of Azure AD Sync to Azure AD Connect tool.

  • Run Azure AD Connect setup files on Azure AD Sync server.
  • Azure AD Connect setup will automatically detect the existing install of AAD Sync.
  • Accept the license agreement and click on Continue.

Upgrade Azure AD Sync to Azure AD Connect

Make sure that you’ve stopped the synchronization of Azure AD Sync tool during the upgrade. This will not impact your existing configuration/synchronization of AAD Sync tool.


  • Provide your Azure Active Directory admin credentials to connect with Azure AD. This account must be a global administrator. Click on Next


  • Select if you would like to immediately synchronize your identities with office 365 after the tool is deployed. If you have filtering requirements then uncheck this option. Click on Upgrade


  • Once the configuration is completed you’ll see a tip for syncing Windows 10 domain joined computers to Azure AD as registered devices. Click on Exit.


  • After you click on Exit, you’ll see an Azure AD connect icon on your desktop. You can perform limited administrative tasks by double clicking on that. You can view current configuration, customization options and configure staging mode for Azure AD Connect.



  • In windows server start menu, search for Synchronization Rules and you will notice utilities such as the Synchronization Rules Editor, Synchronization Service, and the Azure AD PowerShell etc for advanced filtering and administration of the tool.


Azure AD Connect is now Generally Available

On June 24, Microsoft announced the general availability of Azure AD Connect tool, which has been in public preview for some time.

We’re thrilled to announce that as of today Azure AD Connect is now generally available for all Azure AD customers including Office 365 customers. Azure AD Connect is the single tool and experience for connecting your on premises directories to Azure AD, whether you are evaluating, piloting, or in production.

Azure AD Connect is the new version of Directory Synchronization tool which includes number of new features and enhancement over the old version of directory synchronization Azure AD Sync tool. Some of the new features of Azure AD Connect tool are:

Azure AD Connect is now Generally Available

  • Self-service password reset for users in cloud with write-back to on premises Active Directory. Previously this feature was included in Azure AD Premium which requires additional license.
  • Cloud based user can write back to your on premises active directory. This enables administrators to create a user in Cloud and write back the user in on premises Active Directory.
  • Groups in Office 365 can be write back to on premises distribution groups. This requires Active Directory forest with Exchange installed/ AD schema extended for Exchange.
  • Device write back to enforce Access Control policies in ADFS to recognize devices that registered with Azure AD. This includes the recently announced support for Azure AD Join in Windows 10.
  • Custom directory attributes can be synced to your Azure Active Directory tenant.
  • Azure AD Connect tool can be downloaded from Microsoft Website.

Configuring Active Sync and Outlook client to access Shared Mailbox

Configuring Active Sync and outlook client to access shared mailbox is one of those requirements which every customer would like to have. I’ve seen a lot of customers asking me how they can access shared mailbox on active sync clients. Even few customers has asked me if it’s possible to configure shared mailbox to be accessed in outlook as they don’t want to configure a primary user mailbox in outlook. My answer to all these situations and customers was YES. You can access shared mailbox directly in OWA. You can configure your shared mailbox in outlook client just like user mailbox and you can configure shared mailbox in active sync device as well. This blog post will guide you how to configure active sync and outlook client to access shared mailbox.

For this lab, We’ve office 365 tenant setup with We’re using Exchange Online where we’re going to configure a shared mailbox A user mailbox has full access to the Shared Mailbox. We’ll configure the shared mailbox in outlook, active sync and directly access the shared mailbox in OWA. I’m connected with Exchange online and verified that is a shared mailbox.

Configuring Active Sync and Outlook client to access Shared Mailbox

Configuring Outlook to Access Shared Mailbox

To configure outlook client to access shared mailbox, we need to follow the steps as mentioned below. Please note that these steps are tested with outlook 2013 client and can vary based on outlook version.

  • Go to Control Panel –> Mail
  • Click on Show Profiles


  • Click on Add and enter a name for this profile to add a new profile.
  • Enter the mailbox information as shown below. As we know Shared mailbox don’t have a password, you need to enter the password of mailbox that has full access to the shared mailbox. In my case I’ve entered the password of and click on Next.


  • Outlook will established a network connection and pop up for credentials on step 2 i.e. Searching settings for
  • Enter the username and password of the mailbox that has full access to In my case it’s


  • Outlook will verify the credentials and configure the outlook profile for shared mailbox Click on Finish.


  • To verify the configuration, Let’s run the outlook profile that we configured a while ago. You can see that is configured in outlook and connected with Exchange Online. You can send and receive emails using this shared mailbox just like a user mailbox.


Access Shared Mailbox in Outlook Web App

We’ll know that we can access shared mailbox in OWA using Open another Mailbox” but there is another way to access the shared mailbox in OWA. We can bypass the process of login to user mailbox. To do so, What we need to go to and enter the credentials of user mailbox that has full access on shared mailbox. In our lab, I’ll go to and enter the credentials for After authentication we will see Shared Mailbox OWA opened as shown below.


Configuring Active Sync Client to Access Shared Mailbox

Configuring active sync client to access shared mailbox is one of those requirements which is being requested by almost every customer. I’ve configured a test mailbox in my Samsung Galaxy and here are the steps to configure it.

  • Go to Settings –> Accounts –> click on Add Account


  • Click on Email Account
  • Enter email address and password of mailbox that has full access on shared mailbox. In our case email address is and I’ve entered the password of and Click Next


  • On account type, Select Microsoft Exchange ActiveSync
  • On Exchange Server Setting Page, enter the username and password of and update Exchange Server name to and Click Next.


  • Active Sync client will check incoming server settings and verify the user information.
  • On Account options, Select the sync interval and click Next.
  • Give a name to your account and Click Done.

To test your shared mailbox, Send an email to and you’ll receive the email on your cell phone. I’ve sent an email from using my Samsung phone and it works fine. Please note that these steps to access shared mailbox on Active Sync client are not documented in TechNet and hence not supported by Microsoft. test AS

Configuring Office 365 Message Encryption

Configuring Office 365 Message encryption in exchange online helps organization to secure their sensitive information based on transport rules in Exchange online. Before we start configuring Office 365 message encryption, i hope you have a good understanding of what message encryption is and what it can do for you and why we need message encryption. If not, then please read my blog post of Office 365 Encryption Option.

Office 365 Message Encryption is a policy based control of your emails sensitive information and it’s a replacement for Exchange Hosted Encryption Service.

Configuring Office 365 Message Encryption

Before we start configuring Office 365 Message encryption, please make sure you understand the requirements for message encryption as described below.

  • We have Office 365 tenant setup.
  • We’ve the required license. Office 365 Message Encryption requires the purchase of Microsoft Azure Rights Management, which is available for $2.00 per user per month.

Microsoft Azure Rights Management service is already included in E3, E4, A3 and A4 licenses. We’re using E3 license in our lab which qualify us to setup Message encryption in office 365.

  •  We’ve a supported client device. Office 365 encrypted messages can be viewed on any client device that has support to open HTML attachments in a browser that support Form Post.
  • We can encrypt a message of up to 150 megabytes size. For more details about message size limits, see Exchange Online Limits.

To start configuring office 365 message encryption, first step is to activate Azure Rights Management. To activate Azure Rights Management, Navigate to Service Settings –> Rights Management –> Click on Manage

Configuring Office 365 Message Encryption

Configuring Office 365 Message EncryptionEnsure that Rights Management is activated, If not, click on Activate. Once Rights Management is activated. We’re only left with two more steps to configure message encryption. For encryption configuration the administrator must have the required permissions. Administrator must have Compliance Management, Record Management and Organization Management rights in Exchange online. Alternatively, you can download the Azure AD Rights Management Tool from TechNet.

After installing the Azure AD management tool, run the following cmdlet to set the execution policy to RemoteSigned. Default value is Restricted.



  • After setting up execution policy to RemoteSigned, Connect with your exchange online PowerShell.
  • Configure RMS key sharing location in Exchange online. Use the key sharing URL corresponding to your location.
  • Run the following cmdlet to configure the sharing key location. My location is North America and I’ve selected the key for NA.


  • Import the Trusted Publisher Domain from RMS Online. To do so, run the cmdlet Import-RMSTrustedPublishingDomain -RMSOnline -Name “RMS Online”.
  • Run “Test-IRMConfiguration -RMSOnline” cmdlet to verify the IRM configuration.
  • Enable IRM for office 365 Message Encryption using Set-IRMConfiguration -InternalLicensingEnabled $true.
  • Once IRM is configured, next step is configure Transport Rules in Exchange Online.
  • Navigate to Exchange Online –> Mail Flow –> Rules. Click on + icon to create a new rule.

12Name your rule and define the encryption parameters as shown below, We’ve configured a rule to encrypt the messages if the sender is within the organization.


Once you define the rule, click on Save and you’re done with configuring office 365 message encryption. You can configure a rule based on keywords, recipient, sender and a lot of other options. An encrypted email will be sent as an attachment to the recipient and recipient needs to login using his credentials to read the information within the email. Recipient can login using his Microsoft account or Org. account. I would highly suggest to use this cool feature in office 365 and secure your mail flow. For more information on Office 365 message encryption, please have a look at Office 365 Message Encryption FAQs at TechNet.

Understand and Modify Office 365 users ImmutableID

Understand Office 365 ImmutableID

ImmutableID is a specific attribute for an Office 365 object that is synchronized from on prem Active Directory. When we install AAD Sync with the default settings on “Uniquely Identifying your users”, the Active Directory “objectGUID” is used as ImmutableID. It’s important to consider and understand the importance of ImmutableID when we are planning for office 365 directory integration that involves multiple active directory forest company merger etc.

Modify Office 365 users ImmutableID

Poor planning of ImmutableID can cause significant issues with your deployment and service interruption. AAD Sync Metaverse stored the value of ImmutableID as “SourceAnchor”

It’s important to understand that ImmutableID of Office 365 synced object is not the same as of ObjectGUID. Office 365 uses a special method to convert on prem user ObjectGUID to another string and save the string as ImmutableID. However, ImmutableID is also unique in Office 365 and can be mapped with the corresponding unique ObjectGUID in the local AD.

Modify Office 365 users ImmutableID?

You cannot change the ImmutableID of synchronized object without having a maintenance window or downtime. Modifying the ImmutableID of office 365 object will cause significant impact on your services and requires proper planning. The only way you can modify the ImmutableID is by turning off Directory Synchronization, allowing the users to be converted from Synced AD Object to cloud identities, performing the modification, and then re-enabling directory synchronization.

Microsoft authentication platform for federated user doesn’t support special character “@”in ImmutableID which means you can’t use mail or UPN as ImmutableID in AADSync when using AD FS SSO.

Steps to manually change the ImmutableID for few users are:

  • Create a new OU in local AD and move the user temporarily.
  • Go to MIIS Console –> On Prem AD Connector –> Containers –> filter out this temporarily OU to soft delete synced users.
  • Run the full Sync.
  • Temporarily pause the Sync from Windows Task Scheduler.
  • Go to Office 365 Portal and restore soft deleted users, so the old synced status changes to in cloud status. You can only change the ImmutableID once the user status in Office 365 is “In Cloud”
  • Change the UPN of each user with “Set-MsolUserPrincipalName -UserPrincipalName -NewUserPrincipalName“.


  • After changing the UPN for the user, run the Cmdlet Set-Msoluser -UserPrincipalName -ImmutableID ObjectGUIDBase64
  • After changing the ImmutableID, change back user’s UPN with “Set-MsolUserPrincipalName -UserPrincipalName -NewUserPrincipalName“.
  • Test the authentication process.
  • Setup sync mechanism to use ObjectGUID as Source Anchor and perform Full Sync.

If we’ve to change the ImmutableID of all the users then the above mentioned steps will cause a lot of delay and a single typing mistake can cause significant issue with the user account. We’ve created a PowerShell script that requires a CSV file as input which contains the UPN of all the users and this script will change the UPN of all the users to and change the ImmutableID to ObjectGUID. Once the ImmutableID is changed to ObjectGUID, it will change the user UPN back to

#Import Active Directory Module in PowerShell

Import-Module ActiveDirectory
Import-Csv “D:O365.csv” | ForEach-Object {
$upn = $_.”UPN”
$user = $upn.IndexOf(“@”)
$left = $upn.Substring(0,$user)
$upn1 = “$left” + “”
Restore-MsolUser -UserPrincipalName $upn
Set-MsolUserPrincipalName -UserPrincipalName $upn -NewUserPrincipalName $upn1
Set-Msoluser -UserPrincipalName $upn1 -ImmutableID “$Null”
$id=(Get-ADUser -Filter {UserPrincipalName -like $upn } -Properties ObjectGUID | select ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($_.ObjectGUID)).tobytearray())})
Set-MSOLUser –UserPrincipalName $upn1 –ImmutableID $id
Set-MsolUserPrincipalName -UserPrincipalName $upn1 -NewUserPrincipalName $upn

You can also download this script from Microsoft TechNet Gallery. More information on ImmutableID can be found on following URLs.

Understanding Shared Mailbox Limitations in Office 365

Shared mailbox in Exchange Online allow a group of users to view and send email from a common mailbox. Understanding shared mailbox limitations in office 365 is important for setting up right expectations for customers. A lot of customers asked questions about utilizing shared mailboxes in office 365. Before we suggest a solution to the customers we should have a strong understanding of shared mailbox limitations in office 365. In this blog post, we will try to build an understanding on shared mailbox limitations to help customers in making a decision when to use a shared mailbox versus user mailbox.

Understanding Shared Mailbox Limitations in Office 365

A shared mailbox in office 365 is:

  • Free and do not require a license, but every user that accesses the Shared Mailbox must be assigned an Office 365 license.
  • Cannot be accessed by users with Exchange Online Kiosk license.
  • Can be used to store emails sent to and received by the Shared Mailbox.
  • Can be used to store data migrated from on-premises Public Folders.
  • Each shared mailbox can be a maximum size of 50GB but shared mailboxes over 50GB in size need to be licensed.
  • A Shared mailbox doesn’t have a username and password and users cannot log into it directly. A user must sign in to his/her own mailbox and then open the shared mailbox using permissions.

Shared mailboxes aren’t primarily associated with individual users and are generally configured to allow access by multiple users e.g. departmental users, Sales team, HR etc.

  • Cannot be used to archive emails from a user.
  • Cannot be used for Journaling.
  • Cannot be accessed using ActiveSync clients.
  • Doesn’t support Unified Messaging feature.
  • Cannot be accessed using Outlook client. To access a shared mailbox on outlook client, you need to first configure a user mailbox that has access to shared mailbox.
  • Active Directory user associated with a shared mailbox is always a disabled user account.

Create a Shared Mailbox in Office 365 using EAC:

To create a shared mailbox in office 365 using EAC, we need to follow the steps mentioned below.

  1. Log on to Office 365 Admin Center using Global Admin credentials.
  2. Go to Exchange Online Admin Center –> Recipients –> Shared and Click on + iconCreate a shared mailbox
  3. Enter Shared Mailbox information. Add users to Shared Mailbox that will have permissions to view and send email from shared mailbox.

Create a Shared Mailbox in Office 365 using Remote PowerShell:

To create a shared mailbox in office 365 using Remote PowerShell, Follow the steps mentioned below.

  1. Connect to Exchange Online PowerShell.
  2. After connecting to Exchange Online PowerShell, Run the cmdlet New-Mailbox -Name “Shared Mailbox Name” -Alias “Shared Mailbox Alias” -SharedPS
  3. Once the mailbox is created, Run the cmdlet to assign appropriate permissions to users. Add-RecipientPermission “MSTechTalk Shared” –Trustee riaz –AccessRights SendAs. This cmdlet will assign “Send As” permissions to user Riaz.


You can find more information on Exchange online limitations at TechNet.

Office 365 Shared Mailbox Sent Items Limitation

Office 365 Shared mailbox makes it easy for a specific group of people to monitor and send email from a common email address. When a person in the group replies to a message sent to the shared mailbox, the email appears to be from the shared mailbox not from the individual user. Shared Mailbox sent items limitation that cause compliance / regulatory issues for most of the customers utilizing shared mailbox is fixed now. Microosft has fixed this issue for all the customers and now customer can leverage the use of Shared Mailbox in Office 365 and on prem version of Exchange. Before we look at the resolution let’s have a look at shared mailbox sent items issue.

When a user sends an email using shared mailbox alias, the email goes directly to the sent items of sender instead of shared mailbox sent item. This is something that cause issues for organizations using Shared Mailboxes. To meet the compliance requirements organizations need control over Shared Mailbox sent items and admin don’t have to run Mailbox Audit logging to nail down the sender of email.

Shared mailboxes are a great way to handle customer email queries because several people in your organization can share the responsibility of monitoring the mailbox and responding to queries. Your customer queries get quicker answers and related emails are stored in one mailbox. A shared mailbox doesn’t have its own user name and password.

Microsoft didn’t have any control over shared mailbox sent items in Exchange 2013 and Exchange online and as a fix customer need to make registry changes on end users machine. This cause a lot of administrative overhead for customers and IT admins. Several customers of mine has not considered to upgrade to Exchange 2013 or migrate to Office 365 due to this limitation of sent items.

Registry fix doesn’t work with the users using outlook in online mode. This fix is only applicable when user is running outlook in cached mode.

With Exchange 2013 CU9 email sent by a user using shared mailbox will be delivered to the Sent Items folder of shared mailbox and to the user mailbox sent items. Microsoft has already started to roll out this new feature to the customers using Office 365 shared mailboxes.

Enable Office 365 Shared Mailbox Sent Items Feature

By default, this feature will be disabled to all the customers and administrator need to run the following PowerShell cmdlet.

For emails Sent As the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True

For emails Sent On Behalf of the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $True

Disable Office 365 Shared Mailbox Sent Items Feature

To disable this feature run the following powershell cmdlets

For emails Sent As the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $False

For emails Sent On Behalf of the shared mailbox: Set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $False

To enable this feature for Exchange online, we need to first connect to Exchange online powershell.

More information on new enhancements in exchange 2013 CU9 can be found on Microsoft Knowledge Base.

Office 365 Encryption Options

Office 365 Encryption Option

Office 365 Encryption Options

Encryption is the process by which information is encoded so that only an authorized recipient can decode and use the information. Microsoft offered multiple Office 365 encryption options to their customers. Office 365 encryption Option is used in two ways, One is by implementing encryption in the service and the second is by offering it to you as a customer control. In the service, Microsoft make use of encryption in the platform, where it works by default and you don’t have to configure anything. For example, Office 365 uses Transport Layer Security (TLS) to encrypt the connection / session between two servers.

Why we need Office 365 Encryption?

At times, organizations needs to communicate with external organizations on a secure encrypted channel to meet their regulatory / compliance requirements. To fulfill the compliance requirements organizations opt office 365 encryption options. Office 365 encryption options provide their customers the benefit to stay ahead to gain control and improve security and reliability of their system. Encryption options offers following benefits to the customers:

  • To stay in control by automatically protecting sensitive information
  • To meet compliance / regulatory requirements
  • To secure confidential information

We currently have 5 different types of Office 365 message encryption option that we can configure to secure our messages in office 365.

  • Office Message Encryption
  • S/MIME
  • Transport Layer Security (TLS)
  • BitLocker
  • Information Rights Management

Office Message Encryption

In November 2013, Microsoft announced Office 365 Message Encryption to send encrypted email messages to people inside or outside of the organization regardless of the destination email service.

Office 365 Message Encryption is designed to help organizations to send confidential messages to people outside your company simply and securely, without the administrative overhead required to use S/MIME or similar technologies. It’s an outside-the-company companion to Information Rights Management, which is why it’s included as part of the Windows Azure Rights Management offering as well.

There are many scenario’s when you need to encrypt your email like

  • Sending credit card statements to customers over email.
  • Sharing confidential information with someone like Social Security number, credit card number etc.
  • Sharing financial information for a loan application.
  • An attorney sending confidential information to a client or another attorney.
  • Sending a contract to someone else.
  • Sharing a company policy with someone.

Office 365 Message Encryption is an enhanced version of Exchange Hosted Encryption (EHE), with the addition of a new set of features. To learn more about all security features in Office 365, kindly visit the Office 365 Trust Center

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Second Message Encryption option in office 365 that we have is S/MIME, which is a widely accepted method / protocol used to send encrypted and digitally signed messages to the recipient using Rivest-Shamir-Adleman (RSA) encryption system. S/MIME is a client-side encryption technology that requires a certificate management and publishing infrastructure.

S/MIME is as important a standard as SMTP because it brings SMTP to the next level, allowing widespread e-mail connectivity without compromising security.

Before S/MIME, administrators used a widely accepted e-mail protocol SMTP, which was inherently not secure, or they used more secure but proprietary solutions. Administrators chose a solution that emphasized either security or connectivity. S/MIME requires Exchange 2013 SP1 or Exchange online with outlook 2010, outlook 2013, OWA and EAC to work properly.

Transport Layer Security (TLS)

TLS, or Transport Layer Security, allows two separate Exchange organizations to transfer mail between them over an encrypted connection. TLS works very similarly to the way SSL works in your web browser.

By default office 365 uses TLS connections to send/receive email messages. TLS in Exchange Online and Domain Security in Exchange 2010 and 2013 are two different concepts and let’s have a high level overview of both technologies.

Domain Security is a set of functionality in the on-premises version of Exchange that started with Exchange 2010 and Outlook 2007 that is intended to provide a lower cost alternative to S/MIME or other message level security solutions.

Transport Layer Security (TLS) is an encryption protocol designed to create a secure communication tunnel over the public internet. Exchange Online gives you the option to setup send and receive connectors to specific partners that are always encrypted.

TLS encrypts the tunnel between mail server to help prevent snooping/eavesdropping.


BitLocker is a drive encryption technology included in Windows Server 2008 and newer versions. BitLocker provides AES (Advanced Encryption Standard) encryption of your email data at rest. That means if for some reason, someone managed to break into an Office 365 data center and steal the hard drive that contains your Exchange Online database, they would not be able to access the data on that hard drive unless they also had the encryption key.

AES uses the same key to encrypt and decrypt the data. I’m not going to spend much time on the specifics of how this type of encryption works because there is nothing for you to configure in Exchange Online, but you can find more information on BitLocker on TechNet.

BitLocker is a great example of one of the reasons to go to Office 365. Microsoft has already performed a lot of the configuration work for setting up secure Exchange for you. BitLocker is already setup on your tenant and all your data is encrypted in Microsoft data center but there is no way for us verify this. Microsoft does comply with a number of different 3rd party auditing procedures to verify things like this. You can find more information on this subject at the Office 365 Trust Center website.

BitLocker Encryption has already been applied to all office 365 tenants and managed by Microsoft.

Information Rights Management

Information Rights Management (IRM) provides the world of Office 365 with far more control over the degree of document access and security allowed. Information Rights Management in Office 365 prevents sensitive information from being printed, forwarded, or copied by unauthorized people inside the organization. Information Rights Management (IRM) enables content owner / publisher to create rights protected content such as an email message or document.

IRM helps individuals enforce their personal preferences regarding the transmission of personal or private information. It also helps organizations enforce corporate policy governing the control and dissemination of confidential or proprietary information within the organization and with customers and partners. More information on Information Rights Management can be found on TechNet.

Microsoft has two methods to enable IRM within the Office 365 productivity suite (Word, Excel and PowerPoint). The first is to install the IRM services on a Windows 2003 or 2008 server, which enables integration within a corporate Windows domain. This integration allows a content author to select which users and groups from Active Directory have access to their content. The second method is to use a Windows Live ID. This enables companies without an Active Directory environment to restrict user access based on a user’s email address.

Configure Exchange 2013 Virtual Directories

Configure Exchange 2013 Virtual Directories

When you’re working with more then 1 exchange servers then configuring exchange virtual directories is always a concern. You can either manually configure each virtual directory on each server or you use powershell cmdlets to configure the virtual directories. To ease your deployment, I’ve created a powershell script which will help you configure virtual directories URLs on your all exchange 2013 servers within minutes. You only have to provide 3 inputs for Internal, External URL and AutodiscvoerServiceInternalURI and rest this script will do for you.

#       Author: Riaz Javed Butt
#       Date: 03-June-2015
#       Description: This scirpt will help you configure your exchange 2013 organization URLs

#Get all exchange 2013 CAS Servers
$Exchange2013Servers = Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like “Version 15*”) -And ($_.ServerRole -Like “*ClientAccess*”)} | Get-ClientAccessServer

#Get Internal & External URL

$CASInternalURL = Read-Host “Please enter your internal URL e.g.”
$CASExternalURL = Read-Host “Please enter your external URL e.g.”

#Get autodiscoverServiceURI

$AutoDServiceInternalURI = Read-host “Please enter your autodiscoverserviceinternalURI e.g.”
Write-Host “Thank you for providing Required URLs”

#Setting up AutodiscoverInternalServiceURI
Write-Host “Setting up Exchange AutodiscoverServiceInternalURI”
$Exchange2013Servers | Set-ClientAccessServer –AutodiscoverServiceInternalUri “$AutoDServiceInternalURI/autodiscover/autodiscover.xml”

#Setting up virtual Directories URLs
Write-Host “Setting up Virtual Directory Internal and External URLs”
$Exchange2013Servers | Get-OWAvirtualDirectory | Set-OWAvirtualdirectory –Internalurl “$CASInternalURL/OWA” –Externalurl “$CASExternalURL/OWA”
$Exchange2013Servers | Get-ECPVirtualdirectory | Set-ECPvirtualdirectory –Internalurl “$CASInternalURL/ECP” –Externalurl “$CASExternalURL/ECP”
$Exchange2013Servers | Get-WebServicesVirtualDirectory | Set-WebServicesvirtualdirectory –InternalURL “$CASInternalURL/ews/exchange.asmx” –ExternalURL “$CASExternalURL/ews/exchange.asmx”
$Exchange2013Servers | Get-OABvirtualdirectory | Set-OABvirtualdirectory –internalurl “$CASInternalURL/oab” –Externalurl “$CASExternalURL/oab”
$Exchange2013Servers | Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl “$CASInternalURL/Microsoft-Server-ActiveSync” -ExternalUrl “$CASExternalURL/Microsoft-Server-ActiveSync”

#Verify URLs Configuration

$Exchange2013Servers | fl Identity,AutodiscoverServiceInternal*
$Exchange2013Servers | Get-OWAvirtualdirectory | fl identity,Externalurl,Internalurl
$Exchange2013Servers | Get-ECPvirtualdirectory | fl identity,Externalurl,Internalurl
$Exchange2013Servers | Get-Webservicesvirtualdirectory | fl identity,Externalurl,Internalurl
$Exchange2013Servers | Get-OABvirtualdirectory | fl identity,Externalurl,Internalurl
$Exchange2013Servers | Get-ActiveSyncVirtualDirectory | fl identity,Externalurl,Internalurl

#######You can also run Michael Van Horenbeeck Exchange MVP PowerShell Script to generate a HTML based report of your URLs configuration.
####### Please go to and downloaded the script get-virdirinfo.ps1 v1.6 and run as instructed

You can run this script go to Exchange Management Shell and run the script as shown below.


Once you run the script and provide the following 3 inputs then the script will configure everything for you on all exchange 2013 servers.

  • First input is InternalURL: In my case it was
  • Second input is ExternalURL: In my case it’s same as of internal URL
  • Third input is AutodiscoverServiceInternalURI: I’ve configured that as

Once the configure is completed this script will give you the output of all configured virtual directories along with new URLs as shown below.




You can download this script from TechNet Gallery.

To generate a HTML based report of Exchange 2013 virtual Directories URLs, Please run the powershell script of Michael Van Horeenbeeck that can be downloaded from