DTS cube processing from a non sa account

We are running a DTS package from a non-sa owned job and I am getting the following message:

A problem occurred while attempting to logon as the Windows user 'SQLAgentCmdExec': The parameter is incorrect.

When I set the Sql Agent proxy account to an windows administrator on the sql server it works fine.

However when the Sql Agent proxy account is not administrator I get the above error.

Please note that the Analysis Services is located on a different machine.

Thanks

LiorGrant admin privileges to the SQLAgent service account, which is required to carry on such tasks and to overcome this issue.|||Originally posted by Satya
Grant admin privileges to the SQLAgent service account, which is required to carry on such tasks and to overcome this issue.

Do you mean that the sqlagent stratup account should be windows sys admin?

Can I do it with less power priviliges?

Thanks

Lior|||You can do it, but you may have issues again if any of the jobs have to deal with admin tasks.

Its always better and recommended to keep SQL service accounts with Admin privileges on the box.|||Originally posted by Satya
You can do it, but you may have issues again if any of the jobs have to deal with admin tasks.

Its always better and recommended to keep SQL service accounts with Admin privileges on the box.

Hi,

Thanks again for your help.

Do you know what permissions are required for sql server to run cube processing that resides on a different machine.

Lior

DSN VS Logon

Our Database is ignores the authentication method that is chosen in the
database connection under ODBC. Everyone is getting a log on dialog.
Can any one help! ThanksYou didn't provide many details but is it safe to guess that
you are trying to use Windows Authentication in the DSN and
that all user who use this DSN are being prompted to enter a
user and password?
There was a similar issue with an old version of MDAC (2.5
maybe) if that's the case. You can check your MDAC
installation and version with component checker. Component
checker and MDAC versions are available for download from:
http://msdn.microsoft.com/data/ref/mdac/downloads/
-Sue
On Thu, 26 Oct 2006 12:49:02 -0700, Maida
<Maida@.discussions.microsoft.com> wrote:

>Our Database is ignores the authentication method that is chosen in the
>database connection under ODBC. Everyone is getting a log on dialog.
>Can any one help! Thanks|||Thanks Sue - Sorry I was short
We're moving on servers to a new Domain (btoins.com) then we will reimage
the workstation and move them. Before we moved it the DSN file worked fine w
e
didn't get any Windows Authentication box. We did a temp fix by putting the
domain users(genelco.com) in the local machine administrator group. Why
what's up with that - Thanks for your help!
"Sue Hoegemeier" wrote:

> You didn't provide many details but is it safe to guess that
> you are trying to use Windows Authentication in the DSN and
> that all user who use this DSN are being prompted to enter a
> user and password?
> There was a similar issue with an old version of MDAC (2.5
> maybe) if that's the case. You can check your MDAC
> installation and version with component checker. Component
> checker and MDAC versions are available for download from:
> http://msdn.microsoft.com/data/ref/mdac/downloads/
> -Sue
> On Thu, 26 Oct 2006 12:49:02 -0700, Maida
> <Maida@.discussions.microsoft.com> wrote:
>
>|||What protocol are you connecting with? Make sure it's TCP/IP
and not named pipes.
You can end up with some issues on logins, domain mappings
when moving domains but I can't tell from your post if this
is the issue or not. What domain are the users logging into
when they try to use the DSN? What domain are they listed
under in syslogins?
-Sue
On Fri, 27 Oct 2006 07:26:03 -0700, Maida
<Maida@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Thanks Sue - Sorry I was short
>We're moving on servers to a new Domain (btoins.com) then we will reimage
>the workstation and move them. Before we moved it the DSN file worked fine
we
>didn't get any Windows Authentication box. We did a temp fix by putting the
>domain users(genelco.com) in the local machine administrator group. Why
>what's up with that - Thanks for your help!
>"Sue Hoegemeier" wrote:
>