Problems with PULL on remote server

Hi Paul,
I am still having problems with the OS 53 error.
I done what you suggested by mapping a shared drive on the server to
'REPLDATA' and its still causing the same error.
Now I need to clarify a few things before I go any further.
1. The subscriber (SBS2000 Remote Server) has 'sa' as the login for the
Publisher and Distributor in the security tab. Is this right?
2. The distributor link password is the same password as 'sa'.
3. Under the publisher properties, the login name is 'sa'.
4. I created a windows login 'SQLUser' which has all admin rights which is
in the PAL and security,login areas of both servers all with identical
passords.
I'm confused to where you put the 'sa' user and the 'SQLUser' in the
numerous login boxs all over the replication process. This is probably the
reason i'm getting the errors below.
Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script
'\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' could not be propagated to the subscriber.
Category:AGENT
Source: CLIFTSERVER
Number: 0
Message: The process could not read file
'\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' due to OS error 53.
The schema script
'\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' could not be propagated to the subscriber. The step failed.
The job failed. The Job was invoked by Schedule 26 (Replication agent
schedule.). The last step to run was step 1 (Run agent.).
Please help as my boss is getting a bit upset with me coz i'm taking so long
to sort this out.
Many thanks
TIM
The use of sa as the login is for the database access. At the file level,
the access will be via the sql server agent's account on the subscriber. For
this, use a domain user account that has the correct rights on the
publisher. To make life easier, I often use the same account as the
publisher's sql server login.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Paul,
If I setup a PUSH from the distributor it works OK and there is NO
problems....
However, if I setup a PULL from the subsciber then it give the OS 53 error.
So what is causing the PULL to fail. Would it be that the login from the
agent (from the subsciber) is not trusted (but I knew this anyway) or is
there anything else I havent thought of?..
Many thanks
TIM
"Paul Ibison" wrote:

> The use of sa as the login is for the database access. At the file level,
> the access will be via the sql server agent's account on the subscriber. For
> this, use a domain user account that has the correct rights on the
> publisher. To make life easier, I often use the same account as the
> publisher's sql server login.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||This is not inconsistant with what I was suggesting. You'll need a
domain-user with rights on the share to run the SQL Server agent. On sql
server 2005 you can use a proxy for this instead. Alternatives on SQL Server
2000 are : FTP and nosync initializations.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||OS Error 53 basically suggests that the PULL agent on the subscriber is
unable to get the network path \\broadserver\repldata.
Your PUSH subscriptions work successfully because the PUSH agent run on the
distributor and the snapshot files are also located on the distributor.
Where as in case of PULL your agent runs on the subscriber (which in this
case is the SBS2000 Remote Server) and tries to connect to the network path
\\broadserver\repldata to get to the snapshot files.
So to correct the problem, Make sure that the account under which the PULL
agent is getting kicked off, which will most likely be the SQL Agent's
service startup account, can connect to the network path
\\broadserver\repldata and access any or all the sub-folders under it.
HTH
Emaniel
""confused"" wrote:

