IE Crashes In SharePoint 2013 when you mouseover the Profile Image: RESOLVED

Ever since I installed Lync 2013 and started using SharePoint 2013, ever time I hovered over a person's presence indicator, IE would crash. This became very annoying. I first thought since I was one of the first whom has Lync installed, there was something funny with the installation. I tried repairing Office 2013 with no joy.

I finally resolved the issue this morning. I then searched the forums to see if others had an answer but all I found was a locked thread: http://social.technet.microsoft.com/Forums/sharepoint/en-US/dfc80784-f030-4775-9245-7a3fd26bcfb1/ie-crashes-in-sharepoint-2013-when-you-mouseover-the-profile-image?forum=sharepointgeneral

The claim was that it was not SharePoint 2013 related. In my case and in most of those cases it was. The presence in Outlook worked fine. Anyway, I was a bit upset that the thread on the forum was closed with no resolution. People are trying to find an answer.

My resolution was that I still had Microsoft Office Communicator 2007 R2 installed on my machine. This was causing the conflict when hovering over the presence in SharePoint 2013. Once I uninstalled, the issue did not occur anymore and now I am free to move my mouse wherever I want!!

Hope this helps people looking for an answer but finding that Microsoft forums shut the door on them.

 

SharePoint 2013: Database Schema Version Issue using Move-SPSite

You may use Move-SPSite in SharePoint PowerShell to move site collections from one content database to another. However after applying updates and creating new content databases, when attempting to move a site collection, you may receive the following error:

Cannot complete the copy or merge operation because the database schema versions are different.

 

 

Sometimes you content databases do not get properly upgraded during the installation of a cumulative update or service pack. There is a quick an easy fix. Just use the Upgrade-SPContentDatabase cmdlet to update the content database:

 

 

Upgrade-SPContentDatabase -Identity <<content database name>>

 

 





Just for good measure, I usually run this cmdlet on all content databases - just in case. The system will let you know if the content database does not need to upgraded.

Once all databases are in sync, you may use the Move-SPSite as normal without any database schema errors!

 

SharePoint 2013: Login failed for user 'DOMAIN\SERVER$'

Our DBAs kept seeing error messages in their SQL Server log as follows:

Login failed for user 'DOMAIN\SERVER$'. Reason: Could not find a login matching the name provided. [CLIENT: xx.255.222.22]
There was an entry for almost all of the SharePoint servers in the farm. It seemed to occur three times per day at the same times: 5:32am, 1:32pm, and 9:32pm.

I looked in the Event Viewer of one of the servers and located the error there too:

SQL database login for 'SPS_SharePointConfig' on instance 'SPSQLSERVER' failed. Additional error information from SQL Server is included below.
Login failed for user 'DOMAIN\SERVER$'.

Using the Correlation ID in the Event Viewer item , I searched through the ULS Logs.

 

 

I found several items in the SharePoint ULS logs:

SQL database login for 'SPS_SharePointConfig' on instance 'SPSQLSERVER' failed.
powershell (0x03AC) 0x1324 SharePoint Foundation Upgrade SPUpgradeSession ajxme ERROR CanUpgrade [SPConfigurationDatabase] failed.

Essentially, the timer job attempts to run an upgrade check using a PowerShell call. For some reason, the PowerShell call does not run as the timer job account but yet the local system account (hence the DOMAIN\SERVER$).

Those local accounts do not have permissions to run PowerShell commands against the SharePoint farm. Therefore one must allow access to these local accounts by adding them as "Shell Admins":

Get-SPDatabase | Add-SPShellAdmin -UserName DOMAIN\SERVER$

This allows the local system account to run shell commands against each SharePoint database.

Once I issued this for each server in the farm, there were no more SQL Server log entries! The DBAs were very happy!