Den første fejl, jeg vil adressere, er "Excel Connection Manager understøttes ikke i 64-bit versionen af SSIS, da der ikke er nogen OLE DB-udbyder tilgængelig."
De ud af kassen Excel-drivere findes kun i 32 bit adresserummet. BIDS/SSDT er et 32 bit program, så Excel-kilde og -destinationer fungerer fint. Men når du kører dem fra kommandolinjen/SQL-agenten, skal du udtrykkeligt bruge 32 bit-versionen af DTEXEC-programmet.
Trin 1 vil være at sikre, at du kan køre pakken fra kommandolinjen på den server, som agenten kører på som dig selv. Forudsat at din SQL Server er installeret på den sædvanlige placering, har du sandsynligvis en af følgende DTEXEC.exe tilgængelig for dig
C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
c:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Du vil gerne bruge (x86) versionen. Fremtidige læsere, hvis du tilfældigvis er på en 32-version af Windows (måske Windows 2003), vil de første 3 være de eneste tilgængelige muligheder for dig. Som Viveks fejlmeddelelse har indikeret, udfører han en SSIS-pakke i 64 bit-tilstand.
dtexec giver en kommandolinjeswitch /X86 for at give dig mulighed for problemfrit at bruge den samme eksekverbare til både 32 og 64 bit operationer. LØGN! Dokumentationen siger det, men hvem læser dokumentationen?
Denne mulighed bruges kun af SQL Server Agent. Denne mulighed ignoreres, hvis du kører dtexec-værktøjet ved kommandoprompten.
Så du bliver nødt til at køre din pakke ved at angive den eksplicitte sti
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe /file C:\folder\GICSReport.dtsx
Jeg ser "Kunnede ikke dekryptere beskyttet XML-node" i dit output, og du angiver også, at du bruger konfigurationsfiler, så du højst sandsynligt kan ændre dit PackageProtectionLevel fra standarden EncryptSensitiveWithUserKey til DontSaveSensitive. Denne funktion eksisterer for at forhindre utilsigtet eksponering af følsomme data (adgangskoder), men da du allerede håndterer det med konfigurationsfiler, burde det ikke være et problem. ... Det kan faktisk være en fejl fra et af de andre pakkebeskyttelsesniveauer, nu hvor jeg tænker over det.
Prøv i hvert fald at køre fra den 32 bit eksekverbare først. Hvis det ikke virker, prøv at ændre pakkebeskyttelsesniveauet som angivet. Hvis en af disse får pakken til at køre som forventet, så prøv at køre den samme kommando fra SQL-agenten.
Hvis det hele virker, så marker dette som svaret. Hvis ikke, opdater venligst billetten med den aktuelle fejl, der genereres, og vi vil bede om flere oplysninger.