November 2, 2009 at 2:48 pm
This seems like it could be related to User Access Control and limited rights. Do you see any messages logged to the Application, Security, or System event logs?
November 2, 2009 at 5:10 pm
Moving away from Sharepoint, I still have aproblme of a 2008 machine not being able to connect to a 2008 sql server. Eventually, many of the project databases here at my job will be migrated over to the new 2008 sql server. I have to make sure those applications, web applications (Non-sharepoint & sharepoint) running from a 2008/7/vista environemnt will be able to connect to their databases moved from sql server 2005 to sql server 2008.
November 2, 2009 at 5:26 pm
I know that you said that port 1433 is not being blocked on the 2008 machine, but have you tried taking the firewall out of the equation altogether? Can you connect if the windows firewall is disabled?
Joie Andrew
"Since 1982"
November 2, 2009 at 5:44 pm
akilah.mcintyre (11/2/2009)
Moving away from Sharepoint, I still have aproblme of a 2008 machine not being able to connect to a 2008 sql server. Eventually, many of the project databases here at my job will be migrated over to the new 2008 sql server. I have to make sure those applications, web applications (Non-sharepoint & sharepoint) running from a 2008/7/vista environemnt will be able to connect to their databases moved from sql server 2005 to sql server 2008.
All web applications permissions connect to SQL Server in the context of Asp.net which means you must give access to the Asp.net account in SQL Server on the server level and database level. Then if SQL Server and IIS are running two separate servers that is double hop which means you have to give Asp.net access to the SQL Server server on Windows level, SQL Server server level and in the database. This is complex work that will take some planning and testing before implementation.
Kind regards,
Gift Peddie
November 2, 2009 at 10:37 pm
What about applications (*.exe)? They will more than likely to either use ODBC or ADO .NET.
November 2, 2009 at 10:40 pm
I know that you said that port 1433 is not being blocked on the 2008 machine, but have you tried taking the firewall out of the equation altogether? Can you connect if the windows firewall is disabled?
Since the machines are internal and not outward-facing, none of the machines have firewall enabled. I mean the internal machine sits behind our company's firewall.
November 3, 2009 at 7:29 am
akilah.mcintyre (11/2/2009)
What about applications (*.exe)? They will more than likely to either use ODBC or ADO .NET.
ADO.NET is data access that is a wrapper to the RDBMS driver what I am talking about is the difference in RDBMS security and Windows how to use both when your application users needs access to SQL Server. So by application you are talking about Winform users SQL Server access there are two options one you add all the users manually into SQL Server, if your application and SQL Server are in separate boxes you also need to add the users on Windows server level, SQL Server server level and database level. The other option is to use .NET 3.5 introduced new client services which uses a config file to take care of the security resolution. So read my last post in the thread below and post back again.
http://www.sqlservercentral.com/Forums/Topic779867-364-1.aspx
Kind regards,
Gift Peddie
November 3, 2009 at 9:11 am
So by application you are talking about Winform users SQL Server access there are two options one you add all the users manually into SQL Server, if your application and SQL Server are in separate boxes you also need to add the users on Windows server level, SQL Server server level and database level.[\quote]
Ok I get manually adding SQL Server Logins and database users before that databases can be access. I'm still having trouble with the SQL Server authentication, not Windows Aunthentication. Some enterprise applications will not use Windows Authentication, although we can create a AD account for that application.
November 3, 2009 at 9:33 am
akilah.mcintyre (11/3/2009)
So by application you are talking about Winform users SQL Server access there are two options one you add all the users manually into SQL Server, if your application and SQL Server are in separate boxes you also need to add the users on Windows server level, SQL Server server level and database level.[\quote]
Ok I get manually adding SQL Server Logins and database users before that databases can be access. I'm still having trouble with the SQL Server authentication, not Windows Aunthentication. Some enterprise applications will not use Windows Authentication, although we can create a AD account for that application.
The SQL authentication problems comes because when you install SQL Server with Windows authentication the SQL Server installer disables the SA account so when you later change to both Windows and SQL authentication you have to go in to enable the SA account. When you can connect with the SA account then SQL Server is ready to use SQL authentication. So next time before you create and run code with a test account run the first test with SA account if it runs then SQL authentication is good.
You will not have issues with the Enterprise applications because Asp.net only uses Windows authentication for intranet most Asp.net applications use forms authentication so take care of the base requirement and you can use either SQL Server membership or AD membership to manage your users. If you have not implemented membership in an Asp.net 2.0 and up application then that creates more work that is not needed.
Kind regards,
Gift Peddie
November 3, 2009 at 10:18 am
Is your instance in mixed mode for security? Because if not, you will be able to add SQL logins all day long and still not be able to connect.
Joie Andrew
"Since 1982"
November 3, 2009 at 10:20 am
Is your instance in mixed mode for security? Because if not, you will be able to add SQL logins all day long and still not be able to connect.
Yes.
November 3, 2009 at 10:46 pm
During SharePoint setup I had some issues with connecting to sql 2008 remotely and all those issues were related to: sql 2008 being named instance so configured to use a different port than the default. Also, SharePoint required static port (I believe it was the requirement) so I setup sql 2008 named instance to use static port and later on all machines .. when connecting I had to make connection strings to conform to this: server\instancename,port.
It had to be done for asp.net, for SSMS, VS 2008 .. etc..
So, maybe your problem is around this issue. This approach (suspecting named instances and port issues) will not explain why your machines with older systems can connect .. but maybe there is something that was overlooked..Just trying to help. It looks like you eliminated security issues already. What is an error that you are getting.. something like "server does not exist... cannot connect" or "invalid login". Security issues would be like the latter.
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply