Adding Users in a Test Project Server Environment

Ran into this problem a couple of weeks ago and figured it was worth a post.  I’d created a new instance in a test domain (tAD) to support training.  This domain had a one way trusted relationship to our production domain (pAD).

However, I kept running into an issue.  Whenever I’d go into Project Server (2010) and add a user from pAD, I would get the following error message.

image

For the search engines…..

The resource could not be saved due to the following reasons:

  • The NT account specified is invalid.  Check the spelling of the user name, verify that a valid domain name was included, and check that a duplicate domain was not used.

I’m sure there’s a more elegant solution, but the workaround we determined was to have each of the training students hit the new environment (which predictably resulted in them getting an Access Denied message).  Once they’d hit it at least once, I could safely add them to the Project Server user groups.

Advertisements
Adding Users in a Test Project Server Environment

Project 2013 On-Premises: The Missing Settings

For those of you just dipping your toes into the new world of Project Server, you might have noticed some key settings that are now missing from the main Server Settings screen.

The first thing you may notice are all of the missing security settings.  Here’s the default.

image

And here’s the same screen with all of the settings displayed.

image

The basic issue here is that Project Server now operates in two security modes: SharePoint and Project Server.  The default is SharePoint mode which leverages the SharePoint security model.  With some Powershell commands, we can enable the Project Server (or “Classic”) mode.

Here’s the technical reference: http://technet.microsoft.com/en-us/library/jj219486(v=office.15).aspx

Aside from that, you’ll also note that some of the settings have been moved to Central Admin – which makes them inaccessible to Project Online users.  For on-premises deployments, you’ll want to make sure that you include these on your configuration checklist.

Click on the PWA Service Application, highlight the PWA site, and select Manage.

image

From there you’ll see the available settings.

image

And just so the search engines will pick it up:

  • Queue and Database Administration
  • Manage Queue Jobs
  • Daily Schedule Backup
  • Administrative Backup
  • Administrative Restore
  • OLAP Database Management
  • Operational Policies
  • Alerts and Reminders
  • Additional Server Settings
  • Server Side Event Handlers
  • Project Site Provisioning Settings
  • Bulk Update Connected SharePoint Sites
  • Workflow and Project Detail Pages
  • Project Workflow Settings
Project 2013 On-Premises: The Missing Settings

Creating a Secure Enterprise Project Type

Here’s an interesting question that popped up recently…how does one secure a specific Enterprise Project Type within Project Server 2010 so that only specific people may be able to create it?

Process Overview

Let’s start off by reviewing the specific business scenario.  We have an organization that has small, medium, and large projects.  Each of those projects is mapped to various initiation processes and has been assigned a specific enterprise project type (EPT).

image

All large projects must go through an executive approval process, which for now is a manual application.  The application process happens through the use of a form, which then gets signed by the relevant executives.  Once the appropriate signatures have been received, the PMO administrative assistant creates the project record based on the form.

The other path is that users may create a Medium project, then apply to get that project promoted to a Large project.  The application process is the same as defined above, and once the approvals are in place, the PMO administrative assistant will promote the Medium project to a Large project using the Change Workflow button on the Project Center ribbon.

The challenge was that the users were getting confused and would go ahead and create a Large project – even when the approval hadn’t yet been completed.  We initially attempted to train this behavior away, but found a need for more effective enforcement mechanisms.

Honestly, my first thought was to implement some sort of workflow on the backend to ensure that only authorized users would create the restricted project type.  Of course, that would imply that I would have to actually get up and talk to a developer….something I try to avoid at all costs.  (Besides, that’s what the TFS Integration Pack is for, so I never again have to actually talk to a developer.)  Smile  Then, I realized there’s a pretty simple no code solution.

Modifying the Resource Department Field

Enter the workaround.  First off, we need to look at the Resource Department field.  By default, this is a single-select field, i.e. only one value may be entered.  If you’re not really using this field, great.  Leave it as it is and continue following the instructions below.

image

If you are using this field, then you may wish to consider changing it to a multivalue field.  Before you do that though, a couple caveats….

  1. Changing a field from single value to multivalue is irreversible.  You may not change it back.
  2. Changing a field to multivalue makes it much harder to bring into the Office Data Connection files you may be using to support your BI reporting.  Review the SDK for guidance on incorporating multivalue fields in the ODC queries.
  3. Changing a field to multivalue may potentially break your OLAP cubes.  See this post from Brian Smith for a nice synopsis.  That being said, in my preliminary testing, new cubes built after the field change seemed to work just fine.
  4. Even if you don’t break your cube, adding resources to multiple departments may cause odd numbers to appear in your enterprise OLAP cubes, i.e. a resource in “HR” will show in a different department than a resource flagged to “HR, Admin.”  Of course in this case, we’ll simply change the values for our administrative assistants or PMO members – who may not be under the same scrutiny for remaining capacity as a more technical resource.

That being said, if you have already changed the field to a multivalue, then ignore all of those caveats, and feel free to continue.

The next step is to add a new department to the Department lookup table referenced by the Resource Departments field.  I will call this new department “PMO Administration.”

image

Mapping the EPT and Resources

Map the Large project EPT to the PMO Administration department.

image

One more step remaining.  Pick the individuals who will be allowed to create the Large projects and add them to the PMO Administration department.  In this case, I’ll use Niraj Shah as an example.  I modify his record to include the right department.

image

Reviewing the Results

Now let’s test it out.  I navigate to the Project Center and select the option to create a new project.  I don’t see the option to create a Large project. (Good)

