Category Archives: Office 365

Automating the Removal of Old Office Versions to Upgrade to 2016

The end-of-life for the click-to-run version of Office 2013 is quickly approaching (February 28th, 2017). This is a quick reference on how to automate the deployment of Office 2016 to your environment, while also fulfilling the prerequisite of removing any previous versions of Office (including 2013).

Step 1 – Automate the uninstall of previous versions of Office

Installing Office 2016 will not do this on its own, unfortunately. There are several ways to uninstall previous Office versions, but the most reliable I have found in my experience is to use the available OffScrub scripts from Microsoft, which can be extracted from the EasyFix uninstallers for Office 2003, 2007, and 2010. For Office 2013 and 2016, a separate script can be run to automate the uninstall using O15CTRRemove.diagcab. All scripts can be combined and run from a single package/program using SCCM. There is a great guide available from Jay Michaud on how to do all of this: https://www.deploymentmadscientist.com/2016/02/08/deploying-microsoft-office-2016-removing-old-versions/

Step 2 – Automate the installation of Office 2016

There are several guides on how to use the Office 2016 Deployment Tool, which allows you to download the Office 365 client installation files and package them up for deployment. This reference guide contains all available commands to customize the XML file which controls how Office 2016 is downloaded, installed, and configured. The final step is to package it up for deployment in SCCM. All of these steps are outlined here: https://www.systemcenterdudes.com/sccm-2012-office-2016-deployment/.

Step 3 – Deploy both packages simultaneously with Configuration Manager

Of course, you will want to run step 1 and step 2 together to minimize the amount of time that users are without Office on their systems. You can deploy sequential applications in SCCM by using software packages (setting the uninstall program to always run first in the install program properties), by using software applications (setting a software dependency for the uninstall script to run prior to install), or by using a task sequence that contains all of the steps (task sequences can do more than just deploy an OS, after all). As always (and especially with multi-step software deployments), be sure to test deployment with a few pilot systems before running it for all of production.

Microsoft has done a good job of making Office settings/profiles migrate easily to new versions, and the same is true for 2016. Outlook will automatically upgrade any existing mail profiles when run for the first time and should not require any special configuration from the user.

Bulk Assign Licenses in Office 365 Using PowerShell

If you manage an Office 365 tenant, you are probably familiar with assigning licenses to provision services for users. That process is pretty straightforward for a single user.

license1

But how do you do it for a hundred or thousand people in your organization? PowerShell.

First, you will need to connect to Office 365 via PowerShell. If you haven’t done this before, follow these steps to install the prerequisites.

To connect to O365/MSOnline, use the following command:

Import-Module MSOnline
Connect-MsolService

You will be prompted for credentials – this needs to be a user with at least user management role permissions, but most operations in this module will require global admin permissions.

Next, you will need to get a list of licenses available in your tenant. This can be viewed easily in the admin portal under Billing, but is identified by the AccountSkuID in PowerShell. To generate a list of what is available and assigned, run the following command:

Get-MsolAccountSku

The results will contain your tenant name and sku and looks something like this:

license2

If you’re using E1/E3 licenses, they will have a name like “tenantname:ENTERPRISEPACK” or “tenantname:STANDARDPACK”.

Now that you know what you have available to assign, you need to determine which users will be assigned a license. This can be a difficult task, especially in larger organizations.

If you’re lucky enough to just assign all users in your tenant a license, your process will be relatively simple. Prior to assigning licenses, you must assign a location. This is a required field and is done by country. This will essentially provision the Exchange Online mailbox in the proper region and ensure that it follows all local laws, etc.

To assign the US location to a single user, you would use the following command:

Set-MsolUser user@domain.com $upn -UsageLocation US

All countries follow the 2-letter ISO code standard – a list of those can be found here.

Now, we’re using PowerShell – we want to actually bulk assign licenses and locations, not just do single users. To assign the US location to all of your tenant users, use the following command:

Get-MsolUser -All | Set-MsolUser -UsageLocation US

To verify the results, use the following command:

Get-MsolUser -All | Select DisplayName,UsageLocation

Once the location is assigned either through the admin portal or PowerShell, you can assign licenses. The following command would assign an E3 license to all users in the US only:

Get-MsolUser -All -UsageLocation ‘US’ | Set-MsolUserLicense -AddLicenses “tenantname:ENTERPRISEPACK”

