Adding All Services to an Existing Office 365 User License

When working with our clients, we often find that they have enabled only some of the services within an Office 365 license.  Some companies, for example, may enable E3 licenses for a subset of users, but they don’t enable Lync Online.  While it’s very easy to add a service from within the Office 365 Admin Center, this method is not very efficient when a company has to modify several hundred or thousands of accounts and instead want to leverage Windows PowerShell.

By combining the use of the New-MsolLicenseOptions and Set-MsolUserLicense cmdlets, it’s possible to remove and add services.  In the following example, the account has been assigned all E3 services except for Office 365 ProPlus (OFFICESUBSCRIPTION) and Lync Online ‎(Plan 2) (MCOSTANDARD):

The company wants to add the Office 365 ProPlus service, but keep the Lync Online service disabled.  Running the following cmdlet will set the disabled service to only “MCOSTANDARD”:

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId "company:ENTERPRISEPACK" -DisabledPlans MCOSTANDARD

Running this next cmdlet will change the license settings:

Get-MsolUser -UserPrincipalName john.doe@company.com | Set-MsolUserLicense -LicenseOptions $LicenseOptions

Since the “OFFICESUBSCRIPTION” service was not explicitly excluded in the “DisabledPlans” parameter, by default, it will now be enabled:

Note that the “ProvisioningStatus” for OFFICESUBSCRIPTION changed from “Disabled” to “PendingInput”.  When viewing the license settings in the Admin Center, the service will now be enabled under the E3 license details:

Now, again consider the scenario where a company has assigned E3 licenses, but left the Office 365 ProPlus and Lync Online (Plan 2) services disabled for all E3 licensed users.  The company now wants to enable all services, and not exclude any services.  In the past, Microsoft support has always provided that the only way to accomplish this is to remove the license, then reassign it without any “LicenseOptions”, effectively enabling all services.  While this method is perfectly safe, some companies are a bit apprehensive to make this change to a large number of accounts at once, for fear of disconnecting the users’ mailboxes and causing a service outage.

Instead of removing and re-adding the license, it’s possible to accomplish the same task by setting the “DisabledPlans” parameter to “$Null” within the “New-MsolLicenseOptions” cmdlet.  Example:

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId "company:ENTERPRISEPACK" -DisabledPlans $Null
Get-MsolUser -UserPrincipalName john.doe@company.com | Set-MsolUserLicense -LicenseOptions $LicenseOptions

Note that both the OFFICESUBSCRIPTION and the MCOSTANDARD “ProvisioningStatus” have changed to “PendingInput”, and the services will show as enabled under the E3 license details in the Admin Center:

I hope you find this tip useful when managing your Office 365 licenses with Windows PowerShell.

Barry Thompson
Principal Consultant

Why did my email messages disappear from my inbox?

While the Personal Archive mailbox in Exchange Online is a great feature for most end users, some folks become distressed when all of their old mail “disappears” from their inbox and mailbox folders.

By default, when you enable a Personal Archive mailbox, all mail older than two years in all primary mailbox folders will be moved to the Personal Archive mailbox. This is a result of a Retention Policy being applied daily to the mailbox.

You may find that two years isn’t long enough for a majority of your end users, so you want to extend the age of the items archived, or simply disable the automatic archiving. To do so, you’ll need to modify the default retention policy.

Out of the box, every Exchange Online mailbox has the “Default MRM Policy” retention policy assigned to it.

We need to find it the bit in the retention policy that moves mail to the Personal Archive (When the PA is enabled) from the primary mailbox after 2 years.

Go to compliance management >> retention policies.  Double click the “Default MRM Policy” to open the properties:

The retention policy properties window shows a list of retention policy tags and their actions.  We’re trying to identify the tag which archives the email after two years, so we want the one which has the retention action of “Archive”:

Now that we’ve identified the name of the retention tag being used to send items to the archive, click cancel to close the properties window, and then click retention tags in the top menu.  Double click the “Default 2 year…” retention tag to view the properties:

Alter the “Retention period” settings to increase or decrease the item age. You can also select “Never” to never allow the retention tag to move anything to the personal archive.  Just to be tidy, if you change the item age, modify the retention tag name to reflect the new item age. Click save to save these changes:

 

Why don’t we simply delete the retention tag instead of setting the retention period to “Never”? It’s a personal preference. I don’t like to delete default settings. Deleting the tag would have the same effect.

Note: Altering the archive retention tag won’t restore archived mail to the primary mailbox if the retention policy previously ran against a mailbox. Mailbox users will have to manually move the archived items back into their primary mailbox if that’s what they want to do.

See Retention Tags and Retention Policies at Microsoft TechNet for more detailed information.

Barry Thompson
Principal Consultant – Cloud Solutions

Microsoft Online Services Performance Test Tool is Back

The Microsoft Online Services “Performance Test for Internet Connection to Microsoft Online Services” (formerly found at speedtest.microsoftonline.com) is back, after several months of absence.

As a Microsoft Cloud Partner, we’ve found the tool to be extremely useful when performing initial client environment discovery and general Office 365 readiness by measuring response times, bandwidth and connection quality with Microsoft Online Services.  The one notable difference with this tool is the requirement to enter an Office 365 tenant domain before beginning.  Interestingly enough, entering “company.onmicrosoft.com”, as listed in the example, does allow the test to begin.

We typically use the tool during the pre-sales phase with clients.  During instances when we can’t be on site to run the tool ourselves, It’s very easy to direct clients to the tool so they can run it from a computer within their company network, and then return the results to us.

Once the tool has completed it’s run, click on the down arrow in the bottom-left (highlighted in the image below) to reveal more tabs:

Clicking on the Advanced tab reveals summary statistics from the test, including download and upload capacity:

The tool is hosted on two different sets of domains/URLs, each with a version available for three different regions.  Currently, the cloudapp.net locations appear to be the most reliable and available.

Fast Track Network Analysis (North America)
http://na1-fasttrack.cloudapp.net/

Fast Track Network Analysis (Asia Pacific)
http://ap1-fasttrack.cloudapp.net/

Fast Track Network Analysis (EMEA)
http://em1-fasttrack.cloudapp.net/

At the time of this writing, the APAC and EMEA sites at deployoffice365.com are not yet available:

Office 365 Network Analysis Test (North America)
http://na.deployoffice365.com

Office 365 Network Analysis Test (Asia Pacific)
http://apac.deployoffice365.com

Office 365 Network Analysis Test (EMEA)
http://emea.deployoffice365.com

Barry Thompson
Principal Consultant – Cloud Solutions

Lync-to-Phone for Office 365, First Look

We were recently asked to pilot Lync-to-Phone in Office 365, which is going through a soft launch in the US. It’s not a secret or anything – you can find it at http://pinpoint.microsoft.com/en-us/applications/jajah-voice-for-office-365-12884930736 as a public offering. But, it’s being kept off the radar somewhat as the service ramps up. Because we are a major Office 365 partner, we were asked by Microsoft to go ahead and try it, so we are. This blog post is about our ramp-up experience.

I started with the single provider available, JAJAH, which is from a Spanish telephone company. That got me to here:

I accidentally picked the wrong plan, but I was able to close, sign in, and was prompted to reselect my plan and move forward.

Or at least I tried to move forward:

Did a customer support call – took six tries (I am not exaggerating) for them to get my e-mail address right, even with phonetic spelling, which was a rough start, but after about three minutes they had it. Their answer? “Try a different browser with cleared cookies and browser history and try again.” Well, I had been using Firefox because IE 10 RP wasn’t making it past the first screen, but I went over to an IE10 Porn Mode In Private session and tried again. Yet again, I could not take any button presses to register, and they had set their site to not allow compatibility mode. So, I used F12 to force the browser to IE10 Compatibility Mode:

And then tried again to log in. This time, the sign-in button worked, but the login failed. Great. So I tried to register again from the beginning. That time it said I was already registered. More great… So I did a “forgot password” on the sign-in page (even though I know I had it right because I had signed in with Firefox using the same password pasted from the same entry in my password management application). This caused a generated password to be sent by e-mail, in theory at least.

I never got the e-mail, and the original login still worked in Firefox. So then it’s a question of what browser I’m supposed to use. Firefox doesn’t work, IE 10 doesn’t work… so now I needed to install another browser. I guess it’s time to install Chrome… so 20 minutes lost…

Nope… no luck there either. Of course doing anything in Chrome that’s not on a Google site or using WebKit custom proprietary stuff is a coin toss but still, WTF? Then I remembered that I could look up the password that continued to work in Firefox by looking at its stored password list… and it wasn’t the password I set; it was truncated. No idea what was up there – a bug in the registration process I guess… only the first ten characters were taken. Now that I knew that, I could try to sign in using IE again (again using F12 to set compatibility mode)… and that failed again.

So I went back to Chrome again… logged in successfully. And that failed to add the location again. So now I’m back to calling customer service again.

This time, they got my e-mail on only the second try, without use of a phonetic alphabet.. Oops, no, third try… that failed again, so we went to phone number. That seemed to work – I was put on hold again while they looked at the account. It might be part of this goes back to bailing out partway through as described above, but decent QA should have caught this. This offering has been in development for months – some basic testing would have been useful I think… anyway, that led to a 24-48 hour delay while the case was escalated to an engineer… so now we’re in a holding pattern…

… insert multiple days of hold music …

OK, so it was some kind of error on the JAJAH side, but it’s been resolved. How do I know? Because “Yahoo! Voice by JAJAH Customer Service” wrote me and told me it was.  (Aside: I am forced to assume that this is key insider trading information about Microsoft buying Yahoo! now that Jerry Yang turned down a jillion dollars to get the company worth the $3.12 it’s worth today [a steal at half the price!].) So let’s go back in, remembering that Internet Explorer 10 doesn’t work. I went to the site again, sign in again, and again re-select my calling plan and initial account information. This time, adding a location works:

I just did one location for now – it will make sense to add others later but this is good enough to get started. Clicking Continuegets me to phone line selection:

So more “good” news here – there’s only two area codes available for all of Ohio (luckily the one we probably want – 216 – is here), and there’s at least one grammar error (“request addition phone numbers“) on the page. Okay, so let’s take 216 and see what we get:

We get forty-nine lines available. I don’t know if that’s meant to be for 216 or for our account alone. For testing I’m going to take two but I definitely don’t like such a small number showing. You can actually add numbers to multiple locations as part of the order all at once, which is nice – each time you “ADD TO ORDER” it shows up on the right-hand order summary:

Moving on, it’s payment time!

The complaints about blank fields weren’t there when I started, it’s an artifact of my forgetting to screenshot before entering something. So no bug there. I put in my work-issued credit card that I’ve already had cleared to use for this, and get a confirmation:

Still not sure about the $13.99 to $18.99 range here, but after all this, if I didn’t Submit then that would be silly, right? So time to click. And …. It failed again:

Great, another call to customer service so I can spend twenty minutes spelling out my e-mail address… this time I told them to use cell number to look it up, and they fail, so we spend more time with going through my e-mail address, reading it multiple times, and convincing them it’s not a browser issue (everything with them seems to start with assuming you don’t know how to use a web browser), and then finally opening another escalation, which means another 24-48 hours. I wish I was kidding.

Okay, so about 36 hours later, it was “fixed,” so time to try again. I again had to walk through the whole process. This time the final screen showed different results, which suggested it was going to work:

And yay, it did:

I also received a line confirmation e-mail:

So time to activate! This one at least didn’t reference Yahoo! in the Fromaddress, so there’s that. Moving on, it’s activation time:

So time to activate my line and assign it to me, starting with the first of the two Activate links (nice use of a little DHTML here):

I put in my e-mail address, left the location alone for now, and entered my name, then hit Save. This changed the icon in the front to indicate the line was active:

I also received a confirmation e-mail on my location change with some slightly off sentence structure:

Now I had to assign it to myself. There are instructions on the JAJAH site so they must work, right? I started signing in to the Office 365 Portal (I have administrative access). I located my User information, went to Details, and uh oh, we’re syncing our user information, so my office number wasn’t able to be changed. So the instructions are wrong in our case and lots of other cases. That’s fine, I can go to our on-premises Active Directory and set the number, then wait, which is what I did.

The office phone number replicated, so now it was time to set the provider in Lync Online. I went to the Admin Portal and selected Lync, Manageto get to the Lync Online Control Panel. I located my user account on the Users tab, and clicked my name. And then I… did nothing, because our Office 365 plan is E1 and you must have Lync Plan 3 to do Lync to Phone. So I enabled the 30-day trial of Lync Online (Plan 3) and tried again. Provisioning the plan required a very short wait (under one minute), then I was able to go into Licenses and assign myself one of the trial licenses. Then, I went back into the Lync Online Control Panel, and went into my user properties. This happened:

Yay! Yet again a step breaking. This is getting fun.

So I waited about 21 hours and tried again, and this looks better:

OK, so what difference did this make? Well, the Lync 2013 Preview Release client has all kinds of weird bugs, some of which I think impact this work, so I’m going to do it in Lync 2010. First noticeable change is that I have PBX functions showing in the client now:

The location I was forced to add and had so much trouble with before didn’t show up anywhere, but whatever. It would be wrong as I’m typing this anyway as I’m in the United Club in Seattle, which is very far away from the location they have on file.

So I attempted to place a call, and it was successful! But could I receive a call?

Yes, yes I could. This is exciting, we have phone calls! So of course I could leave an Exchange voice mail, right? Well, no, actually, I just get a busy signal when I decline. So that is awful. Time for more delay as I wait on an SR with Microsoft. But that’s going to take some time, and I think it’s too much time at this point, so I’m posting, and I’ll do another post when it’s resolved.

Michael C. Bazarewsky
Principal Consultant, Server and Security

Office 365 E-Mail Migration Performance

Last month Microsoft released a document outlining Exchange Online Migration Performance.  You can find the article here. While it’s not a bad read at 26 pages, I will highlight some of the important pieces.

It’s always important to keep in mind the data and how it will get to Office 365 when considering moving to Exchange Online.  Depending on the size of your total email data, the source mail platform, and the tool you will be using to migrate the data the time per user can vary drastically.

Let’s take a look at the following chart provided by Microsoft that highlights some of the throttling.

Migration tool	Migration   method	User   throttling	Migration-service   throttling	Office 365   resource health-based throttling	Observed   average throughput per hour and per client (if applicable)
Native   O365/Simple Migration	IMAP4   migration	No	Yes	Yes	5-10 gigabyte (GB) (50 concurrency)
Native   O365/Simple Migration	Cutover   Exchange migration	No	Yes	Yes	5-10 GB (50 concurrency)
Native   O365/Simple Migration	Staged   Exchange migration	No	Yes	Yes	5-10 GB (50 concurrency)
Native O365	Hybrid   migration	No	Yes	Yes	10-15 GB (per On-premise Exchange 2010   CAS)
Third Party	MAPI	Yes	No	Yes	0.5-1 GB
Third Party	EWS	No	Yes	Yes	5-10 GB
Client   Uploading	Outlook	Yes	No	Yes	0.5 GB

As you can see there are a few different caps depending on what type of migration you are performing and what type of tool you are using.  For example, the native Office 365 tools in the Exchange Control Panel can perform either a Simple(think IMAP), Cutover(from Exchange on Prem) and Staged(Also from On prem).  Hybrid migration, in which a 2010 Client Access Server where Hybrid mode has been configured, is the fastest means to migrate which makes sense given Microsofts subtle push to have people with Exchange on prem migrate in this fashion.  If you’re using a 3^rd party tool be sure it can use Exchange web services to connect to Office 365.

By far the slowest method of migration is 3^rd party MAPI and Client uploading.  Keep these in mind because if your migration plan was export/import .PST files using either in house methods or some of the *free* migration tools out there you need to understand just how slow they will be.  Typically this type of method should only really be used in which the number of users is very small.

Looking over these #s that they’ve listed and I would say this is somewhat what I’ve observed performing migrations in the field.  For me though, the biggest factor is what platform you are migrating off of and the performance of that server and your network.  Some IMAP migrations from older systems or on servers that have been around for years can take much longer than you would see from other IMAP migrations such as Gmail.  I’ve seen 10 user mailboxes averaging 3gb each take 12 hours to complete in total with max concurrency set to 5(which according to the chart should take 3-4 hours).  It’s always important to pilot and test your migration to get expectations before planning production schedules and dates.

As I mentioned earlier Hybrid Migrations do seem to be the direction Microsoft is pushing companies to if they have Exchange on-premise.  My only concern with this is that it can be extremely complicated for Administrators who do not have a lot of experience with Exchange 2007+ and how web services and autodiscover work.  Putting in Exchange 2010 CAS with hybrid in an Exchange 2003 environment can be complex for a seasoned Exchange administrator, much less one that’s only experience is in Exchange 2003.  With Exchange 2010 SP2 it has made that process somewhat easier(wizard), but it still requires knowing how all the services work to get it right.  My advice is carefully determine what Hybrid mode offers your company and if those additional benefits are worth the extra efforts involved in implementing it.

