Coming soon - Content Type Hubs and Managed Metadata - a post without problems!

I'm making some significant strides in learning about, setting up, and architecting the Managed Metadata Service and Content Type Hubs for my organization. Nothing especially problematic occurring, but it's just such useful stuff that I have to talk about it after it's done. There's an excellent article by Marcel Medina on the administration side of setting this up to work end-to-end.

I've already been trying to get MMS integrated slowly, and now I'm working on a Content Type Hub, but discovering that I've got collision issues trying to create site columns with different data based on context. I started thinking about maybe using multiple Content Type Hubs with multiple MMS services, but wasn't sure how that would affect my term store. Now, I see that I can do exactly what I need with this arrangement (and not an excess of overhead), so I'll be creating a number of departmental MMS service applications and Content Type Hubs for each one. There's a good example scenario in this TechNet article which shows how this might be used.

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.

At SPTechCon Boston 2013!

So yeah, first off, I'm gonna try to be a little more active here. I know I said in the past that I wanted to keep the content here to be as fluff-free as possible, but I'm going to try to be more diligent about writing here. I've got a couple of interesting topics to talk about that aren't necessarily "problem fixes", and I've got a bunch of interesting infrastructure projects coming up that I'll be working on, as well as code, since that never goes away.

In the mean time, I'm attending SPTechCon 2013 in Boston right now. Specifically right now I'm in the first of Liam Cleary's three security-related presentations. We're going to be doing a claims migration within the next six months or so, and I'm trying to learn as much as I can in the mean time. I'm also planning to go to tomorrow night's Very Special Episode of BASPUG (Boston-Area SharePoint User Group).

Rhode Island is hosting their very first SharePoint Saturday (at New Horizons) on November 9th. I'd love to go to that one but I'll be in Iceland. I am planning to go to next month's SPSNH (http://www.spsnh.com/) in Nashua on September 21st, so I hope to see you there!

A Friendly Reminder (Deleting Items From the End User Recycle Bin)

Don't forget - removing items manually from the end user Recycle Bin will lock your Content Database.

If you're deleting a lot of things, that means it will lock your DB for a *while*.

So, unless you have a dire and immediate need for space (in this case, I kinda did), don't do large-scale pruning until off-hours!

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!

On proper care and feeding of content databases

This one will be quick.

Good SharePoint administrators know not to let their databases autogrow. (Note that this is not the same thing as saying "turn off autogrowth"!)

Good SharePoint administrators also know not to grow their databases during regular hours. (The mysterious "w" at SQLTact does a fabulous job of explaining why.)

Presumably, good SharePoint administrators also know not to do large-scale emptying of the recycle bin during regular hours.

I suppose this means I'm not a good SharePoint administrator...because I didn't know about this until just now!

I moved a project site into its own site collection last week as part of a broader effort to try and partition our monolithic SharePoint environment. That went fairly well, and I deleted the original site, but in looking at my space reporting this morning, I see that egads-We only have 2.5 GB free in the root content database! It's growing even faster than I had planned for. I ask myself..."Did I forget to empty the second-stage recycle bin in order to dispose of the deleted site?"

Apparently I did. So, I proceed to clean out my contributions to the bitbucket. Now I see free space is ticking back up in the database, so that's good to see.

However...the DB appears to be locked during this operation, and so now our main site won't load anymore. Yikes! And I can't exactly stop it, lest I break something in the process of trying to get the site to respond again. Thankfully I know ahead of time that this content is about 10 GB, and I can tell when the deletions will finish based on that figure, so it's almost over.

Content approval for folders

Due to unfortunate necessity, I'm having to take our SP2010 branding apart bit-by-bit, redo the solution, and get dragged screaming and kicking into the 21st century of SP2010 development (IE - VS2010 on a server, no more STSDEV). I've certainly had my share of frustrations learning what everyone already knows here, but I discovered a new item that I'd only seen one other person mention anything about. I'm adding masterpages to the site's Master Page Gallery in the solution. Nothing big there. As someone with branding experience might already know, sometimes the masterpages won't be content-approved when you upload them, meaning that your event handler needs to be able to check them in on-the-fly. Nothing big there.

                using (SPSite site = (SPSite)properties.Feature.Parent)
                {
                    SPList masterPageGallery = site.GetCatalog(SPListTemplateType.MasterPageCatalog);
                    SPFolder masterPageTargetFolder = masterPageGallery.RootFolder.SubFolders[themeName];

                    foreach (SPFile file in masterPageTargetFolder.Files)
                    {
                        SPListItem listItem = file.Item;

                        if (!listItem.HasPublishedVersion)
                        {
                            listItem.File.CheckIn("Automatically added by installation feature.", SPCheckinType.MajorCheckIn);
                            listItem.File.Update();
                            listItem.File.Approve("Automatically added by installation feature.");
                            listItem.File.Update();
                        }
                    }
                }

Now, it turns out that since I'm putting the masterpages for this theme in their own folder, the folder also is subject to content type approval (not that this is relevant to the masterpages being accessible). So, let's say we want to be good citizens and have that folder automatically checked in when the code runs. Well, how do you do that? There's no .CheckIn() method on SPFolder or SPListItem...and if you think you'll be clever and try masterPageTargetFolder.Item.File.CheckIn(), the File member is null, so you'll find yourself quickly dashed. I found this post by Jay Noirfalise that got me part of the way there (using SPModerationInformation), but it didn't quite work.

                    SPList masterPageGallery = site.GetCatalog(SPListTemplateType.MasterPageCatalog);

                    SPFolder masterPageTargetFolder = masterPageGallery.RootFolder.SubFolders[themeName];
                    SPListItem masterPageTargetFolderItem = masterPageTargetFolder.Item;
                    SPModerationInformation moderationInformation = masterPageTargetFolderItem.ModerationInformation;
                    moderationInformation.Comment = "Automatically added by installation feature.";
                    moderationInformation.Status = SPModerationStatusType.Approved;
                    masterPageTargetFolderItem.Update();

For starters, it looked a little off to me. If I'm instantiating a SPModerationInformation object and then setting properties there, don't I need to save that object back to the SPListItem to effect the change? I tried to verify this in PowerShell and my suspicions were confirmed - nothing changed when I did this. Maybe it worked like that in WSS/MOSS? I dunno. Further, the SPListItem.ModerationInformation member is read-only. So, you just need to drill into the properties and set them inside the ModerationInformation member, like so:

                    SPList masterPageGallery = site.GetCatalog(SPListTemplateType.MasterPageCatalog);

                    SPFolder masterPageTargetFolder = masterPageGallery.RootFolder.SubFolders[themeName];
                    SPListItem masterPageTargetFolderItem = masterPageTargetFolder.Item;
                    masterPageTargetFolderItem.ModerationInformation.Comment = "Automatically added by installation feature.";
                    masterPageTargetFolderItem.ModerationInformation.Status = SPModerationStatusType.Approved;
                    masterPageTargetFolderItem.SystemUpdate(false);

But it still doesn't work. After running the matching code in PowerShell, my folder is still "Pending". You might notice one change I made which breaks this whole thing. It makes a little sense if you think about it - the approval's supposed to be done by a human, so we can't use SystemUpdate(false) to effect the change, because then there's no record of who did the change.

                    SPList masterPageGallery = site.GetCatalog(SPListTemplateType.MasterPageCatalog);

                    SPFolder masterPageTargetFolder = masterPageGallery.RootFolder.SubFolders[themeName];
                    SPListItem masterPageTargetFolderItem = masterPageTargetFolder.Item;
                    masterPageTargetFolderItem.ModerationInformation.Comment = "Automatically added by installation feature.";
                    masterPageTargetFolderItem.ModerationInformation.Status = SPModerationStatusType.Approved;
                    masterPageTargetFolderItem.Update(true);

Use Update() or SystemUpdate(true), and you're all set.