There is always something new to discover … even in Microsoft Word!

I’ve used Word for I don’t know how many years, yet I just found out something I never knew before … that Aa button on the ribbon under the Home tab/Font section … it allows you to select different casings on your sentence or words … really neat … sorry if you knew that already, I just though it was great as I’ve always dived into Notepad++ to do that kind of thing before.

Little gem hidden in the ribbon ...


Dave Mc


SharePoint 2013 JavaScript API – SP.Taxonomy.LabelMatchInformation

I’ve been working with the SharePoint 2013 JavaScript recently and had cause to want to fetch the Id of a Term within the Term Store using the Taxonomy namespace.

Problem was, the documentation about this particular aspect of the JavaScript API is less than comprehensive to put it politely. In fact it’s pretty mysterious. However I managed to glean that in order to select a specific set of terms relating to a specific label you need to use the SP.Taxonomy.TaxonomySession getTerms() method and pass the method a single parameter of type SP.Taxonomy.LabelMatchInformation.

This is where my problems started.  The documentation says to create an instance of this type you need to pass in a parameter ‘a’ to the constructor.  No information on type of parameter at all.  So I tried simply putting in a string which was the label for my term. Nope. Null? Nope. Zero? Nope.  OK … how about the client context? Bingo!  Yep it’s the client context.  Except that doesn’t actually seem to work when you pass it into the getTerms() method, it doesn’t error, but neither does it actually allow you to enumerate through the returned terms.

OK, back to the drawing board. What about that method called newObject?  So I tried that also with the Client Context and double Bingo … yep created an instance of the SP.Taxonomy.LabelMatchInformation type and it created the enumerator for the returned terms in the call-back function correctly.

So if you want to fetch just a few terms from the term store, don’t bother using the constructor for the SP.Taxonomy.LabelMatchInformation type, use the newObject() method and pass in the Client Context and you’ll be fine….


What I also found was that unless you fully populate the SP.Taxonomy.LabelMatchInformation with initial values, it also gives you problems, despite the fact that the documentation says there are default settings.  So here’s a snippet of code to successfully create  a call to the terms store to fetch a specific term:

// Get the client context
var context = SP.ClientContext.get_current();

// Create the taxonomy session passing in the client context
var taxonomySession = SP.Taxonomy.TaxonomySession.getTaxonomySession(context);

// Create new instance of LabelMatchInformation
var lmi = SP.Taxonomy.LabelMatchInformation.newObject(context);

//Populate the various properties
terms = taxonomySession.getTerms(lmi);
context.executeQueryAsync(successcallback, failurecallback);

function successcallback(sender, args) 
    //Do something with result.
function failurecallback(sender, args) 
    //Show some error message.


Dave Mc

Office 365 Web Part Menu Not Available IE11

I’ve finally managed to get around doing some work on investigating SharePoint 2013 Apps.  Yeah, late I know, but that’s the nature of project work and having a full life outside of IT.  Still better late than never I say.

Anyhow, I noticed this strange behaviour on Office 365.  The menu button for the web parts appeared to have changed and all you can do is to minimise or maximise the web part.


Further more the web part options in the Ribbon appear to be disabled too.  I’m logged on as Global Administrator for the tenancy by the way with Site Collection administrator permissions.


I was using IE11, so I just had this inkling of an idea that it could be a browser issue…  so switching to Chrome sure enough I see on the same page, firstly the Ribbon elements are enabled where appropriate:


And secondly, the web part drop down menu appears nicely:


So back to IE and using the F12 tools, sure enough if I switch the User Agent String to IE10 but leave document mode as Edge


Then the web part menu reappears nicely again.

So how to fix this for all the pages without having to mess around with the F12 tools every time I want to actually edit a page?  Well I’d hoped to just change the X-UA-Compatible meta tag in the header as often this solves such issues.  However the Seattle Master Page already has this set to IE10 – which should tell us something … so no solution there.  It’s not the Document Mode which is the issue really, which is what the X-UA-Compatible meta tag affects.  It’s the User Agent which leads me to suspect that it is the browser itself.  No issue with IE8,9,10, Firefox or Chrome, just IE11. Fab.  If anyone finds a solution let me know.


Dave Mc

SharePoint 2013 Sandbox Solutions – Deprecated or Not?

Had this clarification today from Microsoft on the status of Sandbox Solutions:

“The only thing that is deprecated is sandboxed code. If you created a sandboxed solution in VisualStudio and set the “Include Assembly In Package” property to false, this is a declarative-only solution and that is not deprecated”

So basically provided there is no code in your sandbox solution you are good to go and that is not being removed from SharePoint 2013.

Hope that helps clear-up the rather confused messaging from MS about this!


Dave Mc


SharePoint 2013 “Sorry, this site hasn’t been shared with you”

