Color Codes in SharePoint SPColor Files MUST Be All Caps

With the new world of branding a tenant on Office 365, styling the suite bar and using a theme (aka Composed Look) can take you pretty far toward improving the user experience.

A Composed Look is made up of (potentially):

  • A master page – generally either Seattle or Oslo
  • Theme URL – the spcolor file to use for common classes in a SharePoint page
  • Image URL – an image to use as the background for pages
  • Font Scheme URL – spfont file to use for common classes in a SharePoint page
  • Display order – simply where in the list of Composed Looks yours is displayed

Composed Look Settings

I won’t go into all the details about how this works, but each setting above is somewhat optional: you can use an existing spcolor file, for example, but create your own spfont file. If you want to understand all the mechanics, check out Benjamin Niaulin’s article Step by Step: Create a SharePoint 2013 Composed Look

 

Change the look

Here’s a quick tip about spcolor files. I was tearing my hair out over the last few weeks trying to figure out why sometimes my iterations of an spcolor file were working and other times they weren’t. By not working, I mean that the Composed Look would simply disappear from the Change the look page. I’d revert to my last working version and slowly inch forward again.

It turned out to be something silly and obvious – once you know it!

All of the color codes in the spcolor file MUST be all capitals. So, for instance, this:

<s:color name="ContentAccent1" value="0057b8" />

would not work, but this:

<s:color name="ContentAccent1" value="0057B8" />

would. That was *not* easy to spot, but spot it I did.

Don’t let this one bite you; I hope that your Binglage has led you here for a solution and this helps…

SharePoint Saturday Boston 2016 Follow Up

Thanks to everyone who attended my session at SharePoint Saturday Boston on ‘Best Practices for Small-Scale Client-Side Development in SharePoint’. I’ve posted my slides on SlideShare for everyone’s enjoyment.

Be sure to follow my series on Sympraxis Client Side Development Pipeline for more details on some of the approaches and methods I demonstrated in the session.

Thanks to Heather Newman for the photo!

Thanks to Heather Newman for the photo!

Save Your SharePoint Online Tenant: The SharePoint Sandboxed Solutions Inspector

If you’ve been following the “code-based sandbox solutions on Office 365” saga, you know that there is little time left to fix your existing sandbox solutions in Office 365. See: Microsoft Is Removing Code-Based Sandbox Solutions in SharePoint Online – Be Prepared!

Last week, Vesa Juvonen (@vesajuvonen) released a script (New Script Available from Microsoft PnP: Generate list of sandbox solutions from SharePoint Online tenant) that can help you find your sandbox solutions. Surprisingly, what was missing from Vesa’s script was identification of the solutions that contain code. You’d get a list of all your sandbox solutions, but not specifically the ones that were going to cause you problems.

The Rencore Team

Some of the great looking folks at Rencore. Where’s Waldek?

My awesome friends at Rencore – the SFCAF folks – were kind enough to make a free tool available this week to help with even more with your diagnosis and even some of the cures. In Erwin van Hunen’s (@erwinvanhunenpost Introducing the Rencore SharePoint Sandboxed Solutions Inspector, you can learn more about the free tool and how it can help.

On August 31st, 2016 Microsoft is going to shut down support for Sandboxed Solutions with code.

Sandboxed Solutions containing code will be deactivated and this might impact your Office 365 tenant big time!

If you know you need it, just head right on over to the download page.

The SharePoint Sandboxed Solutions Inspector

They have already released several updates to the tool, and are keeping it current based on feedback from the folks using it. Now that’s service – and for a free tool!

But I think the best thing is that the Rencore tool can fix some of the most common issues – most notably the “empty DLL” issue that makes Office 365 think you have code in your sandbox solution when you don’t.

We heard “30 days” when all this started, and now people seem to be taking that as August 31. Don’t leave your users in the lurch – get going on handling this situation.

Oh, and if you’re a vendor or consultant who has written a sandbox solution with code over the last few years: reach out to your client and own it. Get them back on the right road and you’ll be the better for it.

Clean report!

Clean report!

Microsoft Is Removing Code-Based Sandbox Solutions in SharePoint Online – Be Prepared!

Though Microsoft announced that sandbox solutions with “code” (this is becoming a more confusing distinction than ever with JavaScript becoming a first class coding citizen!) were deprecated back in 2014, last week’s announcement that sandbox code was being shut off caught many people by surprise.

There was a post that went up last Friday, July 29th, 2016, on the Office Dev Center blog that let us know that they were Removing Code-Based Sandbox Solutions in SharePoint Online. Unfortunately, there’s no date on the post, so quite a few people I shared it with doubted its relevance. But if you go up a level, you can see it was posted on the 29th.

Removing Code-Based Sandbox Solutions in SharePoint Online SharePoint team - Published 07/29/2016

Removing Code-Based Sandbox Solutions in SharePoint Online
SharePoint team – Published 07/29/2016

Here at Sympraxis, we’ve never used Sandbox solutions (client side rulez!), but this quick shutdown seems to be hitting many people hard. I would have thought there would have been  series of reminders, maybe a countdown clock, and some targeted emails to people who are still running this type of solution to help them prepare for the eventuality.

There’s been an active discussion on reddit, confusion in the SharePoint group on Facebook, complaints in the SPYam Yammer network, etc. In other words, the communication either didn’t hit or it hit too late.

Even worse, it seems as though the support people had no idea this was going to happen. As late as last Friday afternoon, this was considered a service issue, with updates coming into the Office 365 Admin Center to explain why it was happening.

Custom Solutions and Workflows - Service degradation

Custom Solutions and Workflows – Service degradation

I really try not to be publicly critical of my friends at Microsoft (I know some of you may find that hard to believe!), but this one could have been handled far better. Microsoft is learning how to be more open, and this is one place where I think they are going to learn some things. There may be good reasons why this shutdown is happening ex post haste, and letting us know what those reasons are would be helpful. With SaaS, whether we like it or not, we’re all riding in the same ship. When it springs a leak, not just the women and children need to know it’s time to head to the lifeboats. And it’s August, when not that many people are running at full steam.

There are clear ways to solve this for your own organization, and good articles explaining how to go about it. But you don’t have a lot of time (we’re hearing as little as 30 days, at least in the rumor mill), so you’d better get cracking!

 

Update 2016-08-01: Check out this post from Dave Feldman (@bostonmusicdave) about getting some non-code solutions to activate: Sandbox Solutions removed from SharePoint Online–Here’s the fix for your Visual Studio developed WSPs to get them to activate. It seems as though the change to SharePoint Online may be blocking some solutions it shouldn’t.

Update 2016-08-02: Apparently, some people are seeing a message like this in the Admin Center. If you aren’t sure if you have sandbox solutions, be sure to check!

MC73347 in the admin center:

We’ve detected that you are using a code-based sandbox solution with your tenant account. Please be advised that we’ve moved forward on our plans to remove code-based sandbox solutions as previously announced in 2014.

As part of the removal process, activation of new code-based sandboxed solutions, as well as updates of existing solutions are no longer available. In approximately 30 days, currently running, code-based sandbox solutions in the SharePoint Online environment will be disabled.

Update 2016-08-03: Be sure to read my follow up post New Script Available from Microsoft PnP: Generate list of sandbox solutions from SharePoint Online tenant

Dear Microsoft: Please Make Modified Dates in Site Contents Reflect Content or Structure Changes Only Again

Looking at the modified values in Site Contents has always been a quick way to recognize where activity has occurred – if it has. Without running any code we can quickly see if a site has been used recently. (It was easier to eyeball this in SharePoint 2007 in the vertical listing than it is in SharePoint 2013+, but that’s a different UI issue – tiles aren’t helpful for every use case.)

Site Contents in SharePoint 2007

Site Contents in SharePoint 2007

Site Contents in SharePoint 2010

Site Contents in SharePoint 2010

For months now, a list no one has touched for over a year on Office 365 might say “Modified 23 hours ago”. It seems as though lists and libraries are being “touched” by some background process(es), changing the modified time incorrectly.

Site Contents in SharePoint 2013

Site Contents in SharePoint 2013

An example would be the site in my Sympraxis Office 365 tenant at https://sympraxis.sharepoint.com/sites/Demos2013/_layouts/15/viewlsts.aspx

On that page, I see a number of lists and libraries that say “Modified 5 days ago”. I know for a fact that I have not modified any of those lists or libraries in quite a long time (at least months) and I’m the only person who would be in there.

False Modification Info

I’ve seen this in multiple tenants on Office 365, so it isn’t just something in my tenant. It’s VERY confusing to end users and brings into question the integrity of the platform.

I’ve been told by support that this is “expected behavior” and has been the case since SharePoint 2013. I believe this should be fixed.

I’ve added two UserVoice items to collect votes on this. It seems to be the best way to get some people in Redmond to pay attention to the issue, as my support conduits have failed.

It’s a shame when I feel I need to become an agitator to get  my friends out Seattle way to pay attention to this sort of issue. I know they are better and smarter than this, but large companies sometimes end up with processes that aren’t conducive to absorbing input. Things are SO much better in Redmond now, and I am sincerely enjoying working with the Product Group out there as an MVP.

In this case, let’s politely and constructively let them know this matters to us (and in my case, to my clients) by voting for the UserVoice items. Requests with more votes get more attention. so let’s let them hear us.