Category: Office 365

Exporting E-Mail to Outlook data files programmatically


This post discusses a simple script to export one or more Exchange Online mailboxes to an Outlook data file programmatically.

Why am I doing this?

I wrote the script to export the mailbox data from an Office 365 tenant for an Office 365 tenant-to-tenant migration. Now I know there are tools out there that do this but money constraints meant I had to come up with something else.

How does it work?

First of all your Outlook profile must contain all the mailboxes you want to export i.e. you have been granted ‘Full Access’ over the mailboxes and they must be in online mode not cached, the reason being if they’re cached the copy process might not contain all the mailbox data. Mailboxes which are cached are reported in the logs as per the image below.


So, the script, well the script uses the Outlook Object Model to connect to Outlook and enumerate the MAPI stores. Each store is assigned an associated Outlook data file, which is attached and named PST: ‘mailbox store name’, next the script enumerates the mailbox store folder structure and copies the data from each folder to the Outlook data file store, once complete it disconnects the Outlook data file store and moves onto the next mailbox store in the profile.

The Outlook data file exports are stored in a directory named exports within the directory where the script is run from and the log file is stored in the script root directory.



The script has scope for lots of improvements such as better error checking, retries if the copy process fails on a particular folder and maybe even consuming user credentials to have mailboxes from both tenants, then run the copy process.

The script can be downloaded from GitHub here:

References – used to name the Outlook data file store in order to disconnect it reliably. – used for the disabling of the Outlook cache mode.


Office 365 – Prepare the client computer and configure remote connectivity

Client Computers

Trusted zones

Office 365 offers a number of office applications via a web browser e.g. Office 365 plans P1/E1/E2/E3/E4/K1 and K2 allow read write and read only access to office documents.

In order to get uninterrupted access it is recommended the browser be configured with the following trusted sites assignments.

Trusted sites list:

Local intranet list:

  • *
  • *
  • *
  • *

The above assignments can be configured via group policy or the IEAK. Note that when you configure the trusted browser zones via group policy the end user will be unable to make changes. If you need to implement this in an environment that has not used the ‘site to zone assignment’ group policy object before you may what to script the collection of existing trusted site configuration. See this here.

Client computer requirements

Desktop Setup – required if you’re not installing Office 365 Pro Plus.

Operating system

  • Windows 7 or later
  • Mac OS X 10.5 or later
  • Windows Server 2008 or later
  • Windows XP with SP3; support ends January 2014
  • Windows Vista with SP2; support ends January 2014


  • Office 2010 SP1
  • Office 2007 SP2
  • Office 2011 for MAC
  • Outlook 2003 (POP and IMAP); support ends April 2014
  • Lync 2010
  • Microsoft .NET framework
  • Entourage 2008 Web services addition and Office 2008 for MAC are not supported but probably will work


  • IE 8 or later
  • Firefox latest version
  • Safari 5 or later
  • Chrome latest version

The Office suite available via Office 365 can be deployed in a number of ways:

  • Download from the portal

Downloads are initiated from the portal by the end user; this will require the end user to have local administrative rights.

  • Network share

The IT Administrator downloads the installer to a network share; this will again require the end user to have local administrative rights. This option requires you download Office 365 Pro Plus using the Office Deployment Tool for Click-to-run.

Create a share on a file server e.g. net share sharename=drive:path


Download the Click-to-run tool from the Microsoft download center, extract the files to the network share created above. Then configure the configuration xml file. Microsoft documentation here.


Once the configuration is complete, download Office 365 Pro Plus using the download switch.


To install Office 365 Pro Plus you would run the command below at the client


Office 365 Pro Plus Group Policy

Administrative templates can be found here.

Office licensing considerations

Originally the Office suite provided via Office 365 had a number of restrictions e.g. the office suite used a retail SKU which prevented it being installed within a terminal services environment. The latest Office suite no longer has that limitation. See more below.


Installation and use rights here.

Configuring Remote Connectivity

Troubleshooting Remote Connectivity

As Office 365 services are cloud based, so your internet connectivity and configuration needs to be solid. To diagnose and troubleshoot Microsoft have provided the following tools:


MOSDAL is a good all round tool which collects system and network configuration, performs network diagnostics and logs information for all Microsoft Office 365 applications in use.

To use MOSDAL configure using the setup wizard then reproduce the problem; as you reproduce the problem MOSDAL will collect information, when MOSDAL is finished you can view the report. The MOSDAL report is best viewed top down, first view the summary and drill down where required to view console output, test traces and any attachments.

Remote Connectivity Analyser

browse to and select an applicable test e.g. to test Office 365 single sign-on select the Office 365 tab then select single sign-on test. Enter your credentials when prompted and click perform test.


The image above is a single sign-on test I performed whilst my Federation proxy server was offline.

Office 365 Urls and IP address ranges can be found here.

Office 365 port requirements:

Exchange / Email:

  • Outlook 20xx, Entourage 2008, Outlook 2011 for Mac and Outlook Web Access – TCP 443.
  • SMTP mail routing uses – TCP 25.
  • SMTP relay uses – TCP 587.
  • IMAP migration – TCP 143 / 993
  • POP3 – TCP 995
  • Exchange migration – TCP 433 (Staged and cutover)
  • Exchange management console and shell – TCP 443


  • SharePoint portal ( – TCP 443


  • Lync Client (Lync Online to on-premises Lync Server) – TCP 443.
  • Lync data, video and audio – PSOM/TLS 443, STUN/TCP 443, STUN/UDP 3478 and RTC/UDP 50000 – 59999

Active Directory / Federation:

  • ADFS and ADFS Proxies – TCP 443
  • Directory Sync – TCP 80 / TCP 443

Verifying service connectivity

To verify Exchange / Outlook connectivity hold down the ctrl key whilst right clicking the Outlook icon in the system tray and selecting connection status.

To verify Lync connectivity browse to your local Lync test site from the list below: NOTE: requires Java be installed.

Once connected click start test, then enter the session ID (any number greater than 0), the click ok.

To verify SharePoint connectivity simply browse to the SharePoint site.


The autodiscover service; autodiscover takes the email address and password of a user to automatically configure their Outlook profile. Autodiscover will attempt to get the users display name, connection settings for inbound and outbound connectivity, the mailbox server where the mailbox exists, Urls for free / busy, unified messaging, offline address book and outlook anywhere configuration.

Autodiscover will generally utilise a CNAME within your DNS namespace which points to You can test autodiscover using the Microsoft Remote Connectivity analyser.


Remote connectivity analyser results.


Administering Office 365 via PowerShell

This requires the Microsoft Online Services Module for PowerShell be installed. You can confirm this by opening PowerShell and typing Get-Module -ListAvailable


Once you have confirmed the module is installed import the module and connect to your Office 365 tenant.



Put the credentials into a variable $cred


Connect to the Office 365 tenant using the variable


To get a list of commands available run Get-Command -Module MSOnline


e.g. Get-MsolDomain


Administering Exchange On-line via PowerShell

Exchange On-line can be administered via remote PowerShell.

First of all create a remote session to



Import the session to get the Exchange Online cmdlets. using Import-Session $session. To get a list of commands import the session into a variable and use the ExportedCommands property to retrieve a list of commands.


Run the commands as if you were connected locally.


Staged migration from Exchange 2003 to Exchange online


The following prerequisites must be in place to carry out a staged migration.

  1. A directory sync server must be configured to synchronise on-premises users to Office 365. See here for instructions.
  2. Your Office 365 tenant organisation must have the domain of your on-premises organisation as an accepted domain i.e add the domain to Office 365 within the portal.
  3. Confirm Outlook anywhere is working on your on-premises Exchange deployment
    1. In my scenario I was migrating from Exchange 2003 and Outlook Anywhere was not configured. I used the guide here. The only comments I would make are the
    2. registry entry HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\RPC\RPCPROXY requires the NetBIOS name, internal FQDN and external FQDN (if they’re different) and NTLM authentication is required on the RPC virtual directory and within Outlooks proxy settings; these seems to be true when using Outlook 2010, I haven’t tested other clients.
    3. To confirm Outlook anywhere is working use the Microsoft Remote Connectivity analyser:
    4. OutlookAnywhere2
  4. Create an on-premisesuser who will be the migration administrator; this user can be either a domain admin or assign the user full access to the mailboxes and modify the writeProperty permission on the TargetAddress. The TargetAddress security can be modified using ADSIedit.
  5. Lower the TTL of the MX record for the domain you’re migrating.
  6. Tell the users that their mailbox is being migrated. Depending on your user base Outlook Web App may be suffice if not an autodiscover record should be created but could cause issues.
  7. Export the user account email addresses from Active Directory using csvde e.g. csvde -f c:\output.csv -r “(&(objectCategory=person)(objectClass=user)(mail=*” -l “mail”. The default header is mail but for the migration it must be emailAddress.



Create a migration end point

Login to the Exchange Administration Center and select recipients, then migration, then the plus sign and migration to Exchange On-line.


Select staged migration.


Enter the credentials of the on-premises account which has access to all mailboxes being migrated; this is either the domain admin or the user created in prerequisite step no. 4.


Specify the internal FQDN of the Exchange server and RPC proxy i.e. the public FQDN used when connecting via Outlook Anywhere.


Name the migration e.g. maybe you’re migrating users with surnames A-G then maybe Exchange2003MailboxesAtoG.


The status of the migration can be viewed from within the Exchange Admin Center.


At this point the TargetAddress attribute of the users you’re migrating is modified to


Depending on the size and number of items it may be best to plan migrations over a weekend or may be an evening would suffice e.g. in my experience a 3.8GB mailbox took around 3 hours over a 5Mb connection.

If your user would like to be able view new incoming emails straight away then point them to Outlook Web App, configure their mobile device to use Exchange On-line or configure a new Outlook profile to utilise the Exchange On-line. If you opt for a new Outlook profile a few points to remember:

  • Outlook 2010 or 2007 client needs to be at least SP1 and SP3 respectively
  • Outlook 2010 and earlier client require the desktop setup to be run; pretty sure this installation requires a reboot too.


  • An autodiscover record should exist too; existing users should not see any problems unless you  have to reconfigure their Outlook profile.

Once the migration is complete you’ll receive an email like the one below.


The migrated users’ on-premises mailbox-enabled accounts should be configured as mail-enabled accounts; Microsoft have a number of scripts to streamline this process which can be found here.

The script: ExportO365UserInfo.ps1 requires PowerShell to be installed, the synopsis of the script is as follows:

  • Create and connect to a remote session of Exchange On-line
  • Import the migrated users
  • Using the migrated users email address get the Exchange Distinguished name, cloud email address and on-premises email address
  • export the above to a csv.

The script: Exchange2003MBtoMEU.vbs requires the output of the PowerShell script above, Microsoft Exchange management tools and a FQDN of a domain controller. The synopsis of the script is as follows:

  • Import information from csv file created by the script above
  • Collect information from Active Directory
  • Adds x.500 addresses and distinguished names to a proxy list
  • Deletes the users mailbox
  • Mail enables user using information collected earlier

Once your batch is complete, delete it from the migration section of the Exchange Admin Center.

Final tasks

Switch MX to Exchange On-line; this can be viewed within the Office 365 portal. Login go to domains, select the domain, then select view DNS settings, then select View DNS records.


Upgrade to Exchange 2010 and then remove the Exchange 2003 installation. Guides on Microsoft TechNet:

Understanding upgrade from 2003 to 2010:

Removing Exchange 2003:

Office 365 – Manage identity federation by using ADFS 2.0

Configure Directory Synchronisation

Directory synchronisation must be activated within the Office 365 portal; the activation can take 24 hours to complete.

Directory Synchronisation requires:

  • A domain joined computer.
  • Enterprise administrator credentials (it uses these to create a user object in the forest root domain).
  • Global administrative rights within the Office 365 online environment.
  • Computer hardware depends on no. of objects within ADDS but as a rough guide
    • 1.6Ghz CPU
    • minimum of 4GB RAM up to 32GB RAM
    • minimum 70GB hard disk space up to 500GB hard disk space

See this post for more details on deployment and configuration of directory sync.

Configuring and Managing Identity federation using ADFS 2.0

Single sign -on requirements using AD FS 2.0

  • Single Active Directory forest
  • AD FS 2.0
  • Latest client operating system and service packs
  • Public SSL certificate
  • PowerShell 2.0

Relying party trust between federation servers and Office 365 is required the relying trust acts as a secure channel where authentication tokens can pass.

The AD FS 2.0 install wizard will check for and install all the prerequisites with the exception of Microsoft .NET Framework 3.5 SP1 on Microsoft Windows Server 2008.

The federation server(s) requires a public SSL certificate for server authentication purposes. If federation proxies are also implemented then this public certificate should also be installed on them too. The federation servers also require a x.509 token-signing certificate which by default is a self signed certificate created by AD FS and will be sufficient in most scenarios.

It goes without saying but DNS resolution and TCP/IP are fundamental to the operations of AD FS.

Network Load Balancing (NLB) is recommended too to provide fault tolerance at the federation servers and federation proxies.

AD FS Installation

See this post for more details on deployment and configuration of ADFS 2.0.

Implementing single sign-on and two-factor authentication

Office 365 can utilise two-factor authentication but requires single sign-on be implemented first.

Microsoft recommends either using SecurID or using Forefront UAG and it supported two-factor authentication providers.

Two-factor authentication is only supported by Lync, SharePoint and OWA and the computer being used must be joined to a domain.

Office 365 – Lab 2 ADDS and AD FS 2.0

Lab 2


  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • SSL certificate signed by a public authority
  • Active Directory domain controller
  • Windows 7 client
  • Windows Server client (x 3) – in a production environment you should have 5
    • AD FS 2.0
    • AD FS 2.0 Proxy
    • Directory Sync Server
  • Enterprise Administrator credentials
  • Global administrator credentials with Office 365
  • Delegated write access to the Program Data container within ADDS (not required if you’re installing AD FS 2.0 using domain admin credentials)


The purpose of this lab is to simulate the implementation of true single sign-on with Office 365 using an Active Directory domain. This domain will be deployed with an internal sub domain of the company’s public domain name. See here on how to build an ADDS domain with a internal sub domain.

Lab Setup

Domain Controller

The domain controller should be built as per the guide here.

DirSync Server

The directory sync server should be built as per the guide here.

Federation Server

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name.

Computer Name: ADFS01

IP Address Gateway Primary DNS should be the IP address your DNS server is listening on. The IP Address has been bound to the network adapter for dedicated use by Federation services.


Join the computer to the domain.

Prerequisite Federation Server configuration

  • Create a internal DNS record for your federation server farm e.g.
  • Create a service account for ADFS.
  • Install IIS 7.5 with defaults selected.
  • Generate a CSR for your public domain and install the certificate.

Create DNS record for Federation

Create a DNS record on the internal DNS. You’ll need to create a new zone for the public DNS zone e.g.


I’ve used sts as the host name for my Federation Server. If you also have public records for Exchange and Lync online etc. you’ll need to replicate those here.

ADFS Service Account

Create a normal domain user account to run the Federation Service.



Install IIS

Using server manager or Windows PowerShell install IIS using the defaults. The screenshots below are verification IIS is installed.



Install SSL Certificate

Generate a CSR for the public DNS name e.g; obviously there will be content between the BEGIN and END certificate request.


Send the certificate to a certificate authority, once complete download the certificate and install it within IIS.


Install ADFS

First things first download the ADFS 2.0 installer from the Microsoft download center.


Run the installer and follow the install wizard.

Select Federation server


The installer will install the prerequisites if they haven’t already been installed.


When the installer is complete you’ll be prompted to run the configuration wizard.


Click finish then click the hyperlink below to follow the wizard.


Select the certificate SSL certificate installed earlier.


Select the user account you created earlier for the Federation service account.


When the installation and configuration is complete you’ll see lots of green ticks.


Install update rollup 1 for ADFS and reboot.


Optionally add another Federation server and configure network load balancing using Microsoft NLB or something similar. In my lab environment I didn’t but you can find more info here.

Verify ADFS is functioning by browsing to


Federation Proxy Server

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name.

Computer Name: ADFSP01

IP Address (ideally this would be in the DMZ but in my lab I didn’t have the equipment available). The DNS servers assigned to this computer should be the public DNS servers provided by your ISP.


Do not join this computer to the domain.

Prerequisite Federation Proxy Server configuration

  • Configure the hosts file to point to the internal federation server.
  • Configure an external DNS record to point to the public address of your federation proxy.
  • Install IIS as per the installation on the Federation Server and import the  same SSL certificate; export the original to pfx first.

Configure DNS hosts file

Configure the local hosts to resolve to the internal Federation server.


Create a external DNS record

Configure a public DNS record for the which points to your Federation proxy; remember to point it to the public IP Address of the Federation proxy not the private 192.168. address.


Install IIS and SSL certificate

IIS should be installed as per the same process as the Federation server. To install the SSL certificate first export the certificate from the Federation server, ensure the export file type is a pfx file; remember the private key.

Install the pfx using the certificates MMC console ensuring you select the computer account.



Install ADFS

Copy the ADFSSetup.exe you downloaded for the Federation server installation to the Federation proxy.

Run setup and follow the install wizard.

Select Federation server proxy


Once the installation is complete click finish and update ADFS 2.0 to update rollup 1.


Configure the Federation server proxy using the configuration wizard.

Enter the Federation server when prompted and click test; if the connection is successful you’ll be prompted to enter credentials to establish a trust, use either the built-in administrator or the ADFS service account user.



To verify the Federation server proxy has been installed correctly look for event 198 in the ADFS 2.0 Eventing log.


Install the Windows Azure PowerShell modules on the Federation server; more info here.

Once the Azure modules are installed configure a trust between ADFS and Windows Azure AD using the following commands:

Provide the Office 365 credentials

$Cred = Get-Credential – this prompts you for your Office 365 credentials


Connect to Office 365

Connect-MsolService -Credential $Cred – Connect to Office 365 using the credentials specified above


Convert an existing domain or add a new one

Convert-MsolDomainToFederated -DomainName [domain name] – Converts a existing domain to a federated domain.


If the above command is successful a message similar to the one below will appear.


Verify Single sign-on

browse to

Enter your username Active Directory UPN e.g.


When you tab to the password field Microsoft Azure will attempt to contact your Federation server e.g.


If your Federation or Federation proxy URL is not in your intranet trusted sites then you’ll be prompted for authentication. If you’re using a non-domain joined computer then you’ll be prompted for your credentials by the Federation server e.g. image below.


I also verified SSO using my mobile phones ActiveSync client.


I disconnected the network from the Federation proxy server and my mobile was unable to send emails, reconnecting the network allowed emails to be sent.


Email I attempted to send whilst the Federation proxy was offline


Post Installation considerations

The token signing certificate expires every 12 months; this is a self signed certificate used by the Federation server to sign all authentication tokens it issues. When the certificate expires on the Federation server you will need to update the trust with Azure. More info here.

The Directory sync server synchronises all Active Directory accounts. If you want to only allow specific users access to cloud services then you need to customise the incoming claim. See here.

Office 365 – Lab 1 ADDS and DirSync

Lab 1


  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • Windows Server with ADDS installed
  • Windows 7 client
  • Windows Server client
  • Enterprise Administrator credentials
  • Global Administrator credentials


The purpose of this lab is to simulate the implementation of DirSync with Office 365 using an Active Directory domain which has been deployed with a non-public routable DNS domain name e.g. domain.local or domain.internal.

Once DirSync is synchronised with Office 365 then I’ll look at implementing Office 2013 on the Windows 7 client logging in as a domain user and observing the effects of DirSync and the password synchronisation feature.

Lab Setup

Domain Controller

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address Gateway Primary DNS


Forest root domain FQDN: office.local


The forest functional level needs to be at least Windows Server 2003.

reboot on completion.

DNS configuration

Create a reverse DNS zone for your local subnet.

Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable.

Remove the root hints.

Active Directory configuration

Using the Domains and Trusts snapin configure a publicly routable DNS name; this UPN must match your domain defined within the Office 365 portal.


Then configure all users who will be using Office 365 to use the public DNS name for their UPN; you can multi select.


DirSync Server

Install Windows Server 2008 R2, assign a static IP address, assign a suitable name and join to the domain.

Computer Name: MSOLDS01

IP Address Gateway Primary DNS


Join the computer to the office.local domain.

Install DirSync ensuring the prerequisite software is installed e.g. Microsoft .Net Framework 4.0.

DirSync configuration

Follow the wizard entering the global administrator username and password for your Office 365 environment.


Enter the username and password of an account with Enterprise Administrator membership.


Enable password synchronisation – This enables the user to only remember one password; when the user changes their password within the on-premises ADDS the password will be synchronised within minutes.


Once you click finish you’ll be prompted to synchronise your ADDS with the cloud.


With password sync enabled the directory sync will result in the application event log recording verify Password Change Requests and Password Change Results for user accounts



You also notice event ID 650 and 651 recorded to signify that synchronisation has started and finished.

Once the directory synchronisation is complete you can verify within the Office 365 portal the last sync time and synchronised users.



Windows 7 Client

Install Windows 7, assign a suitable and name and join it to the domain. I’ve assumed DHCP is deployed so no need to configure an IP address.

Computer Name: Client01


Join the computer to the domain.

Client configuration

Logon to the client computer using your domain credentials e.g. jbloggs@UPN, login to the Office 365 portal and install Office 2013.


Open Outlook 2013 and follow the wizard, if your Active Directory properties do not have an email address defined as below then then Outlook auto-configure will not populate the Display Name, Email address etc.



Click next, If you have configured your DNS records as suggested by Microsoft e.g.


then Outlook will auto-configure itself too, you’ll be prompted for your Office 365 credentials as we are not using federated logins but because the password has been synchronised the password is the same as your Windows login credentials.


If you haven’t configured the autodiscover record correctly this step will fail; check out and select Outlook Autodiscover.


Outlook 2013 is now connected to Exchange Online


Office 365 – Manage Roles

Office 365 administrator roles

Billing Administrator – manages subscriptions, purchases, support tickets and service health.

Global Administrator – There can only be one, by default it is the person who signs up for Office 365. This administrator can assign other administrative roles.

Password Administrator – manages password resets, service requests and monitors service health. NOTE: This role cannot reset passwords for other administrative roles.

Service Administrator – manages service requests and monitor service health.

User Management Administrator – manage password resets, monitor service health, manage user accounts and groups and manage service requests. NOTE: This role cannot create administrative users nor can it reset the passwords of users with administrative role assignments.

Delegated Administration

Delegated administrators can create users, reset passwords and manage domains.

To enable delegated administration you need to send your customer a link in an email which will enable delegated administration; this is done via the partner page within the Office 365 portal.


Once the customer accepts you as a delegated administrator you’ll be listed within their delegated administrators. The global administrator of the partner Office 365 account can then decide how much administrative access you have over the partners.



To access a customers resources using your delegated credentials go to service settings from within your customers portal.


Within SharePoint you can grant your organisation as a support partner access to your customers SharePoint site collections.


Exchange role-based access control (RBAC) roles

Exchange role-based access control (RBAC) is used to grant administrative users specific privileges within Exchange and allow users to make changes to their personal settings e.g. mobile number.

RBAC can be assigned in 3 ways.

  1. Management role groups; these are used to assign a group of users administrative privileges within the organisation or for objects with a specific attribute.
  2. Management role assignment policies; these are used to assign users more or less privileges over their own mailbox. Only one management role assignment policy can be assign to any one mailbox at a time.
  3. Direct user role assignment; this is where a user account or universal security group would be granted access to a particular role without using a role group or role assignment policy.

The diagrams below show how RBAC components link together.

e.g the Discovery Management role group has management role assignments of Mailbox Search-Discovery Management and Legal Hold-Discovery Management. The assignments link the role group to the management roles Mailbox Search and Legal Hold, if you query those management role using PowerShell you’ll see which cmdlets are available e.g. Get-ManagementRoleEntry  “Mailbox Search\*”

The scope of the management role assignment can be the organisation or a specific attribute e.g. the office attribute equal to “some location” e.g. New-ManagementScope -Name “Ossy Branch” -RecipientRestrictionFilter {Office -eq “Ossy”} If you wanted to protect who could manage mail recipients in the Office location of Ossy, you could make the scope exclusive.

Once the scope is created you would also create New-DistributionGroup as a universal security group (USG) and a New-RoleGroup which defines the Branch e.g.

New-DistributionGroup -Name “Ossy Admins” -Alias OssyAdmins -Type Security

New-RoleGroup “Oswaldtwistle Recipient Admins”

Finally to link together your role group and management role you would create a role assignment defining the scope created earlier e.g.

New-ManagementRoleAssignment -Name “Oswaldtwistle Recipient Admins-Mail Recipients” -Role “Mail Recipients” -SecurityGroup “Oswaldtwistle Recipient Admins” -CustomRecipientWriteScope “Ossy Branch”

Users are now made a member of the USG OssyAdmins would be able to manage recipients who have the Office attribute equal to Ossy.

A custom management role must have a builtin parent role, and cannot have more rights than its parent role i.e. access to more cmdlets. Every role with a Remove- or Set- cmdlet must have a respective Get- cmdlet.

Management Role Assignment

The management role assignment policies are assigned to end users and allow them to manage their own mailboxes and distribution groups; you can introduce new functionality or remove functionality by creating new management role assignment policies, modifying the role assignments and assigning that new policy to a mailbox.

A mailbox can only have one role assignment policy and can only contain roles which are scoped to the end user i.e. start with My…

To view the role assignment assigned use PowerShell to query the management role assignment that are part of the default role assignment policy e.g.

Get-ManagementRoleAssignment | ? {$_.RoleAssigneeName -eq “Default Role Assignment Policy”} | Select-Object Name, RoleAssigneeName

Management Role Assignment Policy


Office 365 – Provision and manage users, groups, and domains

Office 365 Identities

Office 365 identities can be either based either in the cloud or federated from Active Directory Directory Services (ADDS).

Cloud identities are authenticated within the cloud and are subject to the password policy stored within the cloud whereas federated identities are authenticated against the on-premises ADDS, once verified a token is passed to the cloud to authenticate the user in the cloud.

Office 365 identities fall under three usage scenarios:

  1. Cloud identities
    1. Primarily used by small organisations with no on-premises ADDS.
    2. No single sign-on possible.
    3. No two factor authentication possible.
    4. Two sets of credentials depending on whether local credentials are required to logon to the local workstation.
  2. Cloud identities with Directory Sync (DirSync)
    1. Primarily used by medium sized organisations with an on-premises ADDS.
    2. Allows for co-existence of Exchange and Lync.
    3. No single sign-on.
    4. No two factor authentication.
    5. Two sets of credentials but as of the latest release of DirSync passwords are now synchronised.
    6. Password policies are defined within ADDS; DirSync requires passwords be at least eight characters.
  3. Federated identities
    1. Primarily large organisations.
    2. Requires a minimum of:
      1. ADDS – should be more than one.
      2. Federation server – should be load balanced.
      3. Federation proxy in the DMZ (if using Outlook)  – should be load balanced and will be a member of a workgroup not the domain.
      4. DirSync server.
    3. Enables single sign-on.
    4. Enables two factor authentication.
    5. Password policies are defined within ADDS; DirSync requires passwords be at least eight characters.
    6. Allows for co-existence of Exchange and Lync.

Creating users

Via the Office 365 portal

Login to the Office 365 portal > users and groups > add > Display Name (mandatory) >  Login name (mandatory) > Assign a location (mandatory) and role (optional) > Assign licenses > next > create (optionally you can have the password sent to you or another email address).

Via PowerShell


  • Microsoft Online Services Sign-in Assistant – here
  • Windows 7 or Windows Server 2008 R2
  • Microsoft .NET 3.5.1
  • Microsoft Online Services Module for Windows PowerShell

Open the Microsoft Online Services Module for Windows PowerShell or just open Microsoft Windows PowerShell and just import the Online module using Import-Module MSOnline.

Once in PowerShell get the Office 365 credentials

  • $Cred = Get-Credential

Connect to Office 365

  • Connect-MsolService -Credential $Cred

List of available licenses

  • Get-MsolAccountSku

Create the user

  • New-MsolUser – UserPrincipalName -DisplayName “Joe User” -UsageLocation [Country e.g. “GB”] -LicenseAssignment [AccountSkuId from the previous command]

If you want to specify a password use the -Password parameter.

Via the bulk import wizard

The bulk wizard can be used from within the Office 365 portal. The bulk wizard simply takes a csv file with the following headers:

  • User Name
  • First Name
  • Last Name
  • Display Name
  • Job Title
  • Department
  • Office Number
  • Office Phone
  • Mobile Phone
  • Fax
  • Address
  • City
  • State
  • Postal Code
  • Country

Username and Display Name are mandatory.

You can also bulk import using PowerShell using a csv file and ForEach-Object loop.

If you wish to set a different password for each user consider omitting the password parameter and using Export-Csv to capture the newly created account details.

Via DirSync

Directory Sync can be used to create users in the cloud from users already defined within ADDS. Directory Sync can also synchronised user password but the passwords must be greater than eight characters. Directory Sync must be activated first within the Office 365 portal; users and groups > AD sync > Activate.

Directory Sync must be installed on a domain computer and requires an enterprise administrator account for the on-premises ADDS; the enterprise administrator credentials are used to create the MSOL_… user account. This is the account which will be used to export information from Active Directory.

The ADDS accounts UPN must be publicly resolvable e.g.

User and Group Properties

User and Group properties can be edited via:

Office 365 console

User properties such as Details, Settings and licenses can be edited here e.g.{Guid}

You can also bulk edit users Domains, Department, Office number, Office phone, Fax number, Street, City, State, Zip / Post Code, Country e.g

User admin page

This page is used to reset user passwords e.g. select the checkbox next to the user.


You can use PowerShell to set basic user properties using Set-MsolUser e.g


Other useful PowerShell commands are Set-MsolUserPassword to reset the password; use Set-MsolUser to set the PasswordNeverExpiresFlag.

To assign a licence to a user you would use Set-MsolUserLicense.

Creating a Office 365 domain

The default domain you’re assigned when you sign up for a portal has appended to the tenant name e.g.

To assign the companies actual public domain sign into the Office 365 portal > domains > Add domain > [to prove you own the domain you’re adding you’ll need to add a txt or mx record to the DNS zone file of the domain you’re adding to Office 365].


The record you’re required to create is only needed for the verification process and is completely random.

Licenses and Subscriptions

Licences can be managed and assigned to users via the Office 365 portal and Windows PowerShell.

Before a user can use Exchange they must be granted a licence from the licenses available in the subscription. This can be accomplished via the Office 365 portal or PowerShell; Edit users within the portal or Set-MsolUserLicense within PowerShell. Set-MsolUserLicense can be used in conjunction with New-MsolLicenseOptions. The Licence options allow you to divvy up specifics of the subscription in a granular fashion.

In the Office 365 portal you can add new subscriptions; using the purchase services link.

Licences can be assigned to users with either all licence components or a subset of components.

Recovering Identities and users

Administrators can reset their own passwords, or a global administrator can reset it for you.

If users are deleted they are stored in the deleted view for 30 days. If you need to restore a user from the deleted view you can use Restore-MsolUser or browse to