There are several other properties that may be useful in narrowing down the scope of users to bulk assign licenses to. Use the following command to view only users that do not have a license assigned:

Get-MsolUser -UnlicensedUsersOnly

This command will assign licenses only to users with a specific domain name:

Get-MsolUser -All -DomainName ‘joshheffner.com’ | Set-MsolUserLicense -AddLicenses “tenantname:ENTERPRISEPACK”

A full list of properties to use with Get-MsolUser can be found here.

What if it isn’t this straightforward in your organization? You may have several countries, types of licenses, or maybe you want to assign licenses in batches. Sometimes it’s just easiest to assign both the location and license at the same time from a CSV file – this is usually the preferred method in larger organizations. This operation can be done with a simple PowerShell script (download it here):

license4

The above script references users in a CSV file containing users’ UPN, location, and license to assign. It looks like this (download it here):

license3

You will need to modify the script to use the correct path to the CSV file.

If you need to generate a list of users in your O365 tenant, including their UPN, location, and whether or not a license is currently assigned, you can use the following command:

Get-MsolUser | select-object DisplayName,UserPrincipalName,UsageLocation,IsLicensed

Your results will look similar to this:

license5

To export the same data to a CSV file, add a bit more to the end:

Get-MsolUser | select-object DisplayName,UserPrincipalName,UsageLocation,IsLicensed | export-csv C:\pathtofile\o365export.csv -notype

Azure AD Connect 1.1 Released with Several New Features

azure-active-directoryAzure AD Connect 1.1 (formerly DirSync) is now generally available for download. If you’ve been using Azure AD Connect, you’ll want to pay attention to the new features that come in 1.1.

Automatic Upgrade

This is the last time you need to manually upgrade Azure AD Connect. There is a new auto-update feature that will periodically perform upgrades.

More Frequent Synchronizations

In the past, the default sync interval was 3 hours. Now, you can schedule a sync to run as often as every 30 minutes, if desired.

Support for MFA

This is a big one. Previously, accounts that used multi-factor authentication could not be used with Azure AD Connect. This was a huge security risk because the account used by Azure AD Connect had to be a global administrator on your tenant. In the new release, MFA is now supported to better secure your service accounts.

More Flexibility

You can now configure with OUs to synchronize with your tenant during the installation process. Previously, you had to install Azure AD Connect and then later filter the OUs in the Synchronization Service Manager.

You can also modify the user sign-in method after installation now. Previously, you had to choose this during the install of Azure AD Connect and didn’t have the option to modify it later without reinstalling.

Azure AD Account Support Coming to Windows 10

One of several big Windows 10 announcements from Ignite last week was the integration of Azure AD and Windows 10. If you’re not familiar with Azure AD Sync Services (formerly DirSync), it allows the synchronization of user accounts (and passwords) between your local Active Directory environment and Azure where those credentials can be automatically be used to provision Office 365 email accounts, for instance. This type of federation allows Office 365 users to sign in directly to their organizational email accounts directly from outlook.office365.com.

Starting with Windows 10, users will be able to log into Windows using the same organizational account. This is similar to how you can use a Microsoft account (formerly Windows Live ID) right now, but it also brings additional management capabilities along with it. The initial sign-in process can be done right out of the box on new devices without any prior device deployment/management or being part of a domain. Essentially, this will allow users to provision their own devices. MDM policies can be applied to systems, SSO is be enabled for cloud applications (Lync/Skype for Business, Outlook, etc), and OS state roaming is available to synchronize settings (WiFi, wallpaper, OS settings) automatically between devices. Basically, this is the ultimate BYOD scenario.

During the Window setup experience, users will be able to choose “This device belongs to my organization” to sign into Azure AD.

051315_1842_AzureActive3

Next, they can use their Azure AD credentials to sign in, just like Office 365.

051315_1842_AzureActive4

If a matching tenant is found for the domain, users can proceed to sign in through ADFS or Azure AD.

051315_1842_AzureActive5

MDM enrollment happens next.

051315_1842_AzureActive7

Now the user would be signed into their organizational account on their Window 10 system. Pretty impressive considering that they provisioned it all by themselves, right? Having a single, federated account for all services and devices has some pretty big potential down the road.

For more information on this new feature in Windows 10, see this blog post on TechNet.