Only members of sysadmin role are allowed to update or delete jobs owned by a different login

Question to those who may have had this same error- it seems that I am not able to delete some of the reports that I have created. This just started happening recently and according to our system admin nothing has changed as far as permissions are concernced. We installed SP2 the other day and I was wondering if this could have anything to do with the error message below

by the way I am a member of the sysadmin group

thanks in advance

km

System.Web.Services.Protocols.SoapException: Server was unable to process request. > System.Data.SqlClient.SqlException: Only members of sysadmin role are allowed to update or delete jobs owned by a different login. Only members of sysadmin role are allowed to update or delete jobs owned by a different login. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.ReportingServices.Library.InstrumentedSqlCommand.ExecuteNonQuery() at Microsoft.ReportingServices.Library.DBInterface.DeleteObject(String objectName) at Microsoft.ReportingServices.Library.RSService._DeleteItem(String item) at Microsoft.ReportingServices.Library.RSService.ExecuteBatch(Guid batchId) at Microsoft.ReportingServices.WebServer.ReportingService2005.ExecuteBatch() End of inner exception stack trace

my bad

I need to move this over to SSRS

km

|||

Moved to RS as requested.

The error though is more general than RS, in fact it is a standard SQL Server Agent message. Unless there is a bug, I'd say you really are not a member of sysadmins, or at least not in the context of the RS WS call that is doing the work on yoru behalf. That may be the issue, the security context used by the WS itself. Perhaps run a profiler trace and see what login is being used, and also what job it is trying to delete. You can then verify the job owner. There should not be a problem as you are managing a RS created job, so RS should be able to delete its own jobs... maybe it is a RS thing?

|||Thanks
your info did the trick-- the account used was not a member of sysadmin-- my bad
thanks again
kam
|||

hi kam,

how did you solved the issue? i've added myself as the sysadmin on the server, but i'm still getting the same error. is there any other sysadmin than the sqladmin? thanks.

DK

|||actually, i've found the answer. whatever account used on the app pool need to have sysadmin, as this is the account that is updating/deleting the report. thanks.

Only members of sysadmin role are allowed to update or delete jobs owned by a different login

Question to those who may have had this same error- it seems that I am not able to delete some of the reports that I have created. This just started happening recently and according to our system admin nothing has changed as far as permissions are concernced. We installed SP2 the other day and I was wondering if this could have anything to do with the error message below

by the way I am a member of the sysadmin group

thanks in advance

km

System.Web.Services.Protocols.SoapException: Server was unable to process request. > System.Data.SqlClient.SqlException: Only members of sysadmin role are allowed to update or delete jobs owned by a different login. Only members of sysadmin role are allowed to update or delete jobs owned by a different login. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.ReportingServices.Library.InstrumentedSqlCommand.ExecuteNonQuery() at Microsoft.ReportingServices.Library.DBInterface.DeleteObject(String objectName) at Microsoft.ReportingServices.Library.RSService._DeleteItem(String item) at Microsoft.ReportingServices.Library.RSService.ExecuteBatch(Guid batchId) at Microsoft.ReportingServices.WebServer.ReportingService2005.ExecuteBatch() End of inner exception stack trace

my bad

I need to move this over to SSRS

km

|||

Moved to RS as requested.

The error though is more general than RS, in fact it is a standard SQL Server Agent message. Unless there is a bug, I'd say you really are not a member of sysadmins, or at least not in the context of the RS WS call that is doing the work on yoru behalf. That may be the issue, the security context used by the WS itself. Perhaps run a profiler trace and see what login is being used, and also what job it is trying to delete. You can then verify the job owner. There should not be a problem as you are managing a RS created job, so RS should be able to delete its own jobs... maybe it is a RS thing?

|||Thanks
your info did the trick-- the account used was not a member of sysadmin-- my bad
thanks again
kam|||

hi kam,

how did you solved the issue? i've added myself as the sysadmin on the server, but i'm still getting the same error. is there any other sysadmin than the sqladmin? thanks.

DK

|||actually, i've found the answer. whatever account used on the app pool need to have sysadmin, as this is the account that is updating/deleting the report. thanks.

Only able to access Report Manager as Administrator

Hi,

I have Reporting Services set up with the permissions (via Right Click Server/Permisions in SSMS or System Role Assignments in Report Manager) set as follows:

BUILTIN\Administrators - System Administrator

When logged in as an administrator I am able to access Report Manager, no problem.

However, I want to add a new group so that non-administrators can access Report Manager. However, whatever new item I add in the permissions appears to have no effect. For instance, if I add a permission for Users, i.e. :

