Database and permissions quandry

[JB Fields]

Two students installed Project Server. They are the first office to
impliment it in their company. They have been trained and are setting out
to work in the operational environment the way technicians installed it.
The first thing that the office manager noticed is that he could not manage
users and groups as he was taught. He also could not apply templates to the
users.

I'm told that if we give him permissions to manage users and groups that he
will have the ability to manage people in other work areas (and vice versa
for those with similar needs) unless his work area is placed in a seperate
database.

My concern is that putting things in separate databases will eliminate
enterprise reporting capabilities across all work areas, which is why the
investment in Project Server was made. He's working around with manual
settings for users, but it seems like there should be a way for him to add
new people without involving a technician who does have the manage user &
groups right.

 

[Marc Soester]

Hi JB,

The security in Project Server can be very complex. It is possible to manage
different users based on the RBS ( Resource Breakdown Structure) This
structure is an Resource Outline Code and is already set up as an Outline
Code.
Based on this RBS you have the ability to allow certain access to different
users. You may want to involve a EPM Partner to get this right.
Hope this helps

 

[JB Fields]

That sounded just about like Novel before so many of us decided to dump
Netware. "Who's your CNE?" instead of providing clear manuals and good user
support. You suceeded in sounding important without answering a question,
or being particularly helpfull--a contrast to what we hear from the open
source community.

These newsgroups have been advertised to be a source of value for Microsoft
customers. I frequently point students in this direction. If the trend is
to present those seeking knowledge with fees instead of help, then there
will be one less reason for being a Microsoft customer or a
Microsoft-aligned technical professional.

The questions asked were specific enough to serve as a starting point for a
reasonable conversation. You chose questions arrising from a first
experience with this new product as an opportunity to advertise higher-cost
services rather than point us in the direction of becoming EPM specialists,
ourselves. I asked these questions,in this forum, so that students could
follow a conversation that I expected to be a good follow-on to the training
already provided, and partly so they would be encouraged to employ this
resource themselves in their employment and future careers.

I suspect that whether or not a special role is created in the RBS, the
quesion of what "manage user and goup" permissions enable that role to do
across the enterprise will remain, as will the concerns of administrators
who won't let us go there, currently. Probably, the question of database
partitions and enterprise reports--which is almost a simple yes or no; yes
it matters, no it does not--remains as well.

EPM Partner expenses seem to have been missing from sales pitches. Time for
somebody to write a review of the product that looks at TCO and benefits in
a correct perpective. Or maybe we need to point out that while Microsoft
talks about needing to improve the quality of training and training
professionals, the one thing they most controll, their official curriculum,
is the weak link in the chain. I wonder what EPM they paid to develop it.

 

[Gary L. Chefetz [MVP]]

JB:

IMO, you need to be a lot more specific with your questions. How far have
you gone to find the answers to these questions? You're certainly not going
to find answers on a soap box.

 

[jbfields]

Okay, you market EPM's as the answer. I'll complain. You call it a
complaint a soap box and you can ignore it. "Mind over matter:"
Microsoft doesn't mind and customers don't matter.

 

[jbfields]

Sorry, I'm overly sensitive to Microsoft products incurring additional
expenses. The EPM suggestion got under my skin. I want to know how to
do things, myself; and I hope those I teach will become self sufficient
as well. Telling folks who've just taken a class, "Now go hire a
consultant," is a horrible idea.

Classroom training provides a somewhat canned approach, but students do
set up a RBS. The students, returning to their work areas, find an
implimentation that is not a classroom configuration. The area manager
finds permissions are not as unrestrained. He is probably not an
administrator and cannot apply templates to users. Even though he can
restrict some users to read-only permissions, the users find they still
have the ability to modify things. He calls a meeting with technicians
who installed Project. After the meeting, technicians experiment and
learn that the inability to apply templates boils down to his account
not having "manage users and groups" permission. They experiment
further and learn that once this permission is granted the person to
whom it is granted is unrestricted and able to modify users across the
entire implimentation, probably the result of being in the Resource
Managers group.

Perhaps a quick question, here, might be whether this is the default
behavior if there is no RBS.

Being in different locations, there are limits on how much I can
explore and experiment. I did visit to see the problem and attended a
later meeting with the technicians who installed it. I could not
identify any group memberships that were giving users the rights to
access and modify project information, but may have missed something.

The possible solutions they see are:

1) to allow area managers such unrestrained access to one another's
resources.

2) place each work area's projects in a separate database.

3) to keep the permission restricted and require the area manager to
submit change requests to the technical staff.

Marc suggested...

4) using a RBS to solve the problem.

Questions arrising focus upon the behavior of default groups and
categories when there is no RBS.

I did not know, until I just read your book, that choosing RBS or
Enterprise Resource Outline Code 30 employs a direct link to security,
so I now see how that is probably the best answer. I'm still not
certain that this has a connection to security other than PWA views.
Courseware is vague. Your book does a good job of emphasizing the
significance that there is no default RBS. Microsoft courseware can
leave one thinking these are more like user configurable fields in
Exchange--mostly for cosmetic purposes.

The question about separate databases remains because I hear that this
is how the problem has already been resolved elsewhere (by setting up
separate databases for each division). Someday reporting will want to
become integrated. More simply, what happens when organizations using
Project Server merge? I guess the migration process is the answer. I
wanted to think, and hoped, someone would say that there was an OLAP
solution to reporting with disparate databases, but can now see how
differences in RBS definitions, if they were imposed, would defeat such
an approach.

The question I'm left with is whether RBS is the only way to restrain
members of the Resource Managers group? It seems there should be an
easier way. In some organizations, it seems to me that defining RBS
could require a committee, months of effort, two boy scounts, and the
killing of a small horse.

 

[Gary L. Chefetz [MVP]]

JB:

To some degree, your post supports the suggestion you're reeling against
most.<g>

IMO, you draw the line around a database based on resource usage. When
practice groups, or organizational divisions of any type, share resources on
their projects or are in any way co-constituents of the same portfolio of
projects, they should be incorporated into one database. When deployment
instances do not have overlapping resource pools, separate databases is a
viable option.

When working within an instance, the RBS is the way to resolve the conflicts
you're experiencing.

I fix a lot of things around my house, but I didn't build it. I don't feel
any less worthy for not having done so.

 

[JB Fields]

The separation has been already made because of information sensitivity
rather than the resources which can be shared. I've re-read sections on the
database and am still not certain whether or not analysis services can
straddle the differences and consolidate it all. The good news is that
resource names are consistent. Part of the difficulty that I think people
are finding is the lack of owners having permissions like NTFS full control
on projects and "their" resources. I see that we are building that back in
with RBS.. and more, but it is a rather manual exercise compared to the NTFS
ownership approach which they don't really see happening.

Thanks for the reply.