SharePoint – The service did not start due to a logon failure

Sometimes a minor detail can lead into severe side-effects, as is the case in this posting. Our client installed a new piece of software, and one of the installation steps generated a rather seemingly harmless question. The installation software asked if it can be allowed to update a GPO (Group Policy object) in Active Directory (AD). The unsuspecting IT staff member assumed this was fine and proceeded to make the changes required to make the software work. However, soon after, we started receiving error messages indicating that numerous service accounts and SharePoint service accounts could not login anymore.

If a service account cannot login as a service anymore, the application pretty much stops working. And in this particular case, the SharePoint powered public web site, as well as all intranet sites, simply stopped working. Fortunately, with Intelligent Monitoring the issue was identified as soon as the Group Policy was applied and the IT staff could update the GPO in question without any major outages. Without monitoring, it may have taken the IT staff a long time and a lot of effort to get to the bottom of this issue. Under further investigation it turned out that the new software installed, as advertised, updated an existing GPO. However, instead of adding a new account under Windows User Rights Assignment and Log on as a service, the software replaced all existing associations, which led the issue.


The WebSphere Contrarian: Preparing for failure

Many enterprises ensure that application and infrastructure performance
testing and tuning is part of every implementation project plan. However,
another essential testing and tuning phase is often overlooked — one to
ensure that application and component failover occurs without any impact to
application availability. This installment of the WebSphere Contrarian
discusses how to approach that task.