Our solution stack consists of multiple services, each of which can be run on individual host machines. For a variety of reasons, the services are hosted as a windows service running under a virtual account. Many of these services need to connect to a MS SQL 2008R2 instance running on a remote host. Each of the host machines running the services thus need to added to the MS SQL2008R2 instances as logins. e.g if our services are running on hostnames machine1, machine2...machinen, machine accounts machine1$, machine2$... machinen$ need to be added to MS SQL as logins. I thought I could simplify this by adding each host machine to a machine group on the domain and add the machine group as a login on the MS SQL instance. This did not work. Am I missing some steps ? OR am I forever condemned to add each individual machine accounts to MS SQL instance ? I know that I can run the windows services under a domain user (or maybe have the services impersonate a domain user if possible) and add the domain user to the MS SQL instance but I do not want to try this approach as the password for the domain user now needs to be managed.
Any help appreciated
Once the server and workstation were rebooted, it worked. Now just having the security group on MS SQL and no individual machine account on MS SQL gets our solution stack up and running. Thank you SQLChao for keeping me on track.
Related
The solution consists of an SQL Database and desktop application working hard with that DB. DB Deployed as Azure SQL Database, application running on Azure Virtual Machine with Windows Server onboard. What is the deployment guidelines for this two services in Azure? I want to achieve max performance. Should they both be located in same resource group?
You will need to get your app and the database located as close as possible so yes the same resource group.
Make sure you do not have Mars enabled (MultipleActiveResultSets in connection string).
Make sure you do use connection pooling.
Read this to understand what you are dealing with:
https://www.simple-talk.com/sql/learn-sql-server/improving-the-quality-of-sql-server-database-connections-in-the-cloud/
Ed
I am a system administrator for a small firm. Now we consider to rollout Windows Server 2008 R2 for the firm.
We plan to implement Active Directory.
We would also like to upgrade RDMS, from SQL server 2000 to SQL Server 2014.
We can afford to buy just one server due to size of our organization, so we plan to implement both of AD and SQL Server 2014 on the same machine.
However, Microsoft recommends not to install SQL Server 2014 on a domain controller.
I have checked the reasons, but I don't understand what is the problem, so if someone answers my questions bellow, it's really helpful.
(1)You cannot run SQL Server services on a domain controller under a local service account.
→If we run SQL Server on a domain controller under a domain user account, what would happens?
(2)After SQL Server is installed on a computer, you cannot change the computer from a domain member to a domain controller.
You must uninstall SQL Server before you change the host computer to a domain controller.
→We plan to promote our server to a domain controller before installing SQL server 2014 and don't plan to de-promote to
member server because it's our only server. Is our plan wrong?
(3)After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member.
You must uninstall SQL Server before you change the host computer to a domain member.
→We don't plan to de-promote to member server because it's our only server. Is our plan wrong?
(4)SQL Server failover cluster instances are not supported where cluster nodes are domain controllers.
→We don't plan to install failover cluster, so we think that it's not problem. Are we wrong?
(5)SQL Server Setup cannot create security groups or provision SQL Server service accounts
on a read-only domain controller. In this scenario, Setup will fail.
→Because We have just one server, so it never be a read-only domain controller, so we think that it's not problem. Are we wrong?
Actually, I guess if we clear (1), we can install SQL server 2014 on our domain controller.
Thanks for reading all of sentences.
I hope someone give us answers.
Warmest Regards,
Yoshiaki Fujita, Tokyo, Japan
Currently our windows desktop applications run against a SQL Server instance that resides on our network. I'd like to remove the local instance and seamlessly assess the data from a remote SQL Server instance such as Azure. I could write a middle tier, such as WCF, but I'd rather not. It would be easiest just gain direct access to the SQL server. Can this be done?
Thanks.
Yes. - http://msdn.microsoft.com/en-us/library/windowsazure/ee336282.aspx
You'll need to ensure that the Azure SQL Database firewall rules are set up to allow traffic from your IP.
If you are running full SQL Server on a Windows Azure Virtual Machine you can open the port to the SQL Server. Be aware that you'd likely want to ACL the endpoints on a VM to restrict access to your IPs.
Remote SQL Server and Azure could be very different things.
First difference that you will found is the Connection String form. Azure SQL connection strings looks like:
Server=tcp:xxxxxxxx.database.windows.net;Database=xxxxxxxx;User ID=xxxxxxx#xxxxxxxxx;Password=xxxxxxxxxx;Trusted_Connection=False;Encrypt=True;
I am taking a Windows Azure introductory course and one of the prerrequisites for it is to have installed SQL Server 2008 R2 on my machine.
When I'm installing SQL Server in the Server Configuration section it asks for 2 users: one for the SQL Server Agent and other one for the SQL Server Analysis.
I am a begginer, so that's why I'm asking you to recommend me wich users should I use. And also, is it possible to change the users after installation?
Thanks in advance.
Yes, you can change the user after you install those services. The services will run using those accounts and therefore the services will have the same rights as the accounts.
For DEV/test you can use the local system account.
For production you should create a dedicated domain account for those services.
The best account to use in this instance would be The Network Service Account.
Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services.
The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITY\NETWORK SERVICE".
Network Service Account is the only account which is supported by SQL Server and SQL Server Agent Services, allows for network file system access i.e. SSMS DBA tasks, and yet still avoids using a Local System Account.
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
To change which account the service runs under, do so in the same GUI that you are currently using inside SQL Server Configuration Manager
I need to set up a "throw-away" instance of SQL Server 2008 for students to test a program for a few weeks. SQL Server 2008 is running on a virtual instance of Windows Server 2008. The server is not a member of the domain. The client computers that need to connect to the SQL Server are domain members, as are the student accounts. The client program expects to connect with Windows Authentication. This would all be very simple if the server were in the domain; despite lengthy discussions with the school's IT, this is not going to happen...
So: I need to configure the SQL Server to accept connections from these clients. I'm no sys-admin, so my best guess (based on this article) was:
Enable the Guest account on Windows
Add "NT AUTHORITY\ANONYMOUS LOGON" to the logins accepted by the SQL Server
Set "Network Access: Allow anonymouse SID/Name translation" in Local Security Policy
Add the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TurnOffAnonymousBlock and set it to 1
By my reckoning, that should have done it, but the clients still cannot connect. Can anyone give me a recipe for getting this to work? Basically telling the SQL Server to accept connections from anyone and everyone?
p.s. No security worries: this is all behind the school firewall, and I will reset the instance when we are done.
In order for two machines to connect using Windows Authentication, one of two things must be true:
The machines are in the same domain, or
The machines are in the same workgroup and the Windows account has the same password on both machines
If neither is true, then the only alternative is SQL Authentication (SQL Server-specific username and password).