Friday, March 23, 2012
Job ownership problem
I have scheduled some jobs in SQL Server Agent to run some DTS packages. The
original owner of these jobs is "sa". However, when I changed to the owner to
be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" has
the "db_owner" role. The owner of DTS packages is "Domain\Administrator" and
I logon the Windows server as local Administrator. I am not sure if there is
any problem on this. Can anyone advise? Thanks.
Ivan
If the job is owned by sa or a login that is a member of the
sysadmins server role, then the job executes under the
security context of the SQL Server Agent service account. If
the job is owned by a login that is not a member of the
sysadmins server role, then the job is executed under the
security context of the proxy account.
And then...the default setting for SQL Agent is that
non-sysadmins cannot execute CmdExec or ActiveX scripting
jobs. Scheduling a package is done by executing a CmdExec
step in the job.
That the basics of it and why you are having problems with
your job. You can find more information in the following
article:
INF: How to Run a DTS Package as a Scheduled Job
http://support.microsoft.com/?id=269074
-Sue
On Mon, 31 Oct 2005 20:34:02 -0800, "Ivan"
<Ivan@.discussions.microsoft.com> wrote:
>Dear all,
>I have scheduled some jobs in SQL Server Agent to run some DTS packages. The
>original owner of these jobs is "sa". However, when I changed to the owner to
>be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" has
>the "db_owner" role. The owner of DTS packages is "Domain\Administrator" and
>I logon the Windows server as local Administrator. I am not sure if there is
>any problem on this. Can anyone advise? Thanks.
>Ivan
sql
Job ownership problem
I have scheduled some jobs in SQL Server Agent to run some DTS packages. The
original owner of these jobs is "sa". However, when I changed to the owner t
o
be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" ha
s
the "db_owner" role. The owner of DTS packages is "Domain\Administrator" and
I logon the Windows server as local Administrator. I am not sure if there is
any problem on this. Can anyone advise? Thanks.
IvanIf the job is owned by sa or a login that is a member of the
sysadmins server role, then the job executes under the
security context of the SQL Server Agent service account. If
the job is owned by a login that is not a member of the
sysadmins server role, then the job is executed under the
security context of the proxy account.
And then...the default setting for SQL Agent is that
non-sysadmins cannot execute CmdExec or ActiveX scripting
jobs. Scheduling a package is done by executing a CmdExec
step in the job.
That the basics of it and why you are having problems with
your job. You can find more information in the following
article:
INF: How to Run a DTS Package as a Scheduled Job
http://support.microsoft.com/?id=269074
-Sue
On Mon, 31 Oct 2005 20:34:02 -0800, "Ivan"
<Ivan@.discussions.microsoft.com> wrote:
>Dear all,
>I have scheduled some jobs in SQL Server Agent to run some DTS packages. Th
e
>original owner of these jobs is "sa". However, when I changed to the owner
to
>be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" h
as
>the "db_owner" role. The owner of DTS packages is "Domain\Administrator" an
d
>I logon the Windows server as local Administrator. I am not sure if there i
s
>any problem on this. Can anyone advise? Thanks.
>Ivan
Wednesday, March 21, 2012
Job ownership problem
I have scheduled some jobs in SQL Server Agent to run some DTS packages. The
original owner of these jobs is "sa". However, when I changed to the owner to
be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" has
the "db_owner" role. The owner of DTS packages is "Domain\Administrator" and
I logon the Windows server as local Administrator. I am not sure if there is
any problem on this. Can anyone advise? Thanks.
IvanIf the job is owned by sa or a login that is a member of the
sysadmins server role, then the job executes under the
security context of the SQL Server Agent service account. If
the job is owned by a login that is not a member of the
sysadmins server role, then the job is executed under the
security context of the proxy account.
And then...the default setting for SQL Agent is that
non-sysadmins cannot execute CmdExec or ActiveX scripting
jobs. Scheduling a package is done by executing a CmdExec
step in the job.
That the basics of it and why you are having problems with
your job. You can find more information in the following
article:
INF: How to Run a DTS Package as a Scheduled Job
http://support.microsoft.com/?id=269074
-Sue
On Mon, 31 Oct 2005 20:34:02 -0800, "Ivan"
<Ivan@.discussions.microsoft.com> wrote:
>Dear all,
>I have scheduled some jobs in SQL Server Agent to run some DTS packages. The
>original owner of these jobs is "sa". However, when I changed to the owner to
>be another SQL login id, e.g. myUser, the scheduled jobs failed. "myUser" has
>the "db_owner" role. The owner of DTS packages is "Domain\Administrator" and
>I logon the Windows server as local Administrator. I am not sure if there is
>any problem on this. Can anyone advise? Thanks.
>Ivan
Job not running as owner
I've got a job on one server, owner 'sa'. It runs fine. I created the
same job on another server, still with owner 'sa', and it fails. When I
view the history, it fails because it's running as a different user,
one without the necessary rights. On the server that it works on, the
job is being run as the correct user, 'sa'.
In the step, under advanced, 'Run as user:' is set to '(self)', just as
it is in the server that works.
Help! I cannot see any difference between the jobs on the 2 servers,
and I can't think of any reason why it's trying to execute the job as a
user other than the owner.
Hi,
Have a look into the SQL Agent startup account. See if it have necessary
rights.
Thanks
Hari
SQL Server MVP
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegr oups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>
|||Check *both* the job as a whole and each jobstep. Job should be owned by "sa" and job step should be
<self>. Double and triple check.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegr oups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>
|||Hi. The SQL Server Agent startup account is the same on both servers.
However server1 is running the job as sa, and server2 is running the
job as the SQL Server Agent startup account. Strange.
I've double, triple, quadruple checked that the job in question is set
to owner sa and the step is set to self.
Other jobs on the server are also running as the non-sa account, but
this one is the only one that's failing, because it's running through a
linked server. As a work around I've built a DTS package that runs the
task, and then scheduled that DTS package, but I'd really like to
understand why this server is running jobs under the non-sa account.
|||I'm not sure whether you are talking about TSQL or CmdExec job step. However, two things to check:
1 EM, Agent, right-click, properties, right-most tab. Check how agent log on to SQL Server.
2 Security mode for each SQL Server (Windows only or mixed).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129115237.379149.269800@.g43g2000cwa.googlegr oups.com...
> Hi. The SQL Server Agent startup account is the same on both servers.
> However server1 is running the job as sa, and server2 is running the
> job as the SQL Server Agent startup account. Strange.
> I've double, triple, quadruple checked that the job in question is set
> to owner sa and the step is set to self.
> Other jobs on the server are also running as the non-sa account, but
> this one is the only one that's failing, because it's running through a
> linked server. As a work around I've built a DTS package that runs the
> task, and then scheduled that DTS package, but I'd really like to
> understand why this server is running jobs under the non-sa account.
>
sql
Job not running as owner
I've got a job on one server, owner 'sa'. It runs fine. I created the
same job on another server, still with owner 'sa', and it fails. When I
view the history, it fails because it's running as a different user,
one without the necessary rights. On the server that it works on, the
job is being run as the correct user, 'sa'.
In the step, under advanced, 'Run as user:' is set to '(self)', just as
it is in the server that works.
Help! I cannot see any difference between the jobs on the 2 servers,
and I can't think of any reason why it's trying to execute the job as a
user other than the owner.Hi,
Have a look into the SQL Agent startup account. See if it have necessary
rights.
Thanks
Hari
SQL Server MVP
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegroups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>|||Check *both* the job as a whole and each jobstep. Job should be owned by "sa
" and job step should be
<self>. Double and triple check.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegroups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>|||Hi. The SQL Server Agent startup account is the same on both servers.
However server1 is running the job as sa, and server2 is running the
job as the SQL Server Agent startup account. Strange.
I've double, triple, quadruple checked that the job in question is set
to owner sa and the step is set to self.
Other jobs on the server are also running as the non-sa account, but
this one is the only one that's failing, because it's running through a
linked server. As a work around I've built a DTS package that runs the
task, and then scheduled that DTS package, but I'd really like to
understand why this server is running jobs under the non-sa account.|||I'm not sure whether you are talking about TSQL or CmdExec job step. However
, two things to check:
1 EM, Agent, right-click, properties, right-most tab. Check how agent log on
to SQL Server.
2 Security mode for each SQL Server (Windows only or mixed).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129115237.379149.269800@.g43g2000cwa.googlegroups.com...
> Hi. The SQL Server Agent startup account is the same on both servers.
> However server1 is running the job as sa, and server2 is running the
> job as the SQL Server Agent startup account. Strange.
> I've double, triple, quadruple checked that the job in question is set
> to owner sa and the step is set to self.
> Other jobs on the server are also running as the non-sa account, but
> this one is the only one that's failing, because it's running through a
> linked server. As a work around I've built a DTS package that runs the
> task, and then scheduled that DTS package, but I'd really like to
> understand why this server is running jobs under the non-sa account.
>
Job not running as owner
I've got a job on one server, owner 'sa'. It runs fine. I created the
same job on another server, still with owner 'sa', and it fails. When I
view the history, it fails because it's running as a different user,
one without the necessary rights. On the server that it works on, the
job is being run as the correct user, 'sa'.
In the step, under advanced, 'Run as user:' is set to '(self)', just as
it is in the server that works.
Help! I cannot see any difference between the jobs on the 2 servers,
and I can't think of any reason why it's trying to execute the job as a
user other than the owner.Hi,
Have a look into the SQL Agent startup account. See if it have necessary
rights.
Thanks
Hari
SQL Server MVP
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegroups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>|||Check *both* the job as a whole and each jobstep. Job should be owned by "sa" and job step should be
<self>. Double and triple check.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129111265.698508.242580@.g43g2000cwa.googlegroups.com...
> Here's a weird one.
> I've got a job on one server, owner 'sa'. It runs fine. I created the
> same job on another server, still with owner 'sa', and it fails. When I
> view the history, it fails because it's running as a different user,
> one without the necessary rights. On the server that it works on, the
> job is being run as the correct user, 'sa'.
> In the step, under advanced, 'Run as user:' is set to '(self)', just as
> it is in the server that works.
> Help! I cannot see any difference between the jobs on the 2 servers,
> and I can't think of any reason why it's trying to execute the job as a
> user other than the owner.
>|||Hi. The SQL Server Agent startup account is the same on both servers.
However server1 is running the job as sa, and server2 is running the
job as the SQL Server Agent startup account. Strange.
I've double, triple, quadruple checked that the job in question is set
to owner sa and the step is set to self.
Other jobs on the server are also running as the non-sa account, but
this one is the only one that's failing, because it's running through a
linked server. As a work around I've built a DTS package that runs the
task, and then scheduled that DTS package, but I'd really like to
understand why this server is running jobs under the non-sa account.|||I'm not sure whether you are talking about TSQL or CmdExec job step. However, two things to check:
1 EM, Agent, right-click, properties, right-most tab. Check how agent log on to SQL Server.
2 Security mode for each SQL Server (Windows only or mixed).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<ben.bawden@.btopenworld.com> wrote in message
news:1129115237.379149.269800@.g43g2000cwa.googlegroups.com...
> Hi. The SQL Server Agent startup account is the same on both servers.
> However server1 is running the job as sa, and server2 is running the
> job as the SQL Server Agent startup account. Strange.
> I've double, triple, quadruple checked that the job in question is set
> to owner sa and the step is set to self.
> Other jobs on the server are also running as the non-sa account, but
> this one is the only one that's failing, because it's running through a
> linked server. As a work around I've built a DTS package that runs the
> task, and then scheduled that DTS package, but I'd really like to
> understand why this server is running jobs under the non-sa account.
>
Monday, March 19, 2012
Job failure - error msg attached
following error message:
The job failed. Unable to determine if the owner %OWNER%
of job %JOB% has server access (reason: The log for
database 'tempdb' is not available. [SQLSTATE HY000]
(Error 9001)).
Any ideas how to resolve this one? I've looked in the KB
and BOL, and I see entries for the error and the reason
in parentheses, but not with the two together. Was
thinking just cycling the instance might resolve the
issue, but was hoping to avoid doing this. Never seen
this one before, so any help would be appreciated.
Cheers.
All I can think is no DC available for authentication? I suspect the =
reason in brackets to be misleading, if tempdb had lost it's log you =
would be getting many other problems!)
Mike John
"knives" <anonymous@.discussions.microsoft.com> wrote in message =
news:1e30b01c454a9$cf5029c0$a001280a@.phx.gbl...
> I have a maintenance job that is failing with the=20
> following error message:
>=20
> The job failed. Unable to determine if the owner %OWNER%=20
> of job %JOB% has server access (reason: The log for=20
> database 'tempdb' is not available. [SQLSTATE HY000]=20
> (Error 9001)).
>=20
> Any ideas how to resolve this one? I've looked in the KB=20
> and BOL, and I see entries for the error and the reason=20
> in parentheses, but not with the two together. Was=20
> thinking just cycling the instance might resolve the=20
> issue, but was hoping to avoid doing this. Never seen=20
> this one before, so any help would be appreciated.
>=20
> Cheers.
|||I'd start by setting the job owner to sa.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"knives" <anonymous@.discussions.microsoft.com> wrote in message
news:1e30b01c454a9$cf5029c0$a001280a@.phx.gbl...
> I have a maintenance job that is failing with the
> following error message:
> The job failed. Unable to determine if the owner %OWNER%
> of job %JOB% has server access (reason: The log for
> database 'tempdb' is not available. [SQLSTATE HY000]
> (Error 9001)).
> Any ideas how to resolve this one? I've looked in the KB
> and BOL, and I see entries for the error and the reason
> in parentheses, but not with the two together. Was
> thinking just cycling the instance might resolve the
> issue, but was hoping to avoid doing this. Never seen
> this one before, so any help would be appreciated.
> Cheers.
Job failure - error msg attached
following error message:
The job failed. Unable to determine if the owner %OWNER%
of job %JOB% has server access (reason: The log for
database 'tempdb' is not available. [SQLSTATE HY000]
(Error 9001)).
Any ideas how to resolve this one? I've looked in the KB
and BOL, and I see entries for the error and the reason
in parentheses, but not with the two together. Was
thinking just cycling the instance might resolve the
issue, but was hoping to avoid doing this. Never seen
this one before, so any help would be appreciated.
Cheers.All I can think is no DC available for authentication? I suspect the =reason in brackets to be misleading, if tempdb had lost it's log you =would be getting many other problems!)
Mike John
"knives" <anonymous@.discussions.microsoft.com> wrote in message =news:1e30b01c454a9$cf5029c0$a001280a@.phx.gbl...
> I have a maintenance job that is failing with the > following error message:
> > The job failed. Unable to determine if the owner %OWNER% > of job %JOB% has server access (reason: The log for > database 'tempdb' is not available. [SQLSTATE HY000] > (Error 9001)).
> > Any ideas how to resolve this one? I've looked in the KB > and BOL, and I see entries for the error and the reason > in parentheses, but not with the two together. Was > thinking just cycling the instance might resolve the > issue, but was hoping to avoid doing this. Never seen > this one before, so any help would be appreciated.
> > Cheers.|||I'd start by setting the job owner to sa.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"knives" <anonymous@.discussions.microsoft.com> wrote in message
news:1e30b01c454a9$cf5029c0$a001280a@.phx.gbl...
> I have a maintenance job that is failing with the
> following error message:
> The job failed. Unable to determine if the owner %OWNER%
> of job %JOB% has server access (reason: The log for
> database 'tempdb' is not available. [SQLSTATE HY000]
> (Error 9001)).
> Any ideas how to resolve this one? I've looked in the KB
> and BOL, and I see entries for the error and the reason
> in parentheses, but not with the two together. Was
> thinking just cycling the instance might resolve the
> issue, but was hoping to avoid doing this. Never seen
> this one before, so any help would be appreciated.
> Cheers.
Monday, March 12, 2012
Job failing
I have a scheduled job on a SQL 2000 database which is failing. Here is the error message :
The job failed. Unable to determine if the owner (caci\snasir) of job Integrity Checks Job for DB Maintenance Plan 'IDS' has server access (reason: Could not obtain information about Windows NT group/user 'caci\snasir'. [SQLSTATE 42000] (Error 8198)).
I am the SA on the instance. I wonder why would I be getting this error message? I am able to logon to this instance and browse and change things. So clearly it recognizes me. But when I run the job it fails. Wonder why? my SQL Server version is 8.0.
The Job is owned by [caci\snasir]. The error indicates that SQL Server cannot validate [caci\snasir] credentials.
It may be better to transfer the job ownership to [sa].
Job failed with owner ()
Server Agent jobs are run. But this doesn't always
happen, sometime the jobs run fine.
The job failed. The owner () of job xxxxxxxxxxx does not
have server access.
Any thoughts?
Is the job owned by a group that is in a Domain Local Group?
If so, you'll need this update.
825042 FIX: SQL Server Jobs That Are Owned by Non-sysadmin Users May Not
Start
http://support.microsoft.com/?id=825042
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Friday, March 9, 2012
Job failed with owner ()
Server Agent jobs are run. But this doesn't always
happen, sometime the jobs run fine.
The job failed. The owner () of job xxxxxxxxxxx does not
have server access.
Any thoughts?Is the job owned by a group that is in a Domain Local Group?
If so, you'll need this update.
825042 FIX: SQL Server Jobs That Are Owned by Non-sysadmin Users May Not
Start
http://support.microsoft.com/?id=825042
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
job execution user change and ownership question
I am running my sql server 2000 server and agent as a service with domain
admin user.
Is this recommended?
Who should be the job owner? sa or application user?
Can the job be run by any other user other than the user who started the
sqlserver agent.
TKS
MangeshHi
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:907D7E49-4B58-4D9F-B3D4-149D45B9B94C@.microsoft.com...
> Hi
> I am running my sql server 2000 server and agent as a service with domain
> admin user.
> Is this recommended?
No! A domain admin is over privileged, restrict the account to what you need
to do.
Check out the requirements for this account at
http://msdn.microsoft.com/library/d.../>
ew_6k1f.asp
You may also want to read some of the information on:
http://www.sqlsecurity.com/DesktopD...index=0&tabid=1
> Who should be the job owner? sa or application user?
This will depend what the job does e.g if you need to restrict the job to
the privleges of the application user or if the job needs higher
permissions.
> Can the job be run by any other user other than the user who started the
> sqlserver agent.
>
Yes, look at sp_start_job to run the job at a non-scheduled time. Check out
books online for information about the context in which jobs are run.
>
> TKS
> Mangesh
John
job execution user change and ownership question
I am running my sql server 2000 server and agent as a service with domain
admin user.
Is this recommended?
Who should be the job owner? sa or application user?
Can the job be run by any other user other than the user who started the
sqlserver agent.
TKS
MangeshHi
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:907D7E49-4B58-4D9F-B3D4-149D45B9B94C@.microsoft.com...
> Hi
> I am running my sql server 2000 server and agent as a service with domain
> admin user.
> Is this recommended?
No! A domain admin is over privileged, restrict the account to what you need
to do.
Check out the requirements for this account at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_overview_6k1f.asp
You may also want to read some of the information on:
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=0&tabid=1
> Who should be the job owner? sa or application user?
This will depend what the job does e.g if you need to restrict the job to
the privleges of the application user or if the job needs higher
permissions.
> Can the job be run by any other user other than the user who started the
> sqlserver agent.
>
Yes, look at sp_start_job to run the job at a non-scheduled time. Check out
books online for information about the context in which jobs are run.
>
> TKS
> Mangesh
John
job execution user change and ownership question
I am running my sql server 2000 server and agent as a service with domain
admin user.
Is this recommended?
Who should be the job owner? sa or application user?
Can the job be run by any other user other than the user who started the
sqlserver agent.
TKS
Mangesh
Hi
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:907D7E49-4B58-4D9F-B3D4-149D45B9B94C@.microsoft.com...
> Hi
> I am running my sql server 2000 server and agent as a service with domain
> admin user.
> Is this recommended?
No! A domain admin is over privileged, restrict the account to what you need
to do.
Check out the requirements for this account at
http://msdn.microsoft.com/library/de...rview_6k1f.asp
You may also want to read some of the information on:
http://www.sqlsecurity.com/DesktopDe...ndex=0&tabid=1
> Who should be the job owner? sa or application user?
This will depend what the job does e.g if you need to restrict the job to
the privleges of the application user or if the job needs higher
permissions.
> Can the job be run by any other user other than the user who started the
> sqlserver agent.
>
Yes, look at sp_start_job to run the job at a non-scheduled time. Check out
books online for information about the context in which jobs are run.
>
> TKS
> Mangesh
John