Modern Collaboration

Modern collaboration enables users to consume numerous resources to get the most from Office 365. Often, I’m asked where or what resources I should be using for any given collaboration… Not wanting to give The Consultant answer but it really does depend, no longer is it easy to say you do this with Exchange Online, you do this with SharePoint Online and you do this in Yammer. You need to look at the audience or the team you will be working with, and then select the correct tool to undertake the task or project. Remember just because you used one tool for one project, it doesn’t make it the correct tool for the next.

With Office 365 Groups Microsoft makes Modern Collaboration easier, providing the ability to be share the resources and functionality over several applications (Figure 1-1).

Figure 1-1: Modern collaboration

From this point on I will refer to an Office 365 Group simply as a Group. When you create a Group within Office 365 it can be used in all applications except for Yammer (expected to added to Yammer by March 2017). It’s important to note that you don’t need to create the group before creating the resource, so if you’re using Planner, Office 365 Groups (EXO), and or Microsoft Teams, when you require a new group the application will create it for you.

At the start of the blog I said you need to know your audience; for instance, if you need to collaborate with external users you need to use Office 365 Groups or Yammer, as Microsoft Teams currently does not have the ability to be shared with identities outside of your tenant. This then leads to the questions what functionality is available to each resource and identity scenario. For a recent team meeting I created this infographic (Figure 1-2):

Figure 1-2: Office 365 Group functionality matrix

Exceptions:
* Link through to application
** Can’t open via Outlook Calendar section, need to open via Outlook Mailbox section
*** Hybrid conversation in via local inbox, not the Group section as per Office 365 Mailbox
**** No direct access to calendar, but can participate via inbox

Note: On-premises access requires Azure AD Connect Group writeback (Currently in preview) to enable this functionality. https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx

Microsoft Teams

Microsoft have now released Microsoft Teams (Currently in preview), which is a chat-based Workspace, the functionality is close to Office 365 Groups with a couple of changes (Figure 1-3).

Figure 1-3: Microsoft Teams compared to Office 365 Groups

The main area of difference is with Conversations, both Microsoft Teams and Office 365 Groups have this functionality, for example the conversations are not synchronised as Office 365 Groups stores these in EXO and Microsoft Teams stores these in SfB, so a conversation in Microsoft Teams will not appear in Office 365 groups and vice versa.

Planner

When Microsoft Planner was first released I thought this was a great tool to help manage projects and task, but my biggest complaint was when you created a new Plan you couldn’t have isolated plans within the plan for projects. I know you could have different boards to separate the plans, but the overall status of the plan would include all boards… This might just be the way I work. But now with Microsoft Teams you can have a single Team with multiple Plans within single or multiple channels (Figure 1-4). 

Whilst this works for me, this might not work for everyone. One thing I notice about Planner within Microsoft Teams is that it appears not to use the initial or default plan from the Office 365 Group, so whilst you can work with the plan via Microsoft Teams you only see your My Tasks via https://tasks.office.com and not the complete Plan; Also Teams doesn’t show the charts that you get when using Microsoft Planner, this maybe a current limitation of Microsoft Planner and Microsoft Teams.

Figure 1-4: Microsoft Teams with multiple plans

When you browse to https://tasks.office.com or access Planner via the Office 365 waffle, you will not see the individual Plans, but you see your assigned tasks (Figure 1-5):

Figure 1-5: Microsoft Planner and My Tasks

Conclusion

Modern collaboration is dynamic, agile and cross platform, which enables teams to work across multiple teams and multiple platforms, it no longer matters if you’re working in the office or remotely, if you’re using a computer. laptop, tablet or mobile device; Office 365 with Office 365 Groups gives you the ability to work more efficiently. There is no longer a single workload or workspace in which you must collaborate in for any particularly task. Morden Collaboration enables or allows you to work across all platforms whether its Exchange Online, Skype for Business, SharePoint Online, Yammer or Microsoft Teams.

I for one really think the modern collaboration is constantly evolving to give additional functionality and services to the end user. I can’t wait to see what’s added to this space next.

Office 365–Update users UPN

Catching up on the latest updates in the Office 365 for IT Pros, there was an update to the behaviour of licensed synchronised users User Principal Name (UPN). If this book isn’t part of your library I fully recommend adding it. This change means that licensed synchronised users will have their UPN updated upon change.

Note: In a change, Microsoft made to its synchronization service, tenants created after 15th June 2016, automatically update the UPN of a synchronized account in Office 365 through the directory synchronization process –even if it's licensed. Tenants created before that date must enable the feature. This update does not apply to federated identities.

Like any change/feature I test in my test Office 365 Tenant, here are my notes on the change, using Windows Azure Active Directory Module for Windows PowerShell, run the following cmdlet:

[PS] Get-MsolDirSyncFeatures

To update this setting run the following cmdlet:

[PS] Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true

Checking the Metaverse for my test user Lisa Simpson we can see the UPN is currently set to simpsonl@skitttech.co.uk

Looking in Active Directory Users and Computers (ADUC) you can see this is how the account was setup:

Note: When making any changes to Active Directory, ensure you know what you’re changing and the reason for the change. In my lab and with clients I only change the UPN and not the Windows 2000 name, as users tend to login to Domain joined workstations with this identity.

Simply changing the UPN:

Will result in the Metaverse being updating the UPN to lisa.simpson@skitttech.co.uk:

Which in turn after the Azure AD Connect server has synchronised to Azure AD will update the UPN within Office 365:

Summary

After making these changes to the Office 365 Tenant will enable changes to the UPN to be updated; From my tests, I found that any changes that were been made prior to the configuration change the UPN will not be updated. Just update the AD object again will result in the UPN being updated in the Metaverse and synchronised to Azure AD.

This will not result in any changes to the user’s email address as these should be controlled by the Email Address Policy from Exchange, but I did find that this change did result in a change the users SIP address for Skype for Business Online.

Pre-Change:

Post Change:

I’m not a Skype for Business Online expert and will double check this change with one of my colleagues on the impact to the Skype for Business Online services.

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.

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.