9. October 2015 04:05
At our recent SharePoint User Group, Bogdan Coamesu delivered a great session on Performance Issues Troubleshooting. This included a very detailed slide deck, and complimentary files to help you perform the troubleshooting in your own environment.
We've decided to post those files here for easy access by the SUG and others;
SharePoint-2013-Performance-Issues-Troubleshooting.zip (1.90 mb)
This is a really good community resource from Bogdan.
24. March 2015 09:50
I got a query from a colleague who monthly needs to print many documents from a folder in a document library. This was taking them a lot of time, and they asked me to enable 'something' to print all the documents at once. There are commercial products to achieve this, but for tens of documents there's a free workaround.
Here are my documents in O365 (though this is identical in 2013, and 2010);
Simply click on the venerable 'Open with Explorer' option;
In explorer you can select up to fifteen documents at once, and a print button remains visible. This cuts down the work of multi-document printing a lot! The documents can't be mixed, so this doesn't work for e.g. PDFs and Word together, but you can sort on the Type column to get everything into one batch.
4. March 2015 10:14
Document Sets were first introduced in SharePoint 2010 and are an excellent way to organize content. I've gained many enthusiastic users of Doc Sets, but there is one feature they often ask for - the ability to search inside a particular Document Set. The issue is that Document Sets can easily end up with tens or hundreds of documents in them, but the default search scope in SharePoint is usually going to search the whole site. With this in mind I devised a solution to allow my users to search just in the Document Set they're currently looking at.
Wouldn't it be nice to allow users to search inside the current Document Set like this? It just takes a few minutes to put this together! (I've documented here for SharePoint 2010, but this also works for 2013 and Office 365 with a minor tweak detailed below)
One very nice feature of Document Sets is that they have a 'Homepage' that you can edit. This allows you to change the look and feel, including adding extra web parts and through use of the Content Editor Web Part add Script. This thinking led me to my solution...
Search results webparts in SharePoint are driven by querystring parameters in the url of the page. I therefore realized that if I added a Core Search Results webpart to the Document Set homepage, and manipulated the URL with the users search term and the Document Set address then I could show Document Set specific Search results right there in the Document Set page.
The concept is illustrated below. I need to take the url of the Doc Set, and add two querystring parameters; k for the search term and u for the container I wanted to search. (This is Microsoft's naming convention, not mine!)
To achieve the above I first need to change the Doc Set Homepage for my library. Go to library settings and click the Document Set Content Type. (This is assuming you've already added that!)
In the next page click Document Set Settings
In that next page you'll see an option to edit the Doc Set Welcome Page.
Now you see the default template for the welcome page
This is what that same page looks like when you click edit. The various web part zones are visible;
Now we add a CEWP to the page as shown;
Next add a Search Core Results web part to the same web part zone;
Your page now looks like this;
Your users now see a Search box when they're viewing Document Sets. Entering a Search Term and clicking they see results from just that Document Set as below. This is better than before but the results are kind of ugly.
To change the look of the Search results to be friendlier, edit page again and go into the Search Core Results web part settings. Expand Display Properties, and click the XSL Editor button. (You may need to untick the 'Use Location Visualization' box to ungrey the button). In the editor that pops open, delete the text and paste in the contents of my SearchStyling.xsl file, also at the bottom of this article. Click OK and save your changes.
Your search results should now look fairly like a normal List View. Sorting and filtering is possible on the search columns, and the description field which is sometimes verbose can be expanded or not. The XSL I've provided can be tweaked to display different columns (there's a lot of properties in search results that aren't shown by default) including your own custom columns.
The files you need to make this work are below;
SearchAndFilter.js (3.60 kb) [SP2010]
SearchStyling.xsl (10.91 kb) [SP2010]
SearchAndFilterO365.js (3.60 kb) [SP2013 or Office 365]
9. April 2014 09:47
A quick example of how to create multiple Document Sets in SharePoint driven by a CSV file for the names and properties. Changing a couple of lines would allow this script to create simple Folders instead (but Document Sets are better!). [More]
31. January 2014 08:53
Whilst browsing some SharePoint blogs I came across an interesting code sample. The code showed how to edit item properties in an Event Receiver on a library.Here's a partial excerpt;
using (SPSite site = new SPSite(properties.Web.Site.ID))
using (SPWeb web = site.OpenWeb(properties.Web.ID))
SPList list = web.Lists[properties.List.ID];
SPListItem item = list.Items.GetItemById(properties.ListItemId);
This code caught my eye, because it was totally unnecessary to instantiate the SPSite and SPWeb objects to get a handle to the list item. Far better to just use event properties without instantiating anything!
So, in for a penny, in for a pound I thought I'd compare the code performance. In a standalone dev environment with a few list items the bad code would run fine. I have access to a test environment with tens of thousands of items, which provided a better test of Production-like conditions.
The good code executed in 30ms fairly consistently, according to the logs. Fair enough.
What I found was the bad code execution time started climbing as I fired more and more items into the list and triggered the event receiver more often. I gave up when the bad code was executing in 12000 milliseconds.
Yup. In my sizable library, the bad code ran 400 times slower than the code using properties.ListItem!!
This is why it's not good practice instantiating unnecessary SPSite and SPWeb objects. (So also consider SPContext.Current when you're not in Event Receivers for similar reasons).
Also shows you why you shouldn't trust code samples on blogs without a bit of code review (including mine!).
24. November 2013 04:49
Custom SharePoint Timer Jobs are a bad idea more often than not. Here are some alternative approaches to get the same results in a (hopefully) future-proofed and Cloud Friendly way. [More]
21. November 2013 11:59
I was putting together some CSOM Managed code to update an existing Choice column in SharePoint. Noticed that existing online examples show creating a new column or reading the values in a column, but nothing about update. The Red Herring that is the SchemaXml property on Field sent me the wrong way for a few minutes. Finally realized that by using the CastTo method on the context I could get a FieldChoice instance rather than just a Field. Once you have that the Choices are defined as a string array so very easy to update or replace. Here's the code;
using (ClientContext ctx = new ClientContext("http://MyServer/MySite"))
Field genericField = ctx.Web.Lists.GetById(listID).Fields.GetById(fieldGuid);
FieldChoice fldChoice = ctx.CastTo<FieldChoice>(genericField);
fldChoice.Choices = “MyChoice1;MyChoice2;MyChoice3”.Split(";".ToCharArray());
21. November 2013 08:28
Over the past year or so I've spoken to some SharePoint customers who have been confused by the SharePoint message coming out of Redmond. Microsoft, in their enthusiasm to promote Office 365 have not really assured customers on the future of SharePoint On-premises. There's been a real lack of any clear message about the product and no roadmap was published. Anecdotally this has led to some nervousness amongst customers, and the question has been asked 'Is On-premises SharePoint dead?'. Asking such a question might sound melodramatic, but believe me - silence from Redmond on any technology often means it's doomed.
Don't get me wrong, I believe there are many positives to Office 365 and Cloud in general. I see Office 365 as a great way to make SharePoint available to smaller organizations to whom On-Prem would not be cost effective. However the shift isn't going to happen en masse quite yet. Just look at Gartner’s comments that for example only 8% of office system users employ any sort of cloud based email at all; here In my part of the world, Switzerland, I find many of the large Enterprises have a 'no cloud' rule. Until certain issues to do with guaranteed up time, connectivity, and state snooping are resolved, that is not going to change here. [Update 4th December 2013 Microsoft have issued a very welcome communication on Government Snooping here ]
SharePoint On-Premises is still how the vast majority of customers use SharePoint and it's still a major cash cow for Microsoft.
I'm preparing for the day I might have to move our farm to Cloud (I'll detail how in future blog posts) but I don't expect it to happen for at least five to ten years if it ever does. Many other customers may take the same view.
With this in mind I'm relieved today to see an official post on the MS Office Blog. Not only does it herald the coming release of Service Pack 1 for SharePoint 2013, but it also states here
" we look forward we'll continue to deliver rapid innovation through our Office 365 service as well as continued future on-premises versions of SharePoint on our traditional release cadence of 2-3 years."
This is gold. We'll continue to get rapid innovations and releases from Office 365, for those that want it. However On-Premises is still alive and kicking, and as organizations we still have the stability of not making major changes to the platform outside of the current 2-3 year cycle we know and love. Big business has the stability of the platform it needs. A message I'd have liked to see at least a year ago, but welcome now nonetheless.
24. July 2013 23:05
Recently saw a request to get rid of the delete option on a view item form, but retain the ability to switch into edit mode. As both options were on the ribbon and couldn't be removed independently I came up with a hack. Here is one idea for faking buttons on your InfoPath List Forms so that functionality you couldn't otherwise have can be attained! [More]
19. May 2013 13:21
When searching for Certification info for SharePoint 2013 the only game in town seems to be the MCSE. This is extremely weighted towards server setup and configuration, and requires certification in Windows Server 2012 before getting anywhere near SharePoint. The Developer certs such as MCPD are to be retired so things were looking bad for Developer Certification. Thankfully, information about a Developer Certification Path are now surfacing. [More]