BUILTIN\Administrators - System Administrator

BUILTIN\Users - System Administrator

I can still only access Report Manager as an administrator.. Any other user just gets the blank page.

I have tried creating a custom group, Report Users, with the same result.

I checked IIS to ensure anonymous access was turned off (this was an issue I had earlier on in my setup - it was turned on, but is now firmly off).

I don't know much about IIS, but I guess the problem is there somewhere. Does anybody have any idea what the problem could be and how I get around it?

Thanks very much in advance

Andy

Hi Andy! Reporting Services is Active Directory (AD) aware. If an AD group has been created (ex: reportusers), you can grant access to that group by going to the Home Folder in Report Manager and clicking on properties and then "New Role Assignment" where you would put something like this: DomainName\GroupID (ex: mydomain\reportusers).

If you are not using Active Directory, then please explain where (Report Manager or SQL Server Management Studio) you are creating your groups and how you have added security and we'll go from there.

|||

Hi Chuck,

Thank you so much for your reply.

I have to confess to not being an expert at Windows Server configuration.. and I'm not sure whether the server I am using employs Active Directory.. How can I tell?

I am creating the users in Admin Tools/Computer Management/Local Users and Groups.

I now have a user (MyUser) which is a member of a group (Report Users).

I have added this group in Management Studio (Right Click server/Permissions) as a System User. I am also able to add it via Report Manager/Site Security, it has the same effect.

What is interesting is that if I allow this group System Administrator access in Man. Studio, and I then log on as that user, I appear to have full access as I do for actual administrator users, but only within Management Studio. I still get the standard blank page (i.e. just "Home" bar but no visible reports) in Internet Explorer when connecting to Report Manager!

So there would appear to be some mismatch between what permissions I have within Report Manager versus Management Studio. My guess (and it's only a guess) is that there's either some IIS configuration that's wrong, or something in the security setup is blocking access via a web interface.

Hope this sheds some light on things.

Thanks again for your interest

Andy

|||

There are three types of Authentification in Reporting Services:

1) Integrated Windows Authentification (Active Directory aware) is the default authentification method for the Report Server and Report Manager virtual directories.

2) Anonymous access (only suggested if used with security extensions). Anonymous access limites your ability to vary role assignment because all users will access the Report Server under the Anonymous user account.

3) Basic Authentification, which should only be used with a Secure Sockets Layer (SSL) connection because Basic Authentification sends username and passwords to the server in clear text, which could be picked up with a network sniffer.

The Integrated Windows Authentification method is preferred and widely used. Your network administrator can setup Active Directory groups on the Domain Controller, which you can then grant those groups access to Reporting Services. If you network users have Unix, Mac, Novell or Linux accounts (non-Windows accounts) then you will need to go with Forms Authentification. Forms Authentification directs a request from an unauthenticated user to an HTML form, where they are prompted to enter a username and password. I have not used this method but many in this forum have and a quick search of the forum should return several useful posts.

|||

Hi Chuck,

Thanks very much for the information,

I am using Integrated Windows Authentication. The users I am dealing with are local to this server, it does not appear to be a domain server or to be part of a domain.

I can understand that my problem is to do with the security setup, but I can't get my head around what the difference is between accessing from Internet Explorer and accessing via Management Studio. It must, surely, be something to do with security for IIS rather than Reporting Services itself?

If so, can you give me any clues as to which permissions I should check and where? I can't tell whether it's withing IIS or some local policy on the server that is blocking the access.

Thanks again for your help and interest.

Regards,

Andy

|||

I eventually found out what this was..

It was nothing to do with Windows authentication - as I suspected because the access I granted worked in SSMS, but not via the web interface.

It was just that I had to add Browser access for my users via the Report Manager web interface .. on the home page/properties/New Role Assignment .. Once I did that everything worked as I had hoped.

A previous installation I carried out didn't require this.. I suspect that all users were granted Browser access by default, which wasn't the case here.

Thanks for your interest Chuck!

Andy

|||

Andy, I'm sorry I didn't suggest to verify the users had rights to the home page properties section first as this is required before giving them rights to any sub-folders you may create. I'm glad you figured this out and hope you enjoy reporting services as much as I have.

Only able to access Report Manager as Administrator

Hi,

I have Reporting Services set up with the permissions (via Right Click Server/Permisions in SSMS or System Role Assignments in Report Manager) set as follows:

BUILTIN\Administrators - System Administrator

When logged in as an administrator I am able to access Report Manager, no problem.

