Tagged: PowerShell

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: https://github.com/heathen1878/ExportMailboxToPST


https://social.technet.microsoft.com/Forums/scriptcenter/en-US/c76c7167-8336-4261-ac40-2fb44ff3b3f3/powershell-and-outlook-removestore-method?forum=ITCG – used to name the Outlook data file store in order to disconnect it reliably.

http://www.bytemedev.com/powershell-disable-cached-mode-in-outlook-20102013/ – used for the disabling of the Outlook cache mode.


Spinning up and spinning down Azure VMs


This post discusses a relatively simple piece of code used to start or stop one or more Azure virtual machines within a defined time window.

Why am I doing this?

So, I have come up with this code to solve an issue with one of our customers wanting to de-allocate their VMs during non-business hours using PowerShell; the alternative would be to login to the Azure portal and selecting start…


…or shutdown everyday; not going to happen.


How does it work?

So this post references an earlier article I wrote around authenticating against Azure when scripting – see here.

The script reads in data from a csv file called AzureIaaSVMs.csv; the script looks for this file within the directory the script is being run from.



Once the data has been imported it works out what day it is and then checks whether that particular Azure VM should be running or shutdown and does the necessary.


I have this script scheduled to run every hour using Task Scheduler. The command for example would be c:\…\powershell.exe -file c:\…\deallocateAzureVMs.ps1


So the this script is relatively simple at the minute but does a job. The script could be extended to…

…report failures using email notification

…include multiple subscriptions

…be more granular regarding start or stop time and improved time logic

The current version of the script can be downloaded from GitHub here – https://github.com/heathen1878/AzureVMControl

Copying VHDs between Windows Azure Storage Accounts

Script overview

Thought I’d write an interactive script which allows you to specify the source and destination Storage Account name, container and blob.

Requires you’re already connected to Windows Azure – see this article for more info – should really integrate connecting to Azure as part of this script.


The functions are there basically to check whether the storage accounts, containers and blobs exist.


Script body

The main body of the script uses a valid variable to determine whether it can move to the next step.


Example of script output:


The script is available here.

Connecting to Windows Azure with PowerShell

Installing the PowerShell module

First of all you need the Windows Azure PowerShell module which can be downloaded from here.


The module is installed via the Microsoft Web PI, simply follow the installer. If PowerShell is open when you install the Windows Azure module simply restart PowerShell i.e. close it and reopen.

Next check the module is available using Get-Module -ListAvailable


This will be listed at the bottom if Azure is available.


Import the module using Import-Module Azure


Get-Command -Module Azure will give you a list of the available commands.

Connecting to Azure

[Updated 16/03/2016]:

If you’re looking to use an interactive PowerShell session with Azure then the Add-AzureAccount cmdlet is suitable; this will give you a 12 hour session token; after this time you need to re-authenticate.


Enter your email address associated with the Azure subscription and follow the prompts. Once you have authenticated return to PowerShell and type Get-AzureSubscription to see your subscriptions.

If you have multiple subscription then you’ll need to determine which one if default and which is current.


Get-AzureSubscription -Default returns the default subscription.


Get-AzureSubscription -Current returns the currently selected subscription.


If you have multiple subscriptions with the same name then the -ExtendedDetails parameter is useful to determine what is what.


Now comes the question…how do I authenticate against Azure when scripting? Well you need to use the PublishSettingsFile but If you’ve already added the subscription using the Add-AzureAccount cmdlet you’ll need to remove it first.


Use the Remove-AzureAccount and then use the Get-AzurePublishSettingsFile to get the certificate for the subscription to enable non-interactive authentication.


[Updated 16/03/2016]

Using PublishSettingsFile

First of all run Get-AzurePublishSettingsFile


This will open an internet browser and you’ll be prompted to enter your credentials associated with your Azure subscription, once authenticated a publishsettings file will be downloaded.


Next import the publish settings file using Import-AzurePublishSettingsFile -PublishSettingsFile FileName…


When you run Get-AzureSubscription you’ll notice your subscription will contain a certificate, you should now delete the downloaded .publishSettings file.


Run some commands against your subscription…Get-AzureVM…Get-AzureStorageAccount…


Windows Server 2012 – configuring NIC teaming

Configuring NIC teaming

