次の方法で共有

Best Practices for Project Server 2010, 2013, and Online Permissions

  • [アーティクル]

The cardinal rule of permissions: Keep It Simple

 

  • The highest rule of permissions best practice is to keep your permissions scheme simple. 

    • If you can use the default categories, groups, and permissions with only minor changes, or none at all, do so!

    • Avoid creating unnecessary groups and categories. Having a large number of groups and categories within an instance of PWA can stress the authorization system, which can affect performance.

  • Use the default permissions set.

    • The default permissions in combination with the RBS (resource breakdown structure) checkboxes on Categories is sufficient to efficiently manage permissions in most customer situations with as little overhead as possible.

  • Always test permissions changes in a test environment on a copy of production data. 

    • Avoid making changes to production permissions without thorough testing.

    • Use Act as Delegate feature in your test environment to determine if your permissions changes have the impact you desire.

    • If you must change permissions directly in production, only check Allow checkboxes and avoid directly selecting Deny for anything.

  • Utilize the RBS checkboxes available on Categories and configure the RBS lookup table to mimic your org structure, then…Update the resources’ RBS values on a regular schedule.

    • A permissions scheme that relies on the RBS allows you to use the default permissions and allows resources to see only things based on their org structure or other breakdown structure as defined by the customer.

    • Utilizing the RBS mean you must frequently update the RBS for new resources or resources whose org structure changes.  Typically, this update should happen at least weekly. 

  • Avoid creating separate security groups for team members and project managers for each project plan.

    • This creates an administrative workload every time a project is created and then every time the project membership changes.

    • Imagine having 700 projects in flight and each has two security groups, one for project managers and the other for team members.

  • Avoid allowing or denying permissions on specific users.

    • The more cases where users have rights that differ from the groups they are in, the more trouble you will have figuring out why the permissions are broken for certain users.

  • Avoid utilizing Deny.

    • It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limiting your use of the Deny setting can simplify permissions management for large groups of users.

  • Configure the category and group permissions, then leave it alone.          

    • Changes to the permission scheme should be infrequent.

    • Once you have settled on a permissions scheme, leave it alone unless there is a clear business need and a formal request has been received.

  • Download the Project Server 2010 Administrators Guide from here for full descriptions of groups, categories, and permissions: https://technet.microsoft.com/en-us/library/gg663916(v=office.14).aspx

  • The Administrator group in PWA > Server Settings > Manage groups should not sync with any groups in AD.  An inadvertent problem with that group in AD could cause administrators to be locked out of PWA when the resource or group sync runs.