However, I want to add a new group so that non-administrators can access Report Manager. However, whatever new item I add in the permissions appears to have no effect. For instance, if I add a permission for Users, i.e. :

BUILTIN\Administrators - System Administrator

BUILTIN\Users - System Administrator

I can still only access Report Manager as an administrator.. Any other user just gets the blank page.

I have tried creating a custom group, Report Users, with the same result.

I checked IIS to ensure anonymous access was turned off (this was an issue I had earlier on in my setup - it was turned on, but is now firmly off).

I don't know much about IIS, but I guess the problem is there somewhere. Does anybody have any idea what the problem could be and how I get around it?

Thanks very much in advance

Andy

Hi Andy! Reporting Services is Active Directory (AD) aware. If an AD group has been created (ex: reportusers), you can grant access to that group by going to the Home Folder in Report Manager and clicking on properties and then "New Role Assignment" where you would put something like this: DomainName\GroupID (ex: mydomain\reportusers).

If you are not using Active Directory, then please explain where (Report Manager or SQL Server Management Studio) you are creating your groups and how you have added security and we'll go from there.

|||

Hi Chuck,

Thank you so much for your reply.

I have to confess to not being an expert at Windows Server configuration.. and I'm not sure whether the server I am using employs Active Directory.. How can I tell?

I am creating the users in Admin Tools/Computer Management/Local Users and Groups.

I now have a user (MyUser) which is a member of a group (Report Users).

I have added this group in Management Studio (Right Click server/Permissions) as a System User. I am also able to add it via Report Manager/Site Security, it has the same effect.

What is interesting is that if I allow this group System Administrator access in Man. Studio, and I then log on as that user, I appear to have full access as I do for actual administrator users, but only within Management Studio. I still get the standard blank page (i.e. just "Home" bar but no visible reports) in Internet Explorer when connecting to Report Manager!

So there would appear to be some mismatch between what permissions I have within Report Manager versus Management Studio. My guess (and it's only a guess) is that there's either some IIS configuration that's wrong, or something in the security setup is blocking access via a web interface.

Hope this sheds some light on things.

Thanks again for your interest

Andy

|||

There are three types of Authentification in Reporting Services:

1) Integrated Windows Authentification (Active Directory aware) is the default authentification method for the Report Server and Report Manager virtual directories.

2) Anonymous access (only suggested if used with security extensions). Anonymous access limites your ability to vary role assignment because all users will access the Report Server under the Anonymous user account.

3) Basic Authentification, which should only be used with a Secure Sockets Layer (SSL) connection because Basic Authentification sends username and passwords to the server in clear text, which could be picked up with a network sniffer.

The Integrated Windows Authentification method is preferred and widely used. Your network administrator can setup Active Directory groups on the Domain Controller, which you can then grant those groups access to Reporting Services. If you network users have Unix, Mac, Novell or Linux accounts (non-Windows accounts) then you will need to go with Forms Authentification. Forms Authentification directs a request from an unauthenticated user to an HTML form, where they are prompted to enter a username and password. I have not used this method but many in this forum have and a quick search of the forum should return several useful posts.

|||

Hi Chuck,

Thanks very much for the information,

I am using Integrated Windows Authentication. The users I am dealing with are local to this server, it does not appear to be a domain server or to be part of a domain.

I can understand that my problem is to do with the security setup, but I can't get my head around what the difference is between accessing from Internet Explorer and accessing via Management Studio. It must, surely, be something to do with security for IIS rather than Reporting Services itself?

If so, can you give me any clues as to which permissions I should check and where? I can't tell whether it's withing IIS or some local policy on the server that is blocking the access.

Thanks again for your help and interest.

Regards,

Andy

|||

I eventually found out what this was..

It was nothing to do with Windows authentication - as I suspected because the access I granted worked in SSMS, but not via the web interface.

It was just that I had to add Browser access for my users via the Report Manager web interface .. on the home page/properties/New Role Assignment .. Once I did that everything worked as I had hoped.

A previous installation I carried out didn't require this.. I suspect that all users were granted Browser access by default, which wasn't the case here.

Thanks for your interest Chuck!

Andy

|||

Andy, I'm sorry I didn't suggest to verify the users had rights to the home page properties section first as this is required before giving them rights to any sub-folders you may create. I'm glad you figured this out and hope you enjoy reporting services as much as I have.

Only able to access Report Manager as Administrator

Hi,

I have Reporting Services set up with the permissions (via Right Click Server/Permisions in SSMS or System Role Assignments in Report Manager) set as follows:

