Annon Merge over VPN: WSM Insanity

I have my replication "working", though I would like to script as much
of the client installation as possible, and running into mega
headaches.
Here's the setup:
Client - MSDE
connects to Publisher/Distributor via VPN
annonymous pull subscription
I can install my MSDE, create the db, logins, etc.
1) Through EM, I can create the subscription through wizard. (selecting
"Available to Synch Manager", "Start immediately"). It works.
Syncronization Manager (type in passwords) synch works.
2) I script the subscription created in 1). Delete subscription and run
script with osql (doesn't run Merge Agent job automatically. Why not? I
even put in an extra line: EXEC sp_start_job @.job_name =
'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
Start Synchronizing. It works. WSM (type in passwords) synch works.
3). Delete subcription and recreate with same script as above. Go
straight to WSM. The subscription is in the list. Synch (type in
passwords). DOES NOT WORK!!! I get the error "the schema script <blah
blah blah> could not be propagated to the subscriber."
Why should I have to run the subscription once through EM before it
will work with WSM? I guess it has something to do with that Merge
Agent job and it needs to be fired off first?
Obviously EM will not be distributed to my end users in far off lands.
I want them to be able to run a script and then synch through WSM. What
is the best way to achieve this?
Much Thanks
answers in line.
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
<richerwin@.ubs-europe.org> wrote in message
news:1109180376.620053.87490@.o13g2000cwo.googlegro ups.com...
> I have my replication "working", though I would like to script as much
> of the client installation as possible, and running into mega
> headaches.
> Here's the setup:
> Client - MSDE
> connects to Publisher/Distributor via VPN
> annonymous pull subscription
> I can install my MSDE, create the db, logins, etc.
> 1) Through EM, I can create the subscription through wizard. (selecting
> "Available to Synch Manager", "Start immediately"). It works.
> Syncronization Manager (type in passwords) synch works.
I take it you are using SQL Authentication in WSM. If so your user will have
to enter the password each time WSM runs. You might want to use intergrated
authentication and enter the user account in the pal on the publisher.

> 2) I script the subscription created in 1). Delete subscription and run
> script with osql (doesn't run Merge Agent job automatically. Why not? I
> even put in an extra line: EXEC sp_start_job @.job_name =
> 'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
> Start Synchronizing. It works. WSM (type in passwords) synch works.
The merge agent doesn't start automatically because you have defined it to
start on demand.

> 3). Delete subcription and recreate with same script as above. Go
> straight to WSM. The subscription is in the list. Synch (type in
> passwords). DOES NOT WORK!!! I get the error "the schema script <blah
> blah blah> could not be propagated to the subscriber."
This means that the subscriber does not have rights to read the snapshot
share. You will have to craft a new snapshot share which does not use the
administrative share (ie \\servername\c$\Program Files\Microsoft SQL
Server\MSSQL\ReplData\UNC). Make sure this new snapshot share has read
permission for the accounts or a group which the merge users are in, and
that this group or user has rights to read the underlying files and folders.
> Why should I have to run the subscription once through EM before it
> will work with WSM? I guess it has something to do with that Merge
> Agent job and it needs to be fired off first?
This does sound odd. Perhaps it is a rights issue.
> Obviously EM will not be distributed to my end users in far off lands.
> I want them to be able to run a script and then synch through WSM. What
> is the best way to achieve this?
> Much Thanks
>
|||
> This does sound odd. Perhaps it is a rights issue.
I create my subscription. Local machine is RICH-VAIO,
Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
SQL Server is the default instance.
1) I run the following Win2000 DOS BATCH command:
"C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
[WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
[tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
-DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
[RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
-SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
-SubscriberPassword []
and get the following log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The subscription has been marked for reinitialization. Reinitialization
will occur the next time you synchronize this subscription.
The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:AGENT
Source: RICH-VAIO
Number: 0
Message: The process could not read file
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
due to OS error 1326.
Category:OS
Source:
Number: 1326
Message: Logon failure: unknown user name or bad password.
2) Immediately, I go to EM, right click on my subscription, and select
Start Synchronizing. The last entry in the log history is:
The job succeeded. The Job was invoked by User tmsuser. The last step
to run was step 1 (Run agent.).
3) Immediately, I run the same batch file as above. I get the following
log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
Uploading data changes to the Publisher
No data needed to be merged.
Downloading data changes to the Subscriber
4) Successive changes to the data at the subscriber are successfully
uploaded as in 3).
WHAT THE FREAK IS GOING ON WITH Merge Agent?
Please, please, please help. My kindom for a solution.
It must be noted I am not logged into Win2000 as tmsuser, though
tmsuser is a domain user under which SQLSERVER AGENT runs at the
subscriber, and tmsuser has full rights on the snapshot share at the
Publisher (as evident by the successful replications above).
|||just a wild thought here - why are you running the merge binary from the
command line?
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
<richerwin@.ubs-europe.org> wrote in message
news:1109221256.951320.175930@.f14g2000cwb.googlegr oups.com...
>
> I create my subscription. Local machine is RICH-VAIO,
> Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
> SQL Server is the default instance.
>
> 1) I run the following Win2000 DOS BATCH command:
> "C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
> [WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
> [tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
> -DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
> [RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
> -SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
> -SubscriberPassword []
> and get the following log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The subscription has been marked for reinitialization. Reinitialization
> will occur the next time you synchronize this subscription.
> The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147201001
> Message: The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:AGENT
> Source: RICH-VAIO
> Number: 0
> Message: The process could not read file
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> due to OS error 1326.
> Category:OS
> Source:
> Number: 1326
> Message: Logon failure: unknown user name or bad password.
> 2) Immediately, I go to EM, right click on my subscription, and select
> Start Synchronizing. The last entry in the log history is:
> The job succeeded. The Job was invoked by User tmsuser. The last step
> to run was step 1 (Run agent.).
> 3) Immediately, I run the same batch file as above. I get the following
> log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> Uploading data changes to the Publisher
> No data needed to be merged.
> Downloading data changes to the Subscriber
> 4) Successive changes to the data at the subscriber are successfully
> uploaded as in 3).
>
> WHAT THE FREAK IS GOING ON WITH Merge Agent?
> Please, please, please help. My kindom for a solution.
> It must be noted I am not logged into Win2000 as tmsuser, though
> tmsuser is a domain user under which SQLSERVER AGENT runs at the
> subscriber, and tmsuser has full rights on the snapshot share at the
> Publisher (as evident by the successful replications above).
>
|||
> why are you running the merge binary from the command line?
1) To show I'm getting the same results as from WSM.
2) So I can write the results to a log file with the >> redirect
command (so I can post them here) and show the group what I am doing.
3) End users won't have EM, so they need a way to start replication
(which isn't working from WSM, which is why I started this thread)
4) Proof of concept - it SHOULD work, shouldn't it?
thanks
|||[vbcol=seagreen]
This must have to do with accounts / permissions.
I have a couple of theories.
1) Why would executing the Merge agent job from within EM work, while
neither command-line nor WSM work? After all, I generated the
command-line args from the job from EM.
Is EM firing off the merge job under the same userID that I am when I
fire off the command line? (In the example above, both should be
'tmsuser'). How can I tell?
2) When I execute synchronize from WSM, do I have to be logged in to
Windows with the same domain ID that SQLSERVER AGENT (Windows service)
runs under?
Any help appreciated.
Thanks