Recently, despite ensuring the SSL certificates within Internet Information Services (IIS) were updated ahead of their expiry, I fell foul of the hidden certificate within SharePoint 2013’s Security Token Service. In my defence, this is a certificate not mentioned within IIS or the Central Administration site. Its one of those lovely settings that can only be seen, analysed, and amended via PowerShell commands. Once you know/remember its there, its relatively straight forward to update.
While waiting for a purchase order for Sharegate to be approved, I needed to quickly migrate content of an old SharePoint 2010 list to our new SharePoint 2013 farm. Out of the box this isn’t straight forward, and Microsoft recommend a complete backup, move and upgrade approach for the entire content database. Time-wise, this wasn’t an option and seemed overkill for a single list.
In the past I’ve experimented by writing a PowerShell script to export the list’s content to a .CSV file and it’s attachments into folders, and then another script to suck it back into the destination site.
Very odd. Even though I’ve been using Internet Explorer 11 and SharePoint 2013 together for some time, this morning, when I created a new Site Collection and added a Calendar, it wasn’t rendering as it should and many links were broken.
Note to self: Instead of banging your head for two days trying to resolve the issue of PerformancePoint reports not displaying. When you see a “Failed to Sql Query data XEvent collector on sqldbserver…” message within the log files, first ensure that the SharePoint farm account has been granted the serveradmin role upon the SQL server.
Since the roll out of Internet Explorer 10, our users were having trouble whenever they attempted to give someone access to their SharePoint 2010 area via the Grant Permissions dialog. Whenever they clicked the Browse icon, they’d receive a “An unexpected error has occurred” message.
One solution that seemed to solve this issue was to add the domain of the SharePoint site into the browser’s Compatibility View Settings – but that would effect all sites using the domain (including non-SharePoint sites).
While researching the issue I found a suggestion that it could be corrected by appending a META tag to one of the MasterPages.
Normally I wouldn’t dare edit one of the SharePoint core files, but as this was effecting so many users and we’ll be migrating to SharePoint 2013 in the near future, the benefits outweighed the risks.
Browse to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS and locate the pickerdialog.master file.
Immediately after the opening HEAD tag, insert the following line: <meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE8″ />
The changes appear to have resolved the issue completely.