This rather annoying message kept coming up on our on-premise (well on-Azure) SharePoint 2013 farm when we tried to create a new subsite of any kind.  After a fair amount of beating around and finding nothing around to indicate the cause, I eventually tried adding the current user to the Web Application User Policy in Central Administration and gave it Full Control.  That didn’t seem to work, still got the message.  I then tried the same again but also ticked the “Account operates as System” which did seem to work!  I then tried to add in a Security Group  with Full Control to the User Policy but this would not let me use the “Account operates as System” option.

So this workaround would appear to be OK for a test/dev/demo environment so we’ve opted for this at the moment, but seeing as you cannot have a Group operating as System it’s not really practical for production. I’ve seen other people say re-create the Web Application – well not really an option in this case.  So if anybody has the solution fit for production, please let me know!


Dave Mc

SharePoint 2013 : Configuring an on-premise farm for Apps

At Ridgian we’ve stood-up an on-premise SharePoint 2013 Farm.  Well actually it’s running in Windows Azure under an extension to our own AD and one thing we wanted to test and run through is configuring the Farm for Apps.  Basically setting up our own App Store.

Now TechNet have a an article which is a really good article and quite easy to follow.  There is one problem though.  If you are using SSL and do actually configure a separate DNS domain for your Apps, the article is incomplete.  There is one extremely important item missing and this item results in you always getting redirected to a 404 “Page Not Found” when you deploy and run your App.

Luckily Chris Whitehead, bless him, a Microsoft Premier Field Engineer has filled in the essential detail in his blog article which took me quite a while to track down.

The missing item in the TechNet article is the “Routing Web Application”.  Basically when you have set up everything as per the TechNet article, I was left wondering how does SharePoint actually know where to redirect the request to when all the Apps have a dynamically created DNS name such as .  Yes, it exists in DNS as a wildcard entry against your Apps server, but the server itself has no knowledge of this domain name and so refuses the request.  The trick is in this final step which Chris mentions but the TechNet article omits.  You create a new Web Application through SharePoint which has either:

  • A different IP address to the main SharePoint Domain or …
  • No Host Header if it shares the same IP address as the main SharePoint Domain.

This means that the server can now respond to any dynamically generated DNS name and SharePoint internals handles the fiddly routing bit. Now since we’ve run up our servers in Azure we cannot grant our Apps domain a separate IP address.  This results in another issue.  We end up with the Apps domain Web Application using the same certificate as the main SharePoint domain, so we get a certificate error coming up.  So on your production domain you need to have two IP addresses available in order to successfully implement an App Store using SSL without certificate errors.

I thought this stuff was meant to be getting easier!

In summary read both the TechNet and Chris Whitehead’s articles if you want to successfully run up a production App Store on-premise and make sure you have 2 IP addresses available. One for the SharePoint domain, one for the App domain.

Hope this helps


Dave Mc

SharePoint 2010 : “The search service is not able to connect to the machine that hosts the administration component”

I came across this very annoying message when provisioning the SharePoint 2010 Search Service Application recently, and interestingly it occurred on two farms on the same network.  Both were brand new stand-ups a Test and a Production farm.  Both were two-server farms, a SharePoint and  a SQL Server database.  The message appears when you provision the Search Service Application and then navigate to the Search Service Administration page.  The full message is something like:

Crawl: The search service is not able to connect to the machine that hosts the administration component. 
Verify that the administration component c8519b74 status -<GUID> in search application Search Service 
Application is in a good state and try again."

There are numerous blogs relating to this  post but none of them helped me solved the situation.  So I decided to recreate one of the farms.  This is when I came across another problem initially when trying to create the farm in Powershell, I got the error:

“The given key was not present in the dictionary”

when I tried to create the Central Administration Database. When I used a different account the farm created perfectly OK.  I then tried to create some managed accounts.  Through the UI I got the same error again about the ‘the given key’, but with Powershell it was fine.  On Binging the problem I found the following forums thread:

and the solution suggested which I have seen on other blogs is as follows:

Try this:

  1. Open up “Active Directory Users and Computer”
  2. Select “Advanced features” from the “View” menu
  3. Right-click the relevant account(s) and select “Properties”
  4. Select the “Securities” Tab
  5. Scroll down and select “Authenticated users” in the “Group or user names:” field
  6. Allow “Read” permissions in the “Permissions for Account Operators” field just below
  7. Hit Ok

Sure enough this solved the issue of “The given key was not present in the dictionary”.  I then proceeded to build the rest of the farm, but I still got the original problem of the Search Service being unable to find the administration component.

Eventually I tracked this issue down to there being an installation of IIS 7.5 Express edition having been installed for whatever reason on the SharePoint Server.  Along with this came the .NET 4.0 Client Profile and Extended Profile.  Now I’m unsure exactly which component it was caused the issue, but uninstalling all of then definitely solved the problem on both farms.

So in summary, make sure that IIS 7.5 Express, .NET 4.0 Client Profile and Extended Profile are NOT present on your SharePoint Server when you install.

Hope this helps


Dave Mc