Thursday, March 29, 2012

Access Denied - Remote connection to SSIS

We have 2 SQL2005 servers currently. 1 is a dev box, the other production. To grant remote access to SSIS, I added my developers to the local Distributed COM Users group and also gave them remote Access and remote Activation on the MsDtsServer component.

This worked just fine. Recently we applied SP1 and the follow-on hotfixes to all SQL components. I followed the install order prescribed in the Q article and applied all component fixes. My developers are now unable to access SSIS remotely unless I add them to the local administrator's group. I don't see anywhere that a log gets generated to help me track down what's going on. Nothing shows up in my Windows security log, despite enabling audit logging on: Accout Logon Events, Logon Event, Object Access, and Privilege Use.

Is this a know issue in SP1 or the hotfixes? I'm hesitant to apply the patches to my production box until I can resolve this issue.

Thanks
Steve

With the lack of responses I'm assuming I'm out of luck. Anyone have suggestions on how to troubleshoot this? Is there some reg entry I can flip to enable debugging or even use of the event log for SSIS?

Thanks

|||When you say you have added developers to DCOM Users Groups, is this what you have done - Connecting to a Remote Integration Services Server (17th July 2006) - http://msdn2.microsoft.com/en-us/library/aa337083.aspx ?|||

That article only mentions the need to give them access to the msdtsserver. There is another article that also mentions that they must be placed in the local Windows group called: "Distributed COM Users". I have followed both articles. As I mentioned, this configuration was working until a short time after applying the SP1 and Hotfix patches for SQL2005. It is still working on our production box that has not yet been patched.

Thanks

Steve

|||

I am getting the same behaviour, we have also got SP1 installed.

|||

After applying SP1 and the Hotfixes, we never rebooted Windows (never received a notification that we should). This weekend we applied our monthly round of OS patches. Now that the server has been rebooted access is working correctly again.

I guess the lesson here is that, if you've followed all of the instructions and they still don't work, do a full reboot - restarting services doesn't appear to be enough.

You may consider this thread closed.

Thanks

Steve

No comments:

Post a Comment