Mailbox Migration to Exchange Online, Strange error…

Recently I tried to do some mailbox migration tests between my on-premises Exchange infrastructure and Exchange Online in Office 365. The mailbox move/migration should be the simple part on any migration project as you spend all the time ensuring the other parts of the solution are correct. However I queued a new move request recently as I needed a new mailbox in Exchange Online to test some settings in SharePoint Online… The move started, but it failed with the following:

After a number of checks and trying the migrations again still with no joy, I thought I’d remove the user/object from Office 365. Prior to removing the object I connected to Exchange Online via PowerShell and ran:

Get-MailUser –Identity “Affected user email” | FL *GUID*, Ident*

I then moved the users AD Object in my local Active Directory to an OU that was not being synchronised to Azure AD, and performed a full sync. Once the sync had completed I confirmed the user object was no longer in Azure AD, then moved the AD Object back to synchronised OU and perform another sync. After the sync had completed I re-ran the previous PowerShell cmdlet:

So by performing these actions I can see that I managed to get a new object GUID for the this mail user. I then performed a new mailbox migration to Exchange Online which completed successfully.

I will add that my home lab does get a load of abuse, where I test different exchange scenarios, but I do this so I know how to fix issues etc. its very possible I caused this error within my lab when I was doing previous disaster recovery tests. So there is a very good chance that you may never see this error.

I know that this process can be very long especially if your Directory Synchronisation has a lot of objects, so I’ll continue to look if there is another way to resolve this.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.

Exchange Server 2016 Certification

Back in March last year I passed the final Exchange 2013 exam to earn my MCSE: Messaging 2013 certification, I spent a lot of time reading websites, blogs, and watching videos all covered in the previous post. So little did I think in under a year I would be doing another Exchange exam! but I did…

I saw on the Born To Learn website in January that Microsoft Learning were offering free Beta Exam 345: Designing and Deploying Microsoft Exchange Server 2016 exams (Offer now expired), So I thought what's is the harm in doing a free exam, at the very least I’d get exam simulation experience and get an idea what Microsoft was going to be looking for. I booked for the last possible day in February the offer would allow me to book, because even thou I’ve played with the install and read the Exchange Team Blog post I’d not looked into Exchange 2016 to the same level as 2013…

Little did I appreciate that the material I used for 2013 was not there for 2016… So most of my learning material came from TechNet: Exchange 2016 Site, whilst there was other Exchange resource blogs that had started to post about 2016, it wasn’t the same level of material I used for 2013.

This was the first Microsoft Beta exam I’ve taken, so this was a new experience for me. All Microsoft exams are about taking your time, understand the questions and give the answer Microsoft are looking for, but this I can say this the first time I’ve used the full time allocated to an exam… all 180 minutes of the time. As everyone that has taken a Microsoft exam will know there is that feeling at the end of the exam where you “End the exam?” where you wait for the “Pass or Fail” message on screen… but this time as the exam was a beta I confirmed to end the exam I just got a message of “…Thanks for taking the exam…” or something like that, can’t fully remember the exact text on screen, whilst I knew I wasn’t going to get the result straight away I still got that strange feeling at the end of the exam. I just had the long 8 week wait for the results…

So in April by chance I longed into Microsoft Learning site and saw a banner at the top of the page…

Which obviously was really happy and surprised about as I’d not had any notification from Microsoft or Pearson VUE about the results. For an MCSE: Messaging you now only need the single 70-345 exam on top of you MCSA qualification.

Learning material is slowly being published now:

Pluralsight Course – Migrating to Exchange Server 2016
Exam Ref. 70-345 Designing and Deploying Microsoft Exchange Server 2016

Microsoft later emailed me to confirm the qualification and that I was a Charter Member for Exchange Server 2016

Is PowerShell Flawed?

Following my previous post about automating user licensing in Office 365, I came across a funny issue with Windows PowerShell for Active Directory. The project was to help the client connect to Office 365, they had multiple Active Directory forests in multiple international locations. For those that have worked with Office 365 you will know that before a license is allocated a “Usage Location” has to be set. So the plan was to use the “Country/Region” data from Active Directory. However some of the forests had not set this for their users. As this had not been set for a large number of accounts I thought the easiest solution would be to set this via PowerShell. I always say that if you’re using the GUI to do something twice, you’re doing it wrong… ;-) I ran the following cmdlet:

Set-ADUser [User] –Country:”GB”