NIC teaming is now built into the Windows operating system. This post briefly looks at what is supported, the configurations possible and some example configurations.

What is supported

Datacenter bridging, IPsec task offload, large send offload, receive side coalescing, receive side scaling, receive side checksum offloads, transmit side checksum offloads and virtual machine queues.

What is not supported

SR-IOV, rDMA and TCP Chimney are not supported by NIC teaming because these technologies bypass the network stack. SR-IOV can be implemented with NIC teaming within a virtual machine. 802.1x and QoS are not supported either.

Mixing different speed network adapters in teams is not supported in active / active teams.

NIC teaming configurations

There are two teaming modes switch independent and switch dependent; switch independent does not require the switch to be intelligent all the intelligence is provided in software; this mode also allows the team to span switches. Switch dependent requires that the switch supports Link Aggregation Control Protocol (LACP / 802.1ax) or static teaming (802.3ad draft v1) and only supports one switch.

The load balancing algorithms available are address hashing and Hyper-V ports; address hashing will hash the TCP or UDP port and IP address of the outgoing packet, if the TCP or UDP port is hidden i.e. is protected by IPsec or may be the traffic is not TCP or UDP then the IP addresses are hashed instead. Finally is the traffic is not IP then a hash of the MAC address is generated.

Hyper-V port load balancing uses the virtual port identifier to load balance traffic.

The combination of the teaming modes and algorithms defined above are:

  1. Switch independent with address hashing
    1. Uses all team members to sent outbound traffic. Can only receive inbound traffic on the primary network adapter of the NIC team. This mode is best suited for applications such as IIS, teaming within a virtual machine, teaming where switch diversity is a concern and where active / standby teaming is required.
  2. Switch independent with Hyper-V ports
    1. Each virtual machine will be limited to the bandwidth of one network adapter in the NIC team. The virtual machines will send and receive data on the same network adapter. This mode is best suited when the number of virtual machines far exceeds the number of team members and the limitation of bandwidth is not a concern. This mode also is best suited when virtual machine queue is used.
  3. Switch dependent with address hashing
    1. Uses all team members to send outbound traffic, inbound traffic will be distributed by the switch. This mode is best suited for applications which run on Windows natively and require maximum network performance and can also be used where virtual machines have a requirement for more bandwidth than one network adapter can provide.
  4. Switch independent with Hyper-V ports
    1. More or less the same as the switch independent mode but with the following exceptions: the inbound network traffic is distributed by the switch, this may result in the inbound traffic arriving on all team members thus a VMQ will be present on all team members for a particular VM so this mode may not be best suited when VMQ is configured. The mode suits when the Hyper-V host is densely populated and policy dictates that LACP should be used.

NIC teaming within Hyper-V

NIC teaming within the virtual machine allows you to provide access to two or more virtual switches. Each network adapter must be configured to allow teaming. The team within the virtual machine cannot be anything other than switch independent with address hashing. NIC teaming is also useful where SR-IOV is being used; SR-IOV allows the virtual machine direct access to hardware, more here.

The vSwitches must connect to physically different switches. The virtual machine should be configured with a network adapter assigned to each vSwitch

Image below shows three virtual switches each with one network adapter assigned.


Within the virtual machine create two network adapters connecting each one to a different virtual switch.


Within Server Manager you will notice two network adapters, nothing new there.


Click on the NIC Teaming link to configure NIC teaming.


Select tasks > New Team


Name the team and select the adapters; you’ll notice because the operating system is installed within a virtual machine you’re restricted to address hashing in switch independent mode.



Alternatively to using the GUI you can do the same in one line of PowerShell using New-NetLbfoTeam.

Native NIC teaming

NIC teaming natively allows you to untag multiple VLANs using team interfaces, the most common NIC teaming configuration is switch dependent with address hashing.

NIC teaming configuration example:


Before running the command above I would suggest the network ports are not connected to protect against loops and broadcast storms. I have a HP procurve switch which supports dynamic LACP, so I only had to configure the switch ports to be LACP active and the switch does the rest. HP Documentation here.

To remove the NIC teaming configuration use Remove-NetLbfoTeam -Name [Team name]

NIC teaming can also be used where VLAN tagging at the operating system is required.

Windows Server 2012 – Install and configure servers

Install Servers

Plan for server installation

Windows Server 2012 installation requirements can be found here; in summary Windows Server 2012 requires 64 bit architecture, digitally signed kernel-mode drivers, 32GB disk space (note: pagefile, hibernation file etc takes space too).

Considerations for the installation:

  • Remove any unnecessary serial devices i.e. UPS
  • Mass storage device drivers maybe required
  • Windows firewall is enabled by default

Plan for server roles

Design, deployment and management guidance for Windows Server 2012 roles can be found here.

Active Directory Certificate Services – new functionality incl. PowerShell and integration with Server Manager.

Active Directory Domain Services – support for virtualisation incl. cloning of domain controllers, streamlined deployment with prerequisite checks, simplified management incl. claims-based authorisation and under-the-hood improvements to RID, deferred index creation, AD recycle bin GUI etc.

Active Directory Federation Services – PowerShell and Server Manager integration.

Active Directory Lightweight Directory Services – No change from Server 2008.

Active Directory Rights Management Services – Changes to SQL server requirements (no longer need local administrative credentials on the SQL server; sysadmin privilege is now suffice) and integration with Server Manager.

Application Server – No change from Server 2008.

Failover Clustering – In Windows Server 2012 – improved scalability; now scales to 64 nodes and 8000 virtual machines, new management interface using Server Manager, enhancements to cluster shared volumes, support for scale-out file servers, cluster aware updating, virtual machine application monitoring and management, improved validation tests, active directory integration and quorum configuration.

In Windows Server 2012 R2 – support for guest clusters, virtual machine drain i.e. live migration virtual machines on shutdown of the Hyper-V host, virtual network health detection, improved CSV placement policies, resiliency, diagnostics and interoperability. Less dependency on ADDS, improvements to quorum incl. dynamic witness.

File and Storage Services – work folders, SMB improvements incl. SMB direct, storage spaces incl. tiered storage, distributed RAID?

In Windows Server 2012 R2 SMB sessions are now tracked per file share rather than per server allowing for redirection with the best access to the volume.

Group Policy – remote group policy update, sign-in optimisation i.e. slow link processing, new starter group policies, new PowerShell cmdlets, increased max size of registry.pol, group policy client idling (improves client computer performance).

In Windows Server 2012 R2 group policy has added support for IPv6 around printers, item-level targeting and VPN connections, group policies cached locally which are good for latent connections.

Hyper-V – loads of new features, client Hyper-V, dynamic memory, virtual machine replicas, improvements to import of virtual machines, live migration without shared storage, improved Hyper-V administrative delegation, pass-thru networking and storage adapters, virtual machine storage on file servers using SMB 3.0 and virtual NUMA.

In Windows Server 2012 R2 Hyper-V has shared virtual hard disks to complement guest failover clustering. Virtual hard disk resizing on the fly, storage QoS; set minimum and maximum IOPs per virtual machine. Live migration improvements such as compressing memory before migrating and rDMA support where applicable. New virtual hardware for Windows Server 2012 and Windows 8 and later. Clustering can detect network and storage issues and restart the virtual machine elsewhere.

Hyper-V replica now has 24 hour recovery points and now supports more than one replica.

Networking – New 802.1x protocol EAP-TTLS (Tunneled Transport Layer Security) which supports non-Microsoft RADIUS. improvements to BranchCache, Data Center Bridging support for converged network adapters, DNSSEC improvements, DHCP failover, NIC teaming, QoS and improvements to IPsec IKEv2,

Windows Server 2012 R2 support virtual receive-side scaling to utilise multiple virtual CPU cores.

Print and Document Services – Branch Office direct printing, new driver support etc.

Remote Desktop Services – improvements to sounds and video playback, virtualised GPU support (requires a SLAT processor and GPU driver which supports DX11).

Security and Protection – Dynamic access control provides central access policies to grant or deny access to files and folders across all Windows Server 2012 computers. DNSSEC, improved IPsec, security policies and policy management, Bitlocker improvements, Group Managed Service Accounts, AppLocker improvements etc.

Volume Activation – Is now a server role which automates the issuance and management of Microsoft software licenses. KMS, VAMT and MAK proxies are still available.

Web Server – Web server instances, SSL certificates stores, Server Name Indication (SSL host headers), application initialisation and dynamic IP restrictions.

