getting this nice thing in my user acceptance test environment.

The AcquireConnection method call to the connection manager "XYZ" failed
with error code 0xC0202009.
component "OLE DB Source" (1) failed validation and returned error code
0xC020801C.

Now the interesting:this happens when the ssis runs from a job.
under my own rights - no problem, because I'm a sysadmin and administrator
on both servers.
The job runs under sql server agent account. Usual thing. SSIS is not
encrypted and was migrated between 2 environment without an issue.
The sql server agent is running under domain account; and the account
(already did dig a nice size security hole after trying good amount of other
things) is administrator on both source and the target systems and sysadmin.
The security hole can not be bigger
Still can not authenticate on the source system during only significant data
transformation task.
First I thought, it is this http://support.microsoft.com/kb/933835
granted the rights, did not change a thing. Then the securioty hole was
created, did not change a thing, and that just does not sound right at all.

Tried to create a proxy with my account, same thing. Succeeded only in one
thing: my debug info in that job was gone (and it was set in the parameters)
in dbo.sysdtslog90, the job has failed, so how did that happen do not know,
never seen such a thing before.
The source sql server is 2000 sp4, the target is sql 2005 sp1 (yes I know,
can not upgrade it yet). After job modification I did check that my
connection strings info indeed was not blown away (usualy it does, and that
particular bug is really annoying).

Put a trace on the source system. monitoring of all the errors, connections
succesful and the failed ones, all audit object permissions. The sql 2005
server did not try to establish a connection, my trace did not pick it up
(imitated failed login, so i know for sure the trace was not missconfigured).


This does not happen in any other of my environments, neither development
ones, neither production.

Where else do I dig? Any help is appreciated.

--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

in addition to that:
loaded the ssis into dev studio and changed there protection level to
ServerStorage. after that saved the siis on top of the existing one Executing
that ssis from the job with sql server authentication does not seem to make
any difference at all.
so resolution method described in
http://support.microsoft.com/?kbid=918760
method 2 seems to have problems. as well as method1 (proxy. job has failed,
and logging was gone on top of that which did not make debugging of the issue
any easier.
Could somebody clarify how is it
STATUS
This behavior is by design.
If the ssis I'm talking about has no database authentication neither it has
or accesses any encrypted information.

That does not sound to me like any reasonable behavior by design, that
sounds to me like another not well documented feature.


--
Thanks, Liliya

Hi Liliya,
Have you fix the issue? coz i got same issue...

"Liliya Huff" wrote: