Adjusting Office 365 licenses in PowerShell

So, we just got hit with Wave 15 finally. This in and of itself was actually something of an accident - Microsoft only allows you to specify one "early adopter" group for testing Office 365 updates, and my boss elected only himself. Further, he realized about three days before our update that Microsoft offers a small notice at the bottom of the upgrade announcement email that you must notify them within 7 days if you wish to postpone your update.

So, we got upgraded in a bit of a hurry.

Now that we're on Wave 15, we have the new Outlook Web Access, which features new topbar buttons for Newsfeed, Sites, and SkyDrive. Well, we're using on-premise SharePoint and have no plans to use SharePoint Online, so those buttons are just going to confuse our user community. It turns out that in order to hide these buttons, you actually have to disable the SharePoint Online (and Office Web Apps) license options for each user that you want to conceal them from.

I was pretty certain I could do this with PowerShell, and it turns out I was right, but not without some gotchas involved. Here's what the final script looks like:

$e1Sku = Get-MsolAccountSku | ? {$_.AccountSkuId -match "STANDARDPACK"}
$e2Sku = Get-MsolAccountSku | ? {$_.AccountSkuId -match "STANDARDWOFFPACK"}
$e3Sku = Get-MsolAccountSku | ? {$_.AccountSkuId -match "ENTERPRISEPACK"}

$e1LicenseOption = New-MsolLicenseOptions -AccountSkuId $e1Sku.AccountSkuId -DisabledPlans SHAREPOINTSTANDARD
$e2LicenseOption = New-MsolLicenseOptions -AccountSkuId $e2Sku.AccountSkuId -DisabledPlans SHAREPOINTSTANDARD, SHAREPOINTWAC

$users = Get-MsolUser | ? {$_.IsLicensed -eq $true}

foreach($user in $users)
{
    foreach($license in $user.Licenses)
    {
        switch($license.AccountSkuId)
        {
            "company:STANDARDPACK"
            {
                Write-Output $user.DisplayName
                $user | Set-MsolUserLicense -RemoveLicenses $e1sku.AccountSkuId -AddLicenses $e2sku.AccountSkuId
                $user | Set-MsolUserLicense -RemoveLicenses $e2sku.AccountSkuId -AddLicenses $e1sku.AccountSkuId -LicenseOptions $e1LicenseOption
                break;
            }
            "company:STANDARDWOFFPACK"
            {
                Write-Output $user.DisplayName
                $user | Set-MsolUserLicense -RemoveLicenses $e2sku.AccountSkuId -AddLicenses $e3sku.AccountSkuId
                $user | Set-MsolUserLicense -RemoveLicenses $e3sku.AccountSkuId -AddLicenses $e2sku.AccountSkuId -LicenseOptions $e2LicenseOption
                break;
            }
        }
    }
}

My boss freaked out seeing this, knowing that removing an Exchange Online license meant the mailbox gets trashed. We spent close to an hour between illustrative tests and dashed alternatives before I finally convinced him that this was safe, and the only option. I'm rather surprised not to see a Set-MsolUserLicenseOptions cmdlet, and simply running Set-MsolUserLicense -LicenseOptions does nothing. It's accepted as valid input, so maybe the cmdlet isn't fully functional. I dunno.

Anyway, you'll notice that I run Set-MsolUserLicense twice. According to MSDN documentation, you can run -RemoveLicenses and -AddLicenses in the same cmdlet and both actions will occur simultaneously, meaning that a user will not be left without a license for any period of time. I tested this on a few accounts and had no issue myself. However, since I want to keep the same license level but merely change the product options, I tried to use the same AccountSkuId in both -AddLicenses and -RemoveLicenses, and it did not work. What I ended up having to do instead was to briefly elevate the user's license level and then re-add the old license with the -LicenseOptions as I had configured them. Without doing this, the cmdlet would always fail insisting that a provided AccountSku was not valid.

Connecting on-premise SharePoint to Exchange Online

My company is in the process of migrating our on-premise email system (Exchange 2003!) to BPOS/O365/Exchange Online/other acronyms here. Since we use a slightly non-standard email routing system with SharePoint, I'd been having some difficulties figuring out how all the pieces would come together to make this happen. O365 Support has been...well...there.

Before I get into the particulars, here's the basics of our configuration:

