November 21, 2007 at 9:25 am
Our SQL service account was incorrectly a Domain admin account. As per best practices and give only the minimum rights I followed Microsoft Article 283811 'How to change the SQL Server or SQL Server Agent Service account...'
I have made the regedit/file system permission adjustments.
Upon start-up of the first server (after removing the service account from Domain Admins) I receive this in the SQL logs:
Error: 8319, Severity: 16, State: 1.
Windows kernel object 'Global\SQL_90_MEMOBJ_MSSQLSERVER_0' already exists. It's not owned by the SQL Server service account. SQL Server performance counters are disabled.
Error: 3409, Severity: 16, State: 1.
Performance counter shared memory setup failed with error -1. Reinstall sqlctr.ini for this instance, and ensure that the instance login account has correct registry permissions.
Obviously I am missing something in permissions...
November 29, 2007 at 8:09 am
I got this figured out and wanted to share. It seems (shocker here) that the Microsoft Article I referenced and what is in SQL 2005 BOL are conflicting.
Using Setting Up Windows Service Accounts chapter in SQL 2005 BOL I found that I didn't give the Domain user account that will run the SQL server services Read, Execute and List Contents permissions on the installation/Microsoft SQL Server/80 and installation/Microsoft SQL Server/90 directories.
Once I gave these rights and then restarted the server I didn't have the errors.
September 25, 2008 at 11:00 am
Hi,
I had de same problem.
To fix it try the nex steps:
1.- Change the account that start SQL Server Service and SQL Agent Service to the Local System Account.
2.- Restart SQL Server Service and SQL Agent Service in order to aply the last change.
3.- The Follow permissions must be granted to the SQL Server account in the Local Security Policy> * User Rights Assignment.
* Adjust Memory For A Proccess
* Log on as Service
* Log on as a batch job
* Locks pages in memory
* Act as part of the operating system
* Bypass traverse checking
* Replace a process level token
4.- Add the SQL Server Domain Account to the SQL Server Groups on the server.
5.- Log on and log off the server with the SQL Server Domain Account to aply changes.
6.- Change the account that start SQL Server Service and SQL Agent Service to the SQL Server Domain Account.
7.- Restar SQL Server service and SQL Server Agent Service.
8.- Check your ERRORLOG.
Good luck.
Carlos.sfc
DBA SQL Server :pinch:
November 23, 2008 at 10:05 am
I faced this same problem after changing of the SQL Server 2005 Service accounts. It is on the Windows cluster environment.
Will try the solution advise of granting READ, Execute, Full on the SQL Server Binary folder for the new service account.
July 18, 2011 at 3:32 pm
I had the same error/problem after I changed SQL Server 2008 service accounts (through SQL Server Configuration Manager). To fix it I removed old service accounts from "Local Security Policy" - Local Policies - User Rights Assignment - "Log on as a service" and added new service accounts. And restarted service. Issue is gone.
June 19, 2012 at 7:06 pm
I had the same problem when implementing SSL certificates for encryption. I did not change the service account. After a second restart of SQL Server services, there were no more error messages.
May 9, 2018 at 7:47 am
There are some other reasons that you will see the performance counters locked. Specifically, McAfee - when not placed into logging mode - when files are placed on the root (C:\ drive), McAfee is positioned to lock these files permanently. In this case, you cannot uninstall, or reinstall, or patch... and all because files that are required for access (examples: ../MSSQL/Binn/sqlctr.ini and ../MSSQL/Binn/etwcls.mof.transformed) are permanently locked. If the security ACLs are checked, you will find the permission is there and available (unlike the situation described above) but the message from SQL Server is that you cannot access the file during an install, patch, uninstall, etc. ("Performace counter shared memory setup failed with error - 1. Reinstall sqlctr.ini for this instance, and ensure that the instance login account has correct registry permissions."
This error occurs frequently in my situation because we have no control over the ePO that allows us to go into logging mode and it can be deceiving as to whether McAfee is in logging more or not. It may appear to be in logging mode right up until you run the uninstall. Since that is the piece that locks up the accounts, there is huge risk with running McAfee unless you can be more than 100% sure that the server is actually in logging mode. Sometimes the people whose job it is to put it into logging mode don't know whether it is or not because the server doesn't actually talk to the ePO server to properly put itself into logging mode. The Collect and Send props has to run - it you forget that, you will find it locks regardless of logging mode. And lately, I've been informed that in addition to Collect and Send Props, it is important to reboot the server before hand so that it is certain the server is actually talking to the ePO server.
If anyone finds this insane, join my club. If I had the ability to erase McAfee, it would bring me great joy at this point. But the problem remains McAfee, McAfee, McAfee. So keep this in mind if you are perusing this based on the error in the title.
Jamie
December 3, 2018 at 12:33 pm
Jamie-2229 - Wednesday, May 9, 2018 7:47 AMThere are some other reasons that you will see the performance counters locked. Specifically, McAfee - when not placed into logging mode - when files are placed on the root (C:\ drive), McAfee is positioned to lock these files permanently. In this case, you cannot uninstall, or reinstall, or patch... and all because files that are required for access (examples: ../MSSQL/Binn/sqlctr.ini and ../MSSQL/Binn/etwcls.mof.transformed) are permanently locked. If the security ACLs are checked, you will find the permission is there and available (unlike the situation described above) but the message from SQL Server is that you cannot access the file during an install, patch, uninstall, etc. ("Performace counter shared memory setup failed with error - 1. Reinstall sqlctr.ini for this instance, and ensure that the instance login account has correct registry permissions."This error occurs frequently in my situation because we have no control over the ePO that allows us to go into logging mode and it can be deceiving as to whether McAfee is in logging more or not. It may appear to be in logging mode right up until you run the uninstall. Since that is the piece that locks up the accounts, there is huge risk with running McAfee unless you can be more than 100% sure that the server is actually in logging mode. Sometimes the people whose job it is to put it into logging mode don't know whether it is or not because the server doesn't actually talk to the ePO server to properly put itself into logging mode. The Collect and Send props has to run - it you forget that, you will find it locks regardless of logging mode. And lately, I've been informed that in addition to Collect and Send Props, it is important to reboot the server before hand so that it is certain the server is actually talking to the ePO server.
If anyone finds this insane, join my club. If I had the ability to erase McAfee, it would bring me great joy at this point. But the problem remains McAfee, McAfee, McAfee. So keep this in mind if you are perusing this based on the error in the title.
"'Global SQL_130_MEMOBJ_28_MSSQLServer_0'+already exists. Its not owned by the SQLServer service account. SQL Server performance counters are disabled." - yet another cause for this error. In the process of hiding the instance and removing the browser, the linked server was not updated with the proper connection string and this is the resultant error.
Jamie
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply