Running SSIS jobs from agent job - access denied error

  • Hi All,

    I hope you can help shed some light on this problem. I'm starting to lose hair over it! :S

    Environment:

    windows cluster 2008R2 sp1

    SQL 2008 R2 SP1 CU5 failover cluster

    Node a is for the engine, agent, ssis

    node b is for ssas

    Problem.

    We have a bunch of ssis packages which are being called by agent jobs on node a which are running under the agent service account context. All jobs are failing with the following error:

    Message

    Executed as user: serviceaccountname. Microsoft (R) SQL Server Execute Package Utility Version 10.50.2500.0 for 64-bit Copyright (C) Microsoft Corporation 2010. All rights reserved. Started: 03:01:00 Could not load package "\MSDB\packagename" because of error 0xC00160AE. Description: Connecting to the Integration Services service on the computer "Computername" failed with the following error: "Access is denied. ". This error occurs when the computer has not been configured to allow remote connections through DCOM, or the user does not have permission to access the SQL Server Integration Services service through DCOM. Source: Started: 03:01:00 Finished: 03:01:00 Elapsed: 0.047 seconds. The package could not be loaded. The step failed.

    The strange thing is were not calling these packages on or from a remote machine, it's all being done locally. If we add the agent service account to the Distributed COM users group then the jobs start working, but the problem is that we haven't had to do this on ANY other environments of this setup (we have several other environments like this) - the jobs just work.

    The only difference between this environment and our others is that we are on sp1 CU5, others are on RTM or SP1 CU3.

    Has anyone got any ideas on what i'm missing?

    Cheers,

    Chris

    [font="Times New Roman"]There's no kill switch on awesome![/font]
  • Any diff between the perms serviceaccountname has on the problematic server and the ones acting proper? By perms I mean OS perms, Local Admin membership, etc. I am thinking there may be a diff for serviceaccountname where it gains access to DCOM via a local group membership (direct or inherited) and on the problematic server that might not be the case. Just thinking aloud...

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

Viewing 2 posts - 1 through 1 (of 1 total)

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