Connecting to the SSIS

"When you launched Integration Services,"


it launch from SQL configuration manager automatically ,right?

or the account which use to start it has to be local/domain administrator ?

Currently the account use as the start up account for the integration serve is not an administrator ! why need? too much power on that machine, right?

one thing is, even the startup account for the integration service is a local account, not local administrator, that service can start ! so this mean the startup is ok .

I found it is only happen on SQL server 2012 on Windows 8, I have 2x Windows 8.1 machine with latest update, they gives the same error.

The account the SSIS start with already local administrator account, so this is not admin right problem !

the SQL server 2012 on Windows 7 do not have this problem.

"As the error message states, the account you're using to run SQL Management Studio needs to not only be a local administrator on the server hosting SSIS, but also much have been launched via the "Run as Administrator" escalation (via Right-click when you launch it). Without those two things, you will be unable to connect to and manage SSIS."

I read some article too ! but the method they said is not correct and cant' fix the problem, I am talking about the DCOMcfg one, it just doens't work.

yeah, right lick the SQL SSMS and run as administrator can do it! it is the SSIS design by default!

but just can't see why ! MS SQL server don't need to be secure?

" but I've never been able to get it to work without the user being a local administrator. "

then we keep silence on this as this make hte non DBA one can't touch the SSIS, right? but we can't control the developer on touching that as they can connect to it using SQL data tools! right?

Right. They don't have to be a sysadmin on the database server where you're keeping packages, but they will have to be in the local administrators group on the actual SSIS server. These are commonly the same physical server, but they don't have to be - even if they are, you can revoke SQL Server rights from "BUILTIN\Administrators" (who have sysadmin by default) and grant them to your actual DBA group. While local admin rights on the SSIS server still aren't ideal, this will help keep your sql server itself safe.

sorry, other than right click on the SSMS and run as administrator, what else I can do ?

"They don't have to be a sysadmin on the database server where you're keeping packages, but they will have to be in the local administrators group on the actual SSIS server."

the account of that SSIS service has been assigned the local administrator right, but it doesn't help on this !

The service running SSIS doesn't matter in this case - it's the rights of the person connecting to the SSIS service to manage it. Permissions are really odd in the case of users interacting with SSIS, but that's the way they are, unfortunately.

It seems set up to require your DBAs, not your developers, to deploy and manage SSIS packages.

"Permissions are really odd in the case of users interacting with SSIS, but that's the way they are, unfortunately."

Yes, I can't see why only secure SSIS but not MS SQL in this way ! funny ! probalby SSIS has very special logic that even DBA don't have access.

"The service running SSIS doesn't matter in this case - it's the rights of the person connecting to the SSIS service to manage it"

I don't think so, BEFORE we can connect to it, who can connect to it ?

"It seems set up to require your DBAs, not your developers, "

I am the DBA and learning SSIS. that's why I am wondering !