There may be many reasons for this problem. If this is affecting all the servers it is better to check if you change the password of the user running this service.  Also the user the timer service is running needs access right to "SystemDrive:\ProgramData\Microsoft\SharePoint\Config" directory.In our case problem was not related to user password or permissions.

Just stopping & starting "Sharepoint Timer Service" may solve the problem as well. But again this did not help in our case.

There are many blogposts mentioning that the problem may be config cache in such an issue. Step by step documentation for how to clear sharepoint configuration cache is documented in this blogpost. https://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx Although the blogpost is for Sharepoint 2010 it is same for 2013 as well.In our case clearing configuration cache did not help as well.

Then we realized that OWSTIMER.EXE.Config file timestamp is same as the paused timer jobs time ( SystemDrive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\BIN\OWSTIMER.EXE.Config ) . Viola:) Customer has changed this file for a custom timer job in one server and malformed OWSTIMER.EXE.config file on the servers was causing the problem. After fixing the XML on the config file our deployments finished successfully.

There is a documented solution for this

https://support.microsoft.com/en-us/kb/2384424

But this solution uses stsadm command which will not be available on Sharepoint 2016. This is a sample script to configure this with powershell.

$newdomain1= new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$newdomain1.DomainName ='mydomain1.local';
$newdomain1.ShortDomainName ='mydomain1';
$user1="mydomain1\myuser"
$pass1=convertto-securestring 'mypasswordformyuser' –AsPlainText -Force
$credentials=new-object –typename System.Management.Automation.PSCredential –argumentlist $user1,$pass1
$newdomain1.LoginName=$credentials.UserName
$newdomain1.SetPassword($credentials.Password)
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain1)

$newdomain2 = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$newdomain2.DomainName ='mydomain2.com';
$newdomain2.ShortDomainName='mydomain2';
$user2="mydomain2\myuser2"
$pass2=convertto-securestring 'mypasswordformyuser2' –AsPlainText -Force
$credentials2=new-object –typename System.Management.Automation.PSCredential –argumentlist $user2,$pass2
$newdomain2.LoginName=$credentials2.UserName
$newdomain2.SetPassword($credentials2.Password)
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain2)

$wa.Update()

The difference between server and central admin was 13 hours:) First I checked time of all servers in the farm. And all of them look same and correct. Than I have seen some conversations on internet about this issue and their solution was building the farm from scratch:) No way... I went to https://centraladminsite/_layouts/regionalsetng.aspx url which is hidden by default and  realized that just the central admin is thinking itself as GMT-10 Hawaii time zone.

 When I updated the timezone to UTC+2 my problem has solved.

Another way to fix this issue is updating central admin default time zone through Central Admin -> Application Management -> Manage Web Applications -> SharePoint Central Administration v4 (The Central Admin Web Application) -> General Settings -> Default Time Zone

As far as i understand when creating your sharepoint farm if your server timezone is different than normal time zone central admin is getting this as default and even if you change your server time later central admin timezone will not change automatically. So you need to update it manually.

But there is 2 workarounds for having the same functionality;

1. Change the siteurl with yours and it will ask you for the new username and password

https://siteurl/_layouts/closeConnection.aspx?loginasanotheruser=true

2. Open internet explorer by  using "run as different user" option  (Shift+ right click) by entering the username and password that you like

Keep in mind first option may not work in some browsers and ie10

• Internet Explorer 10
• Internet Explorer 9 with Office 2013 or Sharepoint Designer 2013 installed
• Internet Explorer 8 with Office 2013 or Sharepoint Designer 2013 installed
• FireFox 3.5 (or later)
• Chrome and Safari 5.x (or later)

will do the job for you.

If you try to open general settings of a web application in sharepoint and get an error "Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb.”

You can try this script from powershell.

$myweb = get-spwebapplication https://nameofproblemwebapp
$myweb.HttpThrottleSettings
$myweb.Update()

"SharePoint Server 2013 encountered an error during setup" 

error. When I checked the details of the error in error log file  

I found an entry

"Failed to install the product: c:\global\oserver.msi error code: 1603(0x643) error when istalling sharepoint 2013"

I tried many different things but the solution was very interesting:) Virtual machine was using just one CPU. After increasing the processor on virtual machine from 1 to 4 magic happened and installation finished successfully.

Visual studio 2012 and 2010 has a cool feature called code metrics which you can use under analyze tab or just by right clicking the solution.

Code metrics results shows you how many lines of code do you have. Also this report has some useful info that may help you. The maintability index ratio is calculated by a formula using Cyclomatic Complexity and lines of code. Bigger ratio means easier maintability. There is also a color in front of it which means

Green   High Maintainability                       Between 20 and 100

Yellow   Moderate Maintainability             Between 10 and 20

Red        Low Maintainability                        Between 0 and 9

Cyclomatic complexity measures the structural complexity of the code. High number for cyclomatic complexity indicates that the code may be too complex, and should be refactored.

Depth of inheritance indicates the number of class definitions that extend to the root of the class hierarcy.

Class coupling indicates the total number of dependencies that a class has on other classes.