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