BUILTIN\Administrators - System Administrator

When logged in as an administrator I am able to access Report Manager, no problem.

However, I want to add a new group so that non-administrators can access Report Manager. However, whatever new item I add in the permissions appears to have no effect. For instance, if I add a permission for Users, i.e. :

BUILTIN\Administrators - System Administrator

BUILTIN\Users - System Administrator

I can still only access Report Manager as an administrator.. Any other user just gets the blank page.

I have tried creating a custom group, Report Users, with the same result.

I checked IIS to ensure anonymous access was turned off (this was an issue I had earlier on in my setup - it was turned on, but is now firmly off).

I don't know much about IIS, but I guess the problem is there somewhere. Does anybody have any idea what the problem could be and how I get around it?

Thanks very much in advance

Andy

Hi Andy! Reporting Services is Active Directory (AD) aware. If an AD group has been created (ex: reportusers), you can grant access to that group by going to the Home Folder in Report Manager and clicking on properties and then "New Role Assignment" where you would put something like this: DomainName\GroupID (ex: mydomain\reportusers).

If you are not using Active Directory, then please explain where (Report Manager or SQL Server Management Studio) you are creating your groups and how you have added security and we'll go from there.

|||

Hi Chuck,

Thank you so much for your reply.

I have to confess to not being an expert at Windows Server configuration.. and I'm not sure whether the server I am using employs Active Directory.. How can I tell?

I am creating the users in Admin Tools/Computer Management/Local Users and Groups.

I now have a user (MyUser) which is a member of a group (Report Users).

I have added this group in Management Studio (Right Click server/Permissions) as a System User. I am also able to add it via Report Manager/Site Security, it has the same effect.

What is interesting is that if I allow this group System Administrator access in Man. Studio, and I then log on as that user, I appear to have full access as I do for actual administrator users, but only within Management Studio. I still get the standard blank page (i.e. just "Home" bar but no visible reports) in Internet Explorer when connecting to Report Manager!

So there would appear to be some mismatch between what permissions I have within Report Manager versus Management Studio. My guess (and it's only a guess) is that there's either some IIS configuration that's wrong, or something in the security setup is blocking access via a web interface.

Hope this sheds some light on things.

Thanks again for your interest

Andy

|||

There are three types of Authentification in Reporting Services:

1) Integrated Windows Authentification (Active Directory aware) is the default authentification method for the Report Server and Report Manager virtual directories.

2) Anonymous access (only suggested if used with security extensions). Anonymous access limites your ability to vary role assignment because all users will access the Report Server under the Anonymous user account.

3) Basic Authentification, which should only be used with a Secure Sockets Layer (SSL) connection because Basic Authentification sends username and passwords to the server in clear text, which could be picked up with a network sniffer.

The Integrated Windows Authentification method is preferred and widely used. Your network administrator can setup Active Directory groups on the Domain Controller, which you can then grant those groups access to Reporting Services. If you network users have Unix, Mac, Novell or Linux accounts (non-Windows accounts) then you will need to go with Forms Authentification. Forms Authentification directs a request from an unauthenticated user to an HTML form, where they are prompted to enter a username and password. I have not used this method but many in this forum have and a quick search of the forum should return several useful posts.

|||

Hi Chuck,

Thanks very much for the information,

I am using Integrated Windows Authentication. The users I am dealing with are local to this server, it does not appear to be a domain server or to be part of a domain.

I can understand that my problem is to do with the security setup, but I can't get my head around what the difference is between accessing from Internet Explorer and accessing via Management Studio. It must, surely, be something to do with security for IIS rather than Reporting Services itself?

If so, can you give me any clues as to which permissions I should check and where? I can't tell whether it's withing IIS or some local policy on the server that is blocking the access.

Thanks again for your help and interest.

Regards,

Andy

|||

I eventually found out what this was..

It was nothing to do with Windows authentication - as I suspected because the access I granted worked in SSMS, but not via the web interface.

It was just that I had to add Browser access for my users via the Report Manager web interface .. on the home page/properties/New Role Assignment .. Once I did that everything worked as I had hoped.

A previous installation I carried out didn't require this.. I suspect that all users were granted Browser access by default, which wasn't the case here.

Thanks for your interest Chuck!

Andy

|||

Andy, I'm sorry I didn't suggest to verify the users had rights to the home page properties section first as this is required before giving them rights to any sub-folders you may create. I'm glad you figured this out and hope you enjoy reporting services as much as I have.

Only able to access Report Manager as Administrator

Hi,

I have Reporting Services set up with the permissions (via Right Click Server/Permisions in SSMS or System Role Assignments in Report Manager) set as follows:

BUILTIN\Administrators - System Administrator

When logged in as an administrator I am able to access Report Manager, no problem.

However, I want to add a new group so that non-administrators can access Report Manager. However, whatever new item I add in the permissions appears to have no effect. For instance, if I add a permission for Users, i.e. :

BUILTIN\Administrators - System Administrator

BUILTIN\Users - System Administrator

I can still only access Report Manager as an administrator.. Any other user just gets the blank page.

I have tried creating a custom group, Report Users, with the same result.

I checked IIS to ensure anonymous access was turned off (this was an issue I had earlier on in my setup - it was turned on, but is now firmly off).

I don't know much about IIS, but I guess the problem is there somewhere. Does anybody have any idea what the problem could be and how I get around it?

Thanks very much in advance

Andy

Hi Andy! Reporting Services is Active Directory (AD) aware. If an AD group has been created (ex: reportusers), you can grant access to that group by going to the Home Folder in Report Manager and clicking on properties and then "New Role Assignment" where you would put something like this: DomainName\GroupID (ex: mydomain\reportusers).

If you are not using Active Directory, then please explain where (Report Manager or SQL Server Management Studio) you are creating your groups and how you have added security and we'll go from there.

|||

Hi Chuck,

Thank you so much for your reply.

I have to confess to not being an expert at Windows Server configuration.. and I'm not sure whether the server I am using employs Active Directory.. How can I tell?

I am creating the users in Admin Tools/Computer Management/Local Users and Groups.

I now have a user (MyUser) which is a member of a group (Report Users).

I have added this group in Management Studio (Right Click server/Permissions) as a System User. I am also able to add it via Report Manager/Site Security, it has the same effect.

What is interesting is that if I allow this group System Administrator access in Man. Studio, and I then log on as that user, I appear to have full access as I do for actual administrator users, but only within Management Studio. I still get the standard blank page (i.e. just "Home" bar but no visible reports) in Internet Explorer when connecting to Report Manager!

So there would appear to be some mismatch between what permissions I have within Report Manager versus Management Studio. My guess (and it's only a guess) is that there's either some IIS configuration that's wrong, or something in the security setup is blocking access via a web interface.

Hope this sheds some light on things.

Thanks again for your interest

Andy

|||

There are three types of Authentification in Reporting Services:

1) Integrated Windows Authentification (Active Directory aware) is the default authentification method for the Report Server and Report Manager virtual directories.

2) Anonymous access (only suggested if used with security extensions). Anonymous access limites your ability to vary role assignment because all users will access the Report Server under the Anonymous user account.

3) Basic Authentification, which should only be used with a Secure Sockets Layer (SSL) connection because Basic Authentification sends username and passwords to the server in clear text, which could be picked up with a network sniffer.

The Integrated Windows Authentification method is preferred and widely used. Your network administrator can setup Active Directory groups on the Domain Controller, which you can then grant those groups access to Reporting Services. If you network users have Unix, Mac, Novell or Linux accounts (non-Windows accounts) then you will need to go with Forms Authentification. Forms Authentification directs a request from an unauthenticated user to an HTML form, where they are prompted to enter a username and password. I have not used this method but many in this forum have and a quick search of the forum should return several useful posts.

|||

Hi Chuck,

Thanks very much for the information,

I am using Integrated Windows Authentication. The users I am dealing with are local to this server, it does not appear to be a domain server or to be part of a domain.

I can understand that my problem is to do with the security setup, but I can't get my head around what the difference is between accessing from Internet Explorer and accessing via Management Studio. It must, surely, be something to do with security for IIS rather than Reporting Services itself?

If so, can you give me any clues as to which permissions I should check and where? I can't tell whether it's withing IIS or some local policy on the server that is blocking the access.

Thanks again for your help and interest.

Regards,

Andy

|||

I eventually found out what this was..

It was nothing to do with Windows authentication - as I suspected because the access I granted worked in SSMS, but not via the web interface.

It was just that I had to add Browser access for my users via the Report Manager web interface .. on the home page/properties/New Role Assignment .. Once I did that everything worked as I had hoped.

A previous installation I carried out didn't require this.. I suspect that all users were granted Browser access by default, which wasn't the case here.

Thanks for your interest Chuck!

Andy

|||

Andy, I'm sorry I didn't suggest to verify the users had rights to the home page properties section first as this is required before giving them rights to any sub-folders you may create. I'm glad you figured this out and hope you enjoy reporting services as much as I have.