DMZ to SQL on ISA server

The problem I have is that ISA Server cant listen for
requests on port 1433 as SQL Server which is running on
the same machine has binded to port 1433 on both the
internal and external IP address.
what i need is a way to stop SQL Server from binding to
the external IP so i can setup ISA to do so
Hi Fabian,
There's isn't a way to limit the binding for SQL unfortunately. Your
only options are:
1. Put SQL on another machine & use Server Publishing. SQL could be on the
internal network and not in the DMZ as well.
2. Create a packet filter.
Option 1, would be preferable.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

DMZ to SQL on ISA server

The problem I have is that ISA Server cant listen for
requests on port 1433 as SQL Server which is running on
the same machine has binded to port 1433 on both the
internal and external IP address.
what i need is a way to stop SQL Server from binding to
the external IP so i can setup ISA to do soHi Fabian,
There's isn't a way to limit the binding for SQL unfortunately. Your
only options are:
1. Put SQL on another machine & use Server Publishing. SQL could be on the
internal network and not in the DMZ as well.
2. Create a packet filter.
Option 1, would be preferable.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.sql

distributor_admin problem when configuring replication 18483

I have read many of the postings on the 18483 error, but I must be
missing something because I can't get it to work and I have been trying
for days. I have also read about this topic in BOL which says the same
thing as the postings.
Local replication has been working for almost a year, but I ran into
problems when I wanted to add a remote site to the process. I
therefore decided to disable replication and reenable it to both sites.
I decided to get it working properly to the local server and felt that
I could then setup it up for the remote.
The problem that I am having is the old 'Error 18483
'distributor_admin' is not setup for remote access. I don't understand
why I am receiving this error since I just disabled replication and
immediately tried to reenable it. (NOTE: I have changed the alias
names for easier recognition since the original setup, although I still
point to the ip addesses of the boxes both local and remote.) I have
since read a posting which suggest to alias to the computer name which
I have done.
BOL says that I need to add 'distributor_admin' as a remote login even
though the publisher and the distributor are the same box. I have run
the 'sp_addremotelogin' stored procedure with several permutations i.e.
Local and Remote user 'distributor_admin', Local user
'distributor_admin' Remote user an admin account on the server and vice
versa. If I use 'distributor_admin' as both the Local and Remote user
I still received the 18483 error. When I used 'distributor_admin' as
Local and an admin account for remote, I receive an error that I am
using the wrong password. I know the password of the admin account
because it is mine. I have also set the 'distributor_admin' account
password to match mine via the 'sp_changedistributor_password' stored
procedure. The same happens if 'distributor_admin' is remote and an
admin account is local.
Does anyone have an idea of what I am missing?
Are you running SQL 2000? If so, I think you have misread BOL. BOL states
"The connection between a Publisher and a remote Distributor is a hybrid of
a linked server and remote server. The connection uses the login
distributor_admin. At the remote Distributor, the Publisher can be
configured to be either trusted (no password is required for the
distributor_admin login) or non-trusted (a password is required). It is
recommended that you use a non-trusted connection for the Publisher
connection to the Distributor, requiring a distributor_admin password."
They are referring to the Administrative Link password here - not the
distributor_admin account.
If I were you I would disable replication, if the distributor_admin account
remains, delete it, if repl_distributor remails as a remote server, delete
it.
Then try to enable replication again.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<pw@.indii.com> wrote in message
news:1108397908.962930.70700@.g14g2000cwa.googlegro ups.com...
> I have read many of the postings on the 18483 error, but I must be
> missing something because I can't get it to work and I have been trying
> for days. I have also read about this topic in BOL which says the same
> thing as the postings.
> Local replication has been working for almost a year, but I ran into
> problems when I wanted to add a remote site to the process. I
> therefore decided to disable replication and reenable it to both sites.
> I decided to get it working properly to the local server and felt that
> I could then setup it up for the remote.
> The problem that I am having is the old 'Error 18483
> 'distributor_admin' is not setup for remote access. I don't understand
> why I am receiving this error since I just disabled replication and
> immediately tried to reenable it. (NOTE: I have changed the alias
> names for easier recognition since the original setup, although I still
> point to the ip addesses of the boxes both local and remote.) I have
> since read a posting which suggest to alias to the computer name which
> I have done.
> BOL says that I need to add 'distributor_admin' as a remote login even
> though the publisher and the distributor are the same box. I have run
> the 'sp_addremotelogin' stored procedure with several permutations i.e.
> Local and Remote user 'distributor_admin', Local user
> 'distributor_admin' Remote user an admin account on the server and vice
> versa. If I use 'distributor_admin' as both the Local and Remote user
> I still received the 18483 error. When I used 'distributor_admin' as
> Local and an admin account for remote, I receive an error that I am
> using the wrong password. I know the password of the admin account
> because it is mine. I have also set the 'distributor_admin' account
> password to match mine via the 'sp_changedistributor_password' stored
> procedure. The same happens if 'distributor_admin' is remote and an
> admin account is local.
> Does anyone have an idea of what I am missing?
>
|||Hilary,
Thanks for your response it was very helpful. Also I did read the BOL
about linked servers, but with my limited knowledge I didn't understand
it the way that a more experienced person might. I was going to delete
the linked server and recreate it, but I didn't know what the affect
would be on my production environment.
I followed your advice and deleted the distributor_admin login and the
repl_distributor remote server. I also ran sp_removedbreplication and
then tried to reestablish it. I again got the 18483 remote login
error. DO I NEED TO RESTART THE SERVICE IN ORDER FOR MY CHANGES TO
FULLY TAKE AFFECT?
Thanks,
Peter
|||I re-read BOL, and it is confusing. Now I am not sure if they were referring
to the administrative link password after all. I am going to try to research
this.
I would try the restart - but I am not sure if this is going to fix it.
Someone in the past had similar problems to you and he/she deleted this
account, and then recreated it as a standard SQL Server login, assigned it a
password and then put it in the System Administrator group. It worked for
them. I tried this myself and it also worked.
You might want to try this as a last resort. I would advise you to call PSS
for their help on this one.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<pw@.indii.com> wrote in message
news:1108477637.970068.101100@.o13g2000cwo.googlegr oups.com...
> Hilary,
> Thanks for your response it was very helpful. Also I did read the BOL
> about linked servers, but with my limited knowledge I didn't understand
> it the way that a more experienced person might. I was going to delete
> the linked server and recreate it, but I didn't know what the affect
> would be on my production environment.
> I followed your advice and deleted the distributor_admin login and the
> repl_distributor remote server. I also ran sp_removedbreplication and
> then tried to reestablish it. I again got the 18483 remote login
> error. DO I NEED TO RESTART THE SERVICE IN ORDER FOR MY CHANGES TO
> FULLY TAKE AFFECT?
> Thanks,
> Peter
>
|||Hilary,
I appreciate your comments about BOL. With my limited experience I
felt that I was chasing my tail.
Also I did restart the SQL Server service which cleared up some
problems, but in the end I received the imfamous 'Error 18483'. I will
try your suggestion and manually delete and recreate the
'distributor_admin' login and add it to the SA group.
I will let you know if this works.
Peter
|||Peter,
Yo tena el mismo problema...
Solucin:
http://support.microsoft.com/default...b;en-us;818334
y exec sp_helpserver
Recuerdos
<pw@.indii.com> escribi en el mensaje
news:1108560299.305220.159700@.l41g2000cwc.googlegr oups.com...
> Hilary,
> I appreciate your comments about BOL. With my limited experience I
> felt that I was chasing my tail.
> Also I did restart the SQL Server service which cleared up some
> problems, but in the end I received the imfamous 'Error 18483'. I will
> try your suggestion and manually delete and recreate the
> 'distributor_admin' login and add it to the SA group.
> I will let you know if this works.
> Peter
>
|||Hilary,
I am sorry that I missed you at the last NYC SQL Server User Group
meeting. I just became a member.
On another note, I would like to tell you the outcome of my problem. I
was having problems with my replication setup and decided to redue it.
Lucky for me that I made a copy of the original replication script.
All of the attempts described in this posting didn't work for me, but I
learned a lot about Transact-SQL and using stored procedures. As a
last resort, I edit the oringinal script and managed to get replication
setup again. It took me a few iterations, but it worked.
I don't know why I could setup replication via Enterprise Manager, but
I wanted to let you know this because you assist many people.
Thanks.

Distribution database gone but now can't get rid of publications

I have been messing around with Replication on MS Virtual Server.
Set up a Distributor on a seperate machine from the publication
database.
For some reason unkown my Distribution database went in Suspect Mode.
Finally got rid of it using
sp_dropdistributiondb @.database = 'distribution'
Now I can't get delete any of my publications.
They still look towards my Distribution database which is no longer a
distributor
tried
exec sp_dropsubscription
@.publication='AdventureWorksCentralPublication',@.a rticle='all',@.subscriber='all',
@.ignore_distributor=1
sp_removedbreplication
SHould I just re-set up my Distributor again and leave the
publications? Would that even work?
THere has to be some way to delete my publications
Thanks
Mike
Did you run sp_removedbreplication on the publisher and subscribers also? If
so, and you have removed the distribution database then perhaps you are just
seing residual data from tempdb which is reported in the replication monitor.
try refreshing the replication monitor (sp_MSload_replication_status) to see
if this removes the reference.
Paul Ibison
|||Did you follow the steps outlined here?
http://support.microsoft.com/kb/324401
"jughead" <mike.aarset@.gmail.com> wrote in message
news:1176965268.535472.269400@.b58g2000hsg.googlegr oups.com...
>I have been messing around with Replication on MS Virtual Server.
> Set up a Distributor on a seperate machine from the publication
> database.
> For some reason unkown my Distribution database went in Suspect Mode.
> Finally got rid of it using
> sp_dropdistributiondb @.database = 'distribution'
> Now I can't get delete any of my publications.
> They still look towards my Distribution database which is no longer a
> distributor
> tried
> exec sp_dropsubscription
> @.publication='AdventureWorksCentralPublication',@.a rticle='all',@.subscriber='all',
> @.ignore_distributor=1
> sp_removedbreplication
> SHould I just re-set up my Distributor again and leave the
> publications? Would that even work?
> THere has to be some way to delete my publications
> Thanks
> Mike
>