Web-frontend: PORTAL.company.com
Index/app server: INDEX.company.com

We currently receive mail at @company.com, which has been floated up to Office 365. Our email-enabled lists receive mail at @portal.company.com, and we create Contacts for those addresses in Exchange, but we don't publish them in the Global Address List. Instead, we create a Distribution Group and put the Contact in there, and then provide the Distribution Group to the users, so that if we need to change the address in SharePoint, we can do that somewhat painlessly.

PORTAL doesn't actually process the mail. As a performance measure (probably a very tiny one, but I digress), we actually process inbound mail on INDEX. PORTAL receives the mail, but a scheduled job on PORTAL shuttles the mail into the Drop folder on INDEX every minute, where the Microsoft SharePoint Foundation Incoming E-Mail service runs. Alerts and other notifications are also sent from INDEX.

Now that this is all out of the way, here's the situation. We don't publish an MX record for PORTAL.company.com - instead, our on-premises Exchange server would handle all mail for *.company.com and route PORTAL.company.com messages appropriately. This way, nobody from the outside world can spam our SharePoint farm directly.

In order to set this up, we had to set up a new inbound connector and outbound connector for SharePoint in FOPE (Forefront Online Protection for Exchange). If you're the SharePoint monkey and haven't really gotten into the depths of Office 365, you can access FOPE by logging into your O365 account, then in the top-bar (assuming you're an Office 365 Administrator), click Home, then Admin (Admin is not directly accessible from the mail window).

On the Admin Overview page, in the main content area under the header "Microsoft Office 365", look for the Exchange section, and click Manage. This opens up a new screen which is the Exchange Online administration screen. In the menu on the left, you should be on "Users & Groups". Click "Mail Control". After the page loads, on the far righthand side, you should see, under the header "Additional Security Settings" the link for FOPE. Click this link and you'll be in FOPE.

You may get a notification that your session has expired. This happens a lot. If so, *close Internet Explorer completely*. You'll need to log into Office 365 all over again, even if you just started your Office 365 session from scratch. It appears that FOPE tracks its sessions independently and doesn't clear them on exit, so when you load FOPE and it finds an expired session, it forces you to load all over again.

Anyway. Now you're in FOPE.

In the context of FOPE, "inbound connectors" mean mail inbound TO the server. So, from a SharePoint context, you'll configure an "inbound connector" for your outbound mail, and for your mail incoming to SharePoint, you'll configure an "outbound connector".

Let's do inbound first. A wrinkle, however.

In the past, SMTP on INDEX didn't need to authenticate itself to Exchange by virtue of already being inside the network. This is probably bad practice in a large organization, but since we're a small shop and only have  one Exchange server, it's easily monitored for nefarious activities.

Microsoft will obviously not be so trusting, so we need to configure a secure connection to allow for our server to deliver messages to Office 365. This actually requires us to add an additional user to Office 365 for the purposes of being the delivery proxy for SharePoint's email. So...one E1 license later, and I now have a username and password for use with the connector (I also configured this account to route all of its incoming mail to the SharePoint Administrators distribution group so that if anyone replies to an alert or such, we'll all see it).

On INDEX, IIS 6.0 Management, right-click on your SMTP server, select Properties. Go to the Delivery tab, and we'll be changing settings on all three of the buttons at the bottom.

First, Outbound Security.

If you aren't already using TLS, you will need to be now, so be sure to enable that. You'll also enter the credentials for your new Exchange Online user.

Next, Outbound Connections.

Make sure to change the TCP port since you'll now be using TLS. If you need to punch holes in facesfirewalls, now is the time to do so.

Last, Advanced Delivery.

The Smart Host field will have your client-specific smarthost. You'll probably recognize it with the "pod" prefix, but if that changes in the future, you can locate the smarthost information through the Office 365 page in the POP/IMAP/SMTP settings shown in the connection information.

 

Once you've made the SMTP changes, you'll also need to change SharePoint's mail settings to match.

Now that you've done things on the SharePoint side, time to set up FOPE. Note that FOPE doesn't have to be done last, I just saved it for last.

First, the Inbound Connector (remember - outbound from SharePoint!)

And then the Outbound Connector:

Once these connectors are configured, you will now need to Enforce them in FOPE. Enforcing the connectors means that the changes you've set up will take effect.

After you do this, test your mail setup, because you should be done!