Det första felet jag skulle ta upp är "Excel Connection Manager stöds inte i 64-bitarsversionen av SSIS, eftersom ingen OLE DB-leverantör är tillgänglig."
Excel-drivrutinerna finns bara i 32-bitars adressutrymmet. BIDS/SSDT är ett 32-bitars program så Excel-källa och destinationer fungerar utmärkt. Men när du kör dem från kommandoraden/SQL-agenten måste du uttryckligen använda 32-bitarsversionen av DTEXEC-programmet.
Steg 1 kommer att vara att säkerställa att du kan köra paketet från kommandoraden på servern som agenten kör på som dig själv. Förutsatt att din SQL Server är installerad på den vanliga platsen, har du förmodligen en av följande DTEXEC.exe tillgänglig för 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 kommer att vilja använda (x86) versionen. Framtida läsare, om du råkar ha en 32-version av Windows (Windows 2003, kanske), kommer de första 3 att vara de enda alternativen som är tillgängliga för dig. Som Viveks felmeddelande har antytt kör han ett SSIS-paket i 64-bitarsläge.
dtexec tillhandahåller en kommandoradsväxel /X86 så att du sömlöst kan använda samma körbara för både 32- och 64-bitarsoperationer. LÖGNER! Dokumentationen säger det men vem läser dokumentationen?
Det här alternativet används endast av SQL Server Agent. Det här alternativet ignoreras om du kör verktyget dtexec vid kommandotolken.
Så du måste köra ditt paket genom att ange den explicita sökvägen
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe /file C:\folder\GICSReport.dtsx
Jag ser "Det gick inte att dekryptera skyddad XML-nod" i din utdata och du uppger också att du använder konfigurationsfiler så att du med största sannolikhet kan ändra din PackageProtectionLevel från standard EncryptSensitiveWithUserKey till DontSaveSensitive. Den funktionen finns för att förhindra oavsiktlig exponering av känsliga data (lösenord) men eftersom du redan hanterar det med konfigurationsfiler borde det inte vara ett problem. ... Det kan faktiskt vara ett fel från en av de andra paketskyddsnivåerna nu när jag tänker på det.
Försök i alla fall att köra från 32-bitars körbara först. Om det inte fungerar, försök att ändra paketskyddsnivån enligt anvisningarna. Om någon av dessa gör att paketet körs som förväntat, försök sedan köra samma kommando från SQL-agenten.
Om allt fungerar, markera detta som svaret. Om inte, uppdatera biljetten med det aktuella felet som genereras så ber vi om mer information.