Seems like the problem arises when a new service account is given permissions / added on the server. The DTS is an admin function and occasionally there are reasons why the service account should not have admin on the box. In cases like this, they may need extended permission in the registry.

There are five hives to be concerned with

HKEY_CLASSES_ROOT\CLSID\{FDC3723D-1588-4BA3-92D4-42C430735D7D}

and

HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Server.DtsServer

and

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FDC3723D-1588-4BA3-92D4-42C430735D7D}

and

HKLM\SOFTWARE\Classes\CLSIDand

HKLM\SOFTWARE\Classes\Microsoft.SqlServer.Dts.Server.DtsServer\CLSID

The remaining permissions will autofill (if you choose to do this through the registry).

And easier method might just be to add the service account to the group:

SQLServer2005SQLBrowserUser$<servername>

I haven't tried it this way but it should work in theory.

And another method might be by enabling the local sec policy for that user on :

Log on as a service (SeServiceLogonRight)

Bypass traverse checking (SeChangeNotifyPrivilege)

Impersonate a client after authentication (SeImpersonatePrivilege)

There is also some needed configuration for the Local DTC Properties. If you go to the COM Services and open the Distributed Transaction Coordinator to the Local DTC and check the properties|security tab, make sure the following are checked:

Network DTC Access (with Allow Remote Clients) and (Allow Inbound) and (Allow Outbound) with "No Authentication Required"

and (Enable SNA LU 6.2 Transactions)

The account here is generally the NT AUTHORITY\NetworkService but I suspect it can be changed to whatever is needed. This is probably an inherited right so your service account may need to be specifically entered but if so, I've never had an issue leaving it as is and service accounts run our systems.