Peter Gleek

Enabling Users for Office 365 Licensing Made Easy

When transitioning to the cloud, some of Microsoft’s new PowerShell commands can be hard to find solid answers on and are completely different in some cases from what most Exchange administrators are used to using.  The Set-Msoluser cmdlet for instance is not something that you had ever seen in Exchange 2007 or 2010.  I’m often asked the easiest method for giving a user a license without manually clicking through the Portal for 1000+ users.  Today I’ll share a simple way to get this done and save time during a migration.

These new PowerShell cmdlets make assigning licenses to users very simple and much faster than using the Online Services portal to manually assign licenses. This post will walk you through how to make a basic PowerShell script that reads a CSV file to activate and assign licenses to users in your target Office 365 environment.

Step 1 – Determine the license types you have.

Before we configure the script we’ll need to know what the license types are in order to include them in our script. 

Connect to the Msol service using Connect-MsolService and enter in valid administrator credentials.

Run the following PowerShell command to determine the license types:

Get-MsolAccountSku | Format-Table AccountSkuId, SkuPartNumber

The output should look something like this:


AccountSkuId SkuPartNumber
------------ -------------
COMPANY:STANDARDPACK STANDARDPACK
COMPANY:ENTERPRISEPACK ENTERPRISEPACK


I’ve removed the company name before the : but it should be similar. For this example’s purposes let’s call the licenses TEST:STANDARDPACK and TEST:ENTERPRISEPACK.

Step 2 – Configure your CSV input file

Now we can start to create the input file.  We’ll need a bit more information about your users but generally we’ll set the CSV up with 3 columns:  Username, LicenseType, Location.  The Username column will be the UPN or online login name of the user (these should match).  The LicenseType will be based upon the outputs we received from step 1.  The Location is where the location needs to be set for each user, such as >US for United States, IN for India, MX for Mexico, and so on.  It should look something like the following.

username	licensetype	location
user01@test.onmicrosoft.com	TEST:STANDARD	us
user02@test.onmicrosoft.com	TEST:ENTERPRISE	in
user03@test.onmicrosoft.com	TEST:ENTERPRISE	mx
user04@test.onmicrosoft.com	TEST:STANDARD	us

Save the inputfile in ‘msol_activate.csv’. Now we can go on the script.

Step 3 – Configure the Script

Now that our input file has been setup we can write the script accordingly.  Let’s open a notepad file.

We’ll need to define our list and just refer to it as $List and use Import-CSV to read the CSV file:

$List = Import-CSV “msol_activate.csv"

No we’ll start the loop using foreach and call out $User as each line of the $List

foreach ($User in $List)
{


In the first line we’ll set the UsageLocation since it is required before setting the license.  The name of the columns from our CSV file will be added to $User so the script can grab them specifically.

Set-MsolUser -UserPrincipalName $User.Username -UsageLocation $User.Location

Now we’ll add the license type:

Set-MsolUserLicense –userprincipalname $User.Username –addlicenses $User.LicenseType

And lastly we’ll set a default password and force the user to change that password the first time they log in, then close the loop:

Set-MsolUserPassword -UserPrincipalName $User.Username -ForceChangePassword $true -NewPassword "Office365Rules"
}

You could also add a column to your CSV file named Password and have the –NewPassword be $User.Password.

Put it all together and the script looks like this:


$List = import-csv  “msol_activate.csv"
foreach ($User in $List)
{
    Set-MsolUser -UserPrincipalName $User.Username -UsageLocation $User.Location
    Set-MsolUserLicense –UserPrincipalName $User.Username –addlicenses $User.LicenseType
    Set-MsolUserPassword -UserPrincipalName $User.Username -ForceChangePassword $true -NewPassword "Office365Rules"
}


Summary

So now we have successfully determined our license types, take our user data and put it into an input file and created a script that easily gives our users a license and a temporary password.  This script will help get your users to the cloud faster and assigned licenses much faster than manually using the portal.

 

Peter Gleek
BA Advanced Infrastructure Principal Consultant