Report server service pack

How can I determine what version of service pack for reporting services is
installed on our servers?
I would deeply appreciate step by step instructions.
TIA...Go to http://yourserver/Reportserver
SP1 is Version 8.00.878.00
SP2 is Version 8.00.1038.00
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Trisha" <trisha@.nospam.nospam> wrote in message
news:567D207F-3AED-4D63-96C0-96B0A37C1671@.microsoft.com...
> How can I determine what version of service pack for reporting services is
> installed on our servers?
> I would deeply appreciate step by step instructions.
> TIA...|||Thank you Bruce.
What would version 8.00.743.00 refer to?
TIA...
"Bruce L-C [MVP]" wrote:
> Go to http://yourserver/Reportserver
> SP1 is Version 8.00.878.00
> SP2 is Version 8.00.1038.00
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Trisha" <trisha@.nospam.nospam> wrote in message
> news:567D207F-3AED-4D63-96C0-96B0A37C1671@.microsoft.com...
> > How can I determine what version of service pack for reporting services is
> > installed on our servers?
> >
> > I would deeply appreciate step by step instructions.
> >
> > TIA...
>
>|||That must be RTM (release to Manufacturing, i.e. the first release). That
means you have no service packs installed. Given all the fixes I strongly
recommend applying both service packs.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Trisha" <trisha@.nospam.nospam> wrote in message
news:630BE97F-B5D7-4083-87FC-714D990B90A1@.microsoft.com...
> Thank you Bruce.
> What would version 8.00.743.00 refer to?
> TIA...
> "Bruce L-C [MVP]" wrote:
> > Go to http://yourserver/Reportserver
> >
> > SP1 is Version 8.00.878.00
> > SP2 is Version 8.00.1038.00
> >
> >
> > --
> > Bruce Loehle-Conger
> > MVP SQL Server Reporting Services
> >
> > "Trisha" <trisha@.nospam.nospam> wrote in message
> > news:567D207F-3AED-4D63-96C0-96B0A37C1671@.microsoft.com...
> > > How can I determine what version of service pack for reporting
services is
> > > installed on our servers?
> > >
> > > I would deeply appreciate step by step instructions.
> > >
> > > TIA...
> >
> >
> >|||Bruce,
I just googled for 8.00.743.00 and it turns out to be the installation
version.
Thanks
"Bruce L-C [MVP]" wrote:
> Go to http://yourserver/Reportserver
> SP1 is Version 8.00.878.00
> SP2 is Version 8.00.1038.00
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Trisha" <trisha@.nospam.nospam> wrote in message
> news:567D207F-3AED-4D63-96C0-96B0A37C1671@.microsoft.com...
> > How can I determine what version of service pack for reporting services is
> > installed on our servers?
> >
> > I would deeply appreciate step by step instructions.
> >
> > TIA...
>
>|||Thanks Bruce...
"Bruce L-C [MVP]" wrote:
> That must be RTM (release to Manufacturing, i.e. the first release). That
> means you have no service packs installed. Given all the fixes I strongly
> recommend applying both service packs.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Trisha" <trisha@.nospam.nospam> wrote in message
> news:630BE97F-B5D7-4083-87FC-714D990B90A1@.microsoft.com...
> > Thank you Bruce.
> >
> > What would version 8.00.743.00 refer to?
> >
> > TIA...
> >
> > "Bruce L-C [MVP]" wrote:
> >
> > > Go to http://yourserver/Reportserver
> > >
> > > SP1 is Version 8.00.878.00
> > > SP2 is Version 8.00.1038.00
> > >
> > >
> > > --
> > > Bruce Loehle-Conger
> > > MVP SQL Server Reporting Services
> > >
> > > "Trisha" <trisha@.nospam.nospam> wrote in message
> > > news:567D207F-3AED-4D63-96C0-96B0A37C1671@.microsoft.com...
> > > > How can I determine what version of service pack for reporting
> services is
> > > > installed on our servers?
> > > >
> > > > I would deeply appreciate step by step instructions.
> > > >
> > > > TIA...
> > >
> > >
> > >
>
>|||When you said "both service packs," does that mean that SP2 doesn't include
fixes from SP1?
When I read through the SP2 docs it wasn't clear to me, but it seemed like
if I ran SP2 on an RTM or SP1 installation that I'd end up with equivalent
installations.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in
news:O9bvCaMUFHA.3244@.TK2MSFTNGP15.phx.gbl:
> That must be RTM (release to Manufacturing, i.e. the first release). That
> means you have no service packs installed. Given all the fixes I strongly
> recommend applying both service packs.
>|||SP2 includes everything that comes with SP1. So installing just SP2 is
sufficient.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Nerf Herder" <null@.notta.org> wrote in message
news:Xns964CAFD1F116Ejjjjjj@.207.46.248.16...
> When you said "both service packs," does that mean that SP2 doesn't
> include
> fixes from SP1?
> When I read through the SP2 docs it wasn't clear to me, but it seemed like
> if I ran SP2 on an RTM or SP1 installation that I'd end up with equivalent
> installations.
>
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in
> news:O9bvCaMUFHA.3244@.TK2MSFTNGP15.phx.gbl:
>> That must be RTM (release to Manufacturing, i.e. the first release). That
>> means you have no service packs installed. Given all the fixes I strongly
>> recommend applying both service packs.
>>
>|||I was a little sloppy with that statement. As Robert said, SP2 is all that
is needed to upgrade with.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Nerf Herder" <null@.notta.org> wrote in message
news:Xns964CAFD1F116Ejjjjjj@.207.46.248.16...
> When you said "both service packs," does that mean that SP2 doesn't
> include
> fixes from SP1?
> When I read through the SP2 docs it wasn't clear to me, but it seemed like
> if I ran SP2 on an RTM or SP1 installation that I'd end up with equivalent
> installations.
>
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in
> news:O9bvCaMUFHA.3244@.TK2MSFTNGP15.phx.gbl:
>> That must be RTM (release to Manufacturing, i.e. the first release). That
>> means you have no service packs installed. Given all the fixes I strongly
>> recommend applying both service packs.
>>
>|||Thanks
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in
news:#X0vnASUFHA.228@.TK2MSFTNGP12.phx.gbl:
> I was a little sloppy with that statement. As Robert said, SP2 is all
> that is needed to upgrade with.
>

Report Server Roles - Gaining access to

Does anyone out there know how to programatically determine the Role(s) of
the Logged In User running a report?
Thanks,
Bill MellOn Sep 19, 12:44 pm, "Bill Mell" <Bi...@.netforcement.com> wrote:
> Does anyone out there know how to programatically determine the Role(s) of
> the Logged In User running a report?
> Thanks,
> Bill Mell
You can pass back a hidden parameter from the report set to this
expression:
=User!UserID.ToString
Then in the stored procedure/query that is sourcing the report, run
the following query to obtain the associated roles.
SELECT R.ROLENAME
FROM REPORTSERVER.DBO.USERS AS U
INNER JOIN REPORTSERVER.DBO.POLICYUSERROLE AS P ON U.USERID = P.USERID
INNER JOIN REPORTSERVER.DBO.ROLES AS R ON P.ROLEID = R.ROLEID
WHERE U.USERNAME = @.UserName;
In this query, the @.UserName gets its value from the hidden parameter.
Hope this helps.
Regards,
Enrique Martinez
Sr. Software Consultant|||I am actually trying to get the information before the report actually runs.
I have a custom web page to gather parameters for the report.
It seems, that at the time the web page is called, the User!UserID is not
loaded (or if it is, it is empty)
It is in the web page that I need this info.
Do you know of a way to get that info in this scenario?
Thanks,
Bill Mell
"EMartinez" <emartinez.pr1@.gmail.com> wrote in message
news:1190254670.163591.20770@.y42g2000hsy.googlegroups.com...
> On Sep 19, 12:44 pm, "Bill Mell" <Bi...@.netforcement.com> wrote:
> > Does anyone out there know how to programatically determine the Role(s)
of
> > the Logged In User running a report?
> >
> > Thanks,
> > Bill Mell
>
> You can pass back a hidden parameter from the report set to this
> expression:
> =User!UserID.ToString
> Then in the stored procedure/query that is sourcing the report, run
> the following query to obtain the associated roles.
> SELECT R.ROLENAME
> FROM REPORTSERVER.DBO.USERS AS U
> INNER JOIN REPORTSERVER.DBO.POLICYUSERROLE AS P ON U.USERID = P.USERID
> INNER JOIN REPORTSERVER.DBO.ROLES AS R ON P.ROLEID = R.ROLEID
> WHERE U.USERNAME = @.UserName;
> In this query, the @.UserName gets its value from the hidden parameter.
> Hope this helps.
> Regards,
> Enrique Martinez
> Sr. Software Consultant
>|||We have created many User Aware Reports which pass the user id back to
the query which selects the data required.
It would seem the report should have this built in so no sensitive
data is called where as if you rely on the web page to pass this
parameter, there might be a security loop-hole.
You can pass other parameters from the web page which basically pass
these on to the parameters in the report.
If you run the report by itself and select the parameters you will see
them in the url.
The login/userid should be called there but rather as part of the
report itself as enrique has noted.
Regards,
Tom Bizannes
Microsoft Sql Server Specialist
http://www.macroview.com.au
Sydney, Australia

Report Server Authentication through Internet

We're trying to determine the best way to implement an authentication mechanism for our reporting services solution. Basically, we are exposing a web application to the internet, and allowing a forms authenticated user to access our report server somewhere within our intranet to view reports. I've browsed msdn and found that there are two approaches:

1. create a custom authentication extension for reporting services
2. create a restricted domain user that is allowed to access the report server

Going with approach 2 and assuming I'm using a ReportViewer control, in order to authenticate with the report server (using the one domain user created specifically for report server access), are we supposed to just provide an instance of an object implementing IReportServerCredential containing the domain user information to the Credentials property of the ReportViewer.ServerReport before accessing the report? Is this the correct way to implement approach 2? Also, if implementing approach 2 is so simple compared to approach 1, why would anyone choose to implement custom authentication extension if they don't need fine-grain access control on the report server level?

Thanks for any help and suggestions!If you use IReportServerCredential you essentially implement basic security since you need the user id and password. Instead, I'd recommend you use the identity of the asp.net process (application domain in IIS 6.0). You will need custom security if you need to propagate the user identity to the Report Server so RS can tell the users appart. If you don't need this then trusted account will be the recommended approach. You may find the following article useful.|||Thanks for the reply, Teo.

I read the article. So are you recommending that we run the ASP.Net process, hosting our custom application, under some domain account to grant it access to RS? Are there any security risks using this approach where we are granting the process (and all applications running under it in IIS 5.0, and at least the entire application pool itself in IIS 6.0) domain access? Or am I just misunderstanding this approach entirely? Thanks again for the help!|||Just to note that it doesn't have to be a domain account if the app and RS are on the same machine. Inherently, this approach is more secure because you don't need to deal with passwords.|||Hi Teo, thanks again for the reply.

The App and RS will be on separate machines. The App will be on a internet-facing webserver, whereas RS will be somewhere in an domain-access only machine. So I'm guessing I must run the App under a domain account.

How safe it is to have the domain account's user/pass stored in an encrypted .config file on the webserver machine, which would be read and passed (ie. basic) to RS for authentication on an domain-access only machine? And since I'm only passing these credentials between machines within my domain, isn't the passing of the credentials quite safe? And also this way, isn't it safer that the process running the application does not have more rights than it should at any time, while access to domain/RS is granted to the user only on a on-demand basis?

Sorry for asking so many questions.. I just want to understand all the pros and cons of each approach. Thanks a lot for the patience!|||

So I'm guessing I must run the App under a domain account.

Yes, you are right.

How safe it is to have the domain account's user/pass stored in an encrypted .config file on the webserver machine, which would be read and passed (ie. basic) to RS for authentication on an domain-access only machine?

As I mentioned, if you use IReportCredentials in ReportViewer you are essentially using Windows Basic security. The credentials will be passed base64-encoded between the app server and RS. But since this is on your internal LAN, it may not be a huge security risk for you. We followed this pattern with our applicaton for clients who don't have AD. The ReportViewer would read the credentials from a security service (stored in encrypted format), decrypt them and set them on the call.

|||Hi Teo,

Thanks a lot again for the reply.

As

I mentioned, if you use IReportCredentials in ReportViewer you are

essentially using Windows Basic security. The credentials will be

passed base64-encoded between the app server and RS.

Can I setup ReportServer to use SSL to even further secure this portion of the basic authentication within the LAN?
|||Sure, you can.|||Thanks, Teo.

Final question, can you tell me any security risks of running the asp.net under a domain account? Is there any possibility that that identity could be hijacked and maliciously used?|||None that I know of. With IIS 6.0 I recommend you set up a separate application pool. That way the domain identity will be scoped for the application only.|||Hi Teo,
You have answered all my questions. Thanks for all the replies you've given me on this thread. All your suggestions and pointers have been a great help. Thanks!!