Windows Deployment Services – can deploy vim, vhd and vhdx images; vhdx can be applied to volumes in a similar way to wim files. Support for ARM architecture too.

Windows Server Backup – ability to select individual virtual machines for backup and restore, support for large volumes e.g. greater than 2TB and 4 Kilobyte sectors.

Windows Server Essentials Experience – essentials experience can be installed in Windows Server 2012 Standard and Datacenter, it enables you to manage the server through a simplified dashboard, integrate with Office 365, Exchange Online, Windows Intune etc. Very much the same functionality as Small Business Server.

Windows Server Update Services – PowerShell improvements, improved security and client / server software separation.

Windows System Resource Manager – deprecated in favour of functionality provided by Hyper-V.

Plan for server upgrade

upgrade guidelines:

  • In-place upgrades from 32bit to 64 bit are not supported, nor are upgrades from one language to another and from one build type to another.
  • You cannot upgrade from a release candidate.
  • You cannot upgrade from core to full GUI and vice versa but you can configure Windows Server 2012 to utilise the full GUI or core mode after the upgrade.
  • You cannot upgrade to a lesser version i.e. Server 200x Datacenter to Server 2012 Standard.

Server Core Overview

Server core is now not an irreversible choice you can freely switch between a Gui, Minshell and core mode using PowerShell and DISM.

Install Server Core

Server core is the default choice when you install Windows Server 2012. The installation process is pretty streamlined with minimal questions asked.

Configure Features On Demand

Features on demand allows you to remove binaries from the installation which are not required e.g. if you have a web server which is a member of a domain you can safely remove the Active Directory binaries.

The best practice is to copy the WinSxs folder to a network share and assign the builtin group domain computers read share permissions.


If you need to install a role or feature where the binaries are no longer available on the local computer you can use the source share or Windows Update e.g. where Get-WindowsFeature returns an install state of Removed basically means the binaries no longer exist on the computer. The default locations used by Install-WindowsFeature are the location specified within the Gui wizard, the value of the group policy object ‘Specify settings for optional component installation and component repair’ and Windows Update. To override the above specify the source parameter.





Migrate Roles from Previous Versions of Windows Server

Server role upgrade guidelines:

  • Active Directory upgrade: see here. In summary forest functional level must be Windows Server 2003, compatible clients are Windows XP and later, verify application compatibility, a number of master roles should be accessible during the promotion of a Windows Server 2012 domain controller.
  • Active Directory Federation Services: in general guidelines suggest export AD FS configuration, perform in-place upgrade of the operating system, recreate AD FS configuration and restore AD FS service settings.
  • Active Directory Rights Management Services: In-place upgrades supported but will require the AD RMS upgrade wizard to be run to ensure consistency. NOTE: If AD RMS was installed with the Windows Internal Database (WID) then first of all the WID instance should be migrated to SQL Server. See here.
  • File and Storage services: if DFS was installed prior to the upgrade then DFS will need reinstalling.
  • Hyper-V: shutdown virtual machines and remove any existing snapshots prior to the upgrade.
  • Printer server: migrate using the Printer Migration Wizard.
  • Remote Access: the functionality provided by RRAS is now integrated into Remote Access Server (Direct Access). This role can be migrated to Windows Server 2012 by following this guide.
  • Remote Desktop Services: No migration path but you could utilise existing Server 2008 R2 session host servers by routing users through the Windows Server 2012 RD Web Access server.
  • Volume Activation Services: AD schema must be at Windows Server 2012 level to store activation objects.
  • Web Server: no change in functionality, web applications which work in IIS 7 will work in IIS 8.

Install, Use and Remove Windows Server Migration Tools

The Windows Server Migration Tools are installed on the destination server using Install-WindowsFeature Migration. To configure them browse to the migration tools directory c:\windows\system32\ServerMigrationTools\ then run smigdeploy.exe with the following parameters ‘smigdeploy.exe /package /architecture [amd64|x86] /os [WS03|WS08|WS08R2] /path [deployment folder e.g. c:\smigdeploy]’

Next copy the deployment folder to the source computer and run smigdeploy.exe to get access to the migration cmdlets Import- and Export-SmigServerSetting, Get-SmigServerFeature and Send and Receive-SmigServerData.

