Autentication Problem

  • I have been requested to change my jobs to be scheduled by Control-M so that we can post the errors on our Data Center Screen. The DTS package is used to refresh Cubes.

    Before I moan about the problem here is the architecture.

    The Analysis Services is on a 64 bit Datacenter 2003 platform. The DTS is on a 32 bit Datacenter 2003 platform. (No DTS for 64 bit)

    The Scheduling tool logs into the 32bit machine with a user that is a member of the OLAP admin group on the 64 bit machine. (Analysis Services). The scheduling tool is also a member of admin on both machines.

    When the batch file is executed on the 32 bit machine the DTS fails. Here is the error..

    C:\CTMAG\EXE>DTSRun /S32bit /Uxx /Pxx /NRefresh Cubes(Credit_Vetting)

    DTSRun:  Loading...

    DTSRun:  Executing...

    DTSRun OnStart:  DTSStep_DTSOlapProcess.Task_2

    DTSRun OnError:  DTSStep_DTSOlapProcess.Task_2, Error = -2147221387 (80040075)

       Error string:  Cannot connect to the Analysis server on computer '64bit'.

    Connection to the server is lost

       Error source:  DSO

       Help file:

       Help context:  1000440

    Error Detail Records:

     After checking the events on the 64bit server (Analysis Server) the following error is logged.

    User , logged in from computer 32bit, does not have administrative permissions on the server, but tried to perform an administrative operation on the server. This may indicate an intrusion.

    The error log does not state what user was used to try to log in.

     

    Any pointers or help will be appreciated.

    THANKS


    Andy.

  • Hi Andy,

    When you run a DTS package manually it uses the account that the scheduling tool is logged on as. What scheduling tool do you use? I use the Microsoft Scheduler that comes with Windows for my jobs. I would try logging on interactively (if you can) with the account you are using to see if it works for you.  The sheduler appears to be running jobs from the command line, maybe you can add the command... set user .... to make sure that the user is the one you are expecting. If the use has local administrator rights on both machines then I would have expected it to work ok....

     

    Michael

  • Heh, exactly what I was getting - but I was running the job on the local server. The 32bit/64bit remote server was a red herring here. Michael was exactly right: I added the account that sqlagent logged on as to the administrator group for the SQL server and bingo - ran straight away.

    Gah - its always the simple things!

    Miles

  • YEAH  It was the simple stuff! And I have just noticed how I spelt Authentication!


    Andy.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply