View Complete Post
Just installed a standalone, developer's instance of Sharepoint 2010 on my Windows7 workstation per the instructions outlined in the MSDN article:
When I try to click on the Configure service accounts link on Sharepoint Central Administration site, I get an access denied error. My windows ID is local to the workstation and it has full administrator rights. My Id is in the Farm Administrator's
group plus the BUILTIN\Administrators group. Why can't I access this link? Everything else appears to working fine (still testing).
Want to set up a MOSS 2007 server farm and was reading up on how to do it. One Msft article insist that I need multiple accounts. My sys admin tells me that I can use one account for everything. This account is a domain account and is a member of the domain
admin group, it has dbcreator, public, secadmin, serveradmin, sysadmin roles on the db server.
Any thought on the topic?
http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/28627c31-0c39-4560-8cf9-f41a960fad6c , Network Service is 2nd best.
The only choices other than Network Service, Local Service, and Local System is Domain User. But my laptop isn't a part of a domain. My laptop is running Windows XP SP2.
What do I do?
Which is the best service Account to chosse for while installing SQL.
We are installing SSIS,SSRS,SSAS as well and we will be installing each of then in a differnt sever.
And we do not have a domain account to use for we should chose from network service/ localservice/ local system
I am connecting to a access database by a linked server through a network,
using the network service account. It works fine.
All i want to know is whether using the network service account has any drawbacks?
Can i achieve the same by using a local service account? If i can achieve that through local service account what are the steps i need to do?
Please share your ideas
Looking for detailed information on what resources the MS SQL Engine reads, writes, and modifies in order to operate as designed. Read this carefully. I've been on the search but am not finding anything quickly.
I believe if a Windows domain account is being used for any of the SQL Engine services that account should not have any granular permission settings on any folders related to SQL operations, nor any granular settings on the registry or any where else.
Should be FULL CONTROL. Microsoft wrote the program to run the way it does and we should not be the judge of what permissoins a service account should have so the program runs correctly.
I am troubleshooting unstable SQL issues and I am finding little tips here and there pointing in my mind to be the service account having too many restrictions on the SQL folders, Windows registry, and everything else.
My opinion would be, any domain account used as a SQL service account should have FULL CONTROLL on any folders used for SQL operations and FULL CONTROLL on registry operations and be part of NO group policies.
If anyone knows where I may find detailed information that is written in GOLD as to what permissions SQL needs to run, let me know. Send a link. I think there should be NO restrictions. I haven't met anybody yet that really understand
Crosspost from RIA Services forum: http://forums.silverlight.net/forums/t/196466.aspx
I'm creating a Dynamic Data application in VS2010 and have recently
switched to using a Domain Service to give greater control over the
data presented to the client. I've noticed that the
AutoGenerate<Action>Button attributes on my GridView are being
ignored. The presence of the Edit and Delete buttons appear to be
contingent on the existence of Update and Delete methods on the partial
classes autogenerated in the Domain Service, but i'm not seeing how to
control the generation of the Select button. Is there a way to control this from
within the Domain Service class?