Re: Newbie to Replication Subscriptions

From: Brian Wells (BrianWells_at_discussions.microsoft.com)
Date: 01/13/05


Date: Thu, 13 Jan 2005 09:53:09 -0800

Hi Hillary,

Thanks again for your clarification of these issues. Because I'm new to
replication and also not a network-admin kinda guy, this is all very helpful.
To come full circle to my original question, I think your clarification
allows me to state it more specifically. For starters, please correct these
statements if something sounds confused or wrong:
1. I'm using a pull subscription, and the reason it failed at the outset is
because the localsystem account had no permissions to the network shares
(even though on the network share in question "Everyone" had full rights)
2. Network-admin/security concerns make it not too-well-liked if the network
share is on the C Drive, or visibly so, or something?

So my best way forward is to...
3. Fix the SQLAgent on the pull side so that it uses *any* login (but a
specific one, and not the default) which has been granted rights to the
share, and...
4. Post my snapshot updates on the Publisher side to a fixed folder, which I
share as necessary.

I'm confused as to how #4 is different than #2 if my specified share (per
#4) is still on the C Drive. Is it a question of "how" I share this specific
snapshot folder?

But my key question is #3 -- can my users just put their own logins into
SQLAgent and that will suffice? Many of them (I think) will have pretty
ordinary permissions, i.e. not Admin rights. What confuses me there is why
they'd get in that way but not with the localsystem account that is used by
default. That default account doesn't even qualify as a member of "Everyone"??

Thanks again *SO* much for your help.

Brian

(Correct these

"Hilary Cotter" wrote:

> I'm not talking about the SQL Server agent on the publisher rather the
> subscriber.
>
> It works this way.
>
> For push subscriptions the publisher connects with the snapshot share on the
> publisher reads the files and bcp's them to the subscriber (using odbcbcp).
> Authentication is done via the replication agent (replmerg or distrib). If
> you look at these exe's you will see that you can set the accounts, but if
> you are using NT authentication, the SQL Server agent (on the publisher)
> account's credentials are what are used to read the files.
>
> Normally it reads the default snapshot share which looks like this
> \\PublisherServerName\c$\Program Files\Microsoft SQL Server\MSSQL\ReplData.
>
> For push subscriptions the SQL Server agent on the subscriber does not
> factor into this at all.
>
> For pull subscriptions, the SQL Server agent account on the Subscriber is
> very important, as this time the account that the SQL Server agent on the
> subscriber is what connects to the snapshot share on the publisher, and this
> account must have rights to read the share. So a localsystem account on the
> subscriber won't work as it doesn't have rights to access network shares.
>
> Some dba's and network admins don't like all and sundry to be able to
> connect to their admin share (the c$ share), and so they change the default
> snapshot share on the subscriber to something else, like repldata which maps
> to \\PublisherServerName\c$\Program Files\Microsoft SQL
> Server\MSSQL\ReplData.
>
> Then they make sure that the SQL Server agent account on the subscriber has
> rights to access this share and the files and folders beneath it.
>
> Does this clear up your confusion? If not post back and someone will try to
> answer it more completely.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "Brian Wells" <BrianWells@discussions.microsoft.com> wrote in message
> news:1195F2EB-CC66-45D7-A533-85F2705786C0@microsoft.com...
> > Hello Hilary,
> >
> > Perhaps I didn't write clearly enough, or alternatively I'm confused as to
> > your reply. You seem to be talking about the SQL Server login on the
> > Publication side. I was referring to the SQLAgent service on the
> Subscriber
> > side, related to the issues "\\...unc...\.._1.sh' could not be propagated
> to
> > the subscriber." error or the "The process could not deliver the snapshot
> to
> > the Subscriber" error, both of which seem to be caused by a local system
> > account login for the Subscriber SQLAgent service. When I fixed the
> SQLAgent
> > to use an Administrator login, the synchronization process succeeded.
> >
> > Brian
> >
> > PS -- unrelated -- why do you recommend a different snapshot folder than
> the
> > default? I did try that out when I didn't know what was causing the errors
> > noted above, but it did not in the end make the difference, at least on
> this
> > testing network environment I'm working with.
> >
> > "Hilary Cotter" wrote:
> >
> > > You probably should be using either the ActiveX controls for this and
> hard
> > > coding it in, of you can use pull subscriptions and enter the account
> into
> > > the PAL on the publication. Ideally you would create a group and add
> these
> > > accounts to the group, and then add the group to the PAL.
> > >
> > > Chance are you will want an alternate snapshot folder other than
> > > \\PublisherServerName\C$\Program Files.... and make sure that this group
> has
> > > read rights to this share as well.
> > >
> > > --
> > > Hilary Cotter
> > > Looking for a SQL Server replication book?
> > > http://www.nwsu.com/0974973602.html
> > > "Brian Wells" <Brian Wells@discussions.microsoft.com> wrote in message
> > > news:1FD58FB9-31C9-400C-A997-042221C47BBF@microsoft.com...
> > > > Thanks so much for this thread. It helped me over a similar hump.
> > > Question --
> > > > as this rolls out to a number of MSDE subscribers, how do I ensure
> that
> > > their
> > > > SQLAgent logs in under the appropriate account. Can this be done by
> code
> > > and
> > > > if these are salesreps with login permissions that I'm not acquainted
> > > with,
> > > > what are the odds that by putting in their own login info under the
> "This
> > > > Account" option that they will have sufficient privileges to execute
> the
> > > jobs
> > > > successfully? Thanks again for any tips.
> > > >
> > > > Brian Wells
> > > >
> > > > "Will Gillen" wrote:
> > > >
> > > > > I think I figured it out.
> > > > > The SQLAgent on the subscribing Computer was set to run as "System".
> > > > > I created a local user, and made the SQLAgent run as that local
> user.
> > > > > Bulk Copying is being performed right now...
> > > > >
> > > > > :)
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > > "Jim Breffni" <JimBreffni@discussions.microsoft.com> wrote in
> message
> > > > > news:94B6B378-6FB3-4078-AABB-5845AAB99DAF@microsoft.com...
> > > > > > Are you replicating views that depend on other views? I have seen
> a
> > > > > similar
> > > > > > error in that case and had to exclude views from replication to
> cure
> > > the
> > > > > > problem.
> > > > > >
> > > > > > Jim.
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Will Gillen" wrote:
> > > > > >
> > > > > > > I'm setting up my first subscription, and I keep getting the
> > > following
> > > > > error
> > > > > > > on the subscriber:
> > > > > > >
> > > > > > > The schema script
> > > > > > >
> > > > >
> > >
> '\\MACHINENAME\ReplData$\unc\MACHINENAME_security_security\20041026153509\pe
> > > > > > > rson_1.sch' could not be propagated to the subscriber.
> > > > > > >
> > > > > > > Any ideas on where to begin troubleshooting.
> > > > > > >
> > > > > > > Thanks ahead for any help...
> > > > > > >
> > > > > > > I know I'm new, so not sure if I've even included enough
> information
> > > to
> > > > > help
> > > > > > > me yet....
> > > > > > >
> > > > > > > -- Will G.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>



Relevant Pages

  • Re: Browsing for Publication error message
    ... what is going on with the description you gave previously but I would guess that the subscriber SQL Server Agent service account was somehow added to the publication access list of the publication on the DMZ. ... select from the MSpublication_access table in the distribution database and see if the account for your Subscriber's SQL Server Agent service account shows up. ...
    (microsoft.public.sqlserver.replication)
  • Re: Distributor SQLSERVERAgent Account
    ... your subscriber's sql server agent should be running ... under the same account as the publisher's SQL Server agent, ... that is part of the local admin group on the publisher. ... If this is not possible the SQL Server agent account on the subscriber ...
    (microsoft.public.sqlserver.replication)
  • Re: Merge replication data loss
    ... general network error means your network hic cupped. ... Merge replication refreshes the data on the subscriber when you send the ... This could account for the data loss. ...
    (microsoft.public.sqlserver.replication)
  • Re: Distributor SQLSERVERAgent Account
    ... your subscriber's sql server agent should be ... > under the same account as the publisher's SQL Server agent, ... this is annonymous pull over VPN. ... since my subscriber SQL Server Agent is running under LocalSystem, ...
    (microsoft.public.sqlserver.replication)
  • Re: Trusted SQL Connections & NT AUTHORITYNETWORK SERVICE
    ... SYSTEM account in terms of the credentials it uses on the network. ... hitting a SQL Server on the same machine as the web app. ...
    (microsoft.public.dotnet.framework.aspnet.security)