> Hi Paul,
> I am still having problems with the OS 53 error.
> I done what you suggested by mapping a shared drive on the server to
> 'REPLDATA' and its still causing the same error.
> Now I need to clarify a few things before I go any further.
> 1. The subscriber (SBS2000 Remote Server) has 'sa' as the login for the
> Publisher and Distributor in the security tab. Is this right?
> 2. The distributor link password is the same password as 'sa'.
> 3. Under the publisher properties, the login name is 'sa'.
> 4. I created a windows login 'SQLUser' which has all admin rights which is
> in the PAL and security,login areas of both servers all with identical
> passords.
> I'm confused to where you put the 'sa' user and the 'SQLUser' in the
> numerous login boxs all over the replication process. This is probably the
> reason i'm getting the errors below.
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147201001
> Message: The schema script
> '\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' could not be propagated to the subscriber.
> Category:AGENT
> Source: CLIFTSERVER
> Number: 0
> Message: The process could not read file
> '\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' due to OS error 53.
> The schema script
> '\\broadserver\repldata\unc\BROADSERVER_partner_pa rtner\20070110215231\snapshot.pre' could not be propagated to the subscriber. The step failed.
> The job failed. The Job was invoked by Schedule 26 (Replication agent
> schedule.). The last step to run was step 1 (Run agent.).
> Please help as my boss is getting a bit upset with me coz i'm taking so long
> to sort this out.
> Many thanks
> TIM
|||You can also copy the snapshot to the subscriber so a lot of the
authentication issues go away. Then just tell the subscription to get
the snapshot from a local folder.
Paul Ibison wrote:
> This is not inconsistant with what I was suggesting. You'll need a
> domain-user with rights on the share to run the SQL Server agent. On sql
> server 2005 you can use a proxy for this instead. Alternatives on SQL Server
> 2000 are : FTP and nosync initializations.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
|||Yes - thanks for pointing this out. This is indeed different to a "nosync
initialization" which is what I mentioned. In fact you have jogged my memory
as I used to move large snapshots around this way. If this route is chosen,
I'd create the snapshot, zip it up, transfer the file, unzip, restore then
use the "alternative snapshot location" setting.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Hi Paul,
I want to try the nosync way next but I really need to know if there is
something wrong with the setup i have at the moment.
The problem I've found now is that the subscirber agent simply wont accept
any other login other then 'sa'. I have tried admin, administrator, etc etc.
The reason it fails (assumes) is that 'sa' is not a windows domain account
and therefore doesnt have the rights to the snapshot folder hence the error.
But for the life of me I cannot get the PULL subsciber to login using any
other user login......
If I use any other login name it just gives me 'login user name failed'.
Is it because the windows on my subsciber is CLIFT\[user name] and the
distributor is BROAD\[user name]. Will the distributor detect the login name
has a different domain name and therefore does not accept it.
I dont know as I'm clutching at straws here but i'm sure its something to do
with that. The rights to the snapshot should be ok as I have mapped a drive
to the 'REPLDATA' directory and set it as 'H:' drive. The drive has FULL
admin rights given to Administrator, SQLUser (but not sa for obvious reasons).
Like I said before it works fine if I do a PUSH from the distributor as the
agent logs in locally so its got to be a auth problem regarding the login of
the agent...?
This is really cooking my brain now and all I want to do is sort it.
Any ideas
TIM
"Paul Ibison" wrote:

> Yes - thanks for pointing this out. This is indeed different to a "nosync
> initialization" which is what I mentioned. In fact you have jogged my memory
> as I used to move large snapshots around this way. If this route is chosen,
> I'd create the snapshot, zip it up, transfer the file, unzip, restore then
> use the "alternative snapshot location" setting.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||Please check out my previous responses. Access to the snapshot share is via
the sql server agent logon. Try setting that logon to be a domain user which
is an administrator on the publisher machine. This can be refined later on -
let's just get it working for now. This will only work if the domains are
trusted. If not, then have a look at doing a nosync initialization
(http://www.replicationanswers.com/NoSyncInitializations.asp) or FTP.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Hi,
I would recommend checking the owner of the SQL Agent replication job, as
the distributor_admin login may be owner and may not have access to share.
Phillip Cox
"Emaniel Chekelea" wrote:
[vbcol=seagreen]
> OS Error 53 basically suggests that the PULL agent on the subscriber is
> unable to get the network path \\broadserver\repldata.
> Your PUSH subscriptions work successfully because the PUSH agent run on the
> distributor and the snapshot files are also located on the distributor.
> Where as in case of PULL your agent runs on the subscriber (which in this
> case is the SBS2000 Remote Server) and tries to connect to the network path
> \\broadserver\repldata to get to the snapshot files.
> So to correct the problem, Make sure that the account under which the PULL
> agent is getting kicked off, which will most likely be the SQL Agent's
> service startup account, can connect to the network path
> \\broadserver\repldata and access any or all the sub-folders under it.
> HTH
> Emaniel
> ""confused"" wrote: