Raymond Mak queried about the login account I used and suggested registering
the dll's.
I did this but to no avail. I was wondering if I could re-run the SP4
install using the SQL Server account and if I need to do anything first.
i.e. can I rerun it straight away on a server already with SP4?
As the agents work from the command line, I'm sure the problem is dll / DCom
related but I'm not sure how to trace this further.
Any suggestions would be appreciated.
Thanks!
Hi Daryl,
The most important thing to check first is whether the replication Interface
guids are improperly ACL'd w.r.t. to your SQL Server Agent account. If so,
you may need to un-register and then re-register the replication components
under a high privileged account just so the ACLs on the replication guids are
refreshed. You can, of course, manually update the ACLs also. However, I am
guessing that you want a cleaner approach so you are wondering if an SP4
reinstall will work. My take is that since we don't fully understand why the
problem happened in the first place, a reinstall may lead you to the same
problem with a slight risk of aggravating other parts of the system (well, I
am chicken
. As to why the ACLing problem happened in the first place, I dohave the following semi-educated guesses:
1) SP4 setup could not retrieve information for the SQL Server Agent service
account and so cannot add it to the ACLs of the replication component reg
keys. This may be a domain issue if SQL Server Agent service account is a
domain account or the account running SP4 setup simply doesn't have enough
privilege to enumerate the Agent service account information.
2) The SQL Server Agent service account was changed outside of Enterprise
Manager after SP4 install.
I can be completely wrong above but in any case, it would be tremendously
useful if you can let us know of anything unusual when you first set up SP4.
Thanks much.
-Raymond
"DJ" wrote:
> I posted a week or so ago about replication breaking after I installed SP4.
> Raymond Mak queried about the login account I used and suggested registering
> the dll's.
> I did this but to no avail. I was wondering if I could re-run the SP4
> install using the SQL Server account and if I need to do anything first.
> i.e. can I rerun it straight away on a server already with SP4?
> As the agents work from the command line, I'm sure the problem is dll / DCom
> related but I'm not sure how to trace this further.
> Any suggestions would be appreciated.
> Thanks!
>
>
|||Thanks for the reply Raymond
I'm guessing the problem was probably caused by running SP4 with an account
with lower permissions.
I will try unregistering the components with the service account but what is
the command / what do I un-register?
I'll let you know the outcome.
Many Thanks again
Daryl
"Raymond Mak [MSFT]" wrote:
[vbcol=seagreen]
> Hi Daryl,
> The most important thing to check first is whether the replication Interface
> guids are improperly ACL'd w.r.t. to your SQL Server Agent account. If so,
> you may need to un-register and then re-register the replication components
> under a high privileged account just so the ACLs on the replication guids are
> refreshed. You can, of course, manually update the ACLs also. However, I am
> guessing that you want a cleaner approach so you are wondering if an SP4
> reinstall will work. My take is that since we don't fully understand why the
> problem happened in the first place, a reinstall may lead you to the same
> problem with a slight risk of aggravating other parts of the system (well, I
> am chicken
. As to why the ACLing problem happened in the first place, I do> have the following semi-educated guesses:
> 1) SP4 setup could not retrieve information for the SQL Server Agent service
> account and so cannot add it to the ACLs of the replication component reg
> keys. This may be a domain issue if SQL Server Agent service account is a
> domain account or the account running SP4 setup simply doesn't have enough
> privilege to enumerate the Agent service account information.
> 2) The SQL Server Agent service account was changed outside of Enterprise
> Manager after SP4 install.
> I can be completely wrong above but in any case, it would be tremendously
> useful if you can let us know of anything unusual when you first set up SP4.
> Thanks much.
> -Raymond
> "DJ" wrote:
|||Hi Daryl,
For exe COM servers, you just need run the executable with the /UnRegServer
parameter followed by running it with the /RegServer parameter, e.g.
snapshot.exe /UnRegServer&snapshot.exe /RegServer. For dll COM components in
the 80\COM directory, you just need to run regsvr32 /u followed by regsvr32
on it, e.g. regsvr32 /u replagnt.dll®svr32 replagnt.dll.
-Raymond
"DJ" <DJ@.discussions.microsoft.com> wrote in message
news:FAA6361C-AB9E-468F-B998-212EB2EE18A9@.microsoft.com...[vbcol=seagreen]
> Thanks for the reply Raymond
> I'm guessing the problem was probably caused by running SP4 with an
> account
> with lower permissions.
> I will try unregistering the components with the service account but what
> is
> the command / what do I un-register?
> I'll let you know the outcome.
> Many Thanks again
> Daryl
> "Raymond Mak [MSFT]" wrote:
|||Hi Raymond
I un-registered and then re-registered them and then stopped and started the
agent (using the loacal admin account) but I still get the same error.
There was nothing unusual when I first ran SP4, although it did take ages.
I'm off home for today (in the UK) but any thoughts are appreciated as always.
Daryl
"Raymond Mak [MSFT]" wrote:
> Hi Daryl,
> For exe COM servers, you just need run the executable with the /UnRegServer
> parameter followed by running it with the /RegServer parameter, e.g.
> snapshot.exe /UnRegServer&snapshot.exe /RegServer. For dll COM components in
> the 80\COM directory, you just need to run regsvr32 /u followed by regsvr32
> on it, e.g. regsvr32 /u replagnt.dll®svr32 replagnt.dll.
> -Raymond
> "DJ" <DJ@.discussions.microsoft.com> wrote in message
> news:FAA6361C-AB9E-468F-B998-212EB2EE18A9@.microsoft.com...
>
>
|||I am pretty much out of ideas now... have you checked the ACLs on the
replication reg keys? Can you run, say, the snapshot agent from the command
line?
"DJ" <DJ@.discussions.microsoft.com> wrote in message
news:2A2307B3-DE6E-402E-A8C1-317B55D7FBF2@.microsoft.com...[vbcol=seagreen]
> Hi Raymond
> I un-registered and then re-registered them and then stopped and started
> the
> agent (using the loacal admin account) but I still get the same error.
> There was nothing unusual when I first ran SP4, although it did take ages.
> I'm off home for today (in the UK) but any thoughts are appreciated as
> always.
> Daryl
> "Raymond Mak [MSFT]" wrote:
|||Forgot to mention that you may want to try out regmon from
sysinternals.com...
-Raymond
"Raymond Mak [MSFT]" <rmak@.online.microsoft.com> wrote in message
news:ebwjbh93FHA.3628@.TK2MSFTNGP12.phx.gbl...
>I am pretty much out of ideas now... have you checked the ACLs on the
>replication reg keys? Can you run, say, the snapshot agent from the command
>line?
> "DJ" <DJ@.discussions.microsoft.com> wrote in message
> news:2A2307B3-DE6E-402E-A8C1-317B55D7FBF2@.microsoft.com...
>
|||Thanks for your help Raymond
I've run regmon and filemon the server and when I use the command line, all
processes have the '.exe' icon associated with them. When I run this via EM,
the same processes have a blue square and 'process not accessable'.
However when I compare the permissions at this level, nothing looks out of
place.
Can you confirm what the icons mean and if this does point to a permissions
error?
If I change the owner of the SQLAgent job, will this change who the job tuns
under or is it always the SQL Agent account?
Thanks again for all your help, I would not have known where to start!
Daryl
|||Hi Daryl,
First of all, I might have been on a completely wrong track here so you
should probably keep an open mind that what you are seeing may not be a
permission problem (although I can't really think of an alternative at the
moment). But in case this is indeed a permission problem, you should focus
your attention on SQL Server Agent through reg|filemon and see if it has
trouble accessing certain registry keys (for COM object creation) or files
(various replication COM components). It is actually a really good idea to
run SQL Server Agent temporarily under a high-privileged account (some admin
on the box) just so you can quickly tell whether this is a permission
problem or not. I will also encourage you to focus your troubleshooting
effort on just one agent, say, the snapshot agent which involved the
following components:
80\COM\snapshot.exe
80\COM\rinitcom.dll
80\COM\replagnt.dll
80\COM\Resources\1033\replres.rll
I am not sure if I mentioned this already but you should definitely start a
CMD window under your current SQL Server Agent account and experiment with
starting various agents from that window. This should hopefully a better
means to isolate what the problem is.
-Raymond
"DJ" <DJ@.discussions.microsoft.com> wrote in message
news:7F43DE84-E387-47B5-A735-5F5FD13A5585@.microsoft.com...
> Thanks for your help Raymond
> I've run regmon and filemon the server and when I use the command line,
> all
> processes have the '.exe' icon associated with them. When I run this via
> EM,
> the same processes have a blue square and 'process not accessable'.
> However when I compare the permissions at this level, nothing looks out of
> place.
> Can you confirm what the icons mean and if this does point to a
> permissions
> error?
> If I change the owner of the SQLAgent job, will this change who the job
> tuns
> under or is it always the SQL Agent account?
> Thanks again for all your help, I would not have known where to start!
> Daryl
>
