Project Server Help Blog

When you start making changes to security in Project Server during high-activity business hours, you run the risk of interrupting your users. Project Server uses a common programming approach to synchronizing data by rebuilding the target data store rather than attempting to make programmatic changes to the data based only on deltas. In other words, when you make a change to Project Server security that affects a user, during the permissions synchronization process, the system actually removes all permissions from the user and then applies an all new permission set that includes the net effects of the changes. Given that the system first removes permissions from all affected users, and then applies all new permissions, on systems with hundreds of users and projects, a noticeable gap can develop between the time the permissions are cleared and the new ones set so that users who are active on the system can get seemingly-spurious access denied messages or messages that suggest that they may not have the correct permissions. Under these circumstances, these messages are not the least bit spurious as the user actually has no permissions in the system when the system is between these operations.

Project Server administrators are best advised to make changes to Project Server security early in the morning or after business hours, and only after notifying your users of a maintenance window, just as you would do to apply upgrades and patches to the application software or operating system. Test your changes on your Dev server or sandbox before making your changes in production. Most of all, be nice to your users and spare yourself support calls that you cannot resolve, because these problems are very unlikely to happen while you are troubleshooting connectivity problems rather than making security changes.