Maping loging to users databases in SQL2000

I defined some jobs to move production database in analyst database on other
server. When jobs restore the database on analisys server, the login to the
user are not preserve. I've run an DTS to copy login from production server
to analisys server. Have anybody some clues about this problem. Thank you!Hi,
it is always better to make a script of all user logins created to restore
it over another server , BTW have you include users into that DTS package to
move !
:-)
Regards
--
Andy Davis
Activecrypt Team
---
SQL Server Encryption Software
http://www.activecrypt.com
"tudor" wrote:

> I defined some jobs to move production database in analyst database on oth
er
> server. When jobs restore the database on analisys server, the login to th
e
> user are not preserve. I've run an DTS to copy login from production serve
r
> to analisys server. Have anybody some clues about this problem. Thank you!
>
>|||Hi,
one more thing make me curious that why you make DTS to move DATABASE , is
backup /restore , attach / detach not working, how ever here is a article
FYI :
http://vyaskn.tripod.com/moving_sql_server.htm
:-)
Regards
--
Andy Davis
Activecrypt Team
---
SQL Server Encryption Software
http://www.activecrypt.com
"tudor" wrote:

> I defined some jobs to move production database in analyst database on oth
er
> server. When jobs restore the database on analisys server, the login to th
e
> user are not preserve. I've run an DTS to copy login from production serve
r
> to analisys server. Have anybody some clues about this problem. Thank you!
>
>|||Hi,
here is one more link for your joy , it will list associated role for users:
http://www.sql-server-performance.c...?TOPIC_ID=10504
Andy Davis
Activecrypt Team
---
SQL Server Encryption Software
http://www.activecrypt.com
"tudor" wrote:

> I defined some jobs to move production database in analyst database on oth
er
> server. When jobs restore the database on analisys server, the login to th
e
> user are not preserve. I've run an DTS to copy login from production serve
r
> to analisys server. Have anybody some clues about this problem. Thank you!
>
>

many users...all with different data

Just started looking at SQL Server Replication today. Just need to be shoved in the right direction...I have a 1000 users, and each need to have only their personal data replicated to them....So, is this possible, do I create a 1000 "articles" or do I create one article and somehow pass in a parameter?

This can be achieved using one publication with dynamic filtering. Basically you declare a filter like SELECT * FROM MyTable WHERE Somefield = host_name()

Then each time you setup a replica you enter the host_name or use the default which is the name of the computer.

That will filter one table then you can add joins to filter the rest of the database off that one table.

Martin

Many Installations of MSSQLSERVER.

G/day forum,
I've got a problem where all my Development users have full installations of
MSSQLServer. I want to disable this (for obvious security and financial
reasons) and allow SQL Server on a few dedicated (managed) Development SQL
servers.
This is what I'm thinking:
1) Active Directory - Group Policy Object. The problem is I cant find a
relevant template that incorporates the SQL Services.
2) Through Registry file modification of the Start value -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\MSSQLSERVER.
Either way I'll be deploying the change through Group Policy, and ideally I
would have a template that incorporated the SQL service, that way I wouldn't
have to directly go tampering with any registry files..
Your ideas and/or comments would be greatly appreciated.
Regards,
Steve.If you try using services control from GPO, to disable the
SQL services, what you will likely find is that developers
are resouceful and will just install a named instance of
SQL as the main service is named for the instance name.
You could cripple the other services which are not named
in an instance sensitive way, but SQL itself would escape
your net.
Also, whether setting the service to disabled through the
services portion of GPO or through direct tweaking of the
start key in the reg, this does not prevent them from installing
and running it. As they can install, they are apparently admins,
and as admins they can change the service to manual or auto
long enough to start it. When policy reapplies and sets it back
to disabled it does not necessarily also stop it. Now, you
may be able to combine setting the service to disabled with
software restriction policy so that they cannot start it, but if
you cannot be sure of the service instance name to disable it
then they could get it started by the system at boot.
To answer your actual question, I am not aware of a template
for use in GPO to manage SQL or its internal state.
So, what to do?
First - make sure you understand why the devs have SQL
installed. If your environment has legal VStudio on their
machines, it is very possible that they legally have the
dev version of SQL installed. Also, what are they working
on? Perhaps these are MSDE version of SQL and will ship
out packaged with what they are building.
It might be more simple to just force those machines to
have their patch level up-to-date. It might be better to
provide them with the client tools for SQL but require
them to use MSDE (which can be made to speak only
machine-locally and be unresponsive over the wire).
It would seem to me that the last thing one would want
to do is make their job harder. I can imagine a number
of dev scenarios in which forcing them to share a remote
SQL could complicate their lives, but then I am the one
with SQL server alway installed on the laptop ! On the
other hand, making use of a SQL server remote from the
apps they dev/test might be of value for the quality of
what they will ship. It may be worth exploring whether
this is so and you could find support in your objective
from their project mgmt, as with their being admins it
will be hard to make it so without also having cooperation.
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"The Poster" <nospam@.nospam_dontyoudare.net> wrote in message
news:OYDIBvH2EHA.2196@.TK2MSFTNGP14.phx.gbl...
> G/day forum,
> I've got a problem where all my Development users have full installations
of
> MSSQLServer. I want to disable this (for obvious security and financial
> reasons) and allow SQL Server on a few dedicated (managed) Development SQL
> servers.
> This is what I'm thinking:
> 1) Active Directory - Group Policy Object. The problem is I cant find a
> relevant template that incorporates the SQL Services.
> 2) Through Registry file modification of the Start value -
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\MSSQLSERVER.
> Either way I'll be deploying the change through Group Policy, and ideally
I
> would have a template that incorporated the SQL service, that way I
wouldn't
> have to directly go tampering with any registry files..
> Your ideas and/or comments would be greatly appreciated.
> Regards,
> Steve.
>|||Thanks for your detailed post Roger.
Would you believe that I've got the DBA and Project Managers support on this
one? This motion is driven by the DBA group and the Project group so as far
as support is concerned I'm on a winner. Question: Do you think that Client
side 'full installations' of SQL Server are costly, dangerous (remember
slammer?), and system intensive? The bottom line is that I have to figure
out some way of disabling the MSSQLSERVER service and all named instances
(and in time remove it) - to facilitate compliance I will be conducting
regular SQLScan's, where non-compliance will be dealth with. I have made
provisions for Client Tools (Query Analyzer, Enterprise Manager, etc) on the
DEvelopers systems - I appreciate these are essential tools that are needed
to perform there day to day duties.
In the longer term, I'm planning on revoking Developers Admin level
priviledge on all systems. I've been reading alot of what Keith Brown has
been saying with regards to Security, and I (like our Software Architect)
have been converted to the Longhorn concept of Least Priviledged User
account - that is the most secure way to go. I can even use our own Chief
Software Architect as an example, he had his system rebuilt 6 months ago,
and since that day he has manged to do 99% of his development work as a
Standard user.
Regards,
Steve.
"Roger Abell" <mvpNOSpam@.asu.edu> wrote in message
news:erAlTPR2EHA.1124@.tk2msftngp13.phx.gbl...
> If you try using services control from GPO, to disable the
> SQL services, what you will likely find is that developers
> are resouceful and will just install a named instance of
> SQL as the main service is named for the instance name.
> You could cripple the other services which are not named
> in an instance sensitive way, but SQL itself would escape
> your net.
> Also, whether setting the service to disabled through the
> services portion of GPO or through direct tweaking of the
> start key in the reg, this does not prevent them from installing
> and running it. As they can install, they are apparently admins,
> and as admins they can change the service to manual or auto
> long enough to start it. When policy reapplies and sets it back
> to disabled it does not necessarily also stop it. Now, you
> may be able to combine setting the service to disabled with
> software restriction policy so that they cannot start it, but if
> you cannot be sure of the service instance name to disable it
> then they could get it started by the system at boot.
> To answer your actual question, I am not aware of a template
> for use in GPO to manage SQL or its internal state.
> So, what to do?
> First - make sure you understand why the devs have SQL
> installed. If your environment has legal VStudio on their
> machines, it is very possible that they legally have the
> dev version of SQL installed. Also, what are they working
> on? Perhaps these are MSDE version of SQL and will ship
> out packaged with what they are building.
> It might be more simple to just force those machines to
> have their patch level up-to-date. It might be better to
> provide them with the client tools for SQL but require
> them to use MSDE (which can be made to speak only
> machine-locally and be unresponsive over the wire).
> It would seem to me that the last thing one would want
> to do is make their job harder. I can imagine a number
> of dev scenarios in which forcing them to share a remote
> SQL could complicate their lives, but then I am the one
> with SQL server alway installed on the laptop ! On the
> other hand, making use of a SQL server remote from the
> apps they dev/test might be of value for the quality of
> what they will ship. It may be worth exploring whether
> this is so and you could find support in your objective
> from their project mgmt, as with their being admins it
> will be hard to make it so without also having cooperation.
> --
> Roger Abell
> Microsoft MVP (Windows Security)
> MCSE (W2k3,W2k,Nt4) MCDBA
> "The Poster" <nospam@.nospam_dontyoudare.net> wrote in message
> news:OYDIBvH2EHA.2196@.TK2MSFTNGP14.phx.gbl...
installations[vbcol=seagreen]
> of
SQL[vbcol=seagreen]
ideally[vbcol=seagreen]
> I
> wouldn't
>|||Hi Steve,
Many strands triggered in your reply.
It is great that you do have the buy-in to do things well,
and even better to hear that the LUA objectives of least
access have taken root.
First, one thing you mentioned was security of multiple
installs, if things were that way. You should be aware
that you can use the patch checking engine of the current
version of MBSA (MS Baseline Security Analyzer) to
check service pack and security patch level of SQL and
MSDE installs. From a machine where MBSA is installed
drop to a cmd prompt, cd to the MBSA install dir, and issue
mbsacli -hf -?
You can provide list of target machines in file, etc..
Now, this does not of course address the majority of SQL
install wellness issues like sane sa acct, accts/groups in
the SA server role, use of external procs, etc.. But, with
hfnetchk scan showing you 1) what machines did not let
you scan and 2) what machines have SQL and/or MSDE
instances you on staff DBA could no doubt come up with
a sproc that could interrogate those for the basic sanity
checklist of config items. Now, a last word on the use of
MBSA in this way. In addition to administrative rights on
the target machines, the hfnetchk scan will not work if the
targets are firewalled (doh - but for completeness mentioned),
if they do not have at least C$ shared (the admin shares, but
I have found that I really only need at least a temp C$ allowing
administrators even though the target has admin shares off, and
this one can turn on with remote script prior to the scan), or if
the remote registry service is shut off (again, can be started by
remote script prior to the scan).
Next, you made a mention of cost. I do not know whether your
shop is VStudio based, Delphi, or what. If VStudio it is now
pretty hard to not have license allowing dev version of SQL,
but you need to check what and how the dev shop is licensed.
Unless I am mistaken, as a holder of an SQL Server license
you are allowed client tools install without limit. I am no final
word on licensing matters. MSDE is of course free, and IIRC
the terms have loosened considerably from initial days.
I need to review whether the new mgmt interface tool MS has
released into beta is in the open beta, but that provides another
alternative relative to the client tools install.
It seems to me that a potentially compelling way to go would
be to look at central support of the main dev/test, but also
look at facilitating (temporary) dev local MSDE installs
(or better SQL Express - but that is a versioning issue no
doubt for the app release cycle). You could easily set up
such MSDE so that it gets a copy of a test suite DB loaded
into it with DTS from the dev/test SQL Server. Finally, if the
dev/test SQL Server is Enterprise version, it can accomodate
scenarios for devs in named SQL instances.
Anyway, it seems that there are a number of routes that are
cheap to free and within (what I understand of) licensing
(of course we did not mention CALs or per-proc lics).
So, other than periodic MBSA hfnetchk scans to know where
there is an SQL install (of course you could do that with a
script that just does some WMI poking into the registries of
the systems looking at the MSSQLServer keying - but MBSA
also gives basic health of the bits) how could you exert some
form of enforced control ? Like I said in initial post, about
the best idea I can come up with is to use software restriction
policies via GPO that impacts these dev machines. With it
you could prevent the users from running short list of key exes,
and of course you can have the GPO set the known / commonly
seen service instance names to disabled (it does not hurt to have
services named that are not on machines in scope of the GPO).
All this is totally circumventable while they are local admins.
However, it might just trigger enough of a hurdle to give them
pause to thing better of what they were about to try. With much
regret, the bottom line is that admins can, and that an example
semi-gently hung by the nails outside the coffee room has more
impact that all of the preparatory emails/notices of policy added
together. Getting them able to work as non-admins is IMHO
the key, both to your objectives here, and to the software
quality delivered (I have a total dislike of "well written",
and "well tested" apps which were however never tested by
a non-admin account !!).
Good luck Steve,
Roger
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"The Poster" <nospam@.nospam_dontyoudare.net> wrote in message
news:eEP$onR2EHA.3236@.TK2MSFTNGP15.phx.gbl...
> Thanks for your detailed post Roger.
> Would you believe that I've got the DBA and Project Managers support on
this
> one? This motion is driven by the DBA group and the Project group so as
far
> as support is concerned I'm on a winner. Question: Do you think that
Client
> side 'full installations' of SQL Server are costly, dangerous (remember
> slammer?), and system intensive? The bottom line is that I have to figure
> out some way of disabling the MSSQLSERVER service and all named instances
> (and in time remove it) - to facilitate compliance I will be conducting
> regular SQLScan's, where non-compliance will be dealth with. I have made
> provisions for Client Tools (Query Analyzer, Enterprise Manager, etc) on
the
> DEvelopers systems - I appreciate these are essential tools that are
needed
> to perform there day to day duties.
> In the longer term, I'm planning on revoking Developers Admin level
> priviledge on all systems. I've been reading alot of what Keith Brown has
> been saying with regards to Security, and I (like our Software Architect)
> have been converted to the Longhorn concept of Least Priviledged User
> account - that is the most secure way to go. I can even use our own Chief
> Software Architect as an example, he had his system rebuilt 6 months ago,
> and since that day he has manged to do 99% of his development work as a
> Standard user.
> Regards,
> Steve.
>
> "Roger Abell" <mvpNOSpam@.asu.edu> wrote in message
> news:erAlTPR2EHA.1124@.tk2msftngp13.phx.gbl...
> installations
financial[vbcol=seagreen]
> SQL
a[vbcol=seagreen]
> ideally
>|||You can use Group Policy [for example, via Active Directory] to set
MSSQLSERVER service on Windows 2000, XP and 2003 systems to be disabled by
default. This is probably easier than using Group Policy Software
Restrictions Policy [though if they are local Administrators on their
computers, it might be less secure, I don't really know]. On a computer
running the MSSQLSERVER service, run MMC, add the Security Templates MMC,
create a new GP template where the only change is to the startup value of
the service and possibly the permissions of who can manage the service.
Save the template, apply the security template to the workstations in
question [e.g. use a batch file with the SECEDIT command to create a new
database and import and apply the template on each target workstation, OR
import the template into your active directory and apply that template to
target workstations by putting the workstations into an OU and/or
configuring ACL permissions on which workstations can read that GP. If you
use AD GP, be sure not to accidentally apply the policy to your legitimate
SQL servers.]
If these people's accounts are in the local Administrators or Power Users
group on the workstations, they can undo just about anything you do. Group
Policy will change their changes back, but I'm not sure this will stop the
SQL service once they start it. It's hard to prevent Administrators or
Power Users from doing what they want to do. There are some ways Power
Users can escalate their privileges to Administrator if they know how.
Unless something has changed in the latest version of MS SQL Server, SQL
Server cannot be installed on Windows workstations, only servers. AFAIK,
you can install MSDE on workstation, or if you install the SQL server CD, it
installs the SQL administrator tools and not the server itself.
"The Poster" <nospam@.nospam_dontyoudare.net> wrote in message
news:eEP$onR2EHA.3236@.TK2MSFTNGP15.phx.gbl...
> Thanks for your detailed post Roger.
> Would you believe that I've got the DBA and Project Managers support on
this
> one? This motion is driven by the DBA group and the Project group so as
far
> as support is concerned I'm on a winner. Question: Do you think that
Client
> side 'full installations' of SQL Server are costly, dangerous (remember
> slammer?), and system intensive? The bottom line is that I have to figure
> out some way of disabling the MSSQLSERVER service and all named instances
> (and in time remove it) - to facilitate compliance I will be conducting
> regular SQLScan's, where non-compliance will be dealth with. I have made
> provisions for Client Tools (Query Analyzer, Enterprise Manager, etc) on
the
> DEvelopers systems - I appreciate these are essential tools that are
needed
> to perform there day to day duties.
> In the longer term, I'm planning on revoking Developers Admin level
> priviledge on all systems. I've been reading alot of what Keith Brown has
> been saying with regards to Security, and I (like our Software Architect)
> have been converted to the Longhorn concept of Least Priviledged User
> account - that is the most secure way to go. I can even use our own Chief
> Software Architect as an example, he had his system rebuilt 6 months ago,
> and since that day he has manged to do 99% of his development work as a
> Standard user.
> Regards,
> Steve.
>
> "Roger Abell" <mvpNOSpam@.asu.edu> wrote in message
> news:erAlTPR2EHA.1124@.tk2msftngp13.phx.gbl...
> installations
financial[vbcol=seagreen]
> SQL
a[vbcol=seagreen]
> ideally
>|||"Karl Levinson, mvp" <levinson_k@.despammed.com> wrote in message
news:uM8hgEg2EHA.1564@.TK2MSFTNGP09.phx.gbl...
> You can use Group Policy [for example, via Active Directory] to set
> MSSQLSERVER service on Windows 2000, XP and 2003 systems to be disabled by
> default. This is probably easier than using Group Policy Software
> Restrictions Policy [though if they are local Administrators on their
> computers, it might be less secure, I don't really know]. On a computer
We have pretty much beaten that avenue to death Karl.
The issue is that the registered name of the service is not
a predictable constant.

> running the MSSQLSERVER service, run MMC, add the Security Templates MMC,
> create a new GP template where the only change is to the startup value of
> the service and possibly the permissions of who can manage the service.
> Save the template, apply the security template to the workstations in
> question [e.g. use a batch file with the SECEDIT command to create a n
ew
> database and import and apply the template on each target workstation, OR
> import the template into your active directory and apply that template to
> target workstations by putting the workstations into an OU and/or
> configuring ACL permissions on which workstations can read that GP. If
you
> use AD GP, be sure not to accidentally apply the policy to your legitimate
> SQL servers.]
> If these people's accounts are in the local Administrators or Power Users
> group on the workstations, they can undo just about anything you do.
Group
> Policy will change their changes back, but I'm not sure this will stop the
> SQL service once they start it. It's hard to prevent Administrators or
> Power Users from doing what they want to do. There are some ways Power
> Users can escalate their privileges to Administrator if they know how.
> Unless something has changed in the latest version of MS SQL Server, SQL
> Server cannot be installed on Windows workstations, only servers. AFAIK,
> you can install MSDE on workstation, or if you install the SQL server CD,
it
> installs the SQL administrator tools and not the server itself.
One may install either on non-servers.
The "personal" install of SQL Server on a workstation is
effectively a full standard edition install with some minor
imposed limitations and some licensing differences.

>
> "The Poster" <nospam@.nospam_dontyoudare.net> wrote in message
> news:eEP$onR2EHA.3236@.TK2MSFTNGP15.phx.gbl...
> this
> far
> Client
figure[vbcol=seagreen]
instances[vbcol=seagreen]
> the
> needed
has[vbcol=seagreen]
Architect)[vbcol=seagreen]
Chief[vbcol=seagreen]
ago,[vbcol=seagreen]
> financial
Development[vbcol=seagreen]
find[vbcol=seagreen]
> a
>sql

Manual Installation of Printing ActiveX Control

I have a issue. My users that run RS Reports do not have administrative priviledges to install the ActiveX control required to use the Print function for an RS Report. Currently, the only way they can print the report is to export the report to another format before printing.

Is there a way to manually install the ActiveX Control. I need to install the control on about 200 users, possibly through network logins scripts.

Any help would be appreciated.

Thanks.

did you ever resolve this issue? we're running into the same.

any help is appreciated.

Manual Authentication from a Database

Assuming that I have a table [users] in a MSSQL 2005 database. the table has two columns. [userId] and [password].

I have an aspx with C# page with two textboxes and a button.

I want to let the user login or send him an error message if the password or the username does not match from the table in database.

I always made this possible through the template database from administrating the website. but never tried to do it as simple as that. I'm lost here!

How can I do it?

well this is full fledges program you are asking us to write, which of course is not the place, but i can tell you steps you can follow.

1. drop two text boxes on form txtUsername and txtUserPassword

2. Make SQL Connection with your database

3. Write a function that connect to your DB and pass the select query with where clause of user name and password (select * from users where userId = ' + txtUserName + ' and password = ' + txtUserPassword + ')

4. If query return records you can ask your function return true indicates valid user or otherwise bad user.

|||

Is there any usefull link that takes these steps in details? any website of your recommendation! anything?

I have to hand on a project in 12/May that uses this kind of authentication!

|||Hi,

Here's the code you can refer:

The Button1_Click Event:

protected void Button1_Click(object sender, EventArgs e) {string username =this.TextBox1.Text;string password =this.TextBox2.Text;// connstr is the name of connection string you set in Web.Configstring conn = ConfigurationManager.ConnectionStrings["connstr"].ConnectionString; SqlConnection myconn =new SqlConnection(conn); sqltxt ="select * from UserTable where username = '"+username+"' and password = '"+password+"'"; SqlDataAdapter myadpt =new SqlDataAdapter(sqltxt, myconn); DataSet myds =new DataSet(); myadpt.Fill(myds);if (myds.Tables[0].Rows.Count > 0) {// login successfully }else {// error message } }

aspx file:

<asp:TextBox ID="TextBox2" runat="server"></asp:TextBox><asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Button" />

Thanks.

managing users

Hello,

Has anyone ever come across a reason why someone would manually create a
user table incl. permission flags and not use the inbuilt user/roles
provided by that database? The only reason that stands out for me is to
make the database that bit more portable?

Thanks,
Craig.Craig, it would depend on exactly how the table in question is
constructed and used but some applications provide application based
security. The application might connect to the database using one ID
that is the database owner or has both datareader and datawriter but
via the application limit what end-users can do.

HTH -- Mark D Powell --|||Craig H. (spam@.thehurley.com) writes:
> Has anyone ever come across a reason why someone would manually create a
> user table incl. permission flags and not use the inbuilt user/roles
> provided by that database? The only reason that stands out for me is to
> make the database that bit more portable?

The database-level can be a bit heavy-handed. In our application, our
security scheme on SQL Server is dead simple. All users are added to
a group, and that group is granted execute access on all stored procedures
and select access on most tables.

Then our database includes tables to control access to application
functions, and also access to which accounts and customers a user may
see.

True, our system started its life in the days of 4.x when the permission
system in SQL Server was far less sophistcated than today. But since
our securable entities are not SQL Server entities, I can't see how
SQL Server could help us, even if we were to make a complete restart.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Managing Reporting Services Users

Good afternoon,

I've just started using SQL Server 2005 Reporting Services and after managing to deploy it, on the dev server, I've found myself unable to manage the users that can access it. After searching on the web I've noticed that only windows users can access Reporting Services (unless you develop your custom authentication system using the extentions). That's ok for now, the problem is that I can't seem to find where to assign permissions to the windows users.

The bottom line is that I would like configure reporting services in a way that some users can add reports while others can only view them, as well as making their own using ad-hoc reports. Could someone help me out with this? :)

I started to answer a similar question here:http://forums.asp.net/thread/1573629.aspx

Within the security area you will see the different type of access that are available:

Browser Role : Run reports and navigate through the folder structure.

Content Manager Role : Define a folder structure for storing reports and other items, set security at the item level, and view and manage the items stored by the server.

Report Builder Role: Build and edit reports in Report Builder.

Publisher Role: Publish content to a report server.

My Reports Role : Build reports for personal use or store reports in a user-owned folder.

System Administrator Role: Enable features and set defaults, set site-wide security, create role definitions, and manage jobs.

System User Role : View basic information about the report server such as the schedule information in a shared schedule.

'Roles Copied straight outta the help'

I've found it's easier to set up Global groups within the Active Dir and add them to RS2005, it's a lot easier to manage the users.