Which in principal worked:  But after a Directory Synchronisation to Office 365 I noticed the change had not been applied to the Azure AD user?!? After some troubleshooting and digging around, I found the issue was that the PowerShell cmdlet run only sets the “c” attribute in Active Directory, whereas if you update the Country via the GUI it updates the “c”, “co”, and “countryCode” attributes. The Directory Sync server uses the “co” field to populate the “County/Region” field in Azure AD. So this got me thinking why the PowerShell cmdlet did not set these values? The sometimes much forgotten Active Directory Administration Centre or ADAC makes changes via PowerShell and gives you the history of the run cmdlets, so I made the change in ADAC, which updated all the attributes as expected, the in the PowerShell history it had run the following cmdlet:

 

I copy and pasted the cmdlet from ADAC straight into Windows PowerShell, but it only set the “c” attribute again… So after a bit of digging around, I came up with the following:

$c ="US"
$co ="United States"
$countryCode = "840"
Set-ADUser <USER> -replace @{c=$c; co=$co; countryCode=$countryCode}

Which had the desired result on the Active Directory attributes and once synchronised to Office 365 the data in Azure AD was correct. I don’t fully understand why setting in ADUC and ADAC updates all the attributes, and if ADAC is making additional changes why it’s not being report in the PowerShell history.

So getting back to the title of the Blog “Is PowerShell Flawed?”… No of course not, PowerShell is a very powerful tool to aid any configuration or administration of infrastructure and systems, but you need to make sure you know what the PowerShell cmdlet are setting, you ask it to set something, it will set it!, it maybe not the desired setting you think it’s going to set, just make sure you check what you’re trying to set and what you’re running is applying the correct setting.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.

Office 365 Automate User Licensing

Recently working with a client they wanted to automate the licensing of Office 365 accounts, this client had multiple Active Directory forests being sync and cloud users in their Office 365 tenant. For those that have to assign licenses to users in Office 365 know it’s a two step process:

1. Set user location
2. Assign Office 365 license

To do this requires you to login to Office 365 and assign the information, We all know to run a local scheduled task, credentials can be stored in the task, however this is not possible (…Not that I’ve found) to store Office 365 credentials and pass them thru PowerShell from the scheduled task. For this reason you need to store the password on the local system. Before we get to this you need to make sure the user account your using has the correct permissions to assign licenses. Office 365 has a number of Admin roles Office 365 Admin Roles

So the only roles that can assign licenses are Global Admin and User Management Admin.

I’ve broken the PowerShell into five sections:

1. Get Office 365 Credentials
2. Connect to Office 365
3. Set user usage location
4. Get Office 365 license SKU
5. Assign License

Get Office 365 Credentials

To be able to pass the password from the schedule task to PowerShell the password needs to be stored in plain text, to store passwords in plain text is never recommend. For this reason I’ve not used a domain account, I’ve used a cloud only account with a complex password. The location of the password is a local domain server which has restricted logons and additional NTFS permissions can be added to the location.

## MSOL Credentials
$MsolAdmUser = “MSOL@yourdomain.onmicrosoft.com” 
$pwd = Get-Content C:\Common\msol.txt | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential $MsolAdmUser, $pwd

Connect to Office 365

To connect to Office 365 you need the follow these instructions Manage Azure AD using Windows PowerShell as Prerequisites. Once these steps have been completed. you will be able to connect:

## Connect To Office 365
Import-Module MSOnline
Connect-MsolService -Credential $cred

Set user usage location

A colleague of mine pointed me to this script in the TechNet Gallery, this script makes the local Active Directory country/region field to the Office 365 usage. Download and store this script.

## Set Usage Location for MSOl Users
C:\Common\Set-MSOLUsageLocation.ps1

Get Office 365 license SKU

Before a license can be assigned, we need to get the correct SKU.

## Get Office 365 Account SKUs
$AccountSku = Get-MsolAccountSku

Its possible that you will have a number of different SKU’s on your tenant, you can list individual SKU:

## Account SKU Array
$AccountSku[0].AccountSkuId
$AccountSku[1].AccountSkuId
$AccountSku[2].AccountSkuId

For this project we’re only assign one type of SKU to all users, I’ll post another blog later how to assign different SKU’s within the same script.

Assign Licenses

Last but not least is to assign the license to the users. This takes data from the previous steps and assigns licenses:

## Set License for MSOL Users
$Users = Get-MsolUser -All -UnlicensedUsersOnly
$users = $users | ? {$_.Country -ne $null}

ForEach ($User in $Users)
    {
        Set-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -AddLicenses $AccountSku[0].AccountSkuId
    }

Put all of these steps together in a PS1 script and set a scheduled task. Next steps are to put a query/variable into the Set-MsolUSerLicense this will allow different types of SKU’s to be applied in the same script, I’ll post this once complete…

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.

Exchange 2016 Installation…

Here are my notes of deploying Exchange 2016 into my home lab for testing, My current Exchange deployment is 2013 connected to Office 365 with a hybrid configuration. I plan to deploy two Exchange 2016 servers in Database Availability Group. This post will deal with the initial upgrade to the Schema, Configuration and Domain, then the installation of the first Exchange 2016 server.

Prerequisites

Download Exchange 2016 Download Link, and extract the setup files to local on the Exchange Server. To upgrade the Schema, Configuration and Domain this can be done from a 64-Bit Domain Controller or from an Exchange Server with the Remote Tools Administration Pack feature installed, The Server also requires .NET Framework 4.5.2,  To install this feature:

1. Download and install .NET Framework 4.5.2 (If Windows Update has been run this may already be installed)
2. Open Windows PowerShell (Run as Administrator)
3. Install the Remote Tools Administration Pack using the following command
   
   Install-WindowsFeature RSAT-ADDS

To upgrade the Schema, Configuration and Domain(s) open a command window (Run as Administrator) and run the following commands:

1. Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
2. Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
3. Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

If you you have multiple domains to in the Active Directory Forest you can use the /PrepareAllDomains.

Note: To prepare The Schema the service account used must be a member of Schema Admins and Enterprise Admins, To update the Configuration and Domain(s) the service account used must be a member of Enterprise Admins.

Reference: TechNet Prepare Active Directory and Domains

PrepareSchema, PrepareAD, PrepareDomain

Server Preparation

Before Exchange 2016 is installed a number of Windows Features need to be installed, To install these features:

Reference: TechNet Exchange 2016 Prerequisites

1. Open Windows PowerShell (Run as Administrator)
2. Install required features:
   
   

   Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation
   

3. Restart Server

4. Install Additional Software:
1. .NET Framework 4.5.2
2. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
5. Run Windows Update

Graphical User Interface Installation

The following screenshots are taken from the Graphical User Interface Installation (GUI) of Exchange 2016.

Reference: TechNet Install the Exchange 2016 Mailbox role using the Setup wizard

Note: Please note these installation requirements:

• If you're installing the first Exchange 2016 server in the organization, the account you use needs to be a member of the Enterprise Admins group
• If you haven't previously prepared the Active Directory schema, the account you use also needs to be a member of the Schema Admins group
• If you've already prepared the schema and aren't installing the first Exchange 2016 server in the organization, the account you use needs to be a member of the Exchange 2016 Organization Management role group

1. 
   First window will ask Check for Updates? This the RTM of Exchange 2016 and currently no updates, click Next
2. 
   Click Next
3. 
   The file setup will display Copying Files…
4. 
   The setup will display Initializing Setup… 
5. 
   The setup will display Introduction with links to Exchange 2016 technical information, click Next
6. 
   The License Agreement will be displayed, Once read… Select the radio I accept the terms in the license agreement, and click Next
7. 
   Then select Recommend Settings that you want, the links will display information on these settings, I leave this set on Use Recommended Settings but some clients I work with prefer this to changed, once selected click Next
8. 
   Now there is just a single role to install, check Mailbox Role, and click Next
9. 
   This screen allows you to change the installation directory, please not that Exchange 2016 is still installed in V15, this is the same as Exchange 2013, once installation path has been confirmed click Next
10. 
    Leave the default Malware Protection Settings enabled unless you requirement for them to be turn off, and click Next
11. 
    The setup will run Readiness Checks… to ensure the server and infrastructure is ready for Exchange 2016 to be installed.
12. 
    Any errors and warnings will be displayed, for instance in my environment it warned me that “MAPI over HTTP is the preferred Outlook desktop connectivity…” Now I thought this was default in Exchange 2016 need to check the release notes, this might just be for New/Greenfield installations, if there is no errors and only warnings, click Install to begin the installation.
13. 
    Setup will go through all of the required steps to install Exchange 2016
14. 
    Once complete the last screen will be displayed, click Finish to close the setup window
15. The server should be restarted post installation

Unattended Installation

The over method of installing Exchange 2016 is through a Unattended Installation, this installs Exchange 2016 through the command window, this method uses switches to configure all the options of the Exchange 2016 installation.

Reference: TechNet Install Exchange 2016 using unattended mode

1. Open a command window (Run as Administrator)
2. For a basic Exchange 2016 installation, enter the following command:
   
   Setup.exe /mode:Install /role:Mailbox /InstallWindowsComponents /IAcceptExchangeServerLicenseTerms

This will install Exchange 2016 with a random mailbox database, you can use the switches to change the installation directory and database name and paths etc. The following screen is a completed unattended installation of Exchange 2016.

This completes the basic installation of Exchange 2016, all in all the setup process is very similar as Exchange 2013. Next up will be the configuration of Exchange 2016 including Mailbox Databases, Database Availability Group, Virtual Directories, Office Online Server… and much much more.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.

Exchange 2013 Cumulative Update

The latest Exchange 2013 Cumulative Update (CU) 10 was released on 15th September 2015. There was no schema changes compared to CU9 , in fact the last schema change was in CU7.

Download the CU10 Download Link, and extract the setup files to local on the Exchange Server. To upgrade the Schema, Configuration and Domain this can be done from a 64-Bit Domain Controller or from an Exchange Server with the Remote Tools Administration Pack feature installed. To install this feature:

1. Open Windows PowerShell (Run as Administrator)
2. Install the Remote Tools Administration Pack using the following command
   
   Install-WindowsFeature RSAT-ADDS

To upgrade the Schema, Configuration and Domain(s) open a command window (Run as Administrator) and run the following commands:

1. Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
2. Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
3. Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

If you you have multiple domains to in the Active Directory Forest you can use the /PrepareAllDomains.

Note: To prepare The Schema the service account used must be a member of Schema Admins and Enterprise Admins, To update the Configuration and Domain(s) the service account used must be a member of Enterprise Admins.

Reference: TechNet Prepare Active Directory and Domains

PrepareSchema, PrepareAD, PrepareDomain

Unattended Installation

Once the Schema, Configuration and Domain has been updated, allow time for this to replicate to all Domain Controllers in the forest, The easiest way to upgrade a Exchange 2013 server is with an Unattended Installation. Open a command window (Run as Administrator) and run the following command:

1. Setup.com /Mode:Upgrade /IAcceptExchangeServerLicenseTerms

The setup will check the environment to ensure that it’s ready to install, any warnings will be displayed, for instance my installation warned that I didn’t have a send connector for ‘*’, this is because my lab sits behind a dynamic IP address and I can’t send external SMTP.

Note: This upgrade was on a standalone Exchange server that was not a member of a Database Availability Group(DAG), If a server is a member of a DAG it needs to removed/suspended from the load balanced environment and put into maintenance mode, I’ll get this posted on another day.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.

Azure Active Directory Sync Issue…

Working on an Azure Active Directory Sync for a client with multiple forests I came across a strange issue. The first forest was setup with password synchronization for the On-Premises AD accounts, stepped through the wizard and did the initial sync to Azure AD. Once the sync was complete tested login to Office 365 using one of the synced accounts and all worked as expected.

The issue came when adding the second AD connection. Disabled the scheduled task, then open the Microsoft Azure AD Connection Tool to use the wizard to add the second AD forest. Once the new forest was added and synchronization was complete I tested the new logins with Office 365, however this time I was not able to use the accounts that had been synched.

After double checking all settings and making sure I’d not missed anything, I checked the connector using PowerShell:

Get-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestB.Domain.com

This reported back that:

Password hash synchronization isn’t configured for this connector

I checked the original connector

Get-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestA.Domain.com

This reported back:

SourceConnector: ForestA.Domain.com
TargetConnector: Tenant.Onmicrosoft.com
Enabled: True

I ran the PowerShell to add password synchronization to the new connector:

Set-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestB.Domain.com –TargetConnector “tenant.onmicrosoft.com – AAD” –Enable $True

Re-checked the AD Connector, which reported back:

SourceConnector: ForestB.Domain.com
TargetConnector: Tenant.Onmicrosoft.com
Enabled: True

Re-ran the synchronization to Azure AD, once completed tested the same login and all worked.

Note: We plan to add another AD forest to this Azure Active Directory Sync installation, so will update if the issue was with this AD connector or all connectors…