Thursday, 21 September 2017

New Office 365 sign in experience and Microsoft Authenticator app with code sign-in for 2nd factor issues

This has just happened on my Office 365 account with the new sign in experience - I can  no longer change verification option and enter a code rather than approve or deny based on notification.

This was enforced on Windows Phone/Mobile it appears as notifications no longer work - however users using the code over notification on iOS or Android will most likely be getting the same lockout as they cannot provide 2factor anymore to successfully login.

New experience:

What I have had to fall back to:

It appears the new sign in experience multi factor request needs to add the verification code to the new experience.

When I signed up to the new sign in experience it provided the new sign in but reverted to the old screen for 2factor authentication. Now they have updated it so both parts are the 'new sign in' experience it appears they have forgotten about users that log in with a verification code.

So if you're testing the new sign in experience, ensure you aren't using code verification.

Take care,

Oliver Moazzezi

Wednesday, 30 August 2017

Microsoft 365 Business, E3 and E5 preview

Please see my latest webinar on Microsoft 365. This covers the Business, E3 and E5 SKUs and informs you on the benefits Microsoft 365 brings with Windows 10 Creators update, Office 365 and the Enterprise Mobility + Security suite.

Have Fun!

Oliver Moazzezi

Friday, 23 June 2017

New TechNet Gallery scripts coming

Thought I would just check-in to let you all know what I am working on. In the next two weeks i'll be publishing some new PowerShell scripts to my Technet Gallery page.

The first will help with full mailbox and send as permissions in a Cutover or Staged Migration.

The second will help in AADConnect scenarios when configuring password writeback or enable password synchronisation - to check all objects can be edited by the AADConnect account.

Look out for them!

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Friday, 19 May 2017

UK data residency option in Office 365 Admin Center

For UK companies that currently have their data in the EU Microsoft has now pushed the option to have your data migrated to UK data centres into the Office 365 Admin Portal.

Simply login, Go to Settings | Organisation Profile | Data residency option | and you will be able to make the request.

Edit the options and you can approve the move which Microsoft will complete within 24 months of September 15th 2017.

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Thursday, 27 April 2017

Comparing Azure Conditional Access and Azure Conditional Access Preview

Azure Conditional Access is a policy and access enforcement solution for both Azure and Office 365 services. Conditional Access  requires Azure AD Premium P1 or above before it's available to be configured on your tenant.

Microsoft are currently moving conditional access to the new Azure portal experience where it is in Preview. So I thought I would compare the old and new experience and post it here.

On top of this location and experience change they have also enabled far more granular policy controls for granting access to services as well as expanding support for Office 365 workloads. Which is great news to hear. We can now specify conditional access for Skype for Business online.

First off though, let's look at  the legacy portal experience at

Once logged in select your directory

From here we browse to 'Applications'

Select your workload, in this example I have selected 'Exchange Online'

We then have the option of enabling access rules for 'multi-factor authentication and location based policy control, and device based policies.

Once enabled we can specify rules that effect all users - or concentrate them on a specific group - and include exclusions if necessary.

In this example I am specifying a policy based on specific groups

And blocking access when a user is not at work (or allowed network).

To define your network locations, select 'define/edit your network location' and enter your public IP subnets that should be trusted.

Once back at the rule, ensure you save your selection

Should I wish to enable device access, I simply enable this also

Specify whether I want all devices in scope or specific ones

if I am being specific then selecting which OS/device this is

And then deciding if this is for the browser and native applications or native applications only

And the result of this rule? Being denied access to Exchange Online as I do not meet the conditional access criteria

So how does Azure Conditional Access Preview compare?

For users not used to the new Azure Portal you may at first need time to work out how the interface works.

Once logged in, select Azure Active Directory on the left pane

Once within Azure Active Directory, select Conditional Access

At this moment in time, if you have policies already configured in the legacy portal you cannot see them here. I am sure once out of Preview Microsoft will be looking to migrate your existing policies. For greenfield select 'New Policy'

Select a name for your policy. We then work our way through the assignment section, this specifies Users and Groups, Cloud Apps and Conditions

Specify if the policy is for all uses or groups, exclusions are still possible on the seperate tab

We can now multi select our cloud apps and create policies for multiple workloads

Now we have specified our users or groups, and cloud apps, we move on to the conditions for access

Device based access, multi factor enforcement and location based access are all rolled into one. The Preview still honours your Trusted IPs - and infact you must still configure them in the same place as previously shown.

