January 27, 2011 at 7:54 am
sqlapprentice (1/27/2011)
sgodrich (1/27/2011)
I just solved the same problem on our servers by running (the now depreciated but still accepted) command:netsh firewall set service RemoteAdmin enable
From a command prompt set to run as administrator
Thanks for the reply, but I think the ultimate cause behind this problem still depends on if the login you use to log on to SSMS actually have the service control (start/stop) privileges on the target sql server box.
For example, in my current working environment, my local workstation account (a normal domain user account) is sysadmin to all my sql server intances, but I can't see the service status of any sql server box; however, if I "run as" SSMS with my admin account (a domain user account that have local admin rights on all my sql server boxes), I can see all the sql server services plus all the sql agent services are up and running (or not when they stop).
sqlapprentice,
That doesnt actually work either. I just tried your 'run as ' suggestion using the SQL service account (which is also in the local admins group.
As the origenal poster, what has been missed here is that it is a specific issue effecting x64 sql clusters under the 2008 ssms.
Generally speaking, to get the start/stop functionality and greenn staus icon you need access to start/stop services on the server or nod (local admins) though this is not the case under ssms 2008. If i connect to the cluster instance as me under ssms 2005 its fine; do the same under ssms 2008 and i got boobcus!
Next........... 😉
Adam Zacks-------------------------------------------Be Nice, Or Leave
January 27, 2011 at 8:18 am
Schadenfreude-Mei (1/27/2011)
sqlapprentice (1/27/2011)
sgodrich (1/27/2011)
I just solved the same problem on our servers by running (the now depreciated but still accepted) command:netsh firewall set service RemoteAdmin enable
From a command prompt set to run as administrator
Thanks for the reply, but I think the ultimate cause behind this problem still depends on if the login you use to log on to SSMS actually have the service control (start/stop) privileges on the target sql server box.
For example, in my current working environment, my local workstation account (a normal domain user account) is sysadmin to all my sql server intances, but I can't see the service status of any sql server box; however, if I "run as" SSMS with my admin account (a domain user account that have local admin rights on all my sql server boxes), I can see all the sql server services plus all the sql agent services are up and running (or not when they stop).
sqlapprentice,
That doesnt actually work either. I just tried your 'run as ' suggestion using the SQL service account (which is also in the local admins group.
As the origenal poster, what has been missed here is that it is a specific issue effecting x64 sql clusters under the 2008 ssms.
Generally speaking, to get the start/stop functionality and greenn staus icon you need access to start/stop services on the server or nod (local admins) though this is not the case under ssms 2008. If i connect to the cluster instance as me under ssms 2005 its fine; do the same under ssms 2008 and i got boobcus!
Next........... 😉
Maybe it is just a very specific problem.
I am using SSMS 2008 R2 and connect to a bunch of instances (no clustering, but just one principal mirroring instance) ranging from version 2000, 2005, 2005 Express, 2008 and 2008 R2. I can control all their service statuses and see the green arrow while I do the "run as" trick.
Bazinga!
January 27, 2011 at 8:24 am
Well then be glad you havent come across this mix! Im not running R2 but am running ssms 2008 (patched) and can access our 2000, 2005 servers with no probs (and there was a guy earlier o n in this thread that was fine with x32 cluster).
For some reason x64 cluster breaks it :crazy:
Adam Zacks-------------------------------------------Be Nice, Or Leave
January 27, 2011 at 8:45 am
I was one of the people who can access 32-bit clusters, but I also have 32-bit clusters that don't allow me to interact with the service, despite being identical to other environments in every way except machine name.
64-bit clusters also aren't the problem as I have two of three tiers in an environment working correctly (production and development) but the test cluster doesn't allow service interaction. All relevant WMI and registry settings are identical. The only difference between any of those environments is the data contained in a few user databases.
I even have new 2008R2 machines exhibiting this behavior (again, inconsistently). It's a little maddening to say the least.
June 2, 2011 at 3:00 pm
I run into the same problem and haven't figured it out.
Even though I connect SSMS with a Window login which is a member of sysadmin and the icon SSMS still missing the green arrow.
I've tried with another SQL login (also a member of sysadmin) but it doesn't work either.
So far, searching on the Net has not yet provided any clear, working solution.
Worse than that, with two logins mentioned above, I was able to setup transacation log shipping, but when I tried to uncheck/disable transacation log shipping, SSMS errors out and stating 'your login is NOT a member of sysadmin' which is not true.
Under security, I checked properties of those two logins, they are both checked as sysadmin under Server Roles.
My guess is somehow SSMS does not 'see' my login as member of sysadmin.
Anybody has a solution?
Thanks.
David Nguyen.
June 16, 2011 at 9:18 am
Hi,
I resolved the isssue in Win2K8 by running MSSMS as and administartor. Even though you have local admin access to the Server the issue still persists. I think it is caused by having UAC enabled. Hope this helps.
June 17, 2011 at 1:13 am
Thanks for the reply but I am using XP (so UAC wouldnt be involved) and while I am not logged in as Administrator my AD account is an admin of my machine and all SQL boxes.
Thanks anyway.
Adam Zacks-------------------------------------------Be Nice, Or Leave
July 11, 2011 at 12:11 pm
I am having the same problem. I am running Windows 2003 R2 SP2 and SQL 2005. It was working fine, but IT upgraded the server from Standard to Enterprise. Any suggestions. I have tried everything on this post.
July 12, 2011 at 3:10 am
What is you issue?
This thread is about using a SQL Server 2005 Ent 64-bit A/P cluster through SSMS 2008. Your issue sounds different.
Start from the begining, what are the details?
Adam Zacks-------------------------------------------Be Nice, Or Leave
July 12, 2011 at 6:55 am
My issue is the same as the first post " I can't use right-click the instance icon to select "start", "stop", "pause", "resume" or "restart" because they are all grayed out. But all the rest operations are available" I don't think it is related to a specific version. I found something yesterday that I am going to try that says it is related to the SQL clinet.
July 12, 2011 at 7:38 am
bbrown 40722 (7/12/2011)
My issue is the same as the first post " I can't use right-click the instance icon to select "start", "stop", "pause", "resume" or "restart" because they are all grayed out. But all the rest operations are available" I don't think it is related to a specific version. I found something yesterday that I am going to try that says it is related to the SQL clinet.
If that your issue, it is likely to be permissions related. What you need to have is access to view the 'Server State'.
The first thing to try is to run ssms and connect to the instance as the login used for the sql service (assuming its a domain account). That should work fine.
Now check that the same account has been setup for lock pages in memory, do this: Run:gpedit.msc --> Computer Config --> Windows Settings --> Security Settings --> Local Policies --> User Rights and ensure that Lock Pages in Memory is set to the same account as you service account (this will have to be a domain account).
Once that is done get your user or dba group (if multiple users) setup in the local admin group of the server. Really all you should need is access to Services but it never hurts to have Admin (for backup file permissions and various others).
Let me know and good luck.
Adam Zacks-------------------------------------------Be Nice, Or Leave
August 15, 2011 at 7:48 am
I know this is years late, but i was under the impression the green arrow had to do with the state of SQL Server Agent configuration. Can anyone give clarity on this. I just wanted to clarify this.
August 15, 2011 at 8:24 am
Permissions are consistent across all servers, regardless of OS/version. Service control state is inconsistent regardless of OS/version.
August 24, 2011 at 11:58 am
I still cannot get this to work on my local SSMS client. It's running the same version as on the server. My problem pertains to clustered instances running 2K8 R2 Enterprise. I can gain control of he services state locally on my wkstn if I register the physical cluster node name but the virtual name just gives me the circle. The weird thing is I log onto the virtual host name and connect to the instance and all is well there. Just not my local 2005 client. Any idea on what I have to tweak on my local client in SSMS or within windows to get this to work (green arrow) so I can control all aspects of services and more importantly SSCM. The exact error message i get when accessing SSCM is below.
Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 servers with SQL Server Configuration manager. The RPC server is unavailable [0x800706ba]
Any clues?
August 25, 2011 at 1:30 pm
I had the same issue in SSMS and also while using Central Management Server. I found if i had registered the instance with the port defined, for example: SQLHost\Instance, 1433, I got the white circle and could not control the services from there. If I remove the port portion, I get the green arrow and I am able to control the services. Just figured I'd chime in, since this fixed my issue. BTW, I am connecting to SQL 2000, 2005, 2008 and 2008 R2. All of them had the same issue.
Viewing 15 posts - 46 through 60 (of 94 total)
You must be logged in to reply to this topic. Login to reply