![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I recently deployed an app with SQLExpress2005 as the backend. Despite testing it here on my dev network, this was my first opportunity to use it in a workgroup environment. I had to really jump through some hoops to get connectivity between the app and the SQLExpress database. I'm asking for any advice or constructive criticism on the steps I took, particularly in regards to whether it was unnecessary or exposed any security issues. Scenario: -- Four PCs (all XP Pro) in a workgroup configuration -- no server, connectivity is through a router. -- SQLExpress installed on one of the PCs with a server instance "PC1\SQLExpress". -- Database "AppDB" attached to "PC1\SQLExpress". -- A .Net application is installed on all workgroup PCs. The app works "as advertised" on the PC where there SQLExpress is installed, with connection string security set to SSPI. Could not get connection between the apps on the other PCs to "AppDB", sooooo ... On the SQLExpress PC: 1. Ensured firewall had ports 1433 and 1434 exposed. 2. Added ALL the local workgroup users and their passwords to the XP machine (PC1). 3. Used the SQL Surface Area Config tool. Set to allow Remote Connections over TCP/IP only. 4. Added "PC1\GUEST to SQLExpress Logins. On the downrange PCs, the app now reported, "Cannot open database "AppDB" requested by login." 5. On "PC1\SQLExpress instance, went to Security -> Logins -> PC1\Guest\ -> Properties - UserMapping and checked Map "AppDB" On the downrange PCs, the app now reported, "EXECUTE permission denied on "sel_Employees". So it appears that the user mapping WAS required. 6. On "AppDB", went to Security -> Users -> PC1\Guest -> Properties -> Database Role Membership and set to db_owner. The application on all downrange PCs now connect and function as advertised! This sure strikes me as incredibly Rube Goldberg in order to get connection between local network apps and an SQLExpress database. It seems like a DBA would be required even for SQLExpress installs, which surely is not what Microsoft intended. What could I have done better or easier? |
#3
| |||
| |||
|
|
I recently deployed an app with SQLExpress2005 as the backend. Despite testing it here on my dev network, this was my first opportunity to use it in a workgroup environment. I had to really jump through some hoops to get connectivity between the app and the SQLExpress database. I'm asking for any advice or constructive criticism on the steps I took, particularly in regards to whether it was unnecessary or exposed any security issues. Scenario: -- Four PCs (all XP Pro) in a workgroup configuration -- no server, connectivity is through a router. -- SQLExpress installed on one of the PCs with a server instance "PC1\SQLExpress". -- Database "AppDB" attached to "PC1\SQLExpress". -- A .Net application is installed on all workgroup PCs. The app works "as advertised" on the PC where there SQLExpress is installed, with connection string security set to SSPI. Could not get connection between the apps on the other PCs to "AppDB", sooooo ... On the SQLExpress PC: 1. Ensured firewall had ports 1433 and 1434 exposed. 2. Added ALL the local workgroup users and their passwords to the XP machine (PC1). 3. Used the SQL Surface Area Config tool. Set to allow Remote Connections over TCP/IP only. 4. Added "PC1\GUEST to SQLExpress Logins. On the downrange PCs, the app now reported, "Cannot open database "AppDB" requested by login." 5. On "PC1\SQLExpress instance, went to Security -> Logins - PC1\Guest\ -> Properties -> UserMapping and checked Map "AppDB" On the downrange PCs, the app now reported, "EXECUTE permission denied on "sel_Employees". So it appears that the user mapping WAS required. 6. On "AppDB", went to Security -> Users -> PC1\Guest -> Properties - Database Role Membership and set to db_owner. The application on all downrange PCs now connect and function as advertised! This sure strikes me as incredibly Rube Goldberg in order to get connection between local network apps and an SQLExpress database. It seems like a DBA would be required even for SQLExpress installs, which surely is not what Microsoft intended. What could I have done better or easier? |
#4
| |||
| |||
|
|
I recently deployed an app with SQLExpress2005 as the backend. Despite testing it here on my dev network, this was my first opportunity to use it in a workgroup environment. I had to really jump through some hoops to get connectivity between the app and the SQLExpress database. I'm asking for any advice or constructive criticism on the steps I took, particularly in regards to whether it was unnecessary or exposed any security issues. Scenario: -- Four PCs (all XP Pro) in a workgroup configuration -- no server, connectivity is through a router. -- SQLExpress installed on one of the PCs with a server instance "PC1\SQLExpress". -- Database "AppDB" attached to "PC1\SQLExpress". -- A .Net application is installed on all workgroup PCs. The app works "as advertised" on the PC where there SQLExpress is installed, with connection string security set to SSPI. Could not get connection between the apps on the other PCs to "AppDB", sooooo ... On the SQLExpress PC: 1. Ensured firewall had ports 1433 and 1434 exposed. 2. Added ALL the local workgroup users and their passwords to the XP machine (PC1). 3. Used the SQL Surface Area Config tool. Set to allow Remote Connections over TCP/IP only. 4. Added "PC1\GUEST to SQLExpress Logins. On the downrange PCs, the app now reported, "Cannot open database "AppDB" requested by login." 5. On "PC1\SQLExpress instance, went to Security -> Logins - PC1\Guest\ -> Properties -> UserMapping and checked Map "AppDB" On the downrange PCs, the app now reported, "EXECUTE permission denied on "sel_Employees". So it appears that the user mapping WAS required. 6. On "AppDB", went to Security -> Users -> PC1\Guest -> Properties - Database Role Membership and set to db_owner. The application on all downrange PCs now connect and function as advertised! This sure strikes me as incredibly Rube Goldberg in order to get connection between local network apps and an SQLExpress database. It seems like a DBA would be required even for SQLExpress installs, which surely is not what Microsoft intended. What could I have done better or easier? |
#5
| |||
| |||
|
|
I recently deployed an app with SQLExpress2005 as the backend. Despite testing it here on my dev network, this was my first opportunity to use it in a workgroup environment. I had to really jump through some hoops to get connectivity between the app and the SQLExpress database. I'm asking for any advice or constructive criticism on the steps I took, particularly in regards to whether it was unnecessary or exposed any security issues. Scenario: -- Four PCs (all XP Pro) in a workgroup configuration -- no server, connectivity is through a router. -- SQLExpress installed on one of the PCs with a server instance "PC1\SQLExpress". -- Database "AppDB" attached to "PC1\SQLExpress". -- A .Net application is installed on all workgroup PCs. The app works "as advertised" on the PC where there SQLExpress is installed, with connection string security set to SSPI. Could not get connection between the apps on the other PCs to "AppDB", sooooo ... On the SQLExpress PC: 1. Ensured firewall had ports 1433 and 1434 exposed. 2. Added ALL the local workgroup users and their passwords to the XP machine (PC1). 3. Used the SQL Surface Area Config tool. Set to allow Remote Connections over TCP/IP only. 4. Added "PC1\GUEST to SQLExpress Logins. On the downrange PCs, the app now reported, "Cannot open database "AppDB" requested by login." 5. On "PC1\SQLExpress instance, went to Security -> Logins - PC1\Guest\ -> Properties -> UserMapping and checked Map "AppDB" On the downrange PCs, the app now reported, "EXECUTE permission denied on "sel_Employees". So it appears that the user mapping WAS required. 6. On "AppDB", went to Security -> Users -> PC1\Guest -> Properties - Database Role Membership and set to db_owner. The application on all downrange PCs now connect and function as advertised! This sure strikes me as incredibly Rube Goldberg in order to get connection between local network apps and an SQLExpress database. It seems like a DBA would be required even for SQLExpress installs, which surely is not what Microsoft intended. What could I have done better or easier? |
![]() |
| Thread Tools | |
| Display Modes | |
| |