You will find the Preview has far more granular control for fine tuning your conditional access requirements

We then enable the policy, the policy goes through validation checks and then is immediately enforced

We receive the same conditional access user experience

Keeping in mind the new experience is still in Preview - and you won't want to necessarily move over just yet - I would recommend looking at the new portal experience and start to plan how you will possibly add additional benefits to your conditional access policies that you may not have had the granular ability to do so before - or indeed the support for a particular service.

It will also provide you with the familiarity of the new portal experience.


Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi


Tuesday, 4 April 2017

What happens to my data when an Office 365 subscription ends and expedited deprovisioning

Office 365 will delete your subscription data after 90 days and no later than 180 days after cancellation. However, what happens if you have a requirement to delete that data sooner?

Microsoft offer something called 'expedited deprovisioning', you can read about it and the normal cancellation and deletion processes here, Expedited deprovisioning should probably be exposed more in the article - but at least the article now include information on the matter.

So if you have a requirement for a more resolute data deletion process, contact Microsoft and ask for expedited deprovisioning. They will delete your data within 3 days this way.

However make sure you have backed up the data you need or migrated it elsewhere as this is a permanent process and you won't be able to get the data back afterwards!

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Monday, 3 April 2017

Utilizing Sway instead of Office for document creation and sharing

I had an interesting conversation with a customer last week. They were interested in making use of the benefits of Sway, but wanted to understand how they can protect content when using this service. Sway doesn't support Rights Management integration, so if you're looking at protecting documents and want to control who has access to them, provide instant revocation or indeed see where you're documents are being opened and by who (including who has tried to access them), then Sway isn't for you.

You can only password protect your content. You can limit the share function to users within your Organisation or for all, see the Share functionality below:

If you don't want to be able to provide external sharing, then as a Global Admin you can disable this function in the Office 365 Admin Center. Including limiting where content is ingested from.

Interestingly, Sway doesn't currently support encryption at rest like the traditional core workloads of Exchange, SharePoint, OneDrive for Business and Skype for Business Online which provide Bitlocker or file level encryption at rest services. It's only available from North American datacenters too - so be aware of where your data is being held.

If you need to utilize Rights Management or Information Protection capabilities, then I would suggest at this time continuing to utilize the Office suite with Azure RMS/AIP - especially if you need to share with external third parties. By all means give your employees access to Sway, but you may want to ensure external sharing is disabled for now.

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Friday, 31 March 2017

Planning and deploying directory synchronisation for Exchange Online

I've been involved in many directory synchronisation engagements over the past two years and I thought I would put a post out to help people plan their identity strategy when you want to synchronise your on-premises identities and Exchange Online. I felt the need to write this due to the lack of any consolidated information on the topic and other less complete on the matter articles from around the web!

First and foremost, you need an on-premises Exchange Management Server, Microsoft even provide a free key to license it. If you're moving away from on-premises Exchange then this isn't such an issue, but if you're moving to Exchange Online and haven't had Exchange on-premises before this means you need to plan for the deployment of an on-premises Exchange Management Server. Why? You simply won't be able to fully manage your objects in the Exchange Administrative Center in Office 365 with directory synchronisation in place. Instead you add email addresses, or enable external access to distribution lists by making that change on-premises. Directory synchronisation via AADConnect then replicates that change. You can get around it - but you won't be supported!

So when I engage a customer what are the high level actions I check for? Here's my definitive list.

Check if directory synchronisation has been enabled in Office 365
The first is rather easy to check for, you simply check in the Office 365 Admin Centre, if it's already in place then we need to understand if it's actually being used - we can check for synchronised user and group objects, or if it's not in use, understand who's turned it on and where they may have got to. Beware that if you disable directory synchronisation it can take up to 72 hours to disable! I have verified this from disabling the feature in tenants, I have seen anything between 12-60 hours.

Gather data on Active Directory Domain Controller OS Version
So why do we need this? If we plan to utilise features like password synchronisation, and we plan to home the AADConnect agent on a Domain Controller then we need to ensure they are Windows Server 2008 OS or above. Further, it needs to be a writeable Domain Controller, and there's also pre-requisites for features like password write-back. You can see the check list here.

Gather data on Active Directory Domain and Forest functional levels
If we are planning on introducing an Exchange 2016 management server - some bearing on Forest and Domain functional levels will need to be understood.

Password write-back to on-premises only requires DFL/FFL of Windows 2003, but Windows 2008 Domain Controllers with SP2, however if you are planning on having an Exchange 2016 management server with CU3 or later, then you must have DFL/FFL of at least Windows 2008.

This means that you may find you need to upgrade your on-premises Active Directory to get the features you need. This could be as easy as upping your DFL/FFL levels, to having to actually introduce new Domain Controllers to be able to achieve this.

Gather data on Active Directory sites
I gather data on Active Directory sites to help understand the network topology. Where's the best place to house AADConnect? Which location? Where are the most users homed? Does the customer require a staging AADConnect server - if so which location would be the best to home it?

Gather data on Active Directory Unique Principal Name (UPN) utilisation
I see a lot of customers still utilising .local domains, or domains that have no bearing on their actual routable domains in Office 365. The best move forward is to have the on-premises users have the same UPN as the desired sign in for Office 365. So if the user on-premises is oliver.moazzezi@company.local and they have a cloud user account of, there's a planning excercise here to understand what domains are in Office 365 and what UPN suffixes need to be added to Active Directory. We then plan the change to update on-premises to

Number of Objects in Active Directory
We gather the number of objects in Active Directory not so much as an excercise for any limits in Azure AD (there's an initial 150k object limit which can be removed for Office 365 subscriptions), but for SQL licensing for AADConnect, if it's over 100,000 objects we need to be looking at using SQL Standard or above - rather than the free version SQL Express version that is auto-installed with AADConnect otherwise.

AD Replication Health
Checking the health of your AD goes without saying - you need a healthy AD without replication issues to ensure all necessary replications occur and are synchronised to Azure AD. Fix and resolve any issues you find! There's no point replicating to Azure AD if your own intersite and/or intrasite replication is broken!

Check for Deployment of Exchange
If the customer is coming from Exchange and migrating to Exchange Online, this isn't so hard to immediately check and ratify. However, what if the customer has come from Notes, Zimbra - or even a hosted exchange platform or resource forest model?

To be in a supported state you need an Exchange Management Server on-premises. Sensibilities dictate this would be an Exchange 2016 or possibly 2013 management server. This will give the customer the best possible experience in a unified UI and Powershell cmdlet experience across both on-premises Exchange and Exchange Online.

One of the things I have encountered countless times is the incorrect removal of Exchange Server from on-premises. One customer had three Exchange 2003 Servers that were simply turned off, removed from the racking and disposed of - and on-premises Exchange was classified as removed. Upon performing discovery, it became clear this needed correct removal - and further investigation showed nearly every long standing employee still logically had a mailbox!

Check Exchange Version
Following on from checking for previous Exchange deployments, it's important to understand the version of Exchange currently on-premises and the steps needed to put an Exchange 2016/2016 Management Server in-place. As well as the previously mentioned similar management experience you also do not have to worry about upgrading the management server anytime soon - where for example if you had an Exchange 2010 management server, this is going to fall out of supportability long before Exchange 2016.

Check for Mailboxes on-premises
Checking for mailboxes on-premises, when all users are known to be in Exchange Online will require clean-up of the on-premises mailboxes prior to implementing directory synchronisation. It can be done afterwards, but it will likely get forgotten about or missed.

Check for Mail Enabled Users
When planning for the Exchange management server, ultimately all your synchronised users will be Mail Enabled users - this is so they show up in the on-premises Exchange Administrative Center and you can easily modify the Exchange attributes - allowing Azure ADConnect to synchronise them to Azure AD and subsequently your EXO tenant.

Check for Mail Enabled Distribution Groups
Are you planning on synchronising your on-premises distribution lists, or will you be utilising Cloud only? Or will you decide to only synchronise certain ones for security management, and implement Office 365 Groups in your Exchange Online deployment?

Most of this comes down to what you understand, or help the customer understand, what they are ultimately trying to achieve. If the customer is already in Exchange Online and you see a completely different set of security and distribution groups on-premises to what's in Office 365 - you may recommend to the client to just synchronise users.

Check Accepted Domains in Office 365
Are all domains verified in Office 365? Is anything unnecessary or incorrect? Ratify the list here as this will have a bearing on what you assign to on-premises.

Check Accepted Domains
When deploying the Exchange management server ensure you understand the Accepted Domains in Office 365 - you'll need to add these in the on-premises deployment so you can easily additional SMTP addresses to objects.

Check if directory synchronisation has been enabled in Office 365
If Directory Synchronisation is already in place, this will allow you to plan clean-up activties or additional actions, or allow you to disable it whilst you made a more solid action plan to perform directory synchronisation for the tenant. Beware it can take up to 72 hours to disable this!

Validate recommended AADConnect server configuration
So what does the customer actually want when synchronising their on-premises identities to Office 365? Does the customer want just object synchronisation? Does the customer want password synchronisation also? You will find most customers will benefit greatly when their on-premises username AND password also accesses their Office 365 resources. A unified password is a must. However understand if your customer has any compliance or regulatory requirements - or just has cold feet about Azure AD holding the password hash for all their user accounts.

If password synchronsation utilising the password hash doesn't work for them - steer them down the route of pass through authentication. This will allow for a unified username and password experience but push the authentication of the user back to their on-premises Domain Controllers. It's a much simpler story to tell and ultimately implement than ADFS.

You can also understand your customers availability requirements, is one AADConnect implementation sufficient or would they also desire a server in 'standby' mode, ready to take over (manually I might add at this stage), if the primary server suffers downtime for an extended period of time or cannot be recovered?

Proxy Server usage
Does the customer force all server traffic through a proxy? If so you need to understand this. Does the proxy for example require authentication? If it does you will have to configure web.config files on the server that will home AADConnect to ensure a succesfull deployment.

IDFix is a Microsoft tool that will parse user and group objects and report if they have issues that would require clean-up prior to being able to succesfully synchronise. It will pick up on the aforementioned UPN issue - but it's also good for trailing spaces, or objects with duplicate attributes - for example a UPN or proxy address.

I hope this goes some way to helping you as a consultant, IT admin or inquisitive Office 365 customer on the steps you should be going through to succesfully deploy directory synchronisation for your on-premises Active Directory and Office 365 tenant.
This should provide you the absolute best and reasoned approach to deploying it, capturing any issues in the planning stages, and providing a nice easy and best practice approach to the deployment.

Have fun!

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Friday, 24 March 2017

I want to backport my Azure AD identities to an on-premises AD!

I had this come up in an Office 365 engagement I was involved with in December. The customer was a development start up; creating apps for Android and iOS devices. They had started out as 3 employees but the success of their apps on the respective market places had seen them grow to over 200 employees!
On-premises management of devices was now becoming a serious issue, as the company now saw themselves as having to control their IT.

Now there's a variety of solutions for this. The customer could have decided to keep their identities as cloud users in Azure AD, and utilised Windows Intune for device and application rollout, and Azure AD join Windows 10 devices. However that still presented them with the problem on current on-premises printers and a Linux environment they wanted to integrate into an on-premises AD. So, this presented the problem; how do we backport all identities from Azure AD to an on-premises AD?

1. First of all confirm All domains in Office 365 are set as UPN Suffixes in the on-premises AD, this isn't a problem if you only have one domain, but if your users login to Office 365 with and - then ensure this is their UPN in your on- premises AD you have created.

2. Make sure you have some test mailbox enabled users in the tenant – we'll use these to test the back port feature without causing issue to real users. This is performed by using OU filtering when configuring directory synchronisation.

3. Ensure you have extended the Schema for Exchange and installed an Exchange Management Server. Recommended Exchange 2013 or above and the Management Server is in place. Get a free key here:
How to obtain an Exchange Hybrid Edition product key for your on-premises Exchange 2007 or Exchange 2003 organization

Now we have the basics in place, an on-premises AD, users with matching UPNs, an Exchange Management Server and Azure ADConnect (albeit not currently installed), we're ready to start prepping the on-premises AD objects to ensure they get all their Azure AD counterpart attributes! Things like email addresses, general information and location etc

4. Connect to the tenants Azure AD session:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri -AllowRedirection:$true -Credential $cred
Import-PSSession $session

5. Once connected export all Users, Groups and Contacts:

Get-User -ResultSize Unlimited | Export-Clixml C:\Users.xml
Get-Mailbox -ResultSize Unlimited | Export-Clixml C:\Mailboxes.xml
Get-Recipient -ResultSize Unlimited | Export-Clixml C:\Recipients.xml
$DGs = Get-DistributionGroup -ResultSize Unlimited
$DGs | Export-Clixml C:\DistributionGroups.xml
$DGMembers = foreach ($DG in $DGs) { Get-DistributionGroupMember -Identity $DG.Identity | Select @{Name="Group";Expression={$DG.Name}},PrimarySMTPAddress }
$DGMembers | Export-Clixml C:\DGMembers.xml

6. Now end the Session to Exchange Online by running: Get-PsSession |Remove-PsSession
7. In your Local Active Directory Ensure you have setup your desired OU structure so it is ready and waiting. Select a single OU to ease the ingestion of objects.

8. Create these variables in a local PS session:

$MigrationDomain="domain.local" (where domain.local is the main domain/primary domain they use in Office 365)
$OU="AD domain/OU" (where AD domain = for example, and OU is the OU to ingest all objects into)
$Password = ConvertTo-SecureString "Pa$$w0rd" -AsPlainText –Force (this will give ALL users the same password – change it here if you so wish)
$Recipients = Import-CliXML C:\Recipients.xml | Where {$_.WindowsLiveID -like "*@$($MigrationDomain)"}
$Users = Import-CliXML C:\Users.xml | Where {$_.UserPrincipalName -like "*@$($MigrationDomain)"}
$Mailboxes = Import-CliXML C:\Mailboxes.xml | Where{$_.UserPrincipalName -like "*@$($MigrationDomain)"}

We then Import them as 'Mail enabled Users' (this cannot be word wrapped – single command):

$Recipients|where{$_.RecipientType -eq "UserMailbox"}|foreach{New-MailUser -Name:$_.Name -Alias:$_.Alias -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -PrimarySMTPAddress:$_.PrimarySMTPAddress -OrganizationalUnit:$OU ExternalEmailAddress:$_.PrimarySMTPAddress -Password:$Password| Set-MailUser -EmailAddresses:$_.EmailAddresses}

This won't have any good information on them like phone or office location etc. So we add this using, the below, (if there are multiple DCs or Sites wait for replication, or bind to a specific DC):

$Users|foreach{Set-User $_.UserPrincipalName -City:$_.City -Company:$_.Company -Department:$_.Department -Fax:$_.Fax -FirstName:$_.FirstName -Initials:$_.Initials -LastName:$_.LastName -MobilePhone:$_.MobilePhone -Notes:$_.Notes -Office:$_.Office -Phone:$_.Phone -PostalCode:$_.PostalCode -StateOrProvince:$_.StateOrProvince -StreetAddress:$_.StreetAddress -Title:$_.Title}

9. It should at this time have created all the users in the local AD with all relevant company information, phone numbers, details etc. With the caveat they all have the same password. You will need to manage that process yourself (users will have to change themselves - although you could configure password write-back in Office 365 and allow users to change their password either on-premises or Office 365).

10.  READ: At this point we can utilise the test users created in Step 2 to test Active Directory synchronisation. I presume the user knows how to install AADConnect and also to perform OU filtering AND ensure it doesn't sync on initial install. So this is what they will need to do.

11. Move the test users to a test OU.

12. Install AADConnect – ensuring it is not for Hybrid and it is not set to run after install.

13. Go into it and perform OU filtering, select the test OU from step 11 only with the test users in.

14. Perform a sync – see if the users tie up to the accounts in Office 365, you should see them change from 'cloud users' to 'synced with onpremises Active Directory.

15. Login to the Management Server either through Powershell or the EAC – ensure the synchronised users show as 'Mail Users', if they don't it means you missed some - convert them and check their email addresses!

16. Once you're happy perform more ingestion of real users, move the accounts to their correct OUs that you have setup in Step 7 or even earlier. Add OUs into OU filtering as you go.

And that's it! You're all done.

If you decide to synchronise your Distribution Groups (you can leave them cloud only, unless you're planning on using them for security purposes on premises, or prefer synchronisation of groups - or are looking to utilise group write-back capabilities):

1. Set some more variables:
$OU="AD domain/OU"
$DistributionGroups = Import-Clixml c:\DistributionGroups.xml
$DGMembers = Import-Clixml c:\DGMembers.xml


foreach($DG in $DistributionGroups){$ThisDGMembers=$DGMembers|Where {$_.Group -eq $DG.Name}|%{$_.PrimarySmtpAddress}| New-DistributionGroup -Name:$DG.Name -Alias:$DG.Alias -DisplayName:$DG.DisplayName -PrimarySmtpAddress:$DG.PrimarySmtpAddress -SamAccountName:$DG.SamAccountName OrganizationalUnit $OU Members $ThisDGMembers}

I hope you found this excercise interesting! I did - i'll be pushing out a new post on the pre-requisites you need to meet for directory synchronisation with Exchange Online soon - stay tuned!

Take care,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi