Archive

Posts Tagged ‘Office 365’

Adding Office365 licenses to new users via PowerShell

December 12, 2017 Leave a comment

One of the tasks any school has to do each year is remove old students and add new ones. Using the built-in CSVDE tool, you can bulk import users into Active Directory very easily. Once there, they’ll get synchronised up to Office 365 (provided they are in an OU that is selected for sync) as new users. Good stuff! The only problem is that all those new users do not have licenses assigned to them in Office 365, which means they can’t use anything. You could manually assign a license to each user individually using the Office 365 website, but that will take hours, if not days if you have a huge number of students to license. Thankfully, there is a better way: PowerShell.

A very small script that is only 11 lines long will load usernames from a seperate CSV file and assign licenses to users based on that CSV file. Here is the script:

Import-Module MSOnline
Connect-MsolService
$users = Import-Csv “C:\Users\Username\Desktop\2018.csv” -delimiter “,”
foreach ($user in $users)
{
$upn=$user.UserPrincipalName
$usagelocation=$user.UsageLocation
$SKU=$user.SKU
Set-MsolUser -UserPrincipalName $upn -UsageLocation $usagelocation
Set-MsolUserLicense -UserPrincipalName $upn -AddLicenses $sku
}

Essentially, the script connects to Office 365 with your credentials (use an admin level account to connect). Change the location of the CSV file to your own location. The contents of the CSV file is simple, just 3 columns in total – column 1 is the User Principal Name of each student, column 2 is the 2 digit country code of your country and column 3 is the product license you want to assign to the student. Name the 1st cell in each column UserPrincipalName, UsageLocation and SKU respectively. You can find out what the exact license names for your Office 365 tenancy are by connecting to it as follows in PowerShell:

Import-Module MSOnline
Connect-MsolService
Get-MsolAccountSku

You will end up with a list of license options for your tenancy, with a name along the lines of tenantname:STANDARDPACK. Copy and paste your desired license name into your CSV file for each user you want that license for.

Run the above script when you are happy with your CSV import file and if all goes well, a few minutes later all the users in Office 365 will have been correctly licensed.

You could get more complicated so that each license if configured with certain options disabled etc, but that involved extra complexity in your script. Keep it simple I reckon.

Advertisements

Lessons learned from migrating to Office 365

May 30, 2017 1 comment

My migration of staff email accounts from our onsite Exchange Server to Office 365 continues as I write this, though now at a somewhat quicker pace. With just under 50 mailboxes left to move, I should be done by the the end of this school term. So far the move has been mostly trouble free, with no email being lost. There have been some small incidents that have helped to shape future mailbox moves and have provided valuable lessons. In no order, here’s some of what I’ve learnt along the way:

  • If you plan to migrate your user’s existing mailboxes up to the cloud, you absolutely need a fast internet connection. 20Mbp/s minimum in both directions, but the faster the better.
  • If possible, get your users to perform mail cleanups before you move their mailbox. The less items in a mailbox, the less time it takes to move said mailbox into the cloud. There’s also less clutter for users after the move, which usually makes people happy, since less clutter is always a good thing.
  • If you are doing a staged migration, try to move as many mailboxes as you can per batch, so that you don’t draw the process out too long. The longer you run two systems, the more risk of something breaking or going wrong along the way.
  • Watch out for user accounts that have been renamed, i.e. people with surname changes. If this isn’t cleaned up properly before being synced to the cloud, it can come back to bite you in the ass. Cue frantic searching and entering arcane commands into Powershell.
  • Users don’t always appreciate or use manuals you may have written. Write a manual anyway, so that you’ve covered your ass.
  • Mailbox moves often don’t happen as fast as you think they should. Budget extra time for a large move.
  • Modern Outlook Web App is a really nice mail client. Light years from Exchange 2007 version obviously.
  • Use Office 2016 for fixed desktop users to connect to Exchange where possible. All previous versions are not going to get the same attention and support from Microsoft in case of trouble.
  • Office 2016 perpetual (i.e. the version you volume license and uses MSI installer) won’t get feature updates over its lifespan. This means no new and cool features like Focussed Inbox.
  • Some programs that interface with Outlook don’t like the 64 bit version of Office.
  • Direct users to the stand alone Outlook apps on Android and iOS. The built in mail client should connect with too much hassles, but Android and Exchange have always had a slightly rocky relationship in my view.

I’m in the process of moving the last giant mailboxes over in the coming week. Once that’s done, the pace of migration should go up as I move other users over with more “normal” size mailboxes. Once everyone has moved, it’s a case of testing to make sure everything is ok, then changing MX records to cut over for direct email delivery to the cloud and to cut out mail coming onsite and then back out again.

The slow migration to Office 365

When it comes to corporate mail servers, many would argue that Microsoft Exchange is the king of the hill. It’s a behemoth of a product that powers so many offices around the world providing vital features. If set up correctly, Exchange has been one of those products that in my experience just hums along quietly, doing its job without demanding a lot of attention.

At the end of 2009 when my first colleague and I migrated my school’s network, Exchange 2007 was our mail server of choice. Not only would it provide everything we needed, it would offer many new features to a school that was used to using a very broken Pegasus Mail/Mercury mail server/Novell Netware combination. It also helped that we got Exchange free of charge under the national SA Government agreement with Microsoft, which ended about 6 months after we installed Exchange.

Since that time, this Exchange server has processed millions of emails and survived moving from a decrepit physical machine to a XenServer implementation to finally ending up in Hyper-V. I’ve probably had 10 incidents or less with this server over the last 7 years. External internet connectivity or issues with upstream mail servers not withstanding, our mail server has done its job perfectly.

Like all things in technology however, there comes a time to move on. The web interface of Exchange 2007 has become really dated and leaves you tied to Internet Explorer for the best results. Those were the days before Microsoft became cross browser friendly, where the “lite” version of webmail was seriously crippled. While I would have upgraded us internally to a later version, we couldn’t afford an upgrade. After the government agreement expired, we were stuck. Quotes I received for updates versions made my eyes water and no one could quite work out how to price software for schools. I think every reseller I contacted only knew how to deal with the corporate world.

In the intervening years, Microsoft essentially resolved my dilemma by introducing and refining Office 365 for Education. Originally billed as Live@Edu, the product provided some nice perks – 50GB mailbox, huge (then called) Skydrive storage etc. The problem was that the product lacked unity and cohesiveness at the time. Live@Edu folded into Office 365 and things have only gone up and up since then. For no cost to us, we get access to the latest version of Exchange, albeit Exchange online, 50GB mailbox, superior spam filtering, access to Microsoft Teams and all the other applications available for education users. As long as their is competition with Google’s G-Suite for Education, we all stand to benefit from that rivalry which forces Microsoft to up their game.

Towards the end of 2015, I decided to migrate all my student mailboxes over to the cloud since students had miniscule amounts of mail compared to staff. It got their mailboxes offsite and gave me some valuable experience on how the migration process would work. It took some reading up on how to do it, but the process is something like this:

  • Sync your on site Active Directory to 365 with the new Sync Tool. The new tool is far better than the old version and what was possible in the earlier days.
  • If you want to be able to simply connect to on premises Exchange and migrate the mailbox like that, you need to have a working Outlook Web Access instance running, secured by a SSL certificate. This lets 365 sync the selected users mailbox to the cloud.
  • The process takes a while, especially over slow connections. The faster internet speeds you have, especially upload speed, the better.
  • You are limited to either a cutover or staged migration for Exchange 2007. Cutover is defined as moving everyone at once then changing DNS MX records so that mail flows directly to 365. Staged is slower, where you move some mailboxes at a time and still use the onsite server as the engine for routing mail. There’s slightly more work with staged, but it lets you be methodical and careful.
  • You can upload Outlook PST files as another method of moving mailboxes, but it’s the same issue as an online migration – you need good uploading speed.

This year I started moving staff mailboxes over for the first time. I had only planned to start once our fibre optic internet connection was in, but the unexpected delays in getting our line in has pushed me to start now already, even over our horrible ADSL connection. I’ve now synced about 10 staff mailboxes over and given staff a manual on how to use the new interface. Some are familiar with it already having had access via their universities or other institutes. The real problem is identifying users who can adapt to the new interface and give feedback on the manual. This is easier said than done when you still have some staff who can barely work with the existing system, 7 years after it went online…

Eventually my goal is to have moved all mailboxes over the cloud, with not one email having been misplaced during the journey. Once that is done, I intend to decommission my on site Exchange server, as well as the actual Windows VM it’s running in. It will be good to not have to support Server 2008 as well, one less old OS to worry about.

In short, there’s precious little reason to have an onsite Exchange server anymore if your internet connection is fast enough. Microsoft does a better job of server uptime than what we can do on our own, they have better spam filtering and they provide a package of products that is not only compelling, but free for education as well. The only real reason to have onsite Exchange anymore is because of privacy or regulatory concerns or if you need some sort of feature that Exchange Online can’t provide.