Wyzwaniem przy stosowaniu podejścia do pliku konfiguracyjnego jest konieczność ciągłej modyfikacji pliku. SSIS nie przeładuje pliku konfiguracyjnego po jego uruchomieniu, więc możliwe są zadania o 8:05 i 20:35, które zamieniają pliki konfiguracyjne, ale w pewnym momencie będzie się bałagan i zepsuł.
Poradziłbym sobie z tą sytuacją za pomocą zmiennych wiersza poleceń (/set option in dtexec). Jeśli pakiet był uruchamiany z wiersza poleceń, wyglądałby on tak, jakby był: dtexec.exe /file MyPackage.dtsx Nawet jeśli używasz agenta SQL, za kulisami tworzy on argumenty wiersza poleceń.
To podejście zakłada utworzenie dwóch różnych zadań (w porównaniu do 1 zadań zaplanowanych 2x dziennie). AgentMyPackage2011 ma stopień miejsc pracy SSIS, które powoduje
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2011\"
i AgentMyPackage2012 ma stopień miejsc pracy SSIS, które powoduje
dtexec /file MyPackage.dtsx /Set \Package.Variables[User::Year].Properties[Value];\"2012\"
Poprzez GUI, będzie wyglądać jak 
Nie ma GUI lub wybierak za nieruchomość, którą chcesz skonfigurować. Jednakże, ponieważ już utworzyć plik .dtsConfig dla swojego pakietu, otwórz ten plik i poszukaj sekcji jak
<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Year].Properties[Value]" ValueType="Int32">
<ConfiguredValue>2009</ConfiguredValue>
plik już ścieżkę do „rzeczy”, które próbujesz skonfigurować tak uderz w swój program wywołujący, a następnie wyłącz część roku konfiguracji pakietu.
Wreszcie link do SSIS Configuration Precedence, ponieważ istnieją różnice w modelu 2005 vs 2008. Widzę, że wskazałeś rok 2008 w swoim bilecie, ale dla przyszłych czytelników, jeśli używasz obu/SET i źródła konfiguracji (xml, serwer sql, rejestr, zmienna środowiskowa) kolejność operacji jest różna w różnych wersjach.