Hi I'm trying to setup a push replication between 2 servers on different
networks. both machines can ping eachother using there machine names. I setup
the publication and the distributor on the push server and generate a
snapshot. I then run the distributor but it fails to connect to the
subscriber.
thanks for the help.
Mark
You need to ensure the @.@.servername of the subscriber is how the
publisher/distributor refer to it and vice versa. If you have to use IP
address, you can setup client side alias on the distributor that maps the IP
address to the @.@.servername of the subscriber
“This posting is provided "AS IS" with no warranties, and confers no rights.”
"ACDMark" wrote:
> Hi I'm trying to setup a push replication between 2 servers on different
> networks. both machines can ping eachother using there machine names. I setup
> the publication and the distributor on the push server and generate a
> snapshot. I then run the distributor but it fails to connect to the
> subscriber.
> thanks for the help.
> Mark
|||hi ,
be sure that your sql agent services is
running on a domain account
that has permission to your snapshot folder
and the database
thanks,
joey
"ACDMark" wrote:
> Hi I'm trying to setup a push replication between 2 servers on different
> networks. both machines can ping eachother using there machine names. I setup
> the publication and the distributor on the push server and generate a
> snapshot. I then run the distributor but it fails to connect to the
> subscriber.
> thanks for the help.
> Mark
Showing posts with label machines. Show all posts
Showing posts with label machines. Show all posts
Monday, March 26, 2012
Monday, March 12, 2012
Pull Merge replication between two SQL Server machines in different, but trusted domains
Hi,
We are attempting to setup Pull Merge replication between two SQL Server
(SQL 2K sp3a, Windows Authentication) machines in different domains. We have
been able to get Pull Merge replication to work within the same domain.
While we are running Win2k on both machines, two one way trusts were setup
between them. The server are linked to each other, but cannot initiate the
replication agents. The message we get is:
SQL Server Agent could not access the replication agent. Use the DCOMCNFG
utility to confirm that the SQL Server Agent Windows account has permissions
to launch the replication agent. The step failed.
I did not spot any in DCOMCNFG, but I am not familiar with it. Any
suggections?
Tia
Paul
Paul,
here is an MSDN article which shows how to enable the merge agent to be run
remotely:
http://msdn.microsoft.com/library/de...us/howtosql/ht
_replctem_6c1l.asp
HTH,
Paul Ibison
|||I have a feeling that the error message may be misleading me away from the
true problem. It appears that DCOMCNFG is used for running agents remotely.
I am looking at having the push replication run at the distributor and pull
replications to run at the subscriber. Besides, I couldn't get it to work by
using DCOMCNFG.
I want to have one merge publication which is pushed to subscribers which
will not be intentionally disconnected from the network. And, the same
publication pulled to subscribers which will be removed from the network for
possibly weeks. This currently works as long as long as all the servers are
in the same domain. The problem is that the pull subscribers will be in
different domains with trust relationship setup between them and the
distributor.
When I take the existing scripts that work when all of the server are in the
same domain and run them with the pull subscriber in different domains I get
the error:
SQL Server Agent could not access the replication agent. Use the DCOMCNFG
utility to confirm that the SQL Server Agent Windows account has permissions
to launch the replication agent. The step failed.
I don't think this has any thing to do with running the agent remotely, but
I'm not sure. Any suggestions?
Thanks
Paul
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uQmkhv7FEHA.744@.TK2MSFTNGP09.phx.gbl...
> Paul,
> here is an MSDN article which shows how to enable the merge agent to be
run
> remotely:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _replctem_6c1l.asp
> HTH,
> Paul Ibison
>
|||PaulW,
The easiest way to set up replication between different domains is to create a local user account on both the servers with the same username and password. Make the account an administrator of the local machine. Then set this account as the startup account
for the SQL Server Agent. Restart the SQL Server agent and start the merge agent. This should fix your problem.
Regards
Chris R
|||Thanks for the response. I saw that option for non-trusted domains and when
I presented it, the option was quickly shot down because the production
system will be administered by different companies and they didn't want to
be forced to share passwords..
Thanks,
Paul
"Chris R" <crichardson@.iir-central.com> wrote in message
news:7CE505D6-BE9C-40E4-80D4-75F7287AAB3C@.microsoft.com...
> PaulW,
> The easiest way to set up replication between different domains is to
create a local user account on both the servers with the same username and
password. Make the account an administrator of the local machine. Then set
this account as the startup account for the SQL Server Agent. Restart the
SQL Server agent and start the merge agent. This should fix your problem.
> Regards
> Chris R
|||Non-trusted domains can also be set up using the Guest account, but I would assume that this is even less likely to be allowed :-)
Regards,
Paul Ibison
|||I already know that the guest account has been disabled. There will be a two
way trust between the domains. I don't know how that got approved. There
must be some way to perform pull subscriptions in a trusted relationship
without matching accounts and passwords.
Paul
|||Paul,
I have used pass-through security, or the guest account, because of working
in a non-trusted environment but in your case you should be able to use
impersonation. Have a look at this article:
http://support.microsoft.com/?id=321822.
Regards,
Paul Ibison
|||I think I got it. We started having net work troubles once it appeared to be
working, so I'm not sure. The problem was that the SQL Server agent accounts
had the same name on both machines, but different passwords. Once I changed
the name of the account on one machine and gave it dbo access to the other
machine's database it looked like it was working. Most of the initial
snapshot was applied, but it failed due to the retry count. Before this
change, it never get started.
Thanks for the help.
Paul
We are attempting to setup Pull Merge replication between two SQL Server
(SQL 2K sp3a, Windows Authentication) machines in different domains. We have
been able to get Pull Merge replication to work within the same domain.
While we are running Win2k on both machines, two one way trusts were setup
between them. The server are linked to each other, but cannot initiate the
replication agents. The message we get is:
SQL Server Agent could not access the replication agent. Use the DCOMCNFG
utility to confirm that the SQL Server Agent Windows account has permissions
to launch the replication agent. The step failed.
I did not spot any in DCOMCNFG, but I am not familiar with it. Any
suggections?
Tia
Paul
Paul,
here is an MSDN article which shows how to enable the merge agent to be run
remotely:
http://msdn.microsoft.com/library/de...us/howtosql/ht
_replctem_6c1l.asp
HTH,
Paul Ibison
|||I have a feeling that the error message may be misleading me away from the
true problem. It appears that DCOMCNFG is used for running agents remotely.
I am looking at having the push replication run at the distributor and pull
replications to run at the subscriber. Besides, I couldn't get it to work by
using DCOMCNFG.
I want to have one merge publication which is pushed to subscribers which
will not be intentionally disconnected from the network. And, the same
publication pulled to subscribers which will be removed from the network for
possibly weeks. This currently works as long as long as all the servers are
in the same domain. The problem is that the pull subscribers will be in
different domains with trust relationship setup between them and the
distributor.
When I take the existing scripts that work when all of the server are in the
same domain and run them with the pull subscriber in different domains I get
the error:
SQL Server Agent could not access the replication agent. Use the DCOMCNFG
utility to confirm that the SQL Server Agent Windows account has permissions
to launch the replication agent. The step failed.
I don't think this has any thing to do with running the agent remotely, but
I'm not sure. Any suggestions?
Thanks
Paul
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uQmkhv7FEHA.744@.TK2MSFTNGP09.phx.gbl...
> Paul,
> here is an MSDN article which shows how to enable the merge agent to be
run
> remotely:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _replctem_6c1l.asp
> HTH,
> Paul Ibison
>
|||PaulW,
The easiest way to set up replication between different domains is to create a local user account on both the servers with the same username and password. Make the account an administrator of the local machine. Then set this account as the startup account
for the SQL Server Agent. Restart the SQL Server agent and start the merge agent. This should fix your problem.
Regards
Chris R
|||Thanks for the response. I saw that option for non-trusted domains and when
I presented it, the option was quickly shot down because the production
system will be administered by different companies and they didn't want to
be forced to share passwords..
Thanks,
Paul
"Chris R" <crichardson@.iir-central.com> wrote in message
news:7CE505D6-BE9C-40E4-80D4-75F7287AAB3C@.microsoft.com...
> PaulW,
> The easiest way to set up replication between different domains is to
create a local user account on both the servers with the same username and
password. Make the account an administrator of the local machine. Then set
this account as the startup account for the SQL Server Agent. Restart the
SQL Server agent and start the merge agent. This should fix your problem.
> Regards
> Chris R
|||Non-trusted domains can also be set up using the Guest account, but I would assume that this is even less likely to be allowed :-)
Regards,
Paul Ibison
|||I already know that the guest account has been disabled. There will be a two
way trust between the domains. I don't know how that got approved. There
must be some way to perform pull subscriptions in a trusted relationship
without matching accounts and passwords.
Paul
|||Paul,
I have used pass-through security, or the guest account, because of working
in a non-trusted environment but in your case you should be able to use
impersonation. Have a look at this article:
http://support.microsoft.com/?id=321822.
Regards,
Paul Ibison
|||I think I got it. We started having net work troubles once it appeared to be
working, so I'm not sure. The problem was that the SQL Server agent accounts
had the same name on both machines, but different passwords. Once I changed
the name of the account on one machine and gave it dbo access to the other
machine's database it looked like it was working. Most of the initial
snapshot was applied, but it failed due to the retry count. Before this
change, it never get started.
Thanks for the help.
Paul
Wednesday, March 7, 2012
Publisher unexpectedly drops merge pull subscription
Greetings.
I have several machines that have two merge pull subscriptions for two
databases. One subscription is set to continuous, the other
subscription is set to pull every hour. The publications are set to
drop subscribers if they don't synchronize within 14 days.
This has been in production for one week (we're well under the 14 day
threshold). The continuous subscription is working properly for
everybody. Today, after being off-line for a period of time, one of
the subscribers attempted to merge its hourly subscription, but the
publisher had dropped the subscription from the server and I ended up
with no subscription at the publisher and the following error on the
subscriber:
"The subscription to publication 'Obfuscated' has expired or does not
exist. The step failed."
We have provided a UI through which the user of the subscribing machine
can re-initialize the offending subscription so, we have a work-around.
Hopefully, we can find the cause.
Does any thoughts on why the publication would drop the subscription?
The only entry I can find in this group that seems to match this
straight up was in 1999 regarding a known issue SQL server 7 pre-SP1:
http://groups.google.com/group/microsoft.public.sqlserver.server/browse_thread/thread/1ffdc41526b24f82/e9b07619ecf86b2e?
Thanks,
KenJ
Make sure your history retention is the same as your retention period
otherwise your subscription will expire when the lesser of the history
retention or publication retention is exceeded.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"KenJ" <kenjohnson@.hotmail.com> wrote in message
news:1163198676.820694.304180@.e3g2000cwe.googlegro ups.com...
> Greetings.
> I have several machines that have two merge pull subscriptions for two
> databases. One subscription is set to continuous, the other
> subscription is set to pull every hour. The publications are set to
> drop subscribers if they don't synchronize within 14 days.
> This has been in production for one week (we're well under the 14 day
> threshold). The continuous subscription is working properly for
> everybody. Today, after being off-line for a period of time, one of
> the subscribers attempted to merge its hourly subscription, but the
> publisher had dropped the subscription from the server and I ended up
> with no subscription at the publisher and the following error on the
> subscriber:
> "The subscription to publication 'Obfuscated' has expired or does not
> exist. The step failed."
> We have provided a UI through which the user of the subscribing machine
> can re-initialize the offending subscription so, we have a work-around.
> Hopefully, we can find the cause.
> Does any thoughts on why the publication would drop the subscription?
> The only entry I can find in this group that seems to match this
> straight up was in 1999 regarding a known issue SQL server 7 pre-SP1:
> http://groups.google.com/group/microsoft.public.sqlserver.server/browse_thread/thread/1ffdc41526b24f82/e9b07619ecf86b2e?
>
> Thanks,
> KenJ
>
|||Thanks, Hilary.
We haven't seen one drop off since we made this change. It's a rather
interesting combination of settings.
KenJ
Hilary Cotter wrote:[vbcol=seagreen]
> Make sure your history retention is the same as your retention period
> otherwise your subscription will expire when the lesser of the history
> retention or publication retention is exceeded.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "KenJ" <kenjohnson@.hotmail.com> wrote in message
> news:1163198676.820694.304180@.e3g2000cwe.googlegro ups.com...
I have several machines that have two merge pull subscriptions for two
databases. One subscription is set to continuous, the other
subscription is set to pull every hour. The publications are set to
drop subscribers if they don't synchronize within 14 days.
This has been in production for one week (we're well under the 14 day
threshold). The continuous subscription is working properly for
everybody. Today, after being off-line for a period of time, one of
the subscribers attempted to merge its hourly subscription, but the
publisher had dropped the subscription from the server and I ended up
with no subscription at the publisher and the following error on the
subscriber:
"The subscription to publication 'Obfuscated' has expired or does not
exist. The step failed."
We have provided a UI through which the user of the subscribing machine
can re-initialize the offending subscription so, we have a work-around.
Hopefully, we can find the cause.
Does any thoughts on why the publication would drop the subscription?
The only entry I can find in this group that seems to match this
straight up was in 1999 regarding a known issue SQL server 7 pre-SP1:
http://groups.google.com/group/microsoft.public.sqlserver.server/browse_thread/thread/1ffdc41526b24f82/e9b07619ecf86b2e?
Thanks,
KenJ
Make sure your history retention is the same as your retention period
otherwise your subscription will expire when the lesser of the history
retention or publication retention is exceeded.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"KenJ" <kenjohnson@.hotmail.com> wrote in message
news:1163198676.820694.304180@.e3g2000cwe.googlegro ups.com...
> Greetings.
> I have several machines that have two merge pull subscriptions for two
> databases. One subscription is set to continuous, the other
> subscription is set to pull every hour. The publications are set to
> drop subscribers if they don't synchronize within 14 days.
> This has been in production for one week (we're well under the 14 day
> threshold). The continuous subscription is working properly for
> everybody. Today, after being off-line for a period of time, one of
> the subscribers attempted to merge its hourly subscription, but the
> publisher had dropped the subscription from the server and I ended up
> with no subscription at the publisher and the following error on the
> subscriber:
> "The subscription to publication 'Obfuscated' has expired or does not
> exist. The step failed."
> We have provided a UI through which the user of the subscribing machine
> can re-initialize the offending subscription so, we have a work-around.
> Hopefully, we can find the cause.
> Does any thoughts on why the publication would drop the subscription?
> The only entry I can find in this group that seems to match this
> straight up was in 1999 regarding a known issue SQL server 7 pre-SP1:
> http://groups.google.com/group/microsoft.public.sqlserver.server/browse_thread/thread/1ffdc41526b24f82/e9b07619ecf86b2e?
>
> Thanks,
> KenJ
>
|||Thanks, Hilary.
We haven't seen one drop off since we made this change. It's a rather
interesting combination of settings.
KenJ
Hilary Cotter wrote:[vbcol=seagreen]
> Make sure your history retention is the same as your retention period
> otherwise your subscription will expire when the lesser of the history
> retention or publication retention is exceeded.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "KenJ" <kenjohnson@.hotmail.com> wrote in message
> news:1163198676.820694.304180@.e3g2000cwe.googlegro ups.com...
Monday, February 20, 2012
PTSLite install failure "Target Language is not supported for upgrade"
i need to install the PTS 8.0 in some machines, and i got the message that the target language is not supported for upgrade, the machines that i want to upgrade have windows 2000 proffesional, office 2000, both programs in spanish ... i got sql server in spanish and english, and both said the same error ... does anyone know how to fix it?
thanx
Luis.Hi Luis,
I'm running into the same problem here, did you manage to solve it?
Regards,
Klaus
Originally posted by jlmc1612
i need to install the PTS 8.0 in some machines, and i got the message that the target language is not supported for upgrade, the machines that i want to upgrade have windows 2000 proffesional, office 2000, both programs in spanish ... i got sql server in spanish and english, and both said the same error ... does anyone know how to fix it?
thanx
Luis.
thanx
Luis.Hi Luis,
I'm running into the same problem here, did you manage to solve it?
Regards,
Klaus
Originally posted by jlmc1612
i need to install the PTS 8.0 in some machines, and i got the message that the target language is not supported for upgrade, the machines that i want to upgrade have windows 2000 proffesional, office 2000, both programs in spanish ... i got sql server in spanish and english, and both said the same error ... does anyone know how to fix it?
thanx
Luis.
PTS sp4 causes Distinct Count error
I have Analyisis Sevices service pack 3a. Office xp has been installed on the client machines and the server, which has installed PTS service pack 4. This has resulted in one of the calculated members showing as #1NF in Proclarity. It works perfectly well from client machines still running with PTS service pack 3. The calculated member in question uses a distinct count which is now always returning 0.
Does anyone have any suggestions? Thanks.
If the cube where it happens is a virtual cube - then it is a known regression in SP4 w.r.t. DistinctCount MDX function. There is a hotfix avaialable - please contact product support in order to obtain it.|||Hello,
Yes it is a virtual cube. Is the hotfix for Analysis services sp4? The server is still on Analysis services sp3a but PTS got upgraded when office xp was installed.
Thanks for your help.
|||Yes, the hotfix is on top of SP4 and should be applied to PTS.PTS sp4 causes Distinct Count error
I have Analyisis Sevices service pack 3a. Office xp has been installed on the client machines and the server, which has installed PTS service pack 4. This has resulted in one of the calculated members showing as #1NF in Proclarity. It works perfectly well from client machines still running with PTS service pack 3. The calculated member in question uses a distinct count which is now always returning 0.
Does anyone have any suggestions? Thanks.
If the cube where it happens is a virtual cube - then it is a known regression in SP4 w.r.t. DistinctCount MDX function. There is a hotfix avaialable - please contact product support in order to obtain it.|||Hello,
Yes it is a virtual cube. Is the hotfix for Analysis services sp4? The server is still on Analysis services sp3a but PTS got upgraded when office xp was installed.
Thanks for your help.
|||Yes, the hotfix is on top of SP4 and should be applied to PTS.
Subscribe to:
Posts (Atom)