The death of the internal links

I’ve stopped linking my blog posts together.  No more will you see part 1, part 2, etc.

I realised that this was just administrative overhead and unscalable.  Instead I’ve gone the modern way and am using categories and tags so just use those to find linked posts.

Not sure why after preaching to many lawyers over the years I have failed to listen to what I was saying.  Links are bad, fragile and a pain to maintain, just use tags instead.

Sorry its taken this long for me to actually grok this.

Cheers

Sebastian

An internal database error occurred in the Business Data Connectivity Shared Service. SQL Error Number : 229. Occurs after Applying Sharepoint 2013 Service Pack 1 or a Cumultaive Update

We just had a customer report that their user profiles weren’t updating with information from their HR system.

Checking everything was alright I went to Central Admin and the BCS service failed with a standard “An error has occurred and a correlation id”.  Checking the event logs (ULS) via the ULSViewer I got the following error message:

Application error when access /_admin/BDC/ViewBDCApplication.aspx, Error=An internal database error occurred in the Business Data Connectivity Shared Service. SQL Error Number : 229. Please contact your administrator.

at Microsoft.SharePoint.ApplicationPages.ViewBDCApplication.OnLoad(EventArgs args)

at System.Web.UI.Control.LoadRecursive()

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Not a lot on the Internet about this but some people do mention SQL Permissions.  We had just applied the December 2014 CU for SharePoint and checking the FIM logs that’s when the problem occurred.

So I checked the permissions on the BCS Database.

The Account the BCS Service runs under was listed but with no database role memberships at all.

I gave it SPDataAccess and it all sprang back into life.

We have added this as something to check after each CU now.

Cheers

Sebastian

Sharepoint Restoration Blues: There was an error in accessing the Catalog. Error: System.InvalidOperationException: There is no default Business Data Connectivity Service Proxy available for the given SPServiceContext

Hi Folks

After a Disaster Recovery to a stand by farm I got this error when attempting to add a User Profile Synchronization Connection to a BCS External Source I got the following displayed in the External Content Type Picker:

There is no default Business Data Connectivity Service Proxy available for the given SPServiceContext.

Head scratching ensued until I checked:

• Central Administration
• Application Management
• Web Application
• Selected “SharePoint Central Administration v4” and clicked on Service Connections.

• Select the missing service applications.
• Select OK.

Bish bosh jobs a good’un.

Cheers

Sebastian

SharePoint Menus disappear in IE11 (and Site Actions give “An error has occurred with data fetch. Please refresh the page and retry.”)

Hi Folks

An annoying one this some users when they try to edit a SharePoint item report that the ellipses (…) don’t work correctly.  These users also get the following error message when they click on the site actions (cogwheel) button.

An error has occurred with data fetch. Please refresh the page and retry.

After a few experiments it turned out to be related to the user and not the machine.  So it’s a user profile issue.

Further testing showed that if you use the F12 developer tools the emulation options are all blank and the dropdowns for them are also blank.

It’s a user profile problem.

Specifically one of the following registry keys under one of these keys points to a folder that the user does not have access to.

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache

It was a CachePath key and it had the following value:

• %USERPROFILE%\AppData\Local\Microsoft\Windows\History\History.IE5\MSHist012014110320141110

Deleting this key resolves the issue.

Lovely user can now edit happily.

Next morning she rings up again, the problem is back.

Check the key and its back too.  Delete it things start working.

However we have a mystery what put it back?

• Policy, no we checked.
• Roaming Profile, no they don’t use those.
• AppSense,  no it does touch these keys.
• AppSense, yes it does restore temporary profiles from a network drive and those (it turned out) include these keys.

We deleted the users temp profile, she rebooted and the problem did not reoccur.

So why did AppSense not write back the changes to the registry when she logged off put did restore the old ones when she logged on?

That is still a mystery.

Cheers

Sebastian

FatalError: Backup failed for Object Crawl-1

Hi Folks

Nasty one this happened when using Backup-SPFarm on a client’s production site.

We capture the services every week with the following command:

Backup-SPFarm -Directory:”\\SERVER\\Share\Services” -Item:”Farm\Shared Services” -BackupMethod:Full

This week it failed with:

FatalError: Backup failed for Object Crawl-1

After much digging it turned out that the Share’s permissions had been tightened too far.  Crawl-0 succeeded but its on the box that runs the backup.  Crawl-1 is on another box.

I reinstated the share’s permission so the following had Full Control on it:

• Account that executes the backup.
• The farm account.
• The SQL Server account the service databases run under.
• The Search Service account.

Hope this help

Sebastian

Pulling the table cloth from under the enumeration glasses

Hi Folks

Ever had a need to do something to every item in a collection that would change the collection?  I don’t know lets say removing all SharePoint Site Collections under a managed path.

Now we all know that you can enumerate a collection and then loop through acting on each element but if you change the element in a way that’s meaningful to the enumeration, say adding or removing an element or changing its identifier then, quite rightly, the enumeration throws an error.

Now this is correct when developing a generic solution as it prevents a number of context specific bugs, i.e. I remove all the elements but another process adds one whilst I’m doing it so at the end I think my collection is empty but actually its not.  If this is important to you then this technique is not correct, I’d suggest a while enumeration is not empty remove loop instead.

However often when acting as an administrator such concerns don’t apply, for example I’m the only one acting on the elements of the enumeration or I can always run it twice if needed. In this case there is a well known solution we enumerate the collection and store the result as a variable of a suitable type, probably a list or array, and then act on the variable by enumerating it. As we are modifying the ‘copy’ of the references and not the elements themselves we can happily add, edit and remove them because we are affecting the original elements and not the references we are now enumerating.

So how do we do this in PowerShell?

$Collection = Get-SPSite -Limit:All

This will get us a reference to all the site collections we can now act on, be careful though this will remove all the site collections in your farm.  For safety I’ve put the somewhat confusing double negative confirm flag on so at least you will be prompted before a site is deleted.  If you want it to not prompt you use -Confirm:$false, i.e. do not ask me for confirmation.

$Collection |% { Remove-SPSite -Identity:$_ -Confirm:$true }

Lovely in just two lines we have acted on every site.  We can reduce it to a single line but not as we would expect.

Get-SPSite -Limit:All |% { Remove-SPSite -Identity:$_ -Confirm:$true }

Instead we have to cast our results to an array to force the enumeration to complete before passing it to our script block.

@(Get-SPSite -Limit:All) |% { Remove-SPSite -Identity:$_ -Confirm:$true }

Bish bosh, job’s a good’un!

Cheers

Sebastian

SharePoint 2013 Administration Tools

One of the interesting side effects of the Infrastructure as a Service (IaaS) that seems to be getting more popular is that as well as supplying software we are now also taking on more of the ‘Infrastructure’ role. This seems to be because the client feels that “we don’t do IT now we outsource that” whilst the Service Providers have a very “We run the tin, the network and the OS but nothing else” attitude. This leaves the poor old application with no friends. So as no-one else is doing it we have started taking on this responsibility for hosted solutions.

I don’t think this state of affairs will last. Our Office 365 products are essentially maintenance free and as Software as a Service (SaaS) becomes more prevalent this responsibility will move back to the hosting company but for now its slipped between the cracks.

Ultimately when we move to Transactions as a Service (TaaS) it will disappear completely and we’ll all be very, very glad.

In the mean time we find ourselves configuring and supported hosted SharePoint 2013 solutions, not a problem the folks here probably know more about how to do this than most IT departments.

What it does mean is that we have been thinking about what tools a SharePoint Administrator must have on their desktop (or pinned to their task bar).

1. Internet Explorer, how else will you be able to test what you have done.
2. SharePoint 2013 Central Admin, still the first port of call when wondering how things have been configured.
3. SharePoint 2013 Management Shell, still really useful for quick ad-hoc scripts.
4. Internet Information Services (IIS) Manager, for checking security certificates, .config files, web application pools.
5. SharePoint 2013 Manager, gives you the ability to drill down and investigate SharePoint via its API, incredibly useful for working out why things aren’t as you expect, i.e. showing you the Event Receivers on a list.  Pity its icon is very similar to SharePoint 2013 Central Admin.  (http://spm.codeplex.com/).
6. ULS Viewer, gives you the ability to view and filter the SharePoint logs.  With this you can actually find the errors, the alternative, looking through the many, many .log files with a text editor is very unpalatable.  You could do it but then again  you could always poke out your eyes with a stick, a blunt stick, your choice. (http://archive.msdn.microsoft.com/ULSViewer).

Cheers

Sebastian