Distributed transaction with clustering server

I can't perform a distributed transaction between a remote
server to the central server.
I have 3 sql server 2000 enterprise edition. 2 of them are
installed on win2K server (LOCAL1, LOCAL2) and the other
(CENTRAL_SQL) is installed on clustering win2K server.
None of them is in domain.
Linked servers are defined well between them and I can
perform select statement from any server to any other
server.
I can also perform a distributed transaction between the
remote servers, from LOCAL1 to LOCAL2 and contrarily:
set xact_abort on
begin distributed tran
select count(*) from
LOCAL1.tempdb.INFORMATION_SCHEMA.TABLES
commit
set xact_abort off
MSDTC service starts up with local system account or other
administrators belonging account.
I can also ping the local servers from the central and
even manage them using the Active Directory.
When I perform a distributed transaction between a remote
server (LOCAL1 or LOCAL2) and the central server I get an
error:
Server: Msg 7391, Level 16, State 1, Line 5
The operation could not be performed because the OLE DB
provider 'SQLOLEDB' was unable to begin a distributed
transaction.
[OLE/DB provider returned message: New transaction cannot
enlist in the specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
What am I doing wrong?
Thanks,
Yuval Peleg
DBA, Nice Systems
Look for the following entry in the SQL Server errorlog:
Attempting to initialize Distributed Transaction Coordinator.
Is there an error after it?
If so, have you run comclust on both nodes of the cluster to make MSDTC
cluster aware?
I not run it on both nodes and then take SQL Server off line and back on
line. Then try your query.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||There is a masage before it:
"Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner
Blocks."
I run comclust on both nodes.
Thanks,
Yuval Peleg
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!