Once this part is complete go <a href=”http://technet.microsoft.com/en-us/windowsserver/jj554790.aspx”>here</a&gt; to view the role migration guides.

Once the migration is complete you can remove the migration tools from Windows Server 2012 using Uninstall-WindowsFeature Migration and from Windows Server 2008 R2 and earlier using smigdeploy.exe /unregister.

Configure Servers

Configure Server Core

Common core configuration tasks are:

  • Setting an administrative password: you’re prompted to set a password after the installation is finished. To change a password use Ctrl + Alt + Del.
  • Setting an IP address: you can use sconfig.cmd or PowerShell.
    • PowerShell: Get-NetIPInterface and note the number within the IfIndex column.
    • GetNetIPInterface
    • PowerShell: New-NetIPAddress -InterfaceIndex # -IPaddress xxx.xxx.xxx.xxx -PrefixLength ## -DefaultGateway xxx.xxx.xxx.xxx
    • NewNetIPAddress
    • PowerShell: Set-DNSClientServerAddress -InterfaceIndex # -ServerAddresses xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx.
    • SetDNSClientServerAddress
  • Adding the computer to the domain: run add-computer and follow the prompts or provide the information to the cmdlet.
    • AddComputer
  • To rename a computer use the rename-computer cmdlet, to get the existing computer name use hostname.
  • To activate the computer use slmgr.vbs -ato; you may need to provide a product key using -ipk.
  • To configure the Windows Firewall use Set-NetFirewallProfile, New-NetFirewallRule, Set-NewFirewallRule…more here.
  • To enable PowerShell remoting use Enable-PSRemoting

Add and Remove Server Roles and Features

Use Install-WindowsFeature and Uninstall-WindowsFeature. These commands have optional parameters such as:

  • IncludeAllSubFeature (all applicable sub features) – Install cmdlet only
  • IncludeManagementTools
  • ComputerName (if the computer is remote)
  • ConfigurationFilePath (used to specify roles and features to be installed and any configuration parameters required) – Install cmdlet only
  • LogPath (if you want the cmdlet results)
  • Remove (removes the binaries from the computer) – Uninstall cmdlet only

Convert Server Core to / from Full “Server with Gui”

The installation of server core can be converted to minshell or full GUI by running dism /mount-wim /wimfile:d:\sources\install.wim /index:4 /mountdir:c:\DVD /ReadOnly



Note: my DVD drive letter is D:\ and I created a directory on C:\ called DVD. The index number of the installation can be found by using the PowerShell cmdlet Get-WindowsImage -ImagePath d:\sources\install.wim


To install the full Gui run Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart -Source c:\DVD\Windows\WinSxs

If you just want the minshell leave out Server-Gui-Shell.


The -Source parameter is needed if you have installed the core mode.



on restart you’ll see ‘Configuring Windows Features’


The full GUI can be converted to core or minshell using the PowerShell cmdlet Uninstall-WindowsFeature e.g

To get to the minshell:

Uninstall-WindowsFeature Server-Gui-Shell -Restart


To get to the core mode:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart


Configure Services

The Get-Service cmdlet can be used to get the status of all services; you could pipe this output to Start-Service or Stop-Service depending on the value of the status property.

The Get-Process cmdlet can be used to return all running processes.

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:

  • *.microsoftonline.com
  • *.outlook.com
  • *.sharepoint.com
  • *.lync.com

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 http://testexchangeconnectivity.com 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 (sharepointonline.com) – 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 autodiscover.outlook.com. 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 https://ps.outlook.com/powershell



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.


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 – http://technet.microsoft.com/en-us/library/dn246918.aspx. 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 https://www.testexchangeconnectivity.com/ 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 user@domainname.com -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. @domainname.com

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. https://portal.microsoftonline.com/UserManagement/EditUser.aspx?id={Guid}

You can also bulk edit users Domains, Department, Office number, Office phone, Fax number, Street, City, State, Zip / Post Code, Country e.g  https://portal.microsoftonline.com/UserManagement/BulkEditUser.aspx

User admin page

This page is used to reset user passwords e.g. https://portal.microsoftonline.com/UserManagement/ActiveUsers.aspx 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 onmicrosoft.com appended to the tenant name e.g. companyA.onmicrosoft.com.

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 https://portal.microsoftonline.com/UserManagement/DeletedUsers.aspx