I am reposting this problem because I originally posted with the incorrect
problem.

I have a simple SSIS package executing perfectly in the BID Environment (on
the Windows 2008 Server) when I run BID as administrator. Likewise when I
run Sql Server Management Studio as administrator, the package runs perfectly.

When I do not run these apps as administrator I get this:

Warning: Could not open global shared memory to communicate with
performance DLL; data flow performance are not available. To resolve, run
this package as an administrator, or on the system’s console.

So running BID/SSMS as administrator allows me to execute this package
successfully.

So my problem is how to execute this package with the right privileges.
This package needs to be executed by any windows user using our windows
application called DMS (windows/.Net application/.Net 2.0/3.5 framework).
DMS connects to a web service which in turn executes the package. That code
works.

But the permissions issue is stopping us right now. In fact, no SSIS
package should require Administrator permission so why is this package
requiring it?

WRL

Kind of depends on what the package does, what resources it access, etc, that
determine what permissions are required.

In the SQL Server Configuration, do you have Shared Memory turned on? I
think it is by default.

What priviledges does the Web Service account have?

HTH
=====
Todd C


"Whiskey Romeo Lima" wrote:

I am not a DBA so I wouldn't know what shared memory means in the context of
SQL Server and SSIS. I am logged in as domain administrator yet still have
to run BID/SSMS as administrator.

Hopefully someone who has actually experienced this problem and solved it
can help. If not, I have to use one of my MSDN Subscriber Support Incidences

WRL

"Todd C" wrote:

I wouldn't burn an MSDN incident for this. 99.9% of the time, if you can run
a package in BIDS (business Intelligence Development Studio, aka Visual
Studio) and CANNOT run it any other way, the issue is permissions.

Now, moving on to that "shared memory" thing:
On the SQL Server box, open Programs, SQL Server 2008, COnfiguration Tools,
SQL Server Configuration Manager.
expandSQL Server Network Configuration, click Protocols for MSSQLSERVER and
examine the list at the right. You will most likely want to have Shared
Memory and TCP/IP set to Enabled and Named Pipes and VIA set to Disabled.
Under the SQL Native Client Configuration, same two enabled, with Shared
Memory first in the order.

Now, about the permissions:
Read up on BOL (Books on Line) about dedicated Roles in the MSDB Database
for executing SSIS Packages.

Does the package have any saved passwords in it?

Keep us posted.
=====
Todd C


"Whiskey Romeo Lima" wrote:

Todd,

I bow to the master. I didn't burn a MSDN incident, Microsoft Support
addressed my issue for free. Here is their response which is a longer
version of your response.

The quote below is from Microsoft Support replying to my email stating that
changing from a SQLDB data destination to an OLEDB destination worked.

"Yes, according to the defect description, OLE DB should work, the warning
only says that the package does not have access to the SSIS related perfmon
counters.

I was able to reproduce the failure in almost all environments (All OS
versions with UAC ON i.e. Windows Vista and above). The defect documentation
also says that this error should happen if the executing User does not have
SeCreateGlobalPrivilege on Windows. User-mode applications represent this
privilege as the following user-right string: “Create Global Objects” and I
remember we already granted that. So this might be a regression, I am going
to pursue this with Product Group to see if there is/would be a fix available
to this otherwise it might limit Sql Server Destination task to a great
extent.

As of now, it seems the only work around without any security breach is to
switch to the OLE DB Destination component."


"Todd C" wrote:

Ah, SQL Server Destination. I remember in my early days of SSIS design that I
thought, "Hey, if I'm working with a Microsoft SQL Server product, the BEST
connection option would be the Microsoft SQL Server proprietary Destination."

How wrong I was.

I NEVER use the SQL Server Destination in SSIS design. OLE DB for SQL Native
Client (.1 or 10.0) works without issue.

Glad to hear you got some resolution.
=====
Todd C
MCTS SQL Server 2005


"Whiskey Romeo Lima" wrote:

Todd,

If look at my post titled Permissions Problem and dated 12/13/2008, you can
see the actual code. I made [Our Domain]\Domain Users a member of
db_ssisoperator and I granted db_ssisoperator the Reader Role via the Package
Roles.

That get me by the lines in the code that executes SSIS.ExistsOnSqlServer,
SSIS.LoadFromSqlServer, and sets the values of ExcelFilePath and connections.

But when it gets to myPkgExecute(), that method does not throw an error it
simply returns "Pakage Failed". Domain users have access the folder and file
where the file exist and have permissions on the table where the rows are
inserted.

Yet when I execute the very same Package in Bids or in SSIS the package runs
fine.
--
WRL


"Todd C" wrote: