Hi,
We are implementing ShaprePoint Application.
SharePoint installation is completed and the server is in the DMZ (behind the firewall). Name it as SERVER1
Also, we installed SQL Server database (SHAREPOINTSQL) on a server as second instance (we already had one database). Name it as SERVER2.
I could connect SHAREPOINTSQL from any client within the domain (not from DMZ).
When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTSQL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see de
fault database and connection fine.
Do I need to do any special setup to connect from SERVER1 to SERVER2\SHAREPOINTSQL ?
Hope I explained clearly
Thanks
Port 1433 was opened for firewall. As I said, I could connect SERVER1 to SERVER2 (default database) with out any problem.
Thanks,
Bob
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as second instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTSQL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHAREPOINTSQL ?
> Hope I explained clearly
> Thanks
|||Any update from Guru's. I am still having problem
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as second instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTSQL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHAREPOINTSQL ?
> Hope I explained clearly
> Thanks
|||I found some thing interesting. After opening all the ports, I could able to connect named instance even though named instance was using port 1434.
"Bob Robert" wrote:
[vbcol=seagreen]
> Any update from Guru's. I am still having problem
> "Bob Robert" wrote:
e default database and connection fine.[vbcol=seagreen]
|||Bob, to connect to instances of SQL there are more ports required, 1434 from memory, you'll find info on this on TechNet if you search under SQL.
Steven Collier
SharePoint Portal Server MVP
http://mvp.support.microsoft.com
"Bob Robert" wrote:
[vbcol=seagreen]
> I found some thing interesting. After opening all the ports, I could able to connect named instance even though named instance was using port 1434.
> "Bob Robert" wrote:
see default database and connection fine.[vbcol=seagreen]
|||Run "Server Network Utility" on the server machine (the one you cannot connect to, probably the
named instance), and check what port number it is using, Open for that port in the firewalls. Also,
You might want to fix the port number by typing ion the port number...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Robert" <BobRobert@.discussions.microsoft.com> wrote in message
news:955A498C-6CFA-46F1-B9A1-53075DA9AD42@.microsoft.com...
> I found some thing interesting. After opening all the ports, I could able to connect named
instance even though named instance was using port 1434.[vbcol=seagreen]
> "Bob Robert" wrote:
it as SERVER1[vbcol=seagreen]
already had one database). Name it as SERVER2.[vbcol=seagreen]
when I am in SQL Enterprise Manager. I was hoping to see two entries (one for default database as
SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see default database and connection fine.[vbcol=seagreen]
Showing posts with label implementing. Show all posts
Showing posts with label implementing. Show all posts
Wednesday, March 21, 2012
DMZ to SQL Server 2nd instance connection issue
Hi,
We are implementing ShaprePoint Application.
SharePoint installation is completed and the server is in the DMZ (behind th
e firewall). Name it as SERVER1
Also, we installed SQL Server database (SHAREPOINTSQL) on a server as second
instance (we already had one database). Name it as SERVER2.
I could connect SHAREPOINTSQL from any client within the domain (not from DM
Z).
When I try to connect same database from SERVER1 (in DMZ), I don't see SHARE
POINTSQL listing when I am in SQL Enterprise Manager. I was hoping to see tw
o entries (one for default database as SERVER2 and second one as SERVER2\SHA
REPOINTSQL). I could see de
fault database and connection fine.
Do I need to do any special setup to connect from SERVER1 to SERVER2\SHAREPO
INTSQL ?
Hope I explained clearly
ThanksPort 1433 was opened for firewall. As I said, I could connect SERVER1 to SER
VER2 (default database) with out any problem.
Thanks,
Bob
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind
the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as seco
nd instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from
DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTS
QL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one
for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could s
ee
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHARE
POINTSQL ?
> Hope I explained clearly
> Thanks|||Any update from Guru's. I am still having problem
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind
the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as seco
nd instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from
DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTS
QL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one
for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could s
ee
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHARE
POINTSQL ?
> Hope I explained clearly
> Thanks|||I found some thing interesting. After opening all the ports, I could able to
connect named instance even though named instance was using port 1434.
"Bob Robert" wrote:
[vbcol=seagreen]
> Any update from Guru's. I am still having problem
> "Bob Robert" wrote:
>
e default database and connection fine.[vbcol=seagreen]|||Bob, to connect to instances of SQL there are more ports required, 1434 from
memory, you'll find info on this on technet if you search under SQL.
Steven Collier
SharePoint Portal Server MVP
http://mvp.support.microsoft.com
"Bob Robert" wrote:
[vbcol=seagreen]
> I found some thing interesting. After opening all the ports, I could able
to connect named instance even though named instance was using port 1434.
> "Bob Robert" wrote:
>
see default database and connection fine.[vbcol=seagreen]|||Run "Server Network Utility" on the server machine (the one you cannot conne
ct to, probably the
named instance), and check what port number it is using, Open for that port
in the firewalls. Also,
You might want to fix the port number by typing ion the port number...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Robert" <BobRobert@.discussions.microsoft.com> wrote in message
news:955A498C-6CFA-46F1-B9A1-53075DA9AD42@.microsoft.com...
> I found some thing interesting. After opening all the ports, I could able to conne
ct named
instance even though named instance was using port 1434.[vbcol=seagreen]
> "Bob Robert" wrote:
>
it as SERVER1[vbcol=seagreen]
already had one database). Name it as SERVER2.[vbcol=seagreen]
when I am in SQL Enterprise Manager. I was hoping to see two entries (one fo
r default database as
SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see default database and connectio
n fine.[vbcol=seagreen]
We are implementing ShaprePoint Application.
SharePoint installation is completed and the server is in the DMZ (behind th
e firewall). Name it as SERVER1
Also, we installed SQL Server database (SHAREPOINTSQL) on a server as second
instance (we already had one database). Name it as SERVER2.
I could connect SHAREPOINTSQL from any client within the domain (not from DM
Z).
When I try to connect same database from SERVER1 (in DMZ), I don't see SHARE
POINTSQL listing when I am in SQL Enterprise Manager. I was hoping to see tw
o entries (one for default database as SERVER2 and second one as SERVER2\SHA
REPOINTSQL). I could see de
fault database and connection fine.
Do I need to do any special setup to connect from SERVER1 to SERVER2\SHAREPO
INTSQL ?
Hope I explained clearly
ThanksPort 1433 was opened for firewall. As I said, I could connect SERVER1 to SER
VER2 (default database) with out any problem.
Thanks,
Bob
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind
the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as seco
nd instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from
DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTS
QL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one
for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could s
ee
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHARE
POINTSQL ?
> Hope I explained clearly
> Thanks|||Any update from Guru's. I am still having problem
"Bob Robert" wrote:
> Hi,
> We are implementing ShaprePoint Application.
> SharePoint installation is completed and the server is in the DMZ (behind
the firewall). Name it as SERVER1
> Also, we installed SQL Server database (SHAREPOINTSQL) on a server as seco
nd instance (we already had one database). Name it as SERVER2.
> I could connect SHAREPOINTSQL from any client within the domain (not from
DMZ).
> When I try to connect same database from SERVER1 (in DMZ), I don't see SHAREPOINTS
QL listing when I am in SQL Enterprise Manager. I was hoping to see two entries (one
for default database as SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could s
ee
default database and connection fine.
> Do I need to do any special setup to connect from SERVER1 to SERVER2\SHARE
POINTSQL ?
> Hope I explained clearly
> Thanks|||I found some thing interesting. After opening all the ports, I could able to
connect named instance even though named instance was using port 1434.
"Bob Robert" wrote:
[vbcol=seagreen]
> Any update from Guru's. I am still having problem
> "Bob Robert" wrote:
>
e default database and connection fine.[vbcol=seagreen]|||Bob, to connect to instances of SQL there are more ports required, 1434 from
memory, you'll find info on this on technet if you search under SQL.
Steven Collier
SharePoint Portal Server MVP
http://mvp.support.microsoft.com
"Bob Robert" wrote:
[vbcol=seagreen]
> I found some thing interesting. After opening all the ports, I could able
to connect named instance even though named instance was using port 1434.
> "Bob Robert" wrote:
>
see default database and connection fine.[vbcol=seagreen]|||Run "Server Network Utility" on the server machine (the one you cannot conne
ct to, probably the
named instance), and check what port number it is using, Open for that port
in the firewalls. Also,
You might want to fix the port number by typing ion the port number...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Robert" <BobRobert@.discussions.microsoft.com> wrote in message
news:955A498C-6CFA-46F1-B9A1-53075DA9AD42@.microsoft.com...
> I found some thing interesting. After opening all the ports, I could able to conne
ct named
instance even though named instance was using port 1434.[vbcol=seagreen]
> "Bob Robert" wrote:
>
it as SERVER1[vbcol=seagreen]
already had one database). Name it as SERVER2.[vbcol=seagreen]
when I am in SQL Enterprise Manager. I was hoping to see two entries (one fo
r default database as
SERVER2 and second one as SERVER2\SHAREPOINTSQL). I could see default database and connectio
n fine.[vbcol=seagreen]
Tuesday, February 14, 2012
Distributed transaction aborted by MSDTC
hi,
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?
If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?
If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
Distributed transaction aborted by MSDTC
hi,
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
Distributed transaction aborted by MSDTC
hi,
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
i'm implementing a distributed database(partitioned view) system using 3
linked MSSQL 2000 server(SP3),
when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN, I
get the error "Distributed transaction aborted by MSDTC", or sometime
"Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction."
the http://support.microsoft.com/?kbid=834849 says this only happened if one
of the linked server is MSSQL Server 7.0, but all my servers are 2000 Server
with SP3, so can somebody help to resolve this?If you are running Windows XP or Windows Server 2003 you can use DTC tracing
to find out why the transaction aborts, otherwise you can use SQL Profiler
and include the DTC transaction event class.
Do you have a trigger on one of the tables that is involved in the
transaction?
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"eugeneng" <eugeneng@.discussions.microsoft.com> wrote in message
news:C4FC5E8E-B128-459D-9914-78B8CE2AD795@.microsoft.com...
> hi,
> i'm implementing a distributed database(partitioned view) system using 3
> linked MSSQL 2000 server(SP3),
> when I try update the distributed table within a BEGIN TRAN & COMMIT TRAN,
> I
> get the error "Distributed transaction aborted by MSDTC", or sometime
> "Distributed transaction completed. Either enlist this session in a new
> transaction or the NULL transaction."
> the http://support.microsoft.com/?kbid=834849 says this only happened if
> one
> of the linked server is MSSQL Server 7.0, but all my servers are 2000
> Server
> with SP3, so can somebody help to resolve this?
>
>
Subscribe to:
Posts (Atom)