Issue: You are performing an Sharepoint upgrade (via PSConfig.exe as mentioned here for example) but got the error Message "Cannot open SPTimerV4 service on computer '.'." as seen below:

An error has occurred while validating the configuration settings.  
An exception of type System.InvalidOperationException was thrown.  
Additional exception information: Cannot open SPTimerV4 service on computer '.'.

Solution: Make sure you are running the Powershell with "Run as Administrator" even if the account you are using has local Admin rights.

One of our Clients were experiencing an issue while Opening one of the SharePoint 2010 Lists in Access. They were essentially Clicking on one of the links “Open in Access” from List’s Ribbon that would result in the following error.

“Export to database failed. To export a list, you must have a Microsoft SharePoint Foundation-compatible application.” To resolve this Download and Install the below hotfix for 32-bit Office and then restart your computer.

http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2553170&kbln=en-US  

From here: https://dougieflash.wordpress.com/2013/03/08/updates-are-currently-disallowed-on-get-requests-to-allow-updates-on-a-get-set-the-allowunsafeupdates-property-on-spweb/

If you are in Central Administration > Manage Web Applications and go to the General settings option,
you might run into this error:

· “Updates are currently disallowed on GET requests.

· To allow updates on a GET, set the ‘AllowUnsafeUpdates’ property on SPWeb.

· Troubleshoot issues with Microsoft SharePoint Foundation.

Correlation ID: e845bd26-f70b-4f65-a023-82ca9d126031”

This error occurred in my dev environment. The behavior was that new applications would throw this error,

“Updates are currently disallowed on GET requests” under the General Settings. The error stack trace mentioned

‘EnsureHttpThrottleSettings’ so it means that CA is trying to update these setting on a GET request for new apps
that don’t already have them.

Resolution via Powershell

Launch Powershell and and add these lines:

$w = get-spwebapplication http://yourwebapplication
$w.HttpThrottleSettings
$w.Update()

The call to the HttpThrottleSettings ensures they exist and Update() saves them.

After completing these commands, you should be able to successfully launch the General Settings dialog window.

From hiere: http://sadomovalex.blogspot.ca/2013/11/how-to-restore-site-collection-from.html?showComment=1443900554748#c8594024626886432758

Sometimes you may face with situation that bug is only reproducibly on production, but not e.g. on QA or on your local development environment. Such problems are much harder to troubleshoot. Often they are caused by the content which exist only on production. And if troubleshooting directly on production is problematic (e.g. if you don’t have remote desktop access to it), you should get backup of site collection or whole content database, restore it on local dev env and try to reproduce bug here. But what to do if you have lower Sharepoint version on you local environment, than on production? Of course it is better to have the same versions, but world is not ideal and sometimes we may face with such situation. In this post I will show the trick of how to restore site collection from the higher Sharepoint version. Before to start I need to warn that this is actually a hack and you should not rely on it. There is no guarantee that it will work in your particular case, because new Sharepoint version may have different schema, incompatible with previous one (that’s why standard way is not allowed).

Ok, suppose that we have site collection backup, which is created with Backup-SPSite cmdlet:

Backup-SPSite http://example1.com -Path C:\Backup\example1.bak

We copied it on local environment and want to restore it with Restore-SPSite:

Restore-SPSite http://example2.com -Path C:\Backup\example1.bak –Confirm:$false

(Here I intentionally used different urls for source and target sites in order to show that it is possible to restore site collection to the different url). If we have lower Sharepoint version on the local environment we will get unclear nativehr exception, which won’t say anything. But if we will make our logging verbose and check Sharepoint logs, we will find the following error:

Could not deserialize site from C:\Backup\example1.bak. Microsoft.SharePoint.SPException: Schema version of backup 15.0.4505.1005 does not match current schema version 15.0.4420.1017.

(Exact version number is not important. For this post it is only important that source version 15.0.4505.1005 is higher than target version 15.0.4420.1017).

What to do in this case? Mount-SPContentDatabase also won’t work because of the same reason, i.e. content database backup also won’t work. In this case we can either update our environment (and you should consider this option as basic) or go by non-standard way.

For non-standard way we will need hex editor. At first I thought that site collection backup is regular .cab file, so it will be possible to uncompress it, edit text files inside it and compress back (I described this trick in this post: Retain object identity during export and import of subsites in Sharepoint into different site collection hierarchy location), but this is not the case with site collection backups made with mentioned cmdlets. They look like regular binary files. So we will need some hex editor for modifying it. I used HxD hexeditor, but you can use any other as well.

If we will open backup file in it and will try to find the version, which we got from error message from the log, we will find that it is located in the beginning of the file:

The good thing is that version is stored only once. So we will change source version to the target in the hex editor now:

Now save it and run Restore-SPSite again. This time restore should work. Hope that this trick will help someone. But remember that it is hack and use it carefully.

