365 | Small Business Tech Tips

In this TechTip, I want to address an interesting quirk we discovered in a client’s O365 hybrid implementation back in September. During the process of migrating all of the mailboxes to the cloud, the decision was made to leave the Public Folders on their on-premises Exchange 2010 server. While the migration was going, we discovered that there was a small subset of those migrated mailboxes that couldn’t access or expand the public folder structure. When attempted, they were presented with the following error in Outlook:

Cannot expand the folder. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance.

I was able to recreate this same issue on my computer for an account that works fine, as well as for the non-working user. After an exorbitant amount of netsh tracing, Outlook logging, permission verification on the 365 and on-prem sides of the wire, we discovered that there’s an account attribute that get used in the authentication process back to the on-prem Exchange box. It’s called LinkedMasterAccount.

Evidently in a hybrid environment, if this attribute is populated, authentication against an on-prem Exchange server’s public folders will fail with that vague error message I mentioned above. The solution here is a fairly quick and easy one - clear the attribute from the AD account.

In the on-prem Exchange server, fire up the Exchange Management Shell, and run the following Powershell command: Set-User -Identity [email protected] -LinkedMasterAccount $null Once that’s been run, force a FULL DirSync to run, close Outlook, and try again.

And remember, you can always contact us at [email protected], or reach us at 888-244-1748, for help. We’re available 24/7!

September 24, 2014 Everon TechTips

Tech Tips for Techs: Applying Office 365 licenses in bulk using Powershell

Standard

In this TechTip, I want to cover an issue that’s come up several times in the last few weeks for some of our larger customers. When you’re dealing with a user base in the thousands, user and license management in Office 365 can become quite a tedious task, if you’re using the GUI. Impractical, in fact. So we use Powershell to help us with these requests. Below, I’ll show you a couple of scenarios that I’ve run across and what I’ve done to solve them.

Scenario 1: A company just purchased Office 365 services - 4800 seats of E3. Their IT department has just created all 4800 users in 365, but now needs to assign the purchased licenses to those users.

After you connect to 365 with Powershell, you’ll want to first verify the license types available on your account.

Get-MsolAccountSku

In the context of this scenario, our output should look like this:

ENTERPRISEPACK is 365-lingo for an E3 license. Confirming that this customer has the correct number (and right type) of license they’ve paid for, we can now proceed with assigning them wholesale to the entire organization. Since we’re dealing with such a large number of accounts, we also need to tell Powershell to give us all the results prior to piping them into the subsequent assignment command.

Get-MsolUser -All | Set-MsolUserLicense -AddLicenses "ENTERPRISEPACK" -Verbose

A caveat here… the SKU ID can vary even with the same license type, depending on whether you have 365 direct with Microsoft or if you’ve purchased it from a reseller. You’ll want to change the wording between the quotes to reflect EXACTLY the output you received from the Get-MsolAccountSku cmdlet.

Assigning 4800 licenses took quite awhile, so I left Powershell to do its business while I grabbed a cup of coffee.

Scenario 2: A company has had Office 365 for a few months and has experienced rapid growth in that time. They find themselves needing more licenses and also wanting to add archiving capability to their current infrastructure.

Using a similar process as in the first scenario, we need to confirm the current environment.

Get-MsolAccountSku

STANDARDPACK is 365-lingo for an E1 license. We see that they have 600 of them assigned, but have an additional 168 that they’ve purchased. We can also see that they’ve purchased a matching number of Exchange Online Archiving (addon) licenses that they wish to assign as well. As a matter of due course, we’re going to add a few extra parameters to the cmdlet just to make sure that we only assign the Archiving Addon licenses to those users who only have an E1 license.

Get-MsolUser -All | Where-Object {$_.licenses[0].AccountSku.SkuPartNumber -eq "STANDARDPACK" -and $_.IsLicensed -eq $True} | Set-MsolUserLicense -AddLicenses "EXCHANGEARCHIVE_ADDON" -Verbose

This code will parse the existing user list, grabbing only those who are assigned an E1 license, and then will subsequently assign the Exchange Archiving license to those matching that criteria.

September 16, 2014 Everon TechTips

Tech tips for techs: Potential fix for errors when setting Global Admin rights in O365

Standard

In this TechTip I want to cover an error that we ran across while helping a customer resolve some strange error messages in Office 365.

The situation: Customer has several hundred users DirSync’ed to Office 365 from on-prem AD. Due to the size of their on-prem implementation, they’ve enlisted the help of another third-party vendor to assist with migrating their email over to the 365 platform. After the user accounts have been created, one of the users wants to be set as a Global Admin - but in the process of doing so they encounter an error that will not allow them to set ANY roles from within MOP.

The error: “You can’t edit the user’s role on this page because they have one or more partner-managed roles…”

The solution: “Partner-managed” roles didn’t make a whole lot of sense. This was something we’d never seen before. Scouring through the Active Users list yielded two accounts that were created by the third-party vendor — one of which was a cloud-only user and designated as a Global Admin. Knowing this was the case, we started combing through the available roles in the ECP, but nothing there was yielding a smoking gun.

Now we turn to Powershell…

The cmdlet Get-MsolRole will list the ObjectID, Name, and Description of all the baked-in roles that are available in 365 to be assigned to users. Your mileage may vary, depending on who you have your 365 offering through and how customized things are, but here’s the list I got back when running it against this tenant:

It’s a short list, so it didn’t make sense for me to write a ForEach loop to iterate through it. We manually copy-pasted each ObjectID into the Get-MsolRoleMember cmdlet to see if the user in question was a member of any of them. Lo and behold… we found him in the first one!

As a test, we opted to remove him from the Exchange Service Administrator role. The Remove-MsolRoleMember cmdlet requires you to provide the ObjectID of the user you wish to remove, so make sure that you re-run the Get-MsolRoleMember -RoleObjectID | fl command to grab the ID of the user you’re having a problem with. Once armed with this information, remove the user with the following command:

Remove-MsolRoleMember -RoleObjectID -RoleMemberObjectID

We then confirmed the removal by rerunning the Get-MsolRoleMember cmdlet for that role.

Once done… we retried assigning that user Global Admin perms in MOP… and it worked!

Summary: The user’s membership in the Exchange Service Administrator MSOL role group was preventing us from assigning him Global Administrator permissions in MOP. By removing him from that group, we were then able to unlock that dropdown and add the permissions as expected.

Happy hunting!

September 4, 2014 Everon TechTips

Tech Tips for Techs: Dealing with errors when creating IRM rules in Office 365

Standard

In this TechTip, I want to address a potential fix for an error message we’ve come across when creating a rule in Office 365 that encrypts email messages. Encryption in O365 leverages a Microsoft service called “Information Rights Management,” or IRM. This is supposed to be an enabled/provisioned feature for an Enterprise (read: E3) tenant when it’s created, but as we’re all painfully aware, not all of these automatic provisioning things happen as they’re supposed to. That having been said, if you’re trying to create encryption rules in 365 and run into the following error, chances are that IRM isn’t completely/properly enabled and you’ll have to do it manually through Powershell:

You can't create a rule containing the ApplyOME or RemoveOME action because IRM licensing is disabled.

Should you see this, log into MOP as a global admin, and from Service Settings -> Rights Management -> Manage make sure that Rights Management is active. Once done (and making the assumption that you are in North America), connect to Powershell as a global administrator, and run the following commands:

Set-IRMConfiguration -RMSOnlineKeySharingLocation “https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc”

Import-RMSTrustedPublishingDomain -RMSOnline -name "RMS Online"

Test-IRMConfiguration -RMSOnline

Set-IRMConfiguration -InternalLicensingEnabled $true

The third command (Test-IRMConfiguration) should come back with an overall result of PASS. If it does not, you will not be able to run the fourth. If you hit a FAIL during the test, contact your 365 support folks. We’re advised that this can take up to 24 hours to take effect. I’ve seen it apply as quickly as within a few minutes, but if not, wait the obligatory full day before raising hell.

August 28, 2014 Everon TechTips

Tech Tips for Techs - “Value cannot be null” error when creating rules in Office 365 OWA

Standard

In this TechTip, I want to discuss briefly an error message I’ve been asked about in Office 365 that led one of my peers on a wild goose chase.

The error, verbatim, reads: "Value cannot be null. Parameter name: identity"

This message pops up when trying to create a rule in OWA whereby you are trying to specify a group as either the sender or the recipient. So, while it would make sense to have a message from “[email protected]” go to an internal Distribution Group of “[email protected],” the mechanism within Exchange Online that processes Transport Rules cannot enumerate the members of a DL and, as such, will not allow you to create a rule that forwards to a distro group. Unfortunately for us mere mortals, the message doesn’t make a whole lot of sense and doesn’t give you a whole lot to go on as to where to look next.

The only workaround to this is to abide by the restrictions that Microsoft hath lain before us: list all of the destination emails individually.

For larger groups of people this becomes a huge pain in the posterior. Yes, I’ve complained. No, they won’t do anything about it. Unfortunately, this is all by design, and there are no plans in place (that I’m aware of) to change it anytime soon.