image

I try to change the project type by selecting a project, then clicking on the Change button on the ribbon.  Again, there is no option to promote a project to a Large project. (Good)

image

Now, I log in as Niraj’s delegate to see what his experience would be like.  In Project Center, I now have the option to create a new Large project. (Good)

image

…and in the Change Workflow dialog box, I have the option of promoting a Medium project to a Large project. (Good)

image

There are probably still ways to get around this obstacle, but overall, it’s an easy and elegant method to make it harder for users to accidentally stumble upon process exceptions.

Creating a Secure Enterprise Project Type

Great Project Server Content from the Product Team

Probably worthwhile to point you over to Robert Hoover’s post yesterday on some of the great content released this summer….

http://blogs.technet.com/b/epmcontent/archive/2011/08/11/new-and-updated-content-for-summer-2011.aspx

Big thanks to the folks responsible.  Make sure to check out the Pivot Viewer if you haven’t already.

Great Project Server Content from the Product Team

Applying Security to a PDP Redux

A couple of weeks ago, I thought I’d figured out how to apply security to a PDP page and documented it in a post here.  Well, it turns out I was wrong.  A reader pointed out that she’d tried the same thing – which appeared to work fine when logged in as an Admin, but not as a PM.

That solution may still work in some limited scenarios – specifically where the role with the diminished permissions has the ability to review a project, but not edit or save it.  If the role with the diminished permissions needs to edit the project, then that solution will throw a “Value does not fall within the expected range” error on check-in.

Melodie also pointed out a better method to accomplish the same thing.  This blog post is intended to document that solution.  Thank you very much to Melodie for contributing to the community.

Essentially, we’re going to leverage the SharePoint personalization functionality.  This feature is turned on by default and allows each user to create their own personal view of a page.  In this case, we will need to log in as the user and create personalized views of the required PDPs.

Follow these steps to personalize the page:

1) Log in as the user.  You’ll probably need them to log you in and sit next to you while you do this.

2) Select the option to Personalize this Page from the menu in the top right.

image

3) Add Webparts to the page and configure appropriately.  Click on Stop Editing to, well, stop editing.

SNAGHTML43a267

And now this is what the page looks like for the administrator.

image

When logging in as someone else, this is what I see.

image

Still a bit hard to administer but not bad for specific scenarios.

Applying Security to a PDP Redux

Applying Security to a PDP

[UPDATE 5/8/11 – after some testing based on reader comments, it looks like there’s an issue with this implementation model.  Make sure to read the comments at the bottom before trying to implement.]

Still obsessing about PDPs and how I can extend them with little or no code.  In this episode, I decided to explore how to lock down a PDP.  The primary goal is to enable read only access to a PDP for select members of a security group.  This post represents my first attempt, to see if I could simply implement security on the page.  In an upcoming post, I’ll document how to emulate a read only PDP by embedding an InfoPath form to surface Project Server data.

Put the two techniques together and you might actually be able to deliver some interesting solutions:

  • Security trim PDPs so that they only show up for Group A and not Group B.
  • Create read only PDPs and make them show up for Group B and not Group A.

And presto, you kind of have field level security as long as the PM doesn’t figure out how to open the project in Microsoft Project Professional to change the fields.  Since many PMs are now working almost entirely in the browser, that might be good enough for some organizations.

So after some experimentation, here’s how to do it.  Navigate to the PDP library in Server Settings.  Click on Library Settings under the Library tab.

image

Mouse over the PDP, and click on the drop down option.  Select the link to Manage Permissions.

SNAGHTML2db6d1

Under the Edit tab, select the option to stop inheriting permissions.

image

Users may now be granted or denied permissions as required.

image

Note that as far as I can tell, even readers of the page will have edit rights within the Webpart (assuming they have permissions to edit the project itself).  Based on the permissions however, the page will appear (or not) in the links on the top left of the project page.

So that’s progress.  Coming up next….using InfoPath to render read only PDPs.

Applying Security to a PDP

Creating a My Projects View

With the expansion of Project Server 2010 to include enhanced capabilities in browser-based project creation, I have found many organizations hard pressed to manage the sheer numbers of projects that now appear in the Project Center view.

This post documents a quick and easy view that may be created within the Project Center view to filter projects on only those projects where the user is the owner, essentially creating a “My Projects” view.

This technique is based on two assumptions:

  1. Your organization, like many organizations, allows project managers to see all projects read-only – or at least all projects within specific parameters.
  2. Your organization is using a more or less default security model (whatever that means).  Let’s say that your security model isn’t too crazy and hopefully is compatible with this configuration.

Create the View

Navigate to the Manage View option within Server Settings.

image

Make a copy of the Project Center Summary View.  Note that I like to prefix any custom view with a “*” and the company name.  This allows me to easily identify the more commonly used views.

image

Take the view out of every category but the My Projects category.

image

Confirm Security Settings

For the next step, we’re going to review the My Projects security settings as applied to the Project Manager group.  Within Server Settings, navigate to the option to Manage Categories.

Click on the My Projects category. 

image

Note the default settings for the category.

image

Uncheck two of the boxes so the settings look like this.

image

Note that this may have some unintended consequences as the Team Members may be using that category to view projects to which they have been assigned.  If you believe that changing this security model may have a significant impact on your organization, simply copy the My Projects category in the beginning and then follow the same instructions.

The end result should be a filtered list of personal projects within the Project Center view.

Creating a My Projects View