Item vs. System Level Security

I am trying to deploy RS in a corporate environment. I have folders set up at
different organizational levels. I would like to allow certain users only
within those organization levels to create linked reports and deploy them
within their respective organizational levels. I thought that by granting
those users full item-level security they could achieve this. Unfortunately,
when I tried this it did not work.
1. Which task allows users to view report properties and create linked
reports? I'm assuming this is a system-level task.
2. Is there any way that I can assign this task to a role which restricts
the user to only exercising that authority only within a certain folder. I
obviously don't want to give the user the ability to create linked reports
site wide but only in the respective organizational folder.
3. Is there anyway to combine system-level and item-level tasks into a
single role or to customize security configurations?
Any help would be greatly appreciated.
Thanks,
TedCreating linked reports is an item level task. In report manager go to the
site settings tab and then the 'Configure item-level roledefinitions' link.
From here you can create roles as you see fit. One of the tasks you can
assign is 'Create Linked reports'. You can not combine system and
item-level task, but then again you shouldn't need to.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ted" <Ted@.discussions.microsoft.com> wrote in message
news:287C4AA6-65EC-411A-9E93-4C1CDA463AE2@.microsoft.com...
> I am trying to deploy RS in a corporate environment. I have folders set up
at
> different organizational levels. I would like to allow certain users only
> within those organization levels to create linked reports and deploy them
> within their respective organizational levels. I thought that by granting
> those users full item-level security they could achieve this.
Unfortunately,
> when I tried this it did not work.
> 1. Which task allows users to view report properties and create linked
> reports? I'm assuming this is a system-level task.
> 2. Is there any way that I can assign this task to a role which restricts
> the user to only exercising that authority only within a certain folder. I
> obviously don't want to give the user the ability to create linked reports
> site wide but only in the respective organizational folder.
> 3. Is there anyway to combine system-level and item-level tasks into a
> single role or to customize security configurations?
> Any help would be greatly appreciated.
> Thanks,
> Ted

Issues about deploy Business Logic Handler to a web server for web replication.

Pocket PC 2003, SQL Compact Edition, SQL2005, IIS6.0

I implemented a business logic handler to deal with conflicts. When I deploy it on the SQL server which is also the web replication server, the logic handler seems working fine. However, if I deploy this handler to another web server. The logic handler failed to be loaded.

My enviroment settings are desribed as below.

Machine A, distributor, with database and publication. The business logic handler is deployed at C:\Program Files\Microsoft SQL Server\90\COM\BusinessLogicHandler.dll. It's registered by using sp_registercustomresolver. The @.assembly is specified as @.assembly=C:\Program Files\Microsoft SQL Server\90\COM\BusinessLogicHandler.dll';

Machine B, IIS server. The same business logic handler is deployed at C:\Program Files\Microsoft SQL Server\90\COM\BusinessLogicHandler.dll on the Machine B itself.

When I ran the web replication, the Merge Agent reported the error as below.

Error loading custom assembly "C:\Program Files\Microsoft SQL Server\90\COM\BusinessLogicHandler.dll", Error: "Could not load file or assembly 'C:\\Program Files\\Microsoft SQL Server\\90\\COM\\BusinessLogicHandler.dll' or one of its dependencies. The given assembly name or codebase was invalid.

It seemed that the Merge Agent had trouble to find my logic handler because the path reported in the error log has two backward slashes. I have no idea where did that came from. I am not sure if that's the cause of the error. Without business logic handler. I had successfully finished web replication of Machine B to sync with Machine A. If I setup web replication directly on Machine A with business logic handler, I can successfully sync as well.

Does anyone has any idea about how to correctly deploy business logic handler on a web server?

Thanks,

Nigel

It seems that if I sign the dll and install it in the global assembly of Mahine B. The problem went away. Does it mean we should deploy our assembly in the global assembly instead of the path "@.assembly" of distributor when we deploy our business logic handle to a IIS web replication server? The SQL2005 document does not specify how we should deploy the business logic handler for the web synchronization server. It would be nice if it could MS can provide more detail in business logic handler deploymont. However, it still seems to me it's a bug for the Merge Agent not be able to find the business logic handler in my previous post. Still don't know where the backward slashes come from.

If anyone has more details about this issue, please advise.

Thanks,

Nigel

Issue doing Integrated services programming using Microsoft.SqlServer.ManagedDTS.dll

Hi,

I am writing an installer code in C# to deploy the SSIS package.

I want to use Microsoft.SqlServer.ManagedDTS.dll for it.

It is mentioned in few articles available online that Microsoft.SqlServer.ManagedDTS.dll ships with SQL Server 2005.

I searched on our database server but could not get it.

Anyone having idea on this please help.

HV

Don't try and install SSIS by hand, it is not a good idea It is not supposed to be a redistributable component. There are a lot more assemblies that just that one for SSIS.

Since SSIS requires a full SQL Server license, why not use the regular SQL setup to do this for you. You can choose which servers you want.

If you have installed SSIS on your server then it will certainly be in the GAC, but it may not be on the file system outside of this, unless you installed the tools, in which case it is - C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies

|||Another question to ask: Is SSIS installed on this SQL Server box? A lot of SQL 2005 servers will be set up by their DBAs to not have any unnecessary components installed, and SSIS sometimes falls into this category.|||

Hi,

Thank you Darren.

SSIS is installed on the machine.

I checked the following folder :- C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies

but dll is not available.

Which tool installation delivers Microsoft.SqlServer.ManagedDts.dll?

Please let me know.

HV

|||

Hi,

Thank you Mathew.

SSIS is installed on the machine.

I checked the following folder :- C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies

but it's not available.

HV

|||

Hi,

I picked the Microsoft.SQLServer.ManagedDTS.dll from following folder:

C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS\9.0.242.0__89845dcd8080cc91>

Similarly picked Microsoft.SqlServer.DTSRuntimeWrap.dll also.

I added it as reference in my .NET application.

When I execute the program I get below error:

Retrieving the COM class factory for component with CLSID {E44847F1-FD8C-4251-B5DA-B04BB22E236E} failed due to the following error: 80040154.

Any Clue?

How to get the RunningPackages information back to a client PC?

HV

|||

If you want running packages information, why not just use the MS tools?

Do you have SSIS tools installed on the local machine that hosts the program? The error indicates that Microsoft.SqlServer.DTSRuntimeWrap is not installed on the local PC?

|||

No SSIS is not installed on the machine which hosts program.

But that is my requirement , I want to deploy SSIS package remotely.

I have installed Microsoft.SQLServer.DTSRuntimeWrap.dll in GAC.

Let me know if there is a way out to use it on a machine where SSIS is not installed.

HV

|||

SSIS is not installed you say, and you get an error that says in cannot find a COM component. Do you think there may be a connection?

I refer you to my original post, apart from saying that a manual install was a silly idea, I also pointed out "There are a lot more assemblies that just that one for SSIS."

As a start point that DLL is just a wrapper to the COM library that does the work, the name hints at that, and the error proves that it is trying to use a COM DLL that is not there, a COM DLL with a ProgID of {E44847F1-FD8C-4251-B5DA-B04BB22E236E} perhaps. As I said before there are lots of DLLs involved in SSIS not just one, so use a proper install.

What you are asking for a not a supported scenario, you may be violating your license agreements if not careful, and at any rate will be a very complicated task to try and reverse engineer the requirements, and very slow if you cannot track a missing COM DLL down yourself.

If you think this is wrong, post feedback to MS (http://connect.microsoft.com) telling them why you think you should have some redistribuatable support, but in the mean-time you will need to run one of the MS installs to get this to work.

Why do you not want to use a MS install?