From: http://blog.incworx.com/blog/consulting-from-the-trenches/disable-call-out-menu-in-sharepoint-2013-document-libraries

We recently had a request from a customer that is in the process of upgrading from SharePoint 2007 to 2013 to change the way the edit menus look on items in lists and in document libraries. The desire was to return to the standard look used in SharePoint 2007 as they did not want the additional click when navigating to actions on an item.

This is a fairly easy fix to implement on your lists and document libraries by modifying your existing views or creating new views on the lists or libraries that prefer this look and feel.

The new call out menu looks like the example below

The old style view from 2007 is in the following format

Solution:

In order to get the new menu strcture the easiest way will be to modify the existing view or create a new view for that document library or list.

To do so perform the following steps:

Go to your document library or list

In the ribbon clock on Library and then either Modify View or Create view

Once the view opens up you will scroll down to the bottom and you will see a section for Styles towards the bottom of the page on the left hand side. The current selection will be set to "Default"

There are references out there that list to change this to "Newsletter, no lines", however I dont care for this view as it shows the items with alternating shading on each line which to me does not look very clean.

Instead I utilize the "Basic Table" view as this shows the items just as it looks in a default SharePoint 2007 document library. So select "Basic Table" and then click OK to save the changes to the view.

Once this is complete you will see that the menu drop down next to all documents in your library look like the old 2007 look and feel as is shown above.

You can get rid of /_layouts/15/start.aspx in the URL by going to Site Actions -> Site Settings -> Manager Site Features -> Deactivate Minimal Download Strategy feature

However this is a new framework in SharePoint 2013, which increases performance of SharePoint site..

More reading here:

What is /_layouts/15/start.aspx

Why does /_layouts/15/start.aspx appear as part of SharePoint 2013 URL

In the event logs, I found out, that I have errors in system logs:

• Event Id: 7031, 7034;
• source: Service Control Manager;
• details: The SharePoint 2010 User Code Host service terminated unexpectedly.

I found out, that service account that was running Sandbox code service needs to have access to performance counters on the server. So what you need to do is pretty simple, you need to grant service account access to counters and you can do it by adding service account as a member of local group Performace Monitor Users in Server Manger.

Thanks to https://sajiviswam.wordpress.com/2011/04/15/the-machine-default-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid-000c101c-0000-0000-c000-000000000046-sharepoint-2010/

This error is being logged into the System event logs in Event Viewer due to inadequate permission for the farm admin account on the DCOM component 000C101C-0000-0000-C000-000000000046. In order to change the permission settings, perform the following steps.

1. Open Component Service by clicking Start > Administrative Tools > Component Services.
2. Navigate and expand the node Component Services > Computers > My Computer > DCOM Config.
3. Right Click the sub node “000C101C-0000-0000-C000-000000000046” and select “Properties”.
4. On the Properties dialog box, select Security tab. In most cases you will notice that the settings are grayed out. This is because the logged in user doesn’t have enough permissions on this component to change the settings. In order to provide this permissions, perform the steps described in next section “Change Component Service Owner and Permission”. You may need to restart the server after doing this.
5. Once you set up the permission mentioned in previous step, in the Launch and Activation Permissions section in Security tab, select Customize option and click Edit.
6. In the popup window, add the farm admin user account and check Local Launch and Local Activation permissions.
7. Restart IIS and SP Timer. If possible, restart the server itself.

Change Component Service Owner and Permission

In the DCOM Config dialog box, you noticed that the settings are grayed out. In order to enable those settings, perform the following registry modification.

1. Open Registry Editor by typing “regedit.exe” in Start > Run.
2. Navigate and select the key “[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{000C101C-0000-0000-C000-000000000046}]”
3. Right click and select Permissions.
4. In the popup windows, click Advanced.
5. In the Advanced Security Settings windows, select Owner tab and change the owner to Administrators. Click OK to close the window.
6. In the Permissions screen, select Administrators and check Full Control. Click OK to close the screen.
7. Close the registry editor.

• Site Quotas and Lock in Central Administration (option is greyed-out)
• Stsadm : operation completes successfully but no change
• Using PowerShell : same behavior as stsadm

From this guy: http://www.bleepingtech.com/windows-8-fix-this-app-cant-open-for-built-in-administrator-account/

You might have encountered with this strange and annoying error.  This app can’t open for Built-in Administrator account please sign in with a different account and try again. or  while User Account Control is turned off. You need to turn on UAC . There is an easy solution for the error.

Solution for Windows 8 App Error:
•Hold the  Windows key + R  and in run dialog box type: secpol.msc
•Go to Local Policies –> Security Options –> Scroll down and find “User Access Control: Admin Approval Mode For built in…..”
•Double click on it and select enabled and the press ok
•Again press windows key and R and type  regedit
•Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI
•On the right hand side double click on default and change the value to 0x00000001(1) and click ok
•Restart your computer and all the apps should work.