March 22, 2006 at 1:56 pm
Anyone know why I would get the message "No such Interface supported" when attempting to connect to my local SSIS servce when it is running under the default "network service" service account, but it connects fine if I set the service to run as "localsystem"? I guess it's a permissions setting somewhere, but I can't figure out what it is.
Thanks
March 22, 2006 at 2:45 pm
look in the event viewer | application log for "dcom" errors associated with the process. There are usually 17 of them, and they occur frequently when using the account you are using (which is the best account to use)... click on the help and it will take you to an MS site where you will get a complex set of instructions to fix them... complex, yes, and once you fix it once you will see the shortcuts you can take, and in the future go right to the problem to add the appropriate permissions.
March 23, 2006 at 5:47 am
Thanks for the info. Is there something I need to do to turn on the logging of these dcom messages? I see no errors at all in the event viewer logs after I try to connect to SSIS. I've tried turning on all auditing under the audit policies for this machine and still see nothing.
Thanks again for any assistance you may be able to provide. This is really getting frustrating.
May 9, 2007 at 5:26 am
We're currently having this problem - only in a clustered envrionment. I've ran through the usual stuff with the ini.xml file and placed everything on the shared disks, but I still can't connect to it.
Did anyone have a solution?
Thanks,Dave
May 10, 2007 at 3:27 am
Right - I managed to fix this....
After a few days trying various different options with regards to DCOM, ini.xml files and the shared disks on the cluster - it turned out to be fairly simple. Simply try uninstalling and re-installing both the SSIS services and the workstation components. Remove them both, install SSIS, patch it, reboot, then install the workstation components.
Strangely - the registry entries for SSIS and the ini.xml file I'd moved to the sharde disks were not removed, so I suspect that SSIS wasn't looking at it properly. Once it had been re-installed it seemed to pick up the values correctly and now runs like a charm.
Hope others are able to fix this as well!
Dave
May 30, 2007 at 10:15 am
And I fixed this problem by re-installing SP2 with "Distributed Transaction Coordinator" service up and running under the "NT AUTHORITY\NetworkService" account.
The DTS service has to be up